Page History

1. Unzip the Artifactory distribution archive.
2. If you have not yet done so, perform a graceful shutdown of your currently running installation.

3. If the $ARTIFACTORY_HOME/tomcat/conf/server.xml has been modified keep it in a temporary location.  

4. Backup files to a temporary location according to the conditions described below:
   1. In all cases, backup $ARTIFACTORY_HOME/bin/artifactory.default
   2. If Artifactory is configured to work with a database that is not Derby, backup the $ARTIFACTORY_HOME/tomcat/lib/<JDBC> driver.  
5. Remove the following files and folders from your $ARTIFACTORY_HOME folder:
   

   • webapps/artifactory.war

   • webapps/access.war (this will only be present if your current version is 5.4.0 and above due to addition of the Access Service)

   • tomcat

   • bin

   • misc

6. Replace the removed files and folders with the corresponding ones from the new unzipped version.

7. Any files that were stored in temporary locations should now be returned to their original location under the new installation.

   Note
   title Running Artifactory as a ROOT application in Tomcat
   If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in Newtablink Text this Knowledge Base article URL https://www.jfrog.com/knowledge-base/how-do-i-setup-artifactory-to-run-as-the-root-application-in-tomcat/ .

   Note
   title Version-specific Special Instructions
   To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress. Upgrading to version 5.4.0 and above From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>): Code Block ... <Engine name="Catalina" defaultHost="localhost"> <Host name="localhost" appBase="webapps" startStopThreads="2"/> </Engine> ... Upgrading to version 5.6.1 and above In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below: Code Block <Connector port="8081" sendReasonPhrase="true"/> Upgrading to version 5.7.0 and above From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file Code Block <Connector port="8040" sendReasonPhrase="true" maxThreads="50"/> Upgrading to version 6.3 and above From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below: Code Block <Service name="Catalina"> <Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

8. If you installed Artifactory as a service, you now need to run the service

   1. For a Linux service, browse to $ARTIFACTORY_HOME/bin and execute the following command as root: $ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]

   2. For  Windows service, browse to %ARTIFACTORY_HOME%\bin. First uninstall the service by running uninstallService.bat, then reinstall the service by running installService.bat. You can now run the service through the Windows UI or as described in Running Artifactory.

1. Log in as root (or use sudo su -).
2. If you have not yet done so, perform a graceful shutdown of your currently running installation

3. Execute the following command:

   Code Block
   dpkg -i $jfrog-artifactory-<oss|pro>-6.y.z.deb

Managing Configuration Files

When upgrading a Debian installation the upgrade process overwrites the following set of configuration files:

• system.properties
• config.xml
• default
• logback.xml
• mimetypes.xml
• All files under opt/jfrog/artifactory/misc
• All files under opt/jfrog/artifactory/webapps

If any of these files were modified, a backed up file will be created automatically with a notification in the upgrade log. If you need to restore the configuration changes you can restore them from the backup created.

...
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" startStopThreads="2"/>
        </Engine>
...

<Connector port="8081" sendReasonPhrase="true"/>

<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/>

  <Service name="Catalina">
        <Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

To ensure that all of the data remains in Artifactory following the upgrade to Pro (assuming you are using the default DB), please follow these steps:

1. Perform a graceful shutdown of your currently running installation.
   
2. Perform a backup of $ARTIFACTORY_HOME/data folder.
   
   

3. Delete the OSS installation.

   Code Block
   apt-get remove jfrog-artifactory-oss)

4. Download and install the Pro package.

   Code Block
   dpkg -i $jfrog-artifactory-pro-<version>.deb)

5. Import the ‘data’ backup folder to the new installation location.

   Code Block
   $ARTIFACTORY_HOME/data

6. Start Artifactory.

   Code Block
   $ARTIFACTORY_HOME/data

In order to keep your data and configuration between versions, when upgrading the Artifactory Docker image, you need to use an external mounted volume as described under Managing Data Persistence.

To upgrade the Artifactory Docker image, follow these steps:

1. Stop the current container
2. Start a container with the new version using same data and configuration
3. Remove the old container

The example below shows this process for upgrading Artifactory from v5.0.0 to v5.1.0.

$ # Stop the currently running container
$ docker stop artifactory-5.0.0
 
$ # Start a new container from the new version image
$ docker run -d --name artifactory-5.1.0 --volumes-from=artifactory-5.0.0 -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:5.1.0
 
$ # Remove old container
$ docker rm artifactory-5.0.0

Once these commands have completed successfully, you would have the new version (5.1.0 in the above example) running with the data and configuration from the old version that was removed.

...
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" startStopThreads="2"/>
        </Engine>
...

<Connector port="8081" sendReasonPhrase="true"/>

<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/>

 <Service name="Catalina">
        <Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

1. Download the Artifactory Pro RPM Installer. The latest version can be downloaded from the

   Newtablink
   Text JFrog Artifactory Pro Download Page URL https://bintray.com/jfrog/product/artifactory/download

   . Previous versions can be downloaded from

   Newtablink
   Text JFrog Bintray URL https://jfrog.bintray.com/artifactory-pro-rpms/org/artifactory/pro/rpm/

   .
2. Log in as root (or use sudo su -).
3. If you have not yet done so, perform a graceful shutdown of your currently running installation

4. Execute the following command:

   Code Block
   rpm -U jfrog-artifactory-pro-6.y.z.rpm

   Note
   title Switching from Artifactory OSS to Pro
   If you are just switching from Artifactory with the same version number, you need to append the command with --force --nodeps as follows: rpm -U jfrog-artifactory-pro-6.y.z.rpm --force --nodeps

During an upgrade of an RPM installation different files may get backed up, where the backup file is appended with either a .rpmorig or a .rpmnew extension. 

A .rpmorig extension means that the original file in your installation, the one that was there before performing the upgrade, was backed up before being replaced in the upgrade process.

A .rpmnew extension means that the original file in your installation, was not replaced in the upgrade, and instead, the new file with the same filename was backed up.

In either case, Artifactory will display a message such as:

warning: /etc/opt/jfrog/artifactory/default saved as /etc/opt/jfrog/artifactory/default.rpmorig

In these cases we recommend comparing the file installed once the upgrade has been completed with the backed-up file to see which best fits your needs, and using that one in the final setup.

If you make any changes, you may need to restart Artifactory for the change to be applied.

Upgrading Using YUM

An easy way to upgrade Artifactory from version 3.x  or 4.x to the latest version is to use YUM with the Bintray Artifactory repository. The code snippets below show how to do this depending on whether your current version is below 3.6, or 3.6 and above.

curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum install jfrog-artifactory-pro-6.y.z

yum install jfrog-artifactory-pro

curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpms.repo && sudo mv bintray-jfrog-artifactory-pro-rpms.repo /etc/yum.repos.d
yum upgrade artifactory 
yum install jfrog-artifactory-pro-6.y.z

yum install jfrog-artifactory-pro

...
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" startStopThreads="2"/>
        </Engine>
...

<Connector port="8081" sendReasonPhrase="true"/>

<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/>

 <Service name="Catalina">
        <Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>

If you have configured Artifactory to run as the ROOT application in Tomcat, before you proceed, you need to follow the steps described in

To accommodate internal changes in Artifactory in different version upgrades, you need to perform or ensure certain changes to Artifactory's server.xml according to your target upgrade version. Note that the changes listed below are cumulative as the versions progress.

Upgrading  to version 5.4.0 and above

From version 5.4.0, Artifactory's management of Access Tokens was moved to a separate service, JFrog Access, installed as a separate web application under the same Tomcat as Artifactory. This requires your Tomcat's server.xml to be configured to allow running 2 processes. If you are using a server.xml file from a previous installation, when returning it, make sure it is configured to allow 2 start/stop threads as shown below (see <Host name="localhost" appBase="webapps" startStopThreads="2"/>):

...
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" startStopThreads="2"/>
        </Engine>
...

Upgrading to version 5.6.1 and above

In version 5.6.1, the version of the Tomcat embedded in Artifactory was upgraded. To accommodate YUM clients following this upgrade, a new attribute, sendReasonPhrase was added for each Tomcat connector in the server.xml file as shown in the example below:

<Connector port="8081" sendReasonPhrase="true"/>

Upgrading to version 5.7.0 and above

From version 5.7.0, Artifactory routes requests to its Access service directly through a port, and this requires the following modification to the server.xml file

<Connector port="8040" sendReasonPhrase="true" maxThreads="50"/>

Upgrading from version 6.3 and above

From version 6.3, the version of the Tomcat embedded in Artifactory was upgraded. To accomodate special characters following this upgrade, the following new attributes, relaxedPathChars='[]' relaxedQueryChars='[]' were added for each Tomcat connector in the server.xml as shown in the example below:

<Service name="Catalina">
        <Connector port="8081" sendReasonPhrase="true" relaxedPathChars='[]' relaxedQueryChars='[]'/>