Glyptodon produces new minor releases of Glyptodon Enterprise (1.1, 1.2, 1.3, etc.) roughly every 3 months following the first general availability release. Minor releases are updates to an existing major release which add new features and fix bugs, and will always maintain strict API compatibility. The details of upcoming and past releases can be found in the changelog.

Major releases (the only releases which may break API compatibility) are intentionally isolated from each other such that each major release uses a different base URL within its .repo file. Updates to an existing install of Glyptodon Enterprise are always minor releases and will not break compatibility.

Checking for updates to Glyptodon Enterprise

To check whether updates are available for Glyptodon Enterprise packages without actually applying those updates, you can use the yum list updates command. Providing the "glyptodon-*" pattern to yum list updates restricts the packages checked to only those packages provided by Glyptodon Enterprise:

sudo yum list updates "glyptodon-*"

If the above command lists one or more packages, then there are newer versions of Glyptodon Enterprise packages available, and you should proceed with upgrading when a maintenance window permits.

Performing the upgrade

Updates to Glyptodon Enterprise are brief and can be expected to take only a few minutes, however the update process should be planned for a time that the service can safely be taken down, ideally a scheduled maintenance window. This is because the upgrade procedure generally requires that both Tomcat and guacd are restarted.

Stop Tomcat and guacd services

Before upgrading the Glyptodon Enterprise packages, both Tomcat and guacd should be taken offline:

sudo systemctl stop tomcat guacd

This is because:

  • If both the Guacamole web application and one of its extensions are being updated, the package manager may update the web application first. The running Tomcat service may then redeploy and restart the web application before the extension is updated, resulting in inconsistency.
  • If protocol support for guacd is being updated, older versions of that support may be cached by the system linker until the guacd service has been restarted.
  • If the guacd service is being updated, those updates cannot take effect until the guacd service is restarted. The running process will continue to use the older, cached binary.

The system should remain stable if the upgrade is performed without stopping Tomcat and guacd, however it is best practice to do so. An upgrade to the web application will always result in the web application being restarted, and any updates being applied will likely not take effect until after services are restarted. With updates to the web application inherently causing a service restart, and updates in general requiring a service restart in order to take effect, it's best to plan this restart as a controlled part of the process.

Apply updates using yum

Once Tomcat and guacd are stopped, the Glyptodon Enterprise packages can be upgraded using the yum utility, just like the other packages in the system. The upgrade can be restricted to only Glyptodon Enterprise packages by specifying the "glyptodon-*" pattern:

sudo yum upgrade "glyptodon-*"

Start the Tomcat and guacd services

After yum upgrade completes, the system has been updated and it is safe to start Tomcat and guacd back up:

sudo systemctl start tomcat guacd

That's it! Your Glyptodon Enterprise deployment is now up-to-date. A full list of all changes in the latest release can be found in the changelog.