Predictable network interface names are all the rage in Linux distros these days. My systems are of various vintage so most have carried on with eth0 and eth1 through upgrades by having old udev rules kept around.
To get with the times a few steps are needed: (more…)
If you have already upgraded to jessie and have systemd as init, you can switch back with these commands:
apt-get install -y sysvinit-core reboot apt-get purge -y systemd
Running with sysvinit works better on my servers, as daemons have a chance of doing their own graceful shutdown before the network is brought down.
Before upgrading to jessie, create /etc/apt/preferences.d/use-sysvinit:
Package: systemd-sysv Pin: release o=Debian Pin-Priority: -1
See also: How to stay with sysvinit in Debian Jessie by Petter Reinholdtsen
The latest odd fix for Asterisk after an upgrade (11.13.0~dfsg-1~bpo70+1):
cd /usr/share/asterisk/sounds && ln -s en_US_f_Allison en
I don’t know when this broke. I found out because calling voicemail would fail (due to a missing password prompt sound file).
I’m not sure what failed last night, but I’m guessing the cable Internet connection was down. Interestingly, unbound had stopped resolving even local zones configured with stub-zone and stub-addr directives. This was unexpected: stub-zones are supposed to work “without referring to the public Internet” per the unbound.conf manual page.
To mitigate the issue I wanted to have backup name servers in resolv.conf (ones using a different Internet connection) even on the resolving name server hosts themselves. With resolvconf that boiled down to creating /etc/default/resolvconf with the following setting in it:
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=no
This way name servers configured in /etc/network/interfaces (using dns-nameservers directives) are included in resolv.conf even when unbound has been started.
However, this is a poor workaround, as I don’t have multiple Internet connections at every site.
Debian 7.0 “wheezy” was officially released about a week ago. I’ve been running it on a couple of systems for a few months already because of the more recent software versions available on it. Today I upgraded one of the shell servers, a couple of days ahead of the originally posted schedule due to security updates to MySQL (DSA-2667). As usual for Debian, the upgrade process is well documented1 and robust. However, here are some notes for upgrading the next instance. (more…)
Just a short note on getting a minimal Asterisk environment installed on current versions of Debian and Ubuntu:
aptitude install asterisk m-a a-i zaptel modprobe ztdummy
Also add ztdummy to /etc/modules so it gets loaded when the system starts.
If the m-a command is not found, install the module-assistant package.
I’ve been always a fan of the robust upgrade procedure documented in the Debian release notes, which has worked without problems even over ssh to remote machines. This has made upgrading very painless (at least since sarge — I haven’t used Debian actively longer than that).
Yesterday I ran into a problem, though, which was only saved by having remote console access. I have a system with a slightly more complicated disk setup: it has two SCSI disks running as a RAID 1 array using md and lvm. Upon rebooting after the upgrade, the system didn’t reappear on the network. What I found on the console was the initramfs panic shell: the root file system had not been found. Rebooting the old etch kernel worked fine.
The workaround proved to be very simple, once I distilled it from the search engine results. Just add rootdelay=10 to the kernel options in the bootloader. I’m using GRUB so this translates to editing the kopt line in /boot/grub/menu.lst and running update-grub.
I had also added raid1 to modules in /etc/initramfs-tools and regenerated the initrd, but that (alone) didn’t help. I’m not even sure it is needed at all — it might already be included anyway when using MODULES=most in initramfs.conf.