Installing updates and releases on a Smoothwall is fairly simple, but as with all live systems, sometimes you need to take a bit of extra care. Update procedures vary slightly depending on if the Smoothwall is in a single-unit deployment, part of a cluster, or has a failover unit for high availability attached.
Updates and releases - what's the difference?
A new release is when a major new feature and/or rework of existing features have been performed. Releases are named after famous castles like Hearst, Inverness, Leeds etc. They are released in alphabetical order. The most recent release is Maiden, following on from Leeds.
An update is a smaller package which contains bug fixes and security updates. Updates are specific to a release version, so you will see Leeds updates to signify the update level of a release. At the time of writing, the latest release and update version is Leeds 12. Leeds is the release. 12 is the update level.
When a new release or update is available, always read the description first - this contains a list of the changes in the update or release. Next to the installation button for releases and updates, you will find a "Details" button. Click on this to get a description of what the release or update contains. Always read this, as the description may contain specific update note about changes in functionality, addition or removal of features, or groundwork changes for future features.
When an update or a release in installed, the Smoothwall system will take a snapshot of the current system before applying the update or release. If there are any issues after updating to the latest version, reverting to your previous version is always possible in the "System > Maintenance > System Restore" section. A manual snapshot can also be created here. This can be useful if you are looking at a major reconfiguration and would like to be able to revert, in case anything goes wrong.
Whenever multiple updates and releases are available on a system that has not been updated in a while, it is possible to update to the latest release immediately. You do not need to first apply updates for the current release and then apply each release version in turn.
Updates can be scheduled to be installed automatically when they become available. Releases can not be scheduled. Releases could change the way features work, so it's important to read the description and resolve any questions that may arise from the description, before applying new releases.
Updating a single system.
Read the detailed description, which also gets shown when you click the 'Install' button. Once you have read the description, determine if now is the right time to install the update/release. Once the installation has begun, it cannot be stopped and a reboot will be initiated once the update or release have been installed. This will happen automatically once the system is ready - the reboot time cannot be set. Once the reboot has completed, the Smoothwall system will have been updated to the latest release and update level.
Updating a hardware failover setup.
Updating both systems in a hardware failover setup needs to follow a specific sequence, as the failover system needs to be updated before the master. When an update or a release is installed, it's a good idea to perform a failover test as well. Follow this sequence in order to apply updates and perform a failover test.
To update a HA pair, with the Failover unit being updated first:
- Log in to the Smoothwall Web UI on HTTP port 81 or HTTPS port 441 - this will log you in to the active unit.
- Navigate to System > Central Management > Overview. The Failover Node will be listed with a notification that updates are available.
- Mark the Failover unit on the right of the table and click the 'Schedule Update' button. In the following page, either set a scheduled time for the update to take place, or else select 'Now' and click the 'Schedule Update' button again. If 'Now' was selected, the Failover unit will update itself there and then, using the Primary unit as a proxy. Otherwise, the Failover unit will update itself as per the time set.
- Return to the Central management Overview page - the Failover unit will become available again once it has updated and rebooted, and the status will be set to 'OK' with a green tick mark if all is well.
- Navigate to System > Maintenance > Updates and Releases - you may now update the Primary node either immediately or on a schedule, as you require.
NOTE: Updating the Primary typically incur enough 'dead time' for the Failover unit to go live - this is is typically fine. Before updating, you may wish to check under System > Hardware > Failover if 'Auto Failback' is enabled.
- If Auto Failback is enabled, the Failover will go back to standby once the Primary comes back up from its reboot.
- If Auto Failback is not enabled, you will need to manually set the Failover unit to standby with the 'Enter Standby Mode' button once the Primary unit has rebooted and entered Standby itself. You can check the status of the Primary under System > Central Management > Overview.
Updating a cluster setup.
When systems that are part of a central management cluster needs to be updated, it's important to update the children first and the parent last. Newer versions will be able to understand older configuration files, but the reverse is not always the case - that's why it's important to update children first.
If it is not possible to update a child due to it being offline or other causes and the parent needs to be updated, disable replication to this child from the parent, until the child is ready and updated.
Updates to child nodes can be scheduled from the Parent node under System > Central Management > Overview as per the instructions for Failover units.
Updating a load-balanced Cluster.
The same method applies for a cluster of Smoothwalls sitting behind a Loadbalancer as it does for a decentralized cluster - Child Nodes must be updated first before the Parent, with one small additional detail.
Child Nodes in a load-balanced cluster must be drained and removed from the Loadbalancer pool before being updated. Following the update, the child node should be checked that all services are up and ready, and you may wish to proxy some traffic directly over the updated child node where possible as a direct function check before reintroducing it back into the pool and allowing connections.
Unless the description in the update/release specifies otherwise, following the recommendations above should ensure a smooth upgrade to the latest version of your Smoothwall system.