Following the recent release of Debian 4.0 (etch), I decided to upgrade my backup server, chrome, which was running sarge. My last experience of a Debian upgrade was very good, so my expectations were high.
I followed the instructions in the Release Notes, which went fine until section 4.5.4.2:
First, check whether you have the libfam0c102 and xlibmesa-glu packages installed.
# dpkg -l libfam0c102 | grep ^ii
# dpkg -l xlibmesa-glu | grep ^ii
It looked like I had both of these, so I went ahead and followed the next upgrade step:
# aptitude install x11-common libfam0 xlibmesa-glu
Then I got this:
Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done Some packages had unmet dependencies. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following packages have unmet dependencies: libfam0c102: Conflicts: libfam0 but 2.7.0-12 is to be installed.
I found some advice on the net that this could be fixed by issuing:
aptitude install libfam0=2.7.0-12
So that's what I did. That seemed to work ok, so I tried to
repeat the above step, but missing out libfam0:
# aptitude install x11-common xlibmesa-glu
...
Errors were encountered while processing:
libgconf2-4
liborbit2
gconf2
It was late, I was stupid; I pressed on regardless...
# aptitude install linux-image-2.6-486
Errors were encountered while processing:
libgnome2-common
metacity
libgnomevfs2-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ack! Something bad happened while installing packages. Trying to recover:
Uh oh. This didn't look good. I checked the status of X. Hmm,
xserver-xfree86was still installed; perhaps that was the
problem?
# apt-get remove xserver-xfree86
Reading Package Lists... Done
Building Dependency Tree... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
libgnome2-common: Depends: gconf2 (>= 2.7.92) but it is not going to be installed
libgnomevfs2-common: Depends: libbonobo2-0 (>= 2.8.0) but it is not going to be installed
Depends: libgconf2-4 (>= 2.8.1) but it is not going to be installed
Depends: libglib2.0-0 (>= 2.6.0) but it is not going to be installed
Depends: libgnomevfs2-0 (>= 2.8.3-7) but it is not going to be installed
Depends: liborbit2 (>= 1:2.10.0) but it is not going to be installed
Depends: libsmbclient (>= 3.0.2a-1) but it is not going to be installed
Depends: gconf2 (>= 2.8.0-1) but it is not going to be installed
Depends: shared-mime-info but it is not going to be installed
Depends: desktop-file-utils but it is not going to be installed
metacity: Depends: libatk1.0-0 (>= 1.7.2) but it is not going to be installed
Depends: libgconf2-4 (>= 2.8.1) but it is not going to be installed
Depends: libglib2.0-0 (>= 2.4.7) but it is not going to be installed
Depends: libgtk2.0-0 (>= 2.4.4) but it is not going to be installed
Depends: libmetacity0 (>= 1:2.8.1) but it is not going to be installed
Depends: liborbit2 (>= 1:2.10.0) but it is not going to be installed
Depends: libpango1.0-0 (>= 1.6.0) but it is not going to be installed
Depends: libstartup-notification0 (>= 0.7-1) but it is not going to be installed
Depends: gconf2 (>= 2.6.2-1) but it is not going to be installed
W: You may want to run apt-get update to correct these problems
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
Aaaaaaargh. At this point I gave up, planning to return to it when I was not tired and emotional.
A couple of days later I had enough time to revisit the upgrade.
I first decided on following the suggestion of aptitude and run
apt-get -f install. This suggested I remove pretty much
all of X, but I didn't care as I was already considering it was more
trouble that it was worth on a slow machine like chrome.
Unfortunately, at this point my memory is a little hazy. I think that is what I did, but I am not absolutely sure. Should have scripted the session, of course.
If my memory is correct, this appeared to do the trick. The
removal of vast swathes of X packages finished normally, and I was
able to run the aptitude dist-upgrade step without any
problems.
I decided to replace my existing Apache 1.3 version with apache2
(Apache 2.2). Adapting to the new configuration setup was not too
bad. Local configuration is placed in the
/etc/apache2/httpd.conf file. For me, all this contains is:
# DirectoryIndex: Name of the file or files to use as a pre-written HTML
# directory index. Separate multiple entries with spaces.
#
<IfModule mod_dir.c>
DirectoryIndex index.html index.htm index.shtml index.cgi
</IfModule>
The new method of enabling sites took me a little while to figure
out. I need to offer two site, one for hydrus and
one for the, uh, other site. I used the apache NameVirtualHost *
directive (conveniently provided by the defaultsite
configuration file, and then added the virtual sites using
VirtualHost directives as shown in the O'Reilly Apache
(3rd Edition) book I own.
In /etc/apache2/sites-available, I created two files; the
first fs:
<VirtualHost fs.hydrus.org.uk>
ServerName fs.hydrus.org.uk
ServerAdmin www@hydrus.org.uk
DocumentRoot /home2/www/fs/data/
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
..other directives..
</VirtualHost>
The other, hydrus, contained:
<VirtualHost www.hydrus.org.uk>
ServerName www.hydrus.org.uk
ServerAdmin www@hydrus.org.uk
DocumentRoot /home2/www/hydrus/data/
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
..other directives..
</VirtualHost>
Links are then created in the /etc/apache2/sites-enabled
directory to the actual files, using a naming convention to ensure
site configuration files are read in the right order. That is:
cd /etc/apache2/sites-enabled ln -s ../sites-available/hydrus 001-hydrus ln -s ../sites-available/fs 002-fs
When starting apache, this produced these warnings:
[warn] VirtualHost www.hydrus.org.uk:0 overlaps with VirtualHost fs.hydrus.org.uk:0, the first has precedence, perhaps you need a NameVirtualHost directive
Well, I did have a NameVirtualHost directive. What was
going on? It seems the setup as described in the O'Reilly book is
wrong; the <VirtualHost> argument must not be a site
name, but *, otherwise the warnings as shown above are
issued. The actual sitenames are defined by the ServerName (and
ServerAlias if required). Virtual sites should be defined
something like:
<VirtualHost *>
ServerName fs.hydrus.org.uk
ServerAdmin www@hydrus.org.uk
DocumentRoot /home2/www/fs/data/
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
..other directives..
</VirtualHost>
<VirtualHost *>
ServerName www.hydrus.org.uk
ServerAdmin www@hydrus.org.uk
DocumentRoot /home2/www/hydrus/data/
<Directory />
Options SymLinksIfOwnerMatch
AllowOverride None
</Directory>
..other directives..
</VirtualHost>
Of course, don't forget the NameVirtualHost * directive.
It took me a while to work out why user files were not being displayed; I had to activate this feature by:
ln -s /etc/apache2/mods-available/userdir.conf /etc/apache2/mods-enabled/userdir.conf ln -s /etc/apache2/mods-available/userdir.load /etc/apache2/mods-enabled/userdir.load
I replaced exim (i.e. exim 3) by exim4. I'd hacked around with the
configuration of exim to allow mails to be
sent to machines on the local network. These additions needed to be
included in the exim4.conf.template, but with a slight
modification, as the transports of exim 3 are part of the router
section. I had to add a condition to the locally defined router
local_network to ensure that it was not used when the
recipient was on the local machine.
Add this text to the top of the routers section of
exim4.conf.template:
# In the ROUTES section, a new router is defined, which handles
# recipient addresses on local domain machines - anything ending in
# the domain name, and unadorned host names (assuming they
# contain no digits). If the recipient does not match anything
# in the domains value, the smarthost router will be used.
local_network:
driver = dnslookup
transport = local_smtp
domains = ! +local_domains : *.hydrus.org.uk:^[A-Za-z]*\$
And, add this text to the top of the transport section:
# Define a transport for local machines. This performs
# rewriting of the envelope (return_path) and headers to
# indicate the mail is from chrome.
local_smtp:
driver = smtp
return_path = ${local_part}@chrome.hydrus.org.uk
headers_rewrite = *@hydrus.org.uk ${1}@chrome.hydrus.org.uk fr
You will need to replace the local host name (chrome) and domain name (hydrus.org.uk) as required for your site.
Printing had stopped working on the newly etched chrome. There was
no /dev/lp0. At first I suspected some arcane
udev problem, but it turned out to be solved by adding lp
to /etc/modules.
