This blog post is a little recipe to do a Debian migration for a node using Puppet and some other good practices.
We do all the following commands as root, which on of the exceptional situation where you should have a real root session (login through console, or
su -).
I tend to avoid using the X server while doing an upgrade, so my 'best' setup is to have a laptop to take note and check things on the internet and a session to the computer to upgrade (ssh +
su - or login as root into console). In both case, I use
screen during the upgrade so that I can handle disconnection.
Create or update your admin-syscheck script
First of all, a good practice is to have a script that runs various test on the system that checks everything is ok. This is not only for upgrade but in general. But in the case of upgrade, it can be particularly useful. I call this script admin-syscheck. This is a simple bash script.
This script check various aspect of the system and serve me as my external worker to check the most advanced knowledge I have gathered about setting up a service. For example, I know that having
*.bak or
*.dpkg-dist in
/etc/ means that something needs to be merged and a file should be deleted. Another example is about setting up the right alias for
127.0.0.1 and
::1 (which you can differentiate using
getent ahostsv4 and
getent ahostsv6).
I have packaged this script and distributed it using a specific apt-get repository. You can just distribute it using puppet. I recommend to run it daily to track changes (e.g. after an
apt-get dist-upgrade) and to check that my setup is aligned with my most up-to-date knowledge about setting up a service (i.e. this is my external worker).
In our case we are interested in checking presence of old and new configuration files, before and after upgrading. Here is this specific section of my script:
if ! $IS_ROOT; then
warning "Not trying to detect dpkg leftover file in /etc/."
else
LEFTOVER_FILES=( $(find /etc/ \
-name "*.dpkg-dist" -o \
-name "*.dpkg-old" -o \
-name "*.ucf-old" -o \
-name "*.ucf-dist" -o \
-name "*.bak") )
for i in "$ LEFTOVER_FILES[@] "; do
if [ "$i" = "/etc/hosts.deny.purge.bak" ]; then
continue
fi
if $fix; then
BASE=$ i%.*
cond_exec vim -d $BASE $i
read -p "Delete $i (y/N)? " ans
if [ "$ans" = "y" ]; then
cond_exec rm $i
fi
else
report_error "dpkg leftover file: '$i'."
fi
done
fi
(cond_exec allows to do a dry run, you can just remove it).
Setting
$fix to
true will spawn a
vim -d old new command where you can edit and then delete the leftover file. This is extremly handy.
Upgrading to Wheezy
I strongly recommend to read first the
upgrade chapter of the release notes. This gives you a more complete overview of the upgrade procedure. I just go through the basic step here.
1. Update everything on the system:
$> apt-get update
$> apt-get dist-upgrade
2. Check that the current configuration apply cleanly:
$> puppet agent --test
3. Run admin-syscheck:
$> admin-syscheck
And fix all the problems.
4. Disable puppet:
I use a cronjob to run puppet, so I just comment the line for the job (
/etc/cron.d/puppet-custom). You should disable puppet by stopping the daemon and preventing it to run by editing
/etc/default/puppet and set
START=no.
4. Fix your sources and pinning:
Change squeeze to wheezy in
/etc/apt/sources.list and remove useless files in
/etc/apt/sources.lists.d/.
(You may keep certain sources that refers to stable, like google-chrome.list).
$> rm /etc/apt/sources.list.d/* # Check if this ok to do this with your system.
Although, I tend to fully purge
/etc/apt/sources.list expect for the main line (removing backports and security is fine for a short time). The first run of puppet after upgrade will anyway reset this file.
$> rm /etc/apt/preferences.d/* # (at least the ones that do pin some version)
You can although remove all pinning from
/etc/apt/preferences.
5. Now you start the real upgrade:
$> apt-get update
$> apt-get dist-upgrade
6. During the upgrade you will be asked if you want to keep old configuration files or install the newer one from the maintainer.
I have always wondered what to answer to this. But here is the answer after a few major upgrade: always install configuration files from maintainer if the service has no ultra-specific settings that could break during the upgrade.
The only file, that I should not upgrade on my system, is
/etc/sudoers. In this very specific case, you need to make sure before the upgrade that the old and new configuration can coexist. In the squeeze to wheezy case, I have just setup a few extra augeas rules to set the
secure_path before the upgrade and it was fine. This is typically the kind of situation where you are thankful to have a real root session.
7. The upgrade can be long and require various fixing to remove/re-add packages to circumvent problems. At the end you will have a set of file *.dpkg-old and *.ucf-old (and some *.dpkg-dist and *.ucf-dist). The
*-old files are your old version of the file, while the corresponding files match the maintainer version of it. The
*-dist files are the maintainer version of the file and the corresponding files match your old version of it.
Starting from here you have 2 options:
- This is one of the first computer you upgrade, go to 'first upgrade'.
- Your puppet configuration for wheezy is already bullet proof, go to 'further upgrade'.
First upgrade
This is the tricky part, you'll have to spend a little time on it:
1. Go over all *. ucf,dpkg - old,dist and merge them with the corresponding configuration file. Use
admin-syscheck with
fix=true
2. Make a copy of your
/etc directory into
/etc.new:
$> cp -rp /etc /etc.new
3. Run puppet again:
$> puppet agent --test
4. Disable again the automatic run of puppet, if the previous command has re-enabled it.
5. Make a diff between
/etc and
/etc.new. Since you have a run of puppet, you know what has changed and should not have changed.
$> diff -Nurd /etc.new /etc
Everytime you find some files that doesn't match your expectation for the upgrade with puppet, change the corresponding puppet manifest to have what you expect.
For example, if this is a file:
if ($lsbdistcodename == 'wheezy')
file
"/etc/foo":
source => "puppet:///files/foo.wheezy"
else
file
"/etc/foo":
source => "puppet:///files/foo.squeeze"
People working with augeas and puppet, will appreciate the fact that they probably have 0 changes to make for this to work (since it only does a few replacement in configuration files).
6. Once you are happy with the changes, copy back
/etc.new to
/etc and go to step 3 until the difference is almost 0.
7. Re-enable automatic run of puppet.
Do this procedure for a least each computer category you have (e.g. Desktop and Server nodes). Once you are fully confident your new puppet setup works, you will be able to use 'further upgrade' for the other nodes.
Further upgrade.
This one is super easy compare to a first upgrade:
1. Re-enable puppet and have it run at least once:
$> puppet agent --test
2. Merge
*. dpkg,ucf - dist,old with corresponding files (you can run
admin-syscheck with
fix=true). This is mostly a sanity check since you should have already solved most problem with the 'first upgrade' procedure.
That's it.
Enjoy your upgrade to Wheezy with puppet.
For me, DebConf13 in Switzerland was a perfect DebConf, and generally an
great developer meeting and conference. I've attended several past DebConfs
in Canada, Norway, Brazil, Finland, Mexico, Scotland, Spain, NYC, Bosnia,
and Nicaragua. I have special memories of each. DebConf13 was ideal in every
way.
Let's start with the camping. Only a minority of us did it, and my campsite
was located in a small field behind a bar that was often noisy
late into the night, when I was trying to rest and preserve
my European jetlag remedy of inverted sleeping schedule. Still, I love
sleeping cocooned in a tent, and going through the routines of camping and
spending time alone there was a good counterpoint to DebConf. I generally
find myself retreating for a day or two in the middle of a week-long
conference, burnt out with social interactions. That didn't happen this
time. I need to find way to camp at future DebConfs.
(Also special shout out to wonderful people who lent me a warmer sleeping
bag, and bought me a pillow while on a trip to town! Upgraded my first
backpacking in Europe experience's comfort level a lot!)
The next perfect thing for me were the talks I gave at DebConf.
I always enjoy presenting at DebConf, and barely remember when I'd get
nervous doing it. But I really felt comfortable giving these
talks in a way I've not before. I'm pleased with how
the Debian Cosmology
talk turned out; I'd worried it would be a downer talk, or too light,
or not well received, and none of those problems surfaced.
I was especially happy with my
dh_busfactor
session, which I prepared for all of 10 minutes and was structured entirely
to benefit me by talking over my thoughts and getting feedback, and in
which I probably drove the camerapeople crazy running my own mic into the
audience. Despite all that, I think it succeeded being interesting for the
participants as well as for me. Hope to follow up on it soon..
But beyond the two talks I submitted, there were a series of ad-hoc
scheduled talks. It seemed that every day I spent at least an hour
discussing something I'm deeply involved in. This started with the
Ikiwiki bof,
and then there was an epic series of (unrecorded) BoFs about git stuff,
which basically turned into an unofficial git track at DebConf.
Much, much discussion of git-annex and other things I'm involved in.
BTW, I really like that DebConf, as well as being a formal conference on
top, is really an un-conference underneath, with new BoFs and things
popping up on the schedule all week long. You can even have completely
unscheduled meetings that somehow get just the right mix of people
to make something awesome happen.
But it wasn't all about talks. Indeed, I only attended 2 or 3 sessions a
day. The DebConf13 venue was controversial, but I found it excellent for
getting things done. Rather than one or two massive rooms that get too
noisy to think in, this venue had many little nooks and crannies
suited for different types of work. There were so many I only discovered
some while walking down the hill as I was leaving the venue! Anchoring it
all was the excellent view, and I particularly enjoyed the "scenic hacklab".
I was particularly impressed with the flexability of the venue's
management. Someone asked if we could have cheese for breakfast, and every
breakfast thereafter had not one but often three excellent cheeses. One day
we'd be complaining that there were not enough vegetables in the food, and
the next we'd be eating an excellent vegetarian Swiss lunch. They even
apparently relaxed stringent Swiss rules on not allowing tents in
sightlines visible from people further up the hill. They were clearly happy
to welcome our crazy gathering to Le Camp. They let a DD borrow and use a
chain saw and build a bonfire!
The venue also encouraged getting out and exploring the surrounding
countryside. Too often I end up spending the whole DebConf without seeing
much of the area around. This time I at least got down the hill to see the
castle in Vaumarcus a few times, and enjoyed many evening walks amoung the
grape fields.
The conference dinner (on a boat!) tied into this well too. And the daytrip
to CERN was a great addition. We got to poke around the control center for a
massive particle accellerator! My only regret is we didn't get a chance to
actually go inside the LHC tunnels.
Back to DebConf, another thing I really liked about this one was that its
location allowed several upstream authors of software in Debian (other than
the usual suspects who are both upstreams and Debian Developers) to attend.
I don't know if Lennart Poettering changed any minds about systemd with his
talk, but I was happy for the opportunity to buy him a beer. I didn't get
to Monty's talk, but it was excellent to see him attend as well.
Finally, I got to meet old friends I'd not seen in years, and new ones I've
not met in real life before. We're still not sure where this whole DebConf
thing is going -- will it be all about the cheese and wine party and
greybeards in 20 years time? But one thing we know is we enjoy our little
slice of the year where kilts and coding are equally unremarkable,
where problems that seem intractable online somehow solve themselves in
person, where we come away with ideas for an entire year and memories for a
lifetime.
Eric (a fellow Fedora board member) has a post describing 
Happy twentieth birthday, Debian! For the celebration at 
Hi everyone! We now have both Qt4 and Qt5 in the archive. Those using Qt4 should not need to make any changes in their packages, although you can be extra-safe with a few steps. Don't rush, just read below.
I recently had to migrate the main 
So 
One of my new favorite languages is a peppy little