Schlagwort-Archiv: debian

Hetzner Cloud: LUKS remote unlock on Debian

Von | | , ,
Einen Kommentar hinterlassen

I recently decided to migrate my mailserver away from the (old) Uberspace 6 to a new, self administrated machine. Uberspace has been great but over time I demanded more features than they offer.
Due to the fact that I want to keep the mailserver for my primary mail address separated from my main server, I once again compared multiple virtual server/cloud server hosters. I decided to give Hetzners new Cloud Server a go as you can use custom images to build the OS (Debian is the distribution of my choice) as you like. That was particularly important to me because as this will be the place where all my existing private mails will be stored it has to be fully encrypted. Because of that I needed some kind of remote unlock mechanism to be able to unlock the machine after a reboot without the need to log into the Hetzner web interface and use the console.
There are plenty of how-to’s on how to achive this with Beardrop as SSH server in initramfs and Busybox as shell but none of these seemed to work as Beardrop never got available on the configured port. What I did notice was this error message during boot up:

SIOCSIFNETMASK: Cannot assign requested address

This correlates with an article in the Hetzner wiki about the default gateway for custom installations on cloud servers as their GW is outside of the used subnet. Even when using DHCP to retrieve the IP and default GW, the setup fails as NetworkManager refuses to use the given GW. The same for static IP configuration in /etc/initramfs-tools/initramfs.conf or /etc/default/grub. So probably Dropbear does not start because the network fails.
I found only one report on this exact problem after hours of trial and error and searching the web for help.

tl;dr

To fix this you need to hook in before the network is set up and add the default route yourself. To do that you can either add a hook in /usr/share/initramfs-tools/hooks or (like the Serverfault thread suggests) add two statements to /usr/share/initramfs-tools/scripts/functions:

ip route add ${IPV4GATEWAY}/${IPV4NETMASK} dev ${DEVICE}
ip route add default via ${IPV4GATEWAY} dev ${DEVICE}

To ensure that this methods works you have to remove the static IP configureation in grub and/or initramfs.conifig and enable DHCP again!

Quick Info: Debian stuck at boot due to IPv6

Von | | , ,
Einen Kommentar hinterlassen

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

Von | | , ,
Kommentare deaktiviert für 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.

SoYouStart and IPv6

Von | | , ,
Einen Kommentar hinterlassen

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

Von | | , ,
4 Kommentare

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!