A short introduction to cron-apt
Posted by joe on Tue 14 Jun 2005 at 01:19
I've seen cron-apt mentioned a few times here so I thought I would post a little introduction to it incase anyone was curious as to how to use it, or hadn't heard of it before.
Basically, cron-apt is a very flexible program that can manage automating apt via cron (I suppose thats how it got its name...). You can install it like so:
apt-get install cron-apt
You can configure cron-apt in the /etc/cron-apt directory and you can specify when it runs in the /etc/cron.d/cron-apt file. Personally, I just have everything set to default except for one line in /etc/cron-apt/config:
MAILON="always"
Just as it would imply, it will email me the results of the nightly run no matter what.
By default, cron-apt will only download updates -- it will not install them. I know other packages for other distributions like up2date will automatically install the updates for you, but I've learned to like this and that in the long run, automatically installing updates is a Bad Thing. Why? Well when I was experimenting with auto-installs, I ran into problems:
- Even though I told apt to say Yes to everything, it still prompted me for input on config file conflicts (was I doing something wrong?). This caused the script to hang indefinitely in the background until it was killed.
- Auto-accepting configuration changes can ruin your day. With Debian, it's fairly easy to back out of a change and hopefully you have a backup copy of the config file, but that's not the point. Good System Administration means you should never be in that position in the first place. "OK, what if I just deny all configuration changes and leave my copy?", you ask. Well, what if the upgraded program uses new syntax in its config file. Your program is now broke and you're in the exact opposite position as you were with auto-accepting.
- Just as you should always review configuration file changes, always review what packages are being installed. If you know that installing that new version of Samba will mean some extra work in other places, don't install it yet.
Bottom line: Yes, it can be very tedious to manually review each update batch -- especially if you have several servers -- but that is part of your job when you are running a server. Deal with it!
OK, with that rant done with, lets get back to cron-apt.
So right now we have cron-apt downloading updates for us every day and emailing us about them. Each morning I review the updates to see if there's anything critical that needs updated (like if I've seen a security advisory on BugTraq or something). If not, I usually wait until I have time on the weekend to do the update. If anything, the daily emails serve as a nagging reminder to update your server.
I simply run:
apt-get dist-upgrade
I do one final review and then install the packages and clean up any config file conflict during installation.
That's really it. As mentioned before, cron-apt is very flexible. If you read over the example config in /usr/share/doc/cron-apt/examples, you'll get a better understanding for this flexibility.
For example, you can specify a different package repository to download from at night than when you use apt daily on the command line. Or you can add different arguments or even use completely different programs to do the actual downloading. Out of the box, it works just fine, but if you have some weird special need, it can do it for you.
Questions, comments, and flames are more than welcomed!
#!/bin/bash
#
# Cron Script - run from /etc/crontab or /etc/cron.daily
#
# Runs "apt-get update" and prints the output of a simulated
# dist-upgrade if new packages are found.
if [[ `apt-get update 2>&1 | grep Get` ]]; then
if [[ `apt-get --simulate dist-upgrade 2>&1 | grep Inst` ]]; then
apt-get --simulate dist-upgrade
fi
fi
It can also be found on my website. Cheers! Mattias
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
That's a very similar idea to the script I presented in the Keeping unstable machines up to date easily article.
Steve
-- Steve.org.uk
[ Parent | Reply to this comment ]
Thanks!
Allen
[ Parent | Reply to this comment ]
Yes, it can be very tedious to manually review each update batch -- especially if you have several servers
I believe that the cfengine package is supposed to help with this, but I haven't had any experience of it. If someone could post a guide to it on d-a, I'm sure plenty of people would find it interesting.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
When running Sarge when it was still Testing, there were times when repeated subsequent upgrades of packages were sometimes bothersome, especially when each time a configuration file would change (apcupsd comes to mind at one time), forcing one to review what had changed each time. Now that it's Stable, updates aren't that frequent anymore, which I like a lot better.
One suggestion I'd make, instead of running "apt-get dist-upgrade" I recommend using aptitude for such upgrades, because it gives you an overview and control over suggested/recommended packages. Plus (and this is a big plus in my book), aptitude will uninstall such dependent packages later on if the "parent" package is uninstalled, unless of course there's still a need for it to satisfy other packages' dependencies.
Anton
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
#!/bin/bash /usr/local/sbin/apt-fw start test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /usr/local/sbin/apt-fw stop/usr/local/sbin/apt-fw.sh
#!/bin/bash
IPTABLES=/sbin/iptables
GREP=/bin/grep
AWK=/usr/bin/awk
TAIL=/usr/bin/tail
CHAIN="aptChain"
function d_start() {
$IPTABLES -N $CHAIN
$IPTABLES -A $CHAIN -p udp --dport 53 -j ACCEPT
$IPTABLES -A $CHAIN -p tcp -m multiport --dport 21,80 -j ACCEPT
$IPTABLES -A $CHAIN -j REJECT
for APT in `$GREP ^deb /etc/apt/sources.list | $AWK '{print $2}' | uniq`; do
APT=`echo $APT | $AWK '{sub (/[fht]*p:\/\//,"",$1); print}'`
APT=`echo $APT | $AWK '{sub (/\/[a-zA-Z0-9\-_/]*\/?/,"",$1); print}'`
$IPTABLES -A OUTPUT -d $APT -j $CHAIN
done
}
function d_stop() {
$IPTABLES -F $CHAIN
I=`$IPTABLES -L OUTPUT -n --line-number | $GREP $CHAIN | $TAIL -n 1 | $AWK '{print $1}'`
while [ "$I" != "" ]; do
$IPTABLES -D OUTPUT $I
I=`$IPTABLES -L OUTPUT -n --line-number | $GREP $CHAIN | $TAIL -n 1 | $AWK '{print $1}'`
done
$IPTABLES -X $CHAIN
}
case "$1" in
start)
d_start
;;
stop)
d_stop
;;
*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac
exit 0
The advantage of splitting the process in two seperate files is, that you can call apt-fw.sh manually, when executing aptitude update or the like. For comments, please drop me a mail. :-)
[ Parent | Reply to this comment ]
This "cope" viewpoint is very limited IMHO. The AUTHORS of the updates should have some way to flag fixes that require reboot, update config files, or otherwise cause the user grief. apt/aptitude/dpkg should have a method of filtering these flagged updates to allow non-flagged fixes to be applied, and flagged fixes to be held back until the user manually approves them. This way, the user can zero in on those fixes that actually need attention, and not be bothered by those that don't. THEN it will be easier to "deal with it!".
[ Parent | Reply to this comment ]
I used to do that with a little shell doing apt-get update & apt-get upgrade -qy.
But I have noticed that it's not as simple as that: some packages will still need a user interface (despite -qy options) and some will just break (typically each samba upagrade).
So I do agree it's more sensible to run an apt-get dist-upgrade manually on your own time !
Thanks for sharing.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
If you only use cron-apt for security updates, and refer to the distrib by name instead of by stable,testing,... then the issue you mention should never happen - debian backports updates to avoid this very issue.
[ Parent | Reply to this comment ]