I’ve had an eventful couple of months revolving around wanting to move this web server from a hosted VPS to my home and both the old and new environments running into upgrade troubles.
The hosted VPS was an old stable Debian version running under Virtuozzo with a 2.4 kernel. For years it has been running flawlessly. During a recent upgrade it started installing a new glibc and other programs relying on a 2.6 kernel. I guess my old Debian stable went out of support, but I’m surprised it tried going 2.6. Of course I have no control over the kernel, so I was in a bad spot. The critical services were still running, so I kept them running. (I am pretty sure most services would fail upon restart.) I had some problems with mismatched libraries failing, but overall the web server, DNS servers and sites kept running. Since I was planning on migrating to my home server anyway, I decided to keep it limping along while I prepared my home server environment.
My home environment was a Hardy 8.04 LTS Ubuntu server running OpenVZ containers. This has been stable for at least a couple of years, but in anticipation of moving my web server into a container there I decided to upgrade to Lucid 10.04 LTS. My mistake was not previewing major changes that would affect me. Each one probably deserves its own blog, so I’ll summarize here for now.
OpenVZ deprecated, LXC is the new paravirtualization component. Good news: it’s in the main kernel tree. Bad news: it’s different enough from OpenVZ to introduce a new learning curve, and the documentation and support tools are immature as of mid-2011.
mod_fcgid behaves differently: On my small VPS I had apache and mod_fcgid configured for optimal efficiency in a small RAM footprint, but the same configuration options caused failures on the new mod_fcgid. The short story is that mod_fcgid became an Apache project in 2009, and they’ve made some changes. They’re actually decent changes, but they don’t work with my old config options when trying to minimize process count and RAM usage. mod_fcgid will now by default avoid closing the first three processes for each class, “class” being defined in my case as the php file called in the URL. Since RAM is not an issue on the home server I removed my process count constraints, but I intend to toy with the settings until I can get it like I used to have it: one to four php_cgi processes handling all php requests.
SysV init -> Upstart init: Lucid init is a hybrid between the new Upstart init and the old Sys V init. In many ways I like this, and when installing Ubuntu packages this wouldn’t really be an issue, but inside the LXC containers it has thrown me for a few loops because Upstart keys on events that may not happen inside a container the same way they do on the host. The good news is that in-container init scripts and service starts that key on filesystem mounting and network interface availability can be changed to “start on startup” since you can assume a container will have its filesystem and network set up before the init system is called. In particular you might want to be sure that /etc/init/rc-sysinit.conf is changed to “start on startup” inside LXC containers, and I had to do the same for /etc/init/mysql.conf .