I began updating various servers from Debian 7 (Wheezy) to Debian 8 (Jessie). Here's what I learnt.
Spamassassin no longer looks to
ENABLED=1 to determine whether it should run. Instead you have to issue
systemctl enable spamassassin.service This was causing exim to fail to accept messages.
Stunnel4 now has TLSv1 to be used in place of SSLv3 (or, at least you can no longer use SSLv3, which is a good thing).
MariaDB 10 finally in Debian repos! I've been running MariaDb 5.5 from the project's own repos and wanted to upgrade to v10 (v5.5 is not in the Debian repos). I found that stopping the service, running the main dist-upgrade, then running a separate
apt-get install mariadb-server command was the best workflow. Nb. v5.5→v10 is a one-way upgrade as MariaDb now has different features to MySQL.
Samba / cifs-utils: This used to allow
user as mount option (allow non-root users to mount) as well as
user=foo (mount as foo) but having two user entries in the options of
fstab caused mount not to work.
Apache 2.2 → 2.4
Apache Deserves it's own section!
It moves all its scrappy config bits into
conf-available/*.conf with new
a2disconf commands which work like
NameVirtualHost is deprecated - apparently you can just delete these lines now. Great, that was annoyingly unecessary.
SSLCertificateFile is now expected to contain the intermediate certificate(s) as well as the main one and
SSLCertificateChain is deprecated and must be removed (AH02559).
Less well documented, the ITK module that allows running different virtualhosts as different users (good for security) causes a problem when trying to set the gid. Thanks to gaiterjones for the answer to this: add
LimitUIDRange 0 2000 to
The confusing Order allow,deny .. Allow from ... Deny from syntax has been removed in favour of a more sensible and extensible format.
|Meaning||Previous Allow/Deny config||New Require config|
Order allow, deny
Require all denied
Order deny,allow Deny from all
Require all denied
Require all granted
Order allow,deny Allow from all
Require all granted
|Allow only one IP||
Order allow,deny Allow from 188.8.131.52
Require ip 184.108.40.206 Require all denied
I can't summarise this much here. But I think the idea is to use
systemctl start|stop|restart|reload|status <service> wherever possible because otherwise it gets confused. e.g. Apache hasn't been systemd-ified yet and you can start/stop it with
apache2ctl as usual but if you do systemd won't know it's running.
I have so far upgraded 7 machines. 2 on my own hardware, 3 with Bytemark's BigV and 2 with Linode. One to go with heart internet. All have gone smoothy except the Linodes which caused a kernal panic on reboot. Hmmm.
This is probably an artefact of history, but in case you followed the same path, I'll document it briefly.
Linode have only recently moved from Xen to KVM. On Xen, VMs were set up using Linode's own kernels, not the distribution kernels. This was frustrating for me because it led to problems when software (e.g. firehol) probed for certain kernel modules only to find there was no kernel. And I found it a bit weird. So I had opted to use their 'pv-grub' method of booting which meant I had my own kernel, and it was booted from grub-legacy as per Linode's instructions at the time.
When I migrated to KVM I was still using grub-legacy and after the Debian upgrade it failed to boot the new kernel. Thankfully it would still boot the older (Wheezy) kernel. My BigV machines also use grub-legacy, still, and they're booting fine with Debian 8.
After firing up a couple of practice VMs to try things out I found that if you can boot your machine you can then run
apt-get remove --purge grub*
Then follow Linode's instructions about instaling grub2 (
apt-get install grub2, then modify
update-grub then update your Linode's 'configuration profile' to Grub2 then reboot).
This got the new kernel booting (phew) although you can't see the grub menu for some reason under "Lish", their out-of-band console access tool.
So if you're on a KVM Linode and you're using grub-legacy, change to grub2 before the update and save yourself a lot of worry.