Automatic (or unattended) upgrades in openSUSE, CentOS and Fedora, Debian and Ubuntu

Each one of us is a system administrator: for at least your workstation (or notebook) you can decide when and how to administrate it. In the special case in which you are being elected to administer servers too, the matter becomes thorny: what is the workflow in terms of patching, time of reaction to security issues and, in general, when and how to install updates?

Some distributions offer the concept of automatic (or unattended) upgrades: install automatically a subset (or all) the available updates via the package manager. This particular subset can be specified by the system administrator, a notable example would be the subset of security updates.

The approach is, of course, debatable: should you use it for a critical server? What happens if the upgrade goes south? Would this approach scale?

The answer is, nevertheless, debatable: it depends. You are not required to use automatic updates, but installing security patches automatically might make sense in some non-mission-critical situations. You can read an opinionated list of reasons to use automatic updates, as well as an equally opinionated list of reasons NOT to use automatic updates.

In this post, I am going to present the three approaches for automatic updates offered in:

  • openSUSE
  • CentOS and Fedora
  • Debian and Ubuntu

and how I setup them for my own “very special, do not try this at home” situation, which means that servers always install only security updates automatically.


openSUSE can schedule automatic updates via Automatic Online Update.

Take a look at the documentation: everything is already well documented, you just need to the package with:

# zypper install yast2-online-update-configuration

and then, to configure it:

# yast2 online_update_configuration

The servers must weekly check and install only security updates automatically (category “Security”), except the ones declared as “Interactive”. From the documentation:

Sometimes patches may require the attention of the administrator, for example when restarting critical services. For example, this might be an update for Docker Open Source Engine that requires all containers to be restarted. Before these patches are installed, the user is informed about the consequences and is asked to confirm the installation of the patch. Such patches are called “Interactive Patches”.
When installing patches automatically, it is assumed that you have accepted the installation of interactive patches. If you rather prefer to review these patches before they get installed, select Skip Interactive Patches. In this case, interactive patches will be skipped during automated patching. Make sure to periodically run a manual online update, to check whether interactive patches are waiting to be installed.

Skipping interactive patches absolutely makes sense to me, as well as using delta RPMs (to save bandwidth), auto-agreeing with licensing and including recommended packages.

Update: Richard reminded me that if you are running Leap or Tumbleweed with transactional updates, you can take advantage of automatic transactional updates; rebootmgr will take care of automatically reboot the machine in case any transactional updates were installed.


The package that enables automatic updates is called yum-cron. To install it:

# yum -y install yum-cron

The configuration file (/etc/yum/yum-cron.conf) is self-documenting: just open it in an editor and begin tweaking. In my case, to check and install only security updates I just changed the following two lines:

update_cmd = security
apply_updates = yes

Finally, make sure that the corresponding service is enabled:

# systemctl start yum-cron.service


Fedora automatic updates are enabled by installing the dnf-automatic package:

# dnf install -y dnf-automatic

As with CentOS, I just changed the configuration file (/etc/dnf/automatic.conf) to install security updates only:

upgrade_type = security

After the configuration, start the service:

# systemctl enable --now dnf-automatic.timer

Debian and Ubuntu

Debian and Ubuntu make use of the unattended-upgrades package in order to enable automatic updates. Let’s begin with installing it:

# apt install unattended-upgrades

It is configuration time: make sure to enable the update of package lists and perform the upgrade in /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Now enable the repository from which updates can be installed in /etc/apt/apt.conf.d/50unattended-upgrades; in our case, only the security repository:

Unattended-Upgrade::Origins-Pattern {


Every distribution offers then its own tweaks (like email notifications when updates are ready and when are installed), package exclusions based on package names, install updates at shutdown time and whatnot: be sure to read the documentation! The examples are just a starting point.

Happy automatic patching!

Packaging software for Debian/Ubuntu: eclipse

Eclipse is my (Java, Python, Ruby, XML, <insert any other text format here) editor of choice, and it has been for many years. One thing that bothers me is that Eclipse package is outdated in Ubuntu: so, instead of using apt, I should resort to download/unpack/copy/create links to install it. These days are finished, though.

In fact, I have been introduced to Debian packaging and I contributed to the Debian package of the latest version of the Eclipse IDE (4.5.1). EDIT: Repository has been removed as obsolete.

This package is really simple (and in fact I used it to learn the packaging process for Debian/Ubuntu). How did I learn it? Recommended reading: How to package for Debian.

In the following days I will try to publish a PPA with the built package. In the meanwhile, if you want to try to build the package on your own, just: 1. git clone -b eclipse_4.5.1
2. cd eclipse-ide-java
3. cd eclipse-ide-java_4.5.1
4. debuild -i -us -uc -b
5. cd ..

Now you have a *.deb package waiting for you to be installed (via dpkg -i): upon installing it will fetch (via wget) the latest version of Eclipse, unpack, copy and create links.

Evitare riavvii e shutdown remoti su Ubuntu con molly-guard

Non mi è mai capitato ma potrebbe essere molto utile ai sysadmin più distratti: molly-guard è un pacchetto presente su Ubuntu/Debian che vi permette di evitare un riavvio/shutdown di una macchina remota a cui siete collegati tramite ssh.

Se, per esempio, tentate di eseguire uno shutdown di una macchina remota a cui siete collegati tramite ssh, molly-guard vi chiede di scrivere per intero l’hostname della macchina che volete riavviare/spegnere.

Il pacchetto è incluso nei repository ed è molto semplice da installare (basta un apt-get) ed è davvero molto utile: ho provveduto ad installarlo su tutte le macchine che gestisco.

Per i più curiosi, il nome molly-guard deriva da una “divertente” vicenda.

Come impostare il pinning (non aggiornare, ovvero mantenere la versione attuale) di un pacchetto su Ubuntu/Debian

A volte può capitare che su certe macchine Ubuntu (o Debian) alcuni pacchetti importanti non debbano essere aggiornati dal gestore di pacchetti (apt-get o aptitude). Le ragioni possono essere le più svariate: incompatibilità, volontà di tenere la versione corrente (!), aggiornamento manuale, etc.

Per fare in modo che un pacchetto non venga mai aggiornato (ovvero che il sistema continui a mantenere la stessa versione del pacchetto installato, bisogna ricorrere alla tecnica del apt pinning, che ci consente di specificare al sistema che un pacchetto (o un gruppo di pacchetti) non deve essere aggiornato e deve essere tenuto “in hold”.

Per fare in modo che un pacchetto non venga aggiornato basta aprire un terminale e digitare:

echo nomepacchetto hold | dpkg --set-selections

dove nomepacchetto è il nome del pacchetto di cui volete che non vengano scaricati aggiornamenti successivi rispetto alla versione installata correntemente.

Per rimuovere il “blocco”, aprite un terminale e digitate:

echo nomepacchetto hold | dpkg --set-selections

dove nomepacchetto è il nome del pacchetto di cui volete che vengano scaricati aggiornamenti successivi rispetto alla versione installata correntemente.