autostructure / artifactory Goto Github PK

When I change the artifactory version, the module can't install the new version, because it hasn't updated its yum cache, so a yum clean all prior to installing the new version would be great.

Hi, I´m trying to use this module, but a have an upset error, the execution of the wget wrapper, are you sure about the correcto operation of the puppet's URL like:
puppet:///modules/my_resources/artifactory/mysql-connector-java-5.1.40-bin.jar

the logs of the puppet execution seems good...
Info: Using configured environment 'development' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Info: Caching catalog for artifactory-dev-1.4iq.vm Info: Applying configuration version '1480961869' Notice: /Stage[main]/Artifactory::Config/Wget::Fetch[puppet://modules/resources_4iq/artifactory/mysql-connector-java-5.1.40-bin.jar]/Exec[wget-puppet://modules/resources_4iq/artifactory/mysql-connector-java-5.1.40-bin.jar]/returns: executed successfully Info: Class[Artifactory::Config]: Scheduling refresh of Class[Artifactory::Service] Info: Class[Artifactory::Service]: Scheduling refresh of Service[artifactory] Notice: /Stage[main]/Artifactory::Service/Service[artifactory]: Triggered 'refresh' from 1 events Notice: Applied catalog in 8.31 seconds
but the file size is 0

https://github.com/autostructure/artifactory/blob/master/manifests/init.pp#L51-L53

Putting this outside of the if statement probably installs java anyway, right?

We've just deployed artifactory-pro (5.9.1) using this puppet module and run into the issue described below.

Do you know of any solutions to this problem? Or better workarounds than what we've got (also described below)?

Details

When artifactory launches, it reads db.properties and, if it finds that the db password is not encrypted, modifies that file to encrypt the password.

For example,

password=foobar

is turned into something like

password=JEW9gKVqXK66PJVWVD...

The problem is that the next time puppet runs it identifies that db.properties has changed and reverts the change to restore password back to its unencrypted form. It also restarts the artifactory service, and the cycle begins again.

Versions

Puppet version: 4.10.8
artifactory module version: 2.0.13
artifactory version: 5.9.1

Workaround

We've worked around this by not setting any db_* parameters in the artifactory class, which means puppet does not manage db.properties. We have to instead edit this file by hand, which is quite undesirable.

In 2.1.0 Puppet creates the etc/.secrets/.temp.db.properties file. Which triggers Artifactory service refresh, which Artifactory reads then deletes...next puppet run, etc/.secrets/.temp.db.properties files does not exist so puppet creates it and refreshes service causing restart.

Additionally if service is stopped and started by human etc/.secrets/.temp.db.properties does not exist, so etc/db.properties file is created if it does not exist and is configured to use Derby database.

Using 2.0.14 version of config.pp, can set db parameters and puppet will create etc/db.properties, then can unset parameters leaving db.properties unmanaged, and Artifactory can reset encrypted password as it pleases.

Artifactory Version: 6.10.3

Error: Evaluation Error: Error while evaluating a Function Call, Could not find template 'artifactory/storage.properties.epp' at /etc/puppetlabs/code/environments/production/modules/artifactory_ha/manifests/config.pp:51:16 on node