Friday, November 13, 2009

How to keep Gentoo safely updated

When I first started using Gentoo, I broke the system a few times by updating it. I've noticed that I have a lot less issues keeping the system up to date these days. I'm sure part of it is the great job the Gentoo Devs are doing but I think the other part is following a procedure each time I update the system.

Update portage
I use app-portage/eix so I run eix-sync. This gives me a nice diff at the end of the changes. I can quickly see if any packages I have installed have updates. An alternative is the tried and true emerge --sync. Some sample output of eix-sync below:
  • [>] == x11-themes/mythtv-themes-extra (0.21_p17416 -> 0.21_p18657): A collection of themes for the MythTV project. (Has been updated, but I don't have it installed)
  • < (Has been removed from portage)
  • [N] >> dev-java/piccolo2d (~1.2.1!t): A Structured 2D Graphics Framework (A new package to portage)
  • [U] == net-libs/gnutls (2.8.3@09/22/09; 2.8.3 -> 2.8.4): A TLS 1.0 and SSL 3.0 implementation for the GNU project (Has been updated to 2.8.4. I have 2.8.3 which was installed on 9/22/09)
Update packages
I use emerge -avuND world. The options are as follows:
  • a means ask. It's like doing a (p)retend but instead of calculating dependencies twice, it's only once.
  • v is verbose output. I like to see the use flags listed.
  • u is update.
  • N is new-use. This means rebuild any package whose use-flags have changed since it was last installed.
  • D is deep. This looks further into the dependencies and will end up keeping more stuff up to date. I find this still doesn't catch *every* little package update, but it's good enough for me.
  • world is the world package set. This means potentially update any package on the system.
Update configuration files
I use dispatch-conf instead of etc-update as, over time, it saves me a lot of time. dispatch-conf is a lot more powerful and you can turn on a lot of options that aren't enabled by default in it's configuration file, /etc/dispatch-conf.conf. The easy ones to turn on, IMO, are the "automerge" options.

Check for broken packages
This one is easy. revdep-rebuild, which is a part of app-portage/gentoolkit.

Restart services referencing old versions of shared libraries

I can't take credit for coming up with this little snippet, but I use it every time. It's especially important after you've applied an update that was a security fix for a network service.
lsof | grep 'DEL.*lib' | cut -f 1 -d ' ' | sort -u

Example:
# lsof | grep 'DEL.*lib' | cut -f 1 -d ' ' | sort -u
console-k
hald
hald-addo
hald-runn
syslog-ng
# /etc/init.d/hald restart
* Caching service dependencies... [ ok ]
* Stopping Hardware Abstraction Layer daemon ... [ ok ]
* Starting Hardware Abstraction Layer daemon ... [ ok ]
# /etc/init.d/syslog-ng restart
* Stopping syslog-ng ... [ ok ]
* Starting syslog-ng ... [ ok ]
# /etc/init.d/consolekit restart
* Stopping ConsoleKit daemon ... [ ok ]
* Starting ConsoleKit daemon ... [ ok ]
# lsof | grep 'DEL.*lib' | cut -f 1 -d ' ' | sort -u
#
Essentially, it searches for open files that the filesystem has tagged as deleted, finds the process that has opened the deleted library and alphabetizes the list. You need to manually restart any service that shows up in that list. A little gotcha is that if sshd shows up in the list, you can restart it and you should stay connected to your session. If you re-run the command above, sshd would still be listed as your current session is still using the old process/version of sshd. If you log out and then log back in and run the command, all should be clear at that point.

Wrap up
Something else that I use that I'm not going to cover here is portage's elog feature. You configure this in /etc/make.conf and you can enable several forms of reporting errors, warnings, info, etc that ebuilds output to you. I have it set up to mail them to me, one per package. After an update, I look over the mails and check to make sure there isn't some important information in there about some action I have to take. In the make.conf manpage it says "Please see /usr/share/portage/config/make.conf.example for elog documentation."

So there you have it. This is the process I follow both at home and at work and things have been running smoothly for the past few years.