[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#883611:



Hi Paul,

Thanks for following up on this. To address your points:

1) The point raised in the ITP about stopping critical applications cleanly is an example scenario. The idea being that you have the ability to run any custom script at each of those phases. Other examples may include:
  - Backing up config files before applying updates
  - making an API call to a monitoring system to put the server in maintenance mode 
  - adjust a status file which is used to keep the server in a loadbalance pool
  - possibly creating lvm snapshots before applying updates
  - capture current system statistics and states metrics which can then be compared post updates ie: listening ports before updates are applied and after the patching process has completed (Including post-reboot)
The possibilities with these pre and post scripts are endless and have the potential to be extremely useful especially with tasks that you may not want or need to write a specific custom systemd file or init script. In addition tho this, the script hooks are not only for the reboot phase but also for the download and apply phases. 

2) While it is possible to separate the download and install schedules in unattended-upgrades, it becomes a bit more of a task to work around an automatic version controlled setup. For example, you want a test environment to install updates in the first week of the month but the production environment should only be updated in the third week. With unattended upgrades, the latest packages will be downloaded and installed which may not have been the packages that were tested. With auter, you can set all environments to download patches at the same time and only install those specific downloaded packages at the required schedule. 

3) While unattended-upgrades can also schedule automatic reboots, the huge advantage here is being able to run pre and post reboot scripts which are specific to the patching process as discussed in point 1

4) The separate patching profiles is one of the specific request we had when building this tool. 

5) I am sure there are many use cases where system administrators are maintaining environments  with multiple Linux distributions and having a tool which can be configured in the same way regardless of distribution is a huge advantage. 

Thanks
Paolo


On Wed, Dec 6, 2017 at 11:51 AM, Paul Wise <pabs@debian.org> wrote:
On Wed, Dec 6, 2017 at 6:12 PM, Paolo Gigante wrote:

> As per the ITP (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880600)
> there is a lot of additional functionality that auter provides which goes
> way beyond what is offered by cron-apt and unattended-upgrades:

A comment on the ITP features:

> This allows servers to be configured to stop any critical
> applications cleanly using custom scripts before any actions are taken.

Critical applications should be cleanly integrated with the system so
that normal shutdown/reboot does the right thing.

> - Auter has the functionality to separate download schedules from install
> schedules which is great for organisations wanting to version control
> updates across multiple servers and environments while staggering the update
> process for the servers.

This is also supported by unattended-upgrades under systemd.

> - It also allows for customised scripts to be executed pre and post
> downloading updates, applying updates and rebooting the server

This is also supported by apt, except reboot hooks but those should
probably be integrated into the init system instead.

> - It has the option to automate reboots after the patching process has been
> applied

This is also supported by unattended-upgrades, including a set reboot time.

> - There is an option of setting up multiple patching profiles eg: weekly
> application patches and monthly system/kernel patching (This is entirely
> customiseable)

In theory this could be possible with unattended-upgrades but I think
it would be hard to setup.

> - In cases where admins have multiple servers with different rehdat or
> debian based distributions, the same application and configuration files can
> be deployed to servers regardless of the distribution.

That seems like a plus for those stuck in that situation indeed.

--
bye,
pabs

https://wiki.debian.org/PaulWise


Reply to: