On Mon, Jul 31, 2017 at 6:12 AM, Nick Couchman <[email protected]> wrote: > I would do them in this order: > 1) guacd > 2) Postgres > 3) WAR/Extensions > > guacd should be completely backward-compatible, so you shouldn't have any > problem using older Guacamole client with newer guacd (in general). > Updating the Postgres DB schema before upgrading the WAR and extensions also > should not cause any problems. >
There have been cases where the schema has changed in such a way that the older version of the webapp would fail to execute certain queries. In general, the above will likely work, but as upgrading guacd necessitates restarting guacd (which will kick off all active connections), and upgrading the webapp requires restarting Tomcat (which will log off all users), I'm not sure it makes any sense to try to keep things running during the upgrade. For any upgrade, I'd recommend the following as good practice: * Schedule the upgrade during a maintenance window when you can stop/restart Guacamole-related services with minimal impact. * Backup your database, so you can safely revert if things do not go as planned. As for the process itself: 1) Stop the Tomcat and guacd services. 2) Install the latest version of the webapp and guacd, overwriting what is currently installed. 3) Apply the database upgrade script, if provided with the release. 4) Start the Tomcat and guacd services. 5) Do a quick run through and make sure things work. With the services stopped, the process is predictable and order of upgrade does not matter. If you are going for absolutely zero downtime, the safe method would be to serve Guacamole through a reverse proxy, clone the Guacamole server, perform the upgrade on the clone only, and then switch the reverse proxy to point to the new server once it's confirmed working. Active users will still be logged out and disconnected, but the service itself remains continuously available. - Mike
