Last week the new Ubuntu was released, and I installed it on my workstation without issue. Today I spent some time installing it also on my main web and mail server; the one serving this blog and others. The installation wasn't quite hitch free.
First, I made sure the important and critical configuration and data files were backed-up on the remote storage. I can re-add the applications if I need to, but recreating the configurations can be difficult.
Then I made sure the server wasn't under heavy load. I knew I was doing a mid-day upgrade and that the software and servers, but still wanted to both minimize interruption and maximize CPU and network throughput.
Finally, I kicked off the upgrade. I took about an hour to download everything. I had to answer a few questions, for which I made notes in case it meant I'd have to revert something.
- The installation wanted to remove the user and group that the Apache server uses. It's installed by source and not by the package manager, so I'm sure the default system doesn't recognize the usefulness of the user/group. It's easy to recreate, so I let the upgrade remove them.
- Then the installation complained about changes in the logrotate configuration file. Changes put in by the e-mail server, which I can replace later, so I let it remove those.
- It also complained about configuration changes related to the e-mail server (more correctly, the e-mail client server...), which I also allowed it to replace. I don't think anyone uses POP or IMAP on the server any more, instead opting for the web-based access. Plus I keep meaning to move the end-user e-mail off to some other service; there are four of us who use it, I think.
- It complained about some IP forwarding changes I put in place while I was tinkering with IPv6 (and don't need) and network routing for virtual machines. I don't need it, I documented it, and I let the installer replace it.
- Finally, it complained about some changes I put into the login configuration for two-factor authentication. Easy to replace, so I let the installer undo those changes.
That done, the installer chugged for a while longer and exploded everything into its place. Then the minor mayhem started.
For some reason, the SpamAssassin package had an invalid regex in a configuration file that has worked for years. I had to hunt that down and remove it, and ultimately remove SpamAssasin from the package-installed (when did I do that?) and use the PERL installation mechanism. That regex failure lived through three reboot attempts (each failing attempt telling me I needed to reboot).
When SpamAssassin stopped being a problem the system started running mostly normally. As expected, Apache wouldn't start without re-adding the users, and once done, it's been working since. None of the other servers, including the sendmail server I feared would be trouble, were trouble. Even with the changed e-mail client configuration files, it has started and seems to be running (although it's unused).
The system is a recycled desktop, so it's got a GUI. Usually it sits displaying the system monitor which I turn on when working in the office for some additional light. The desktop failed to load, however. I found some bits and pieces and eventually ended up removing compiz, ubuntu-desktop, gdm, and lightgdm, and ultimately installing gdm, lightgdm, and xfce4 instead. It took a little tweaking of some auto-login and auto-start files, but now it's again sitting with its system monitor, and all of the services seem to be running.
It'll take a little getting used to the boxy style of xfce, but I so seldom interact with it that it'll not be a big deal. I do occasionally use VNC to control the desktop, and I haven't tested that, but it's on my list.
The server seems to be behaving, and in all the upgrade was pretty painless, even with the desktop tomfoolery. Next will be to move back from the desktop-migrated-to-server, and make a nice server with some LXC nodes or something so the upgrades can be more isolated and less painful.