Paranoid, Init

Having marvelled at the er… unique nature of MikeeUSA’s Systemd Blues: Took our thing (Wooo) blues homage to the perils of using systemd, I decided what the world actually needs is something from the metal genre.

So, here’s the lyrics to Paranoid, Init.

Default soon on Debian
This doesn’t help me with my mind
People think I’m insane
Because I am trolling all the time

All day long I fight Red Hat
And uphold UNIX philosophy
Think I’ll lose my mind
If I can’t use sysvinit on jessie

Can you help me
Terrorise pid 1?
Oh yeah!

Tried to show the committee
That things were wrong with this design
They can’t see Poettering’s plan in this
They must be blind

Some sick joke I could just cry
GNOME needs logind API
QR codes gave me a feel
Then binary logs just broke the deal

And so as you hear these words
Telling you now of my state
Can’t log off and enjoy life
I’ve another sock puppet to create

rsync: “Inflate (token) returned -5”

Today one of my rsync backups began failing with:

inflate (token) returned -5
rsync error: error in rsync protocol data stream (code 12) at token.c(604) [receiver=3.0.3]
rsync: writefd_unbuffered failed to write 373 bytes [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1544) [generator=3.0.3]

It was repeatable when trying to transfer the same file (a large gzipped SQL dump file).

It turned out to be a bug in that version of rsync.

rsync 3.0.3 comes with Debian lenny. In order to get a newer version I have had to use lenny-backports for this. That gets me rsync v3.0.7, which does not exhibit this bug.

(Yes, I am aware that squeeze has been released and this host should be upgraded to that. There is security support for lenny until at least February 2012.)

Linux, IPv6, router advertisements and forwarding

By default, a Linux host on an IPv6 network will listen for and solicit router advertisements in order to choose an IPv6 address for itself and to set up its default route. This is referred to as stateless address autoconfiguration (SLAAC).

If you don’t want a host to automatically configure an address and route then you could disable this behaviour by writing “0” to /proc/sys/net/ipv6/conf/*/accept_ra.

Additionally, if the Linux host considers itself to be a router then it will ignore all router advertisements.

In this context, what makes the difference between router or not are the settings of the /proc/sys/net/ipv6/conf/*/forwarding files (or the net.ipv6.conf.*.forwarding sysctl). If you turn your host into a router by setting one of those to “1”, you may find that your host removes any IPv6 address and default route it learnt via SLAAC.

There is a valid argument that a router should not be autoconfiguring itself, and should have its addresses and routes configured statically. Linux has IP forwarding features for a reason though, and sometimes you want to forward packets with a Linux box while still enjoying autoconfiguration. In my case I have some hosts running virtual machines, with IPv6 prefixes routed to the virtual machines. I’d still like the hosts to learn their default route via SLAAC.

It’s taken me a long time to work out how to do this. It isn’t well-documented.

Firstly, if you have a kernel version of 2.6.37 or higher then your answer is to set accept_ra to “2”. From ip-sysctl.txt:

accept_ra – BOOLEAN

Accept Router Advertisements; autoconfigure using them.

Possible values are:

  • 0 Do not accept Router Advertisements.
  • 1 Accept Router Advertisements if forwarding is disabled.
  • 2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled.

Functional default:

  • enabled if local forwarding is disabled.
  • disabled if local forwarding is enabled.

This appears to be a type of boolean that I wasn’t previously familiar with – one that has three different values.

If you don’t have kernel version 2.6.37 though, like say, everyone running the current Debian stable (2.6.32), this will not work. Helpfully, it also doesn’t give you any sort of error when you set accept_ra to “2”. It just sets it and continues silently ignoring router advertisements.

fuuuuuuuuuuuuuuuuuuuuuu

Fortunately Bjørn Mork posted about a workaround for earlier kernels which I would likely have never discovered otherwise. You just have to disable forwarding for the interface that your router advertisements will come in on, e.g.:

# echo 0 > /proc/sys/net/ipv6/conf/eth0/forwarding

Apparently as long as /proc/sys/net/ipv6/conf/all/forwarding is still set to “1” then forwarding will still be enabled. Obviously.

Additionally there are some extremely unintuitive interactions between “default” and “all” settings you may set in /etc/sysctl.conf and pre-existing interfaces. So there is a race condition on boot between IPv6 interfaces coming up and sysctl configuration being parsed. martin f krafft posted about this, and on Debian recommends setting desired sysctls in pre-up headers of the relevant iface stanza in /etc/network/interfaces, e.g.:

iface eth0 inet6 static
    address 2001:0db8:10c0:d0c5::1
    netmask 64
# Enable forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
# But disable forwarding on THIS interface so we still get RAs
    pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/forwarding
    pre-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
    pre-up echo 1 > /proc/sys/net/ipv6/conf/all/accept_ra
    pre-up echo 1 > /proc/sys/net/ipv6/conf/default/accept_ra

You will now have forwarding and SLAAC.

everything went better than expected

Recently updated gnutls then found you can’t connect to LDAP?

If you recently installed this update:

gnutls26 (2.4.2-6+lenny2) stable-security; urgency=high
  * Non-maintainer upload by the Security Team.
  * Fixed CVE-2009-2730: a vulnerability related to NUL bytes in
    X.509 certificate name fields. (Closes: #541439)
    GNUTLS-SA-2009-4

 -- Giuseppe Iuculano <iuculano@debian.org> Sun, 01 Nov 2009 21:29:06
+0100

and then found that your applications began failing to connect to your LDAP server, you may want to check that your SSL certificate is valid. Along with this update it seems that the default behaviour changed to being more strict. In my case I was using self-signed SSL certificates without the CA being available.

You can disable the verification if you don’t want it by adding:

TLS_REQCERT     never

in /etc/ldap/ldap.conf on each client machine.

New fileserver for home

specialbrew's disks

Recently my fileserver, becks, was not only getting filled to capacity but was also undergoing some severe performance problems. It’s by no means a poorly-specced machine (not for home use anyway) but my use of rsnapshot has grown so much in the last 6 months that it was no longer up to the job.

Read on for the saga of its replacement.

Continue reading “New fileserver for home”

Private voting in Debian?

Martin, why would you want voting private? In most societies and voting systems people are entitled to their opinions, to state them, and campaign on behalf of others if they like.

Note that I’m not expressing any opinion on the content of these posts (I haven’t been following it and I’m not a DD anyway, so my opinion isn’t worth much), only that I can’t understand why you’d want to stop people making them.

Linux Gazette — Configuring Apache for Maximum Performance

Linux Gazette has an interesting article on Configuring Apache for Maximum Performance. It’s a good read and I can’t find fault with anything said, although it would have been nice if it touched on some of the alternative lightweight web servers out there, especially for the static content, e.g. Lighttpd (now in Sarge backports!). But then, it was about Apache I suppose.

Luckily I also came across another article about using Lighttpd to serve certain content behind Apache.

“The following signatures couldn’t be verified”

The last two days I’ve been getting the following breakage email from the daily updates script on one of my etch Xen domains:

/etc/cron.daily/local-apt:
W: GPG error: http://admin.curacao.strugglers.net etch
Release: The following signatures couldn't be verified
because the public key is not available: NO_PUBKEY
010908312D230C5F
W: You may want to run apt-get update to correct these problems

On further investigaton it seems to be because etch’s APT is now checking signatures against a GPG key I do not have configured. Thanks to JackieBrown’s post at DebCentral (and Google), a solution is found. Read more on the wiki.