Just read a great article called
Top ten rules for using ports on BSDPants -
BSDPants looks like a good blog btw if you're into FreeBSD, check it out. Got me to thinking about my strategy for upgrading my ports.
My port upgrade strategy - in order of prioritization - is:
Get a daily portaudit report of any ports that have security problems. Upgrade those ports as soon as I get the report.
Portaudit is a tool that checks each port you have installed against a list of ports that have security problems. If any of your ports match up with the ports on the security list, they're flagged as being insecure and you receive a notification of this when the periodic script is run.
On a daily basis, have a script - cvsup_cron.sh - run the following. I'll add the script in the extended body, but essentially all it does is:
CODE:
# cvsup the ports tree to latest ver:
/usr/local/bin/cvsup -g -L 0 /etc/supfile-ports-all
# Use portupgrade to fetch any distfiles for any ports that have been updated:
/usr/local/sbin/portupgrade -arRF
# Then output a list of all those ports:
/usr/local/sbin/portversion -vl "<"
This updates my ports tree to the latest, fetches any distfiles for newly updated ports and then prints out a list of those ports that are out of date. Fetching the updated distfiles just makes upgrading faster when I'm sat there in front of the console doing the work - instead of waiting ages for distfiles to download, the distfiles are already there waiting to be installed.
From the daily cvsup_cron.sh script output, if there are any services/servers that need updating, I'll update those immediately. Why? Well on a Saturday I upgrade all the out of date ports in one go using the '-arR' flags with portupgrade. This recursively upgrades all the out of date ports and those that rely on them, but if any of those are services then there's a chance that the service will be taken down by the upgrade process. By upgrading any services seperately I can make sure the services are restarted immediately instead of waiting for the 'portupgrade -arR' process to finish (I usually go off and do something else anyway whilst that's going on:).
Finally on a Saturday as mentioned above, I upgrade every port that's out of date automatically using 'portupgrade -arR'. I like to try and read /usr/ports/UPDATING first for any info on what might go wrong, but I have to admit I don't usually read it until something's already gone wrong - doh.
Until a year or so ago I just used to run 'portupgrade -arRi' once a week - which upgrades everything but prompts you for responses. This gave me the chance to read up on what had changed on each port before saying 'yes' to the upgrade. However this gets very tedious after a while since most ports never really need any special attention and are only being upgraded with minor patches that don't affect the service it provides significantly. As a result I moved to checking which ports had changed daily, upgrading services immediately, then upgrading everything else automatically using 'portupgrade -arR' every Saturday.
Freshports Daily Watch List Notifications
I should also mention the excellent
watch list service at freshports.org - you create a watch list of all the ports you currently have on your system and then opt to get daily email notification when any of those ports are updated. This is a very handy thing in combination with the strategy above - the notification email includes the cvs commit message for the ports that have changed so you know how urgent the update is and whether you should do something about it immediately or let it wait for the weekly update.
Read the FAQ article linked in the previous paragraph for more info on watch lists - easiest thing is to just register on the freshports.org site and get stuck in though.
I've been meaning to write a script to update my watch list at freshports automatically - it will get done eventually and I'll post about it here when it happens.
I'll include the cvsup_cron.sh script in the extended article, it requires the 'fastest_cvsup' port to be installed - a useful script for working out which cvsup server is fastest/closest in terms of ping speeds, worth installing if you haven't got it already.
CODE:
#!/bin/sh
quiet=2
if [ "$1" = "-q" ]; then
# quiet mode:
quiet=0
fi
cvsup=/usr/local/bin/cvsup
# make sure fastest_cvsup is installed in this location first!:
fastest_cvsup=/usr/local/bin/fastest_cvsup
# change to your ports supfile:
ports_supfile=/etc/supfile-ports-all
PID=$$
# all of this next bit is because of probs I had with cvsup processes stalling, probably
# to do with timeouts with the cvsup server. This just checks to see if any cvsup procs
# are already running and if they are it mails out a 'kill' command for me to manually kill
# the proc after checking it out:
# check to see if another cvsup instance is running already:
running_pgid=`ps auxwwj | grep "[/]usr/local/bin/cvsup" | awk '{print $15}'`
if [ "$running_pgid" ];then
tempfoo=`basename $0`
TMPFILE=`mktemp /tmp/${tempfoo}.XXXXXX` || exit 1
# get the command needed to kill all nastiness:
cmd="ps auxj | grep '[ ]$running_pgid ' | awk '{print \$2}' | sed -e 's/.*/kill -9 &/'"
# mail munk and quit:
echo "cvsup found in ps aux listing, check before running cvsup again!" >> $TMPFILE
echo >> $TMPFILE
echo "Use this command to kill the procs:" >> $TMPFILE
echo "$cmd" >> $TMPFILE
cat $TMPFILE | mail -s 'cvsup error: cvsup already running' munk
rm $TMPFILE
exit
fi
# check files exist first:
for file in $cvsup $fastest_cvsup $ports_supfile
do
[ ! -f $file ] && echo "$file does not exist, quitting" && exit
done
# find fastest cvsup servers in UK:
server=`$fastest_cvsup -Q -c uk`
# run the cvsup command, output depends on how the script is run -
# run on the commandline, output is more verbose.
# run from a cron job, output is quiet:
$cvsup -h $server -g -L $quiet $ports_supfile
cmd="(echo 'Fetching updated INDEX file' && cd /usr/ports && make fetchindex \
&& portsdb -u)"
[ $quiet = 0 ] && cmd="$cmd > /dev/null 2>&1"
eval $cmd
/usr/local/sbin/portupgrade -arRF
/usr/local/sbin/portversion -vl "<"
