Mario,
I use 'unattended-upgrades' on a couple hundred enduser desktop workstations. The idea being that most potential exploits in our environment might be through end-user browser/surfing.
I choose not to use it on a few hundred servers, most of which are internal or perform specialized scientific work, at this point in time. We have a very limited set of servers exposed to the Internet and we tend to manage them manually. (see below for 'pdsh' and approach to servers)
I also have 'apper' installed with a change to the policy-kit rules to allow ANYONE (at the console) to *update* packages, but not to install new packages w/o root. (dual-approach to updates, convenient if i ever have to backout unattended-upgrades for some reason)
I enable the update-notifier-kde package as well (kingston-notifier?) because 'apper's notifier popup doesn't reliably notify users of reboot-required events, even though it is supposed to ('update-notifier-kde' was supposedly deprecated for this reason). update-notifier-kde does trigger occasional popups successfully.
The hope here is that the end users will actually reboot the systems from being prompted by update-notifier-kde when an automatic security patch requiring reboot occurs. I have limited success with that. Probable reasons are:
- users are not easy to train -- we also have lots of transient visitors.
- users do not want to interrupt workflow
- users often run multi-day/week/month long scientific jobs
- users may just not "get" that they really should reboot
- Wheezy has been much worse than Squeeze for updates that trigger a
required reboot. Users may be getting "burnt-out" on the frequency.
while not strictly addressing your question w.r.t. "servers", my experience with unattended-upgrades on the workstations over the past 3 years has been good. I setup e-mails to myself -- so i have been notified a few times when a configuration file change blocks updates.
I have also setup 'apt-listbugs' on my systems, and 'unattended-upgrades' will sometimes block hard, because it has an issue where 'apt-listbugs' detects that ONE (or more) packages has a problem and returns a failcode causing UA to abort the upgrade entirely (no piecemeal re-attempt). This requires manual intervention. I have upped the threshhold on 'apt-listbugs' to critical to avoid that condition recurring frequently.
My experience in the past 10 years with Debian, is that i have maybe seen ONE update that had some fallout that was at all inconvenient.
For my servers, i will typically use 'pdsh' (LLNL distributed shell) to perform a global run of a forced updates. ('pdsh' is very helpful here).
I use both 'dsh-group's for personal use, and an nfs-shared /usr/local/etc/genders (libgenders) file which contains attributes like 'os=debian_linux' to select servers/systems to hit
so, something like (genders module in play):
pdsh -lroot -g 'os=debian_linux&&hwtype=server' 'aptitude update -q=2 && aptitude safe-upgrade -q=2 --assume-yes ... {pkgs...}' 2>&1 | tee upgrade.log
(it's important to use safe-upgrade, otherwise if you force-yes with noninteractive in batch mode like this, aptitude can end up removing packages if a package you specify doesn't have explicit dependency packages also listed on the command line. It's always a good idea to run this command on one server first to make sure it doesn't end up doing something you didn't mean to. said from experience :-( )
(i'm at home and don't have the full invocations of Dpkg options for stuff like retaining old configfiles and using noninteractive DPKG UI (via env-var -- i can get that later, if you're interested)
--stephen