I manage around 30 Ubuntu servers using puppet. I've seen many references to cron-apt and apticron as approaches to keeping their packages up to date but I haven't been able to find a way to centrally manage the process. With cront-apt/apticron I would still need to log in to each host and run aptitude update to perform the update. Not to mention review notifications from all 30 machines whenever a core package is updated.

There has to be a better way. Any suggestions?

7 Answers 7


Landscape might be of interest to you. This is the "official" management tool for managing large Ubuntu deployments, and Canonical is probably very keen to get your dollars for its use.


First, a disclaimer; I haven't used mirroring for Debian or Ubuntu, so I am not familiar with the software.

Second, it appears that apt-mirror would be "too heavy" a solution, my apologies. The original idea was that you would have a separate test machine (or test environment, probably a virtual machine?) to deploy the update on. Once you are satisfied with the performance of the update, you would pull/put the package into your "deploy" mirror (there would be the local mirror from the official sources, and a secondary mirror for just updates that you wish to deploy). The remote machines would then run an update at a pre-set time and pull it from your "deploy" mirror onto each machine, a cron job consisting of:

apt-get update && apt-get upgrade --quiet --assume-yes

Unfortunately, as I began to read through the details, it seems that apt-mirror will pull all kinds of stuff and not just the packages you are after. So, I'm going to abandon this idea, although the concept has some merit.

  • Landscape looks interesting. I'll have to look more closely at that. I'm not clear on how running a local apt mirror (which I currently do) would help me approve / review pending updates. Can you clarify that?
    – Insyte
    Aug 7, 2009 at 19:07

A co-worker discovered and has looked briefly into apt-dater, which is a "terminal-based remote package update manager".

You use a curses-based interface to manage updates on all of your hosts, or groups of hosts, etc. Supports logging of the full apt session, including any errors that may be encountered, etc.

Relies on ssh and sudo on the managed machines.

see https://github.com/DE-IBH/apt-dater

Haven't used it myself, so I can't endorse it, but it sounds close to what you're looking for.

  • This looks very promising. Insyte, I'm going to recommend this answer over my own. While you can do all the steps I've described, do you want to really invest the time in that, when you could probably do a very quick setup of this and just get on with life? @Jeff, +1 for a nice suggestion. Aug 7, 2009 at 19:28

Since you're already using Puppet, the easiest way to do this (and the best for change control/tracking purposes) is to specify the desired version of packages you want installed in the puppet manifest. You keep an eye on the security announcements list, and when something you use comes through you just update Puppet to say "install this new version of this package". Assuming you're using revision control on your manifests, you then know when the "policy" was changed, and the reports from Puppet show you exactly when the change was actually made (so you can correlate that easily against any later log events).

  • This is pretty much what we do. We don't use the puppet package type as that would cause every server to install every package. Instead, we write a file on the server with the package name and version and then use a script to run through them and check to see if they're installed and then try to install them. The second part is a script that reads my mail folder with apticron emails in and grabs all the packages that need updating and rewrite the manifest file. We're not entirely sure how well this method works yet. Aug 8, 2009 at 6:05
  • 2
    Why would the Puppet package type install all packages on every machine? You put the stanzas for each package into the relevant class or defined type, so it only gets installed on the appropriate machine(s). If you want to centralise the version list into one file, have a big list of virtual resources and then realise them where necessary.
    – womble
    Aug 8, 2009 at 6:28

Have a look at clusterssh (apt-get install clusterssh):

$ cssh server1 server2 server3 ...

  • 1
    This actually works still in 10.9.3... it's kind of hilarious to use it Jun 6, 2014 at 19:23

Without having really thought about it previously, my first idea would be something similar to what avery has suggested, especially if you already have a test envrionment.

Basically, you set your production machines to automatically upgrade from your own local repo, and you only update this repo after you've upgraded your test environment to the newest version of whatever you run.

Apticron doesn't scale well, it's designed to be ran in pretty small environments, but it does have some good points:

  • It doesn't just send you a list, but also the changelogs for packages to be upgraded.
  • To get the changelogs it downloads the packages, so when you upgrade you don't have to wait for them to download.

Sometimes ago I wrote a low level/dirty automation Fabric script (fabfile) to meet similar requirements, you can check it at:



shell script to do it? where you set also individual packages per node?

for each serverlist as server (eg server1 server2 server3...)
   scp installupdate.sh root@$server:/tmp/installupdate.sh
   ssh root@$server "/tmp/installupdate.sh" # manage installation/ updates manually or set auto "yes" to requests
   # next server

this can be customised to individual endpoints or make it full automatically running.

this way i use it to update some cloud servers web & db servers. some get special packages other dont and it scales.

its like @lgaggini posted

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .