Upgrading Woody to Sarge

Debian have just released sarge as the new stable distribution which means I need to start upgrading my machines. Before I upgraded the main machine though I decided to run through it on a UML machine first to see where the gotchas are.
Things to watch out for
1. The sshd config file gets an extra parameter added to it ie.
UsePAM yes
When I tested ssh after the upgrade I was unable to log into the machine and I found that I had to remove this option or set it to “no” to get ssh to work. This surprised me because I was not expecting Debian to modify config file without my knowledge.
2. The RECORD option is no longer valid
xinetd[5691]: Bad log_on_failure flag: RECORD [file=/etc/xinetd.conf] [line=13]
xinetd[5691]: A fatal error was encountered while parsing the default section. xinetd will exit.
xinetd[5691]: Exiting…
this prevents xinetd from starting up. This was also noticed while testing the machine after the upgrade.
What follows is roughly the files the upgrade offered to update to new versions. Since I had modified most of these I selected the default option which is “N” ie do not upgrade to the maintainers version. This may have been the reason the ssh upgrade wasn’t too smooth. However I would not recommend taking the maintainers version if you have customized the files.
Configuration file `/etc/pam.d/login’
Configuration file `/etc/securetty’
Configuration file `/etc/pam.d/passwd’
Configuration file `/etc/bash.bashrc’
Configuration file `/etc/init.d/sysklogd’
Configuration file `/etc/services’
Configuration file `/etc/init.d/bind9′
Configuration file `/etc/bind/named.conf’
Configuration file `/etc/bind/db.root’
Configuration file `/etc/init.d/xinetd’
Configuration file `/etc/xinetd.conf’
During the upgrade you may also be asked to add any users and groups that are
missing from the default debian lot. The following bits are just the output of some other configurations options and warnings of things that have changed between the woody and sarge.
Configuring ssh
Environment options on keys have been deprecated This version of OpenSSH
disables the environment option for public keys by default, in order to avoid
certain attacks (for example, LD_PRELOAD). If you are using this option in an
authorized_keys file, beware that the keys in question will no longer work
until the option is removed. To re-enable this option, set
“PermitUserEnvironment yes” in /etc/ssh/sshd_config after the upgrade is
complete, taking note of the warning in the sshd_config(5) manual page.

Configuring man-db
This version of man-db is incompatible with your existing database of manual
page descriptions, so that database needs to be x rebuilt. This may take some
time, depending on how many pages you have installed; it will happen in the
background, possibly slowing down the installation of other packages. If you do
not build the database now, it will be built the next time
/etc/cron.weekly/mandb runs, or you can do it yourself using ‘mandb -c’ as user
‘man’. In the meantime, the ‘whatis’ and ‘apropos’ commands will not be able to
display any output. Incompatible changes like this should happen rarely. Should
mandb build its database now?

So far I have upgraded two machines and had the same trouble with ssh and xinetd both times. If I encounter any mmore trouble I will add more here.

Creating a Debian Package

Ever since I started using Debian I have meant to try and create a debian package for various reasons,
a) I am just a curious bugger.
b) I am just a curious bugger.
today was my chance to have a go and see what exactly it involves or should I say what it involves to create a very minimal package.
The reason for this is that I have written a Content Management System that uses about 20 Perl modules some internal some external and rather than worry when it comes to the install or an upgrade we have decided to stick the whole thing in subversion and then wrap each release in a debian package. We have several sites to run this from so the more we can automate the better particularly if I can get the automatic testing sorted. Using subversion and the debian packages the whole system should be relatively low maintainance as far as upgrades are concerned and this is important. We don’t want to scrub ourselves into the upgrade corner and find we have neither the time or the budget to spend time on an upgrade. We want it automated for us and although it might be a pain in the arse to put in place it will pay dividends when we come to change things later.
We also have a postgres schema and some config files that need taking care of but as I found out today this is relatively simple using the debian packaging tools.
I suppose I should write a simple howto about how I did it because using the debian new maintainers guide is not really the best tutorial for those wishing to package their own application for internal use. I imagine there are some other tutorials around but I didn’t find them.

AMD64 and MSI K8T

Well, I got the AMD64 today and got it all put together with a few little mishaps. I am using an MSI K8T Neo motherboard which was bought simply because I couldn’t wait 5 days for the Asus which I would have preferred simply because it can take an extra gig of RAM over the MSI. I also had a problem with the power supply that was in the tower. Who would have thought that an ATX power supply wouldn’t have the proper 4 pin connector required to power the chip. I ripped Jen’s power supply out and used it. I can now safely say that an AMD 64 with 1 SATA 160Gb two 20Gb hard disks, CD player and 32Mb nvidia video card will run on a 300Watt power supply or at least it will on mine. I will be ordering a bigger quieter one but more on that later.
I uses an old netinst CD that I had laying around to put woody on and the immediately upgraded to sarge. All this went with very little mishap and so far the hardware has been running fine. All I need now is SATA support, I’ll do that tomorrow.