Linux

Bei Einrichten einer meiner bind Instanzen als Secondary DNS bin ich unter Ubuntu 12.04 auf einen zunächst merkwürdigen Effekt gestossen:

Nach dem ich mit der initialen Konfiguration fertig war, wartete ich gespannt auf den anstehenden Zonentransfer. Leider blieb dig mir auch nach Minuten noch eine Antwort schuldig,

Also alles nocheinmal kontrollieren:

Bind war korrekt konfiguiert, das Verzeichnis für die slave-zone-Dateien war ebenfalls für den User bind zugänglich und er konnte auch Dateien erzeugen.

Daran lag es also nicht. Ein Blick ins Syslog brachte mehr zu Tage und verwies auf apparmor als Schuldigen:

Jul 19 22:06:23 ns1 named[4064]: transfer of 'XXX.XX/IN' from XX.YY.XX.YY#53: connected using YY.YY.YY.YY#56041
Jul 19 22:06:23 ns1 named[4064]: dumping master file: /etc/bind/zones/slave/tmp-yqPDfV0iX5: open: permission denied
Jul 19 22:06:23 ns1 named[4064]: transfer of 'XXX.XX/IN' from XX.YY.XX.YY#53: failed while receiving responses: permission denied
Jul 19 22:06:23 ns1 named[4064]: transfer of 'XXX.XX/IN' from XX.YY.XX.YY#53: end of transfer
Jul 19 22:06:23 ns1 kernel: [1290024.958677] audit(1342728383.126:12): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::" name="/etc/bind/zones/slave/tmp-yqPDfV0iX5" pid=4065 profile="/usr/sbin/named" namespace="default"

Nach Hinzufügen von

/pfad/zu/meinen/slaves/** rw,
/pfad/zu/meinen/slaves rw,

zu /etc/apparmor.d/usr.sbin.named und reload von apparmor funktionierte alles wie von Geisterhand,

It's a known issue to everyone who ever set up an multi-boot environment using Windows and $other_OS, that Windows likes to replace the existing boot manger with its own.
Normally, you'd just boot up a rescue CD and reinstall your favorite boot loader (or that one that comes with your OS' rescue CD ).
Sadly, the Ubuntu 10.04 Alternate Desktop CD doesn't support my crypto-raid-setup. The rescue mode installer doesn't recognize my raid set up at all (even thou it gets assembled^^).
Therefore I've to repair it by hand:

After booting, the Ubuntu rescue CD offers to switch into a root terminal.

The raid was assembled automatically, so there is no need for doing it manually:

mdadm --assemble /dev/sda1 md0 

I am going to build a chroot environment in /mnt, change root into it and reinstall grub2:

At first I have to mount the crypto device for the root file system:

cryptsetup luksOpen /dev/md0 md0 
mount /dev/mapper/md0 /mnt 

Now we've to add the missing pseudo file systems:

mount -o bind /dev /mnt/dev
mount -t sysfs sys /mnt/sys
mount -t proc proc /mnt/proc

Last but not least: We must not forget to mount the boot device. In my case it is just an ordinary partition:

mount /dev/sda4 /mnt/boot

Our change root environment is ready for usage and we simply have to chroot into it:

chroot /mnt 

Now, grub2 can be easily restored:

grub-install /dev/sda

As a final step, we'll ensure that grub is up-to-date:

update-grub

Da wollte ich gerade eine Änderung an einer meiner Websites hochladen, die ich lokal unter Ubuntu 10.04 entwickelt habe, da muss ich feststellen, dass das dafür notwendige Paket qrencode auf meinem Produktiv-System (Ubuntu 8.04 LTS) gar nicht verfügbar ist.

Da ich keine Lust auf langes Suchen und Rumfummeln hatte, habe ich mir fix die aktuellen Sourcen von von http://fukuchi.org/works/qrencode/index.en.html gezogen und händisch compiliert:

Source-Code laden und entpacken:

cd ~
mkdir qrencode-build
cd qrencode-build
wget http://fukuchi.org/works/qrencode/qrencode-3.1.1.tar.gz
tar xfvz qrencode-3.1.1.tar.gz

Falls noch nicht vorhanden, eine Build-Umgebung installieren:

apt-get install gcc binutils-doc autoconf automake1.9 bison flex gcc-doc gcc-multilib gdb pkg-config libpng12-dev make

Als finaler Schritt wird qrencode gebaut und installiert.

cd qrencode-3.1.1
./configure --bindir=/usr/bin --libdir=/usr/lib --includedir=/usr/include
make
make install

Nun sollte qrencode aufrufbar sein und funktionieren.

Aus gegebenem Anlass musste ich letztens meinen Root-Server bei Manitu neu aufsetzen:

Ursprünglich war das System nur mit einer Festplatte ausgerüstet. Im Rahmen einer Weihnachtsaktion war vor längerem einmal eine zweite Platte (sdb) - die bisher als Backup Platte diente - hinzugekommen. Im Rahmen der Neuinstallation wurden beide Platten zu einem Raid 1 zusammengefasst.

Nachdem ich das vorhandene System auf der zweiten Platte gesichert hatte, habe ich mich an die Neuinstallation gemacht:

Mein Ziel für die Neuinstallation war ein lauffähiges System, bestehend aus einem degraded Raid 1 (bestehend nur aus der ersten Platte /dev/sda) und der vorhandenen Datenplatte /dev/sdb, welche nicht verändert werden sollte.

Leider bietet das Manitu Kundenmenu keine Möglichkeit, ein degraded Raid zu erzeugen. Also blieb mir nur der Weg über das Rettungssystem.

Da dem Manitu-Rettungssystem das Tool debootstrap fehlt (es fehlt leider auch eine benötigte Library - darum ist es mit entpacken des deb Files nicht getan..) habe ich den Schritt lokal ausgeführt und das Resultat auf den Server hochgeladen. Als tar.bz2 ist das Basissystem mit 100MB recht schlank, so das die Upload Zeit selbst bei einem relativ langsamen DSL-Anschluss noch erträglich.

"HOW-TO: Ubuntu 10.04 LTS auf degraded RAID 1..." vollständig lesen »

Bei mir Stand mal wieder neue Hardware ins Haus, um meinen - mittlerweile doch etwas arg in die Jahre gekommenen - Athlon XP 2000+ zu ersetzen. Geworden ist es ein schöner neuer AMD-Phenom X4.

Um gegen Festplattenausfälle gewabnet zu sein, habe ich meinem neuen System zwei schöne Western Digital WD2EARS spendiert, die ihr dasein fortan im Software-RAID-1-Betrieb fristen sollen. Da die CPU mit 4 mal 3 ghz ordentlich 'Power unter der Haube' hat und mir meine Daten lieb und wichtig sind, sollte mein System auf jeden Fall grundverschlüsselt zu sein.

Als Betriebssysteme habe ich mir zum Arbeiten Ubuntu 10.4 und zum spielen Windows 7 und Windows XP auserkoren.
Herausgekommen ist schließlich folgende Plattenaufteilung:

/dev/sd(a|b)1 Linux Software RAID mit 1,8 TB für /
/dev/sd(a|b)2 Linux Software RAID mit 10 GB für swap
/dev/sd(a|b)3 Rest frei für Windows (7 / XP)
/dev/sd(a|b)4 200MB (am Ende), für /boot

Die beiden Windows Partitionen sind unverschlüsselt und ganz gewöhnlich installiert.
Die Linux Partitionen sind über dm-crypt transparent grundverschlüsselt.

Die Einrichtung gestaltet sich recht easy und läßt sich mit über die 'alternate Desktop CD' während des Setups leicht vornehmen.

Dazu müssen zunächst die RAID Partitionen als Mirror RAID (1) erzeugt werden. In diesen Partitionen werden nun mittels cryptosetup jeweils die verschlüsselte root und swap Parition angelegt.

Zu beachten ist lediglich die Tatsache, dass in jedem jedem RAID-Device direkt nur eine Partition erzeugt werden kann. Sollen mehrere Partitionen benutzt werden, muss man dazu LVM bemühen (und hat damit eine weitere prozessorlastige Abstraktionsschicht in Betrieb ).

Für / vergibt man einen möglichst langen und guten Key mit >> 20 Zeichen. Merken können sollte man sich den Key aber besser dennoch, da man ohne eben diesen nie wieder an seine Daten gelangt.

Für swap kann man einen radom key beim booten generieren lassen - nach einem reboot benötigt man die alten Swap Daten ja eh nicht mehr - um sich eine weitere Passwortabfrage beim Startvorgang zu ersparen.