A short introduction to cron-apt

Prev		Next

http://www.debian-administration.org/articles/162

by joe on 14 Jun 2005

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.

apt, cron-apt, and firewall issues

by lb on Fri 21 Jul 2006

My firewall server settings are pretty tight, and restrict outgoing traffic to absolute minimum. In order not to pierce holes into the ruleset for apt, I created a short shellscript that dynamically opens up the firewall for outgoing traffic during the update/upgrade process, and closes the firewall again, when finished. The script analyses the /etc/apt/sources.list/ and allowes ftp and http connections. after finishing cron-apt, the newly created rules are deleted again. It basically works like this:

create a script /usr/local/sbin/my-cron-apt that calls the firewall-rules script apt-fw.sh first, then executes cron-apt, and afterwards calles apt-fw.sh again.
in /etc/cron.d/cron-apt, replace /usr/sbin/cron-apt with /usr/local/sbin/my-cron-apt

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.

The scripts are:

Example 1. File /usr/local/sbin/my-cron-apt

#!/bin/bash

/usr/local/sbin/apt-fw start
test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
/usr/local/sbin/apt-fw stop

Example 2. File /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