A short introduction to cron-apt

Posted by joe on Tue 14 Jun 2005 at 01:19

Tags: none.

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!

 

 


Posted by Anonymous (81.175.xx.xx) on Wed 15 Jun 2005 at 12:16
I use this homebrew shell-script, it only mails if there is anything new:
#!/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 ]

Posted by Steve (82.41.xx.xx) on Thu 16 Jun 2005 at 10:43
[ 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 ]

Posted by Anonymous (68.202.xx.xx) on Sun 4 Dec 2011 at 01:27
Hey! I like this script. Seems like the perfect compromise.

Thanks!

Allen

[ Parent | Reply to this comment ]

Posted by grimoire (82.70.xx.xx) on Wed 15 Jun 2005 at 13:15
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 ]

Posted by joe (208.0.xx.xx) on Wed 15 Jun 2005 at 13:34
[ View joe's Scratchpad ]
This book covers cfengine throughout it. I've been meaning to take a better look at it when I have time but it looks to be really involved.

[ Parent | Reply to this comment ]

Posted by Anton (66.156.xx.xx) on Thu 16 Jun 2005 at 06:47
Very handy, thanks for the article. I'm going to give it a try. The best feature - for me at least - is to be informed when/which updates are available, because I agree that auto-installing is not such a good idea.

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 ]

Posted by Anonymous (64.114.xx.xx) on Tue 31 Jan 2006 at 14:48
Can cron-apt be configured to silently upgrade any and all packages where no questions are asked during their installation, but then when a package asks what to do about a new config file (keep old or overwrite original with new version, saving old), then cron-apt emails you for manual intervention?

[ Parent | Reply to this comment ]

Posted by Anonymous (209.184.xx.xx) on Thu 1 Feb 2007 at 22:55
I would also like to see this happen.

[ Parent | Reply to this comment ]

Posted by lb (130.75.xx.xx) on Fri 21 Jul 2006 at 15:47
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 scripts are: /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
/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 ]

Posted by Anonymous (142.68.xx.xx) on Thu 7 Jun 2007 at 13:52
>>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!<<

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 ]

Posted by Anonymous (82.122.xx.xx) on Wed 19 Dec 2007 at 11:11
Good !

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 ]

Posted by Anonymous (86.47.xx.xx) on Tue 8 Apr 2008 at 18:02
How do you configure cron-apt so that it does not download the updates, but just notifies you of updates?

[ Parent | Reply to this comment ]

Posted by Anonymous (130.126.xx.xx) on Sat 7 Jun 2008 at 01:48
Bump ... can someone answer this?

[ Parent | Reply to this comment ]

Posted by Anonymous (62.236.xx.xx) on Mon 9 Jun 2008 at 11:42
Remove /etc/cron-apt/action.d/3-download

[ Parent | Reply to this comment ]

Posted by Anonymous (63.20.xx.xx) on Sun 6 Jul 2008 at 20:26
"Well, what if the upgraded program uses new syntax in its config file. Your program is now broke"

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 ]

Posted by sagar13 (192.168.xx.xx) on Tue 19 Feb 2013 at 13:13
Is there some way I can get the list of updates to a local machine connected in LAN instead of getting it mailed to an e-mail id?

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

What do you use for configuration management?








( 147 votes ~ 0 comments )