join.key file not created or deleted on upgrade to 6.8.x Artifactory Pro

1
votes

I am using Artifactory Pro, and recently upgraded (from 6.6.5) to 6.8.6.

When the server comes up it shows messages like these:

(o.a.w.s.ArtifactoryContextConfigListener:96) - Application could not be initialized: Timed out waiting for join.key file to be made available at /var/opt/jfrog/artifactory/etc/security/join.key (o.a.w.s.ArtifactoryFilter:194) - Artifactory failed to initialize: Context is null

I've searched and found docs like: https://www.jfrog.com/confluence/display/ACC/Join.key+-+Creating+Trust+between+Services

Which say I can create my own 128 bit AES key (which I did with openssl) but then the server deletes on on bootstrap with messages like could not be read or validated. I see error messages like:

2019-03-12 22:49:15,670 [art-init] [INFO ] (o.j.a.c.AccessClientBootstrap:70) - creating access token with join key 2019-03-12 22:49:15,790 [art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:96) - Application could not be initialized: Couldn't grant a token, response code: 400, body: {
"errors" : [ { "code" : "BAD_REQUEST", "message" : "Could not Verify the jwt sha: 30f20af6bed379ee249ce6d5e536596c8d087f7d08ff907b6515e289d909c2f5" } ] }

I'm curently looking at an artifactory page which says :

{ "errors" : [ { "status" : 500, "message" : "Artifactory failed to initialize: check Artifactory logs for errors." } ] }

I'm using the downloaded rpm method "rpm -U jfrog-artifactory-pro-6.8.6.rpm" to install.

I've tried downgrading to 6.8.2, I've tried downgrading to 6.6.8 then upgrading back to 6.8.6. BTW downgrading to 6.6.8 I end up with a 404.

How can I get a join.key file that works, or turn off the functionality that requires it ?

6
artifactory
How are you starting the Artifactory server? What script are you executing? - Ortsigat
Using the default service: /bin/systemctl start artifactory.service - Benjamin
subsequent to this inquiry I also tried starting artifactory with the artifactory.sh command and it did not work. In addition the systemd service (called indirectly/directly with both "service" and "systemctl" commands) both call artifactoryManage.sh, from a unix side I think I've run out of commands to try, but I'm open to anything you have to offer. - Benjamin
Couple of things: 1. the join.key is automatically distributed from Access to Artifactory. From the error message it seems like you're only distributing the key to Artifactory, which means Access and Artifactory have different keys (Access will use a generated one) 2. I would try to revert back to a clean install of 6.8.6 and start it without providing a join.key. just to make sure it is not permission related on your env. 3. Check the $ACCESS_HOME/logs/access.log for error message - Ortsigat

6 Answers

3
votes

I was also upgrading artifactory from 6.6.5 to 6.8.7 and got the same issue as OP, but in my case setup is with custom tomcat and own init.d service file. In logs of Artifactory Access app I noticed following line:

[WARN ] (o.j.a.s.s.JoinKeyDistributer:73) - There are no Paths to distribute the Join Key to

and after reviewing built-in script artifactoryManage.sh found that Artifactory introduces new java startup parameter - jfrog.join.key.paths

Below is quote from artifactoryManage.sh

JOIN_PATHS=$ARTIFACTORY_HOME
    if runMetadata;then
       export JFROG_MDS_HOME="$ARTIFACTORY_HOME/metadata"
       export JOIN_PATHS=$JOIN_PATHS:$JFROG_MDS_HOME
    fi

JAVA_OPTIONS="$JAVA_OPTIONS -Djfrog.join.key.paths=$JOIN_PATHS"

As soon as I add it to my init.d service script key was properly and automatically generated.

2
votes

This solution provided by JFROG worked for us

  • stop Artifactory & Tomcat
  • delete any key under etc/security/join.key if any
    export JFROG_JOIN_KEY=abcdef1234567890abcdef1234567890

start artifactory using this specific command 

   systemctl start artifactory

Setting the key (which shouldn't be the key above) in the environement variable and starting worked successfully.

1
votes

I encountered this problem on a clean install of Artifactory 6.10.2 on an Amazon Linux EC2 instance. Since I use the Amazon Linux tomcat-8.5 package, I can't use the normal artifactory install scripts, there are a few extra steps required in order to avoid the following exception. The trick is to create the appropriate keys at the right time during the initialization of the access and artifactory instance. I had a lot of failed attempts before I found this combination of steps, which works reliably for me and allows a new instance to be created cleanly.

Note: This only applies to a clean install, not to upgrades.

java.lang.IllegalStateException: Timed out waiting for join.key file to be made available at /usr/share/artifactory/etc/security/join.key

The process I used was:

# Upload the access.war and artifactory.war via the Tomcat Manager webapp.
# As soon as these are uploaded, stop tomcat and delete the automatically-created artifactory folder.

# Create artifactory folder.
mkdir /usr/share/artifactory
chown tomcat.tomcat /usr/share/artifactory
cd /usr/share/artifactory

# Start tomcat.
service tomcat8 start

# Monitor the etc/security folder repeatedly until it has been automatically created by the artifactory webapp (a few seconds):
ls etc/security
ls etc/security
ls etc/security

# Create a new master key for artifactory:
openssl rand -hex 16 > etc/security/master.key
chown tomcat.tomcat etc/security/master.key
chmod 600 etc/security/master.key

# Monitor the access/etc/keys folder repeatedly until it has been automatically created by the access webapp  (about 20 seconds):
ls access/etc/keys
ls access/etc/keys
ls access/etc/keys

# Create a new join key for access:
openssl rand -hex 16 > access/etc/keys/join.key
chown tomcat.tomcat access/etc/keys/join.key
chmod 600 access/etc/keys/join.key
cp -a access/etc/keys/join.key etc/security/join.key

# Check the logs to confirm artifactory was able to connect to the access server:
tail logs/artifactory.log

2019-06-03 15:47:51,644 [art-init] [INFO ] (o.a.w.s.ArtifactoryContextConfigListener:215) -
###########################################################
### Artifactory successfully started (53.527 seconds)   ###
###########################################################
0
votes

The join key concept is introduced in version 6.8 previous to that the authentication was done by a key called master.key which was generated along with the DB component. Since you are migrating the DB won't be able to access artifactory service as the old key is registered with them. Can you try one thing

  1. Create a new DB for the same using the db.properties file
  2. Reconfigure artifactory --> see if it up or not --> If it is up then the issue is with the key authentication so you have to use the existing key instead of the new one as it is a migration.

Also I believe in all migrations we don't change the authentication mechanism

0
votes

I faced this erro migrating to 6.12.2

Found a simple solution for my case.

  1. Creating the join.key file manually (instructions);

Create an AES-128 bit key and paste it in a file.

Save the file as join.key.

Copy the file to the following location on Access.

$ACCESS_HOME/etc/keys/join.key

cat > $ACCESS_HOME/etc/keys/join.key
chown tomcat.tomcat $ACCESS_HOME/etc/keys/join.key
chmod 640 $ACCESS_HOME/etc/keys/join.key

  1. Copied the key file to access and artifactory as the root of the issue was access not being able to distribute the key.

    cp $ACCESS_HOME/etc/keys/join.key $ARTIFACTORY_HOME/etc/security/join.key

*Ideally the distribution path should be configured, but if you need to restart the services fast, you can go for the manual procedure and fix the properties after.

0
votes

This thread is a bit old, but thought users running Artifactory on Windows might benefit from our experience working through this issue.

We recently ran into this same issue upgrading a 5.x OSS instance to 6.10 on Windows Server. The solution was simply to uninstall and reinstall the Artifactory windows service. The application configuration captured during the original service install was out of date. This was the root cause of the "there are no Paths to distribute the Join Key to" error. We have seen this issue before with other Tomcat applications.