You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 13, 2025. It is now read-only.
This issue is being imported from our ticketing system to better centralize all feature requests and bug reports.
A couple of users were bitten by out-of-sync cluster versions when we updated to Exim 4.97.1. Specifically, slave nodes were able to update, but the master was not. The result of this was that new quarantined items from the slave were indexed in the master with a truncated ID and the Web Interface was unable to show and release messages with the longer IDs.
We should re-work Updater4MC to only ever update the slaves if the master has been updated successfully. This is somewhat difficult to coordinate, because the updates run at the same time. If we have the slave simply check the version of the master, they will always end up updating 1 day late because the version will not have changed by the time they check.
The alternative is to have the master be responsible for executing the update on the slaves when it finishes. Having this happen within the Updater4MC script is messy because it would be run similar to command_to_cluster.sh which would serialize the updates and would be quite likely to cause the overall updates to timeout.
The better way to do this would be to have an API request to run the Updater4MC script. This could potentially allow for us to add a GUI button to install updates outside of the nightly update cycle also.
This issue is being imported from our ticketing system to better centralize all feature requests and bug reports.
A couple of users were bitten by out-of-sync cluster versions when we updated to Exim 4.97.1. Specifically, slave nodes were able to update, but the master was not. The result of this was that new quarantined items from the slave were indexed in the master with a truncated ID and the Web Interface was unable to show and release messages with the longer IDs.
We should re-work Updater4MC to only ever update the slaves if the master has been updated successfully. This is somewhat difficult to coordinate, because the updates run at the same time. If we have the slave simply check the version of the master, they will always end up updating 1 day late because the version will not have changed by the time they check.
The alternative is to have the master be responsible for executing the update on the slaves when it finishes. Having this happen within the Updater4MC script is messy because it would be run similar to command_to_cluster.sh which would serialize the updates and would be quite likely to cause the overall updates to timeout.
The better way to do this would be to have an API request to run the Updater4MC script. This could potentially allow for us to add a GUI button to install updates outside of the nightly update cycle also.