Quick Info: Debian stuck at boot due to IPv6

Lately I bought a couple HDDs to finish my home made NAS running OpenMediaVault Debian. I personally think that IPv6 should be supported by any means, so I activated it right after finishing the installation process and everything was working fine. I shut down the system during the night hours because there was no reason to leave it on because I had not yet copied any data onto the NAS.
Next day the system got stuck at bootup! At first I thought something messed up the resolv.conf because the bootup process was throwing a couple errors that indicated something like that but in the end it was the NIC waiting for an IPv6 lease from the DHCP server runnig on my fritzbox (don’t judge me, if I could this thing would take a visit to the trash can asap). The DHCP was somehow misconfigured so that Debian was waiting endlessly for an address.
I fixed it by enabling IA_PD and IA_NA in the fritzbox GUI and voilà Debian finished booting right away.

Quick Info: Debian hängt im Bootprozess dank IPv6

Ich habe vor kurzem einige HDDs gekauft, um mein selbst gebautes OpenMediaVault Debian NAS zu vollenden. Ich persönlich bin der Ansicht, dass IPv6 unter allen Umständen supported werden sollte, also aktivierte ich es nach Abschluss der Installation und anschließend lief alles Fehlerfrei. Über Nacht habe ich das NAS runter gefahren, da es noch keinen Inhalt hatte der dauerhaft verfügbar sein musste.
Beim nächsten Boot blieb Debian dann an einem Punkt hängen und weigerte sich weiter zu machen. Auf den ersten Blick sah es nach einem Fehler in der resolv.conf aus, da während des Boots einige Fehlermeldungen dazu kamen aber am Ende stellte sich raus, dass der NIC auf eine IPv6 Adresse vom DHCP Server auf meiner FritzBox (bitte keine Kommentare dazu, wenn ich darüber entscheiden könnte, dann wäre das Teil schon lange im Müll). In der DHCP Config war allerdings irgendetwas verstellt weshalb Debian endlos auf eine Adresse wartete.
Die Lösung für das Problem war IA_PD und IA_NA via FritzBox GUI zu aktivieren und voilà: der Boot lief fehlerfrei durch.

Bestehende Postfächer auf Uberspace abrufen

Ich habe mir kürzlich einen Uberspace zugelegt, um die Erreichbarkeit von einigen kritischen Services zu sichern. Unter anderem läuft mein Mailverkehr zukünftig nicht mehr über den Freemailer GMX, sondern über meine name.tld auf dem Uberspace. Zumindest in den ersten Monaten möchte ich allerdings weiterhin die Mails von meinen GMX Postfächern abrufen weil es immer irgendeinen Account gibt, den ich noch nicht umgestellt habe oder eine mir schreibende Person den Adresswechsel bisher nicht mitbekommen hat.
Fetchmail ist auf den Uberspaces nicht installiert, dafür aber das offenbar sogar bessere Getmail. Die Konfiguration ist trivial einfach und die vorhandene Doku mehr als ausgiebig.

Der Abruf meiner GMX Postfächer funktioniert und liefert alles in mein entsprechendes Maildir aus. Soweit so gut. Ich hätte aber gern Spam wie zum Beispiel die GMX Newsletter auch als solchen markiert und aussortiert und nicht in meiner Inbox. Getmails Filter-Option bringt mir leider nicht mehr als einen [SPAM] Tag im Betreff und DSPAMs potentielle Spamwahrscheinlichkeit im Header weil Getmail die Mails nur an die Filter weitergibt und wieder abholt. Einzige Verarbeitungsoptionen nach den Filtern wären dann drop oder keep was mir im Falle eines False Positives nicht erlaubt die Mail trotzdem zu sehen oder mir weiterhin dem Spam in die Inbox zustellt.

Mein Lösungsansatz ist die Mails nach dem Abrufen durch Getmail in den Uberspace Mailflow (in meiner Konfiguration netqmail -> maildrop -> SpamAssassin -> DSPAM -> Maildir) einzubinden. Dadurch würden sie ebenfalls die Filter durchlaufen aber danach von Maildrop auch entsprechend wegsortiert werden.
Getmail bietet als MDA qmail-local an was in der Theorie gut passen würde. Leider setzt Getmail einen Multidrop-Retriever für MDA_qmaillocal als Destination voraus und das trifft bei GMX/Web.de nicht zu.
Dies lässt sich aber einfach umgehen, indem man als Destination MDA_external mit selbst definierten qmail-local Parametern verwendet:

[destination]
type = MDA_external
path = /var/qmail/bin/qmail-local
arguments = ("-N", "unix user", "/pfad/maildir", "%(local)", ".qmail Trennzeichen", ".qmail-EXT bei virtuellen Postfächern", "%(domain)", "%(sender)", "alternative Zustelladresse")

Die Variablen (alles wo ein % vor steht) werden durch Getmail mit den erforderlichen Werten gefüllt. Der qmail-local Pfad ist natürlich nicht absolut und muss für die entsprechende Installation angepasst werden. Alles in den eckigen Klammern, muss mit euren gewünschten Werten gefüllt werden.
Ein Beispiel:

arguments = ("-N", "max", "/user/max/", "%(local)", "-", "max", "%(domain)", "%(sender)", "max@mustermann.tld")

Beim Mailabruf wird jetzt ganz normal qmail aufgerufen der dann nach der passenden .qmail-EXT (in unserem Beispiel .email-max) Datei sucht in welcher der Maildrop Aufruf zum Filtern und sortieren steht.

Mails kommen an und ich bin glücklich!

SoYouStart and IPv6

Some month ago I switched from Kimsufi to SoYouStart and for the first time I used my /64 IPv4 subnet. On my server only the loopback interface was configured but I heard that in some cases deployed servers had at least one IPv6 address set up. The aim of my configuration is to have two IPv6 addresses correctly set up on my Debian Wheezy server. The OVH wiki has an article which wraps the most important information up:

  • your kernel must support IPv6
  • the gateway is outside your used subnet
  • you have to set up a route to your gateway

The gateway address is composed of your subnet and fice FF nibbles.
If our subnet is 2001:41D0:1:46e::/64 then the gateway is 2001:41D0:1:4FF:FF:FF:FF:FF because we leave the first three nibbles an fill up the empty ones with FF.

Lets do the configuration:
Enable eth0’s inet6 protocol at boot and set the static IP 2001:41D0:1:46e::1 with subnet /64:

iface eth0 inet6 static
address 2001:41D0:1:46e::1
netmask 64

Automatically create a route to the OVH gateway and set it as default route on interface startup and delete it on interface shutdown:

up ip -6 route add 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0
up ip -6 route add default via 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0
down ip -6 route del 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0
down ip -6 route del default via 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0

Reboot!

No seriously. Reboot. Not a service networking restart or a start and stop via init.d, a good and healty reboot. For that reason alone to verify that the auto-config is working on bootup and your server does not stay offline after a unplanned restart due to a crash just because the config is not working.
Reboot is not an option? That leaves you with executing the commands yourself.

After doing so you should be able to use ping6 ipv6.google.com to connect to Google via 2001:41D0:1:46e::1.

Thanks to henk at freenode’s #debian-de!

SoYouStart und IPv6

Ich habe vor einigen Monaten meine Infrastruktur von Kimsufi zu SoYouStart umgezogen und dort erstmals mein verfügbares IPv6 /64 Subnet näher in Augenschein genommen. Zumindest bei meinem Server, war IPv6 nicht weiter konfiguriert als die Loopback Adresse fe80:: aber angeblich soll es auch Deployments mit mindestens einer gekonften IPv6 Adresse geben.
Ziel meiner Konfiguration ist es, zwei IPv6 Adressen auf Wheezy eingerichtet und nutzbar zu haben. Im OVH Wiki gibt es zum Thema weitere IPs hinzufügen einen Artikel der die wichtigsten Informationen zusammenfast:

  • dein Kernel muss IPv6 fähig sein
  • das Gateway befindet sich außerhalb deines Subnets
  • zum Gateway muss eine eine Route gesetzt werden

Die Gateway Adresse setzt sich zusammen aus deinem Subnet und fünf FF Nibbles.
Haben wir das Subnet 2001:41D0:1:46e::/64 so ist das Gateway 2001:41D0:1:4FF:FF:FF:FF:FF weil wir die ersten dreieinhalb Nibbles stehen lassen und die restlichen Nibbles mit FF auffüllen.

Kommen wir zur Konfiguration:
Interface eth0’s inet6 Protokoll beim Boot aktivieren und auf statisch mit der IP 2001:41D0:1:46e::1 und dem Subnet /64 setzen:

iface eth0 inet6 static
address 2001:41D0:1:46e::1
netmask 64

Beim Interface-Start eine Route zu OVHs IPv6 Gateway für dein Subnet hinzufügen, als Default setzen und beim Stop automatisch entfernen:

up ip -6 route add 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0 up ip -6 route add default via 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0 down ip -6 route del 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0 down ip -6 route del default via 2001:41D0:1:4FF:FF:FF:FF:FF dev eth0

Reboot!

Nein wirklich. Reboot. Kein service networking restart oder stoppen und starten via init.d sondern ein gesunder Reboot. Allein schon weil es beruhigt zu wissen das die Auto-Config beim Boot funktioniert und der Server nach einem Crash oder Ähnlichem nicht offline bleibt weil seine Interfaces die Config nicht schlucken.
Kommt nicht in Frage? Dann bleibt dir nur die Commands manuell auszuführen.

Jetzt solltest du mit ping6 ipv6.google.com in der Lage sein, eine IPv6 Verbindung zu Google aufzubauen oder deinen Server über 2001:41D0:1:46e::1 anzupingen.

Dank für Rat und Tat an henk in freenode’s #debian-de!