Skip to Content

Upgrade or uninstall a Linux Jitterbit private agent

Introduction

Upgrading a private agent from an earlier private agent version to a later one can be done without uninstalling the prior agent version, as described in Upgrade an agent below. However, there are additional considerations when upgrading from a 10.x to an 11.x Linux private agent.

Rolling back an agent and uninstalling an agent are also covered on this page.

Upgrade an agent

Upgrading a private agent on Linux can be performed by using the same commands used during initial installation. You do not need to run the configuration script when upgrading an existing private agent.

For more information, see Debian or RPM instructions for installing a private agent.

Important

All configuration files are retained during a private agent upgrade, but the directory /opt/jitterbit/jre is removed and replaced with a new copy. If you have added certificates to the keystore file (/opt/jitterbit/jre/lib/security/cacerts), copy it to a safe location outside of /opt/jitterbit, and restore it after upgrading.

The following subsections provide instructions for minor upgrades and major upgrades, along with recommendations for large deployments.

Minor upgrade

Minor upgrades from the same major version (that is, 10.x to 10.x, or 11.x to 11.x) take only a few minutes to complete.

If you have added certificates to the keystore file (/opt/jitterbit/jre/lib/security/cacerts), restore it from your backup copy, then restart the agent.

Major upgrade from 10.x to 11.x

Linux private agents can be upgraded to 11.x from any supported 10.x agent version without any additional commands. A PostgreSQL database upgrade and PostgreSQL ODBC driver upgrade will be completed automatically when the agent is upgraded, provided the PostgreSQL requirements are met.

On upgrading to an 11.x version of the agent, the following will occur:

  • The PostgreSQL ODBC driver will be upgraded to PostgreSQL ODBC 13.2.0.0.

  • A full sync of environments will occur. During a full sync, all projects and metadata in each environment are re-downloaded from the Harmony cloud to populate the PostgreSQL database.

    Caution

    The length of time it takes to perform a full sync depends on the number and complexity of projects in each environment. For typical environment usage, a full sync typically takes up to 10 minutes to complete. However, environments with a very large number of projects may take several hours to sync. If having an outage is a concern, see the recommendations for large deployments below.

  • The scheduler has a delayed startup of 10 minutes, as indicated in Scheduler.log. During this time, scheduled operations will not be triggered to run. Once the delay is complete, scheduled operations that would have been triggered to run during the delay will be triggered to run.

Upgrade recommendations for large deployments

If having an outage is a concern during an agent upgrade, we recommend using high availability (two or more agents) so that requests are routed to another available agent in the agent group. If your current subscription does not have agent grouping, contact your Customer Success Manager (CSM).

When a full sync is expected to occur, such as when upgrading from a 10.x to an 11.x agent version, we recommend a rolling upgrade approach, where you install new agents in standby mode one at a time in an existing agent group prior to decommissioning existing agents. This approach provides a clean rollback path should the need arise.

Starting agents in standby mode involves adding a setting to an agent's properties file (jitterbit-agent-config.properties) to make sure the agent stays out of commission and will not start to accumulate a backlog of requests before the full sync is complete.

To implement a rolling upgrade approach:

  1. Install a new agent in an existing agent group following the Debian or RPM instructions for installing a Linux private agent.

  2. In the new agent's jitterbit-agent-config.properties file, add the agent.starting.standby property set to true to force the agent to stay in Starting agent status and prevent it from entering a Running state where it can accept requests.

  3. Restart the agent.

  4. As the agent starts up, you can monitor the sync status in the agent's jitterbit-agent.log file, looking for lines similar to those below that indicate when syncing started and completed:

    Agent synchronization for environment <123456> and agent group ID <987654> started at ...
. . .
Agent synchronization for environment <123456> and agent group ID <987654> completed at ...

  5. Once logs indicate the sync is complete, remove the agent.starting.standby property or change its value to false and restart the agent.

  6. When the new agent reports Running status, decommission a former agent in the agent group.

  7. Repeat this process for each agent in the agent group to ensure that requests continue to be routed to a capable agent during the upgrade process.

Roll back an agent

It is not expected to be required to revert to a previous version of a private agent. However, should it be required, these are the steps:

  1. Back up the configuration files and security certificates for reference (optional; see Uninstall agent below).
  2. Uninstall the agent (see Uninstall agent below).
  3. Remove all Jitterbit-related files (see Uninstall agent below).
  4. Install the selected version of the agent. See Install a Linux agent (Debian or RPM).

  5. To use your backup files (optional):

    1. Stop agent services (see Restart a Linux private agent).

    2. Place your saved security certificates in the installation directory. Manually update the newly installed configuration files based on the settings in your saved files.

      Warning

      Directly copying over saved configuration files after an agent version change can cause errors. Instead, use tools like the Notepad++ Compare plugin to help you manually compare and update configuration settings. Do not change settings with defined passwords or ports such as those found in the credentials.txt file and under the [DbInfo] section of the jitterbit.conf file.

    3. Start agent services (see Restart a Linux private agent).

Uninstall an agent

Before uninstalling, it is recommended to save the configuration files and security certificates for your current installation for referential purposes. These are typically located at:

Files
/opt/jitterbit/jitterbit.conf
/opt/jitterbit/apache/conf/httpd.conf
/opt/jitterbit/JdbcDrivers.conf
/opt/jitterbit/Resources/jitterbit-agent-config.properties
/opt/jitterbit/Resources/credentials.txt
Directories
/opt/jitterbit/apache/conf/extra/
/opt/jitterbit/apache/conf/ssl.crt/
/opt/jitterbit/apache/conf/ssl.key/

Caution

To be able to use your backup files in a future installation, you must stop services while you move the files over, then restart services once completed (see Restart a Linux private agent).

Warning

Directly copying over saved configuration files after an agent version change can cause errors. Instead, use tools like the Notepad++ Compare plugin to help you manually compare and update configuration settings. Do not change settings with defined passwords or ports such as those found in the credentials.txt file and under the [DbInfo] section of the jitterbit.conf file.

Use this command to uninstall the Jitterbit private agent:

$ sudo apt-get remove jitterbit-agent

Use this command to uninstall the Jitterbit private agent:

$ yum remove jitterbit-agent

You can also use this rpm command to uninstall the Jitterbit private agent:

$ rpm --erase jitterbit-agent

The uninstall will remove the files installed during the installation. The /opt/jitterbit directory and Jitterbit private agent database are not automatically erased, and may include log files and application files generated when running operations. To completely remove all Jitterbit-related files, use these two commands:

$ sudo rm -rf /opt/jitterbit
$ sudo rm -rf /tmp/jitterbit