There is a premise that "the settings are always slightly different". For example, even if you have 1000 units, if you have the same configuration, the number of update packages will be the same and you should have a distribution server, so you should not need such a tool. It doesn't have much of a sledge with the much talked about Docker infrastructure, and it has nothing to do with the temporary launch of vagrant.
I have about 5 environments by myself, but I use it when Debian / Ubuntu / CentOS are different.
I simply couldn't think of software that manages such checks across OSs.
https://github.com/dmiyakawa/check_linux_updates
This is an implementation that goes to see updates for each host via Fabric (ssh). By default, it goes to check in parallel.
Example(The snip part was actually equivalent to the FQDN):
$ check_updates.py
hansode.(snip) : 0(0) (REBOOT-REQUIRED)
gobusode.(snip) : 40(0)
shichibusode.(snip): 1(0)
mowa-net.jp : 3(2)
centos64.(snip) : 2(?) (REBOOT_REQUIRED)
gobusode is Debian sid. It will be like this as soon as it is left unattended. However, a little more important is mowa-net.jp, which has two security updates (in parentheses), so this should be updated. Of course Debian has a mechanism to automatically apply security updates, so this is a punishment for not using it.
$ check_updates.py --upgrade mowa-net
Will be upgraded. In this case, it will be executed serially on one host, so it is okay to ask for the password.
I have changed the host name in various ways, but it generally works like that. It can be mixed with CentOS (eg centos64 above), but I'm skipping the implementation and haven't seen any security updates on CentOS. So it is "?". (I see it with the tools described later. That)
The implementation on my side around Paramiko (ssh connection) is too appropriate, and when running in parallel, if you do not enter with public key authentication, it will fail at the password prompt. sudo I still die at the password prompt when I need it.
You can set a group such as "My own server group". The following example walks through the hosts in the mine group and makes interactive update and reboot decisions. (Fabric does not allow interactive Yes / No when running in parallel)
$ check_updates.py --serial --ask-upgrade mine
It is assumed that the executing side is Python 2.7.
$ check_updates.py -h
usage: check_updates.py [-h] [-s] [-q] [-n] [-v] [--ask-upgrade]
[--auto-upgrade] [--dist-upgrade]
[--auto-upgrade-restart] [--refresh] [--show-packages]
[--sanity-check]
[HOST [HOST ...]]
Checks if remote hosts need update or not.
positional arguments:
HOST Host names or host groups. If not specified, default
hosts configuration will be used. This may allow
special command "all" "list", "groups" (=
"list_groups").
optional arguments:
-h, --help show this help message and exit
-s, --serial Executes check in serial manner
-q, --quiet Suppress unnecessary output.
-n, --nonregistered Allow host names that are not registered
-v, --verbose Show verbose outputs, including Fabric ones.
--ask-upgrade Asks if upgrade should be done when appropriate. Only
effective when --serial (-s) option is set
--auto-upgrade Requests hosts to upgrade itself when necessary.
--dist-upgrade Use "dist-upgrade" instead of "upgrade". Only
effective with debian-like systems. Meaningless on
redhat-like systems.
--auto-upgrade-restart
Requests hosts to upgrade itself and restart when
upgrade is finished. With this option restart will be
executed regardless of necessity (with/without
"Reboot-Required" status). This will execute "dist-
upgrade" on debian(-like) OSes, not "upgrade.
--refresh Run "apt-get update" on debian-like systems.
--show-packages This will show names of packages to be upgraded.
--sanity-check First executes sanity check toward each host serially
(not in parallel). If some hosts show prompt in the
check phase, this command will abort itself
immediately. Might be useful for "debugging" new
hosts. If you are considering --serial option, This
"check" would be meaningless.
With the above script, you have to connect with ssh, and the authentication / authorization process is delicate. There are many inconveniences when monitoring with Zabbix.
Let's make something that can be monitored from Zabbix Agent even if a script (Python) is placed on each host.
$ check_update_local.py -h
usage: check_update_local.py [-h] [--log LOG] [-d] [-s] [-r] [-q]
Check if update is available. Returns num of updates
optional arguments:
-h, --help show this help message and exit
--log LOG Set Python log level. e.g. DEBUG, INFO, WARN
-d, --debug Shortcut for --log DEBUG
-s, --security-updates
Instead of showing num of updates, show num of
security updates.
-r, --reboot_required
Instead of showing num of updates, return 1 if reboot
is required
-q, --quiet Logging will be disabled entirely.
$ check_update_local.py
0
$ check_update_local.py -s
0
$ check_update_local.py -r
1
Debian requires the update-notifier-common package to use the apt-check command.
Certainly, it seems that it is included from the beginning if it is an Ubuntu system, but the details are unknown.
It was relatively easy so far, If you're not careful and try to make this script compatible with CentOS 6 The default Python for CentOS 6 was scared at 2.6 (rather than 2.7). I made a lot of strange hacks, and if I entered argparse with pip, I made it to a level where it works, but I would like to expect a cleaner method.
Unfortunately, Python 3 support is not included. 14.04 It may not be LTS-like.
How to use with Zabbix is described in README.md. Both apt-check and yum are really heavy to hit from the Agent, so it's uneasy. When used with many monitored objects, the server-side process that hits the Agent may become full. I made it earlier, so I can't verify it.
Better tool than this