Upgrading from Debian 7 (Wheezy) to 8 (Jessie)

I began updating various servers from Debian 7 (Wheezy) to Debian 8 (Jessie). Here's what I learnt.

Spamassassin no longer looks to /etc/defaults/spamassassin's 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 a2enconf and a2disconf commands which work like a2ensite a2dissite etc.

Also, NameVirtualHost is deprecated - apparently you can just delete these lines now. Great, that was annoyingly unecessary.

Also 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 /etc/apache2/mods-available/mpm_prefork.conf

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
Deny everything
Order allow, deny
Require all denied
Deny everything
Order deny,allow
Deny from all
Require all denied
Allow everything
Order deny,allow
Require all granted
Allow everything
Order allow,deny
Allow from all
Require all granted
Allow only one IP
Order allow,deny
Allow from
Require ip
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 /etc/default/grub, then 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.