GRUB Probleme mit unter GRML erstelltem Software RAID

Standard

Im Rahmen des des FTPC Projekts, gab es die eigentlich recht triviale Aufgabe zu erfüllen, das bereits laufende Installationsserver-System von einem alten Laptop auf einen Server im 19″-Gehäuse samt Software RAID-1 zu übertragen. Aus der Vergangenheit wusste ich, dass das mit GRML eigentlich kein Problem sein sollte. Allerdings hat sich seit dem letzten Debian Stable, was die Basis des Installationsservers darstellt, wieder einiges verändert. Man konnte ohne Probleme das Software RAID erstellen und die Daten per Rsync in das entspreche Zielverzeichnis übertragen.

Soweit alles wie immer. Aber dann weigerte GRUB sich installieren zu lassen. Egal was man versuchte, es endete immer in der Meldung “bad file or directory type”. Leider fand sich dazu rein gar Nichts, was auf die Ursache des Problems hingewiesen hätte.

Ich erinnerte mich dann daran, dass ich irgendwann mal das Problem hatte, dass sich die Standard-Inode-Size zwischenzeitlich mal von 128 auf 256 geändert hat, was auch dazu geführt hatte, das man GRUB zwar installieren konnte aber ein Start nicht möglich war.

Also machte ich mich auf die Suche nach einem ähnlichen Unterschied und wurde bei mdadm fündig.

Erst als ich das Software RAID mit

mdadm create /dev/md0 -e 0.90 --raid-devices=2 --level=1 /dev/sda1 /dev/sdb1

,also zwingend mit dem alten Format der Metadaten, erstellt habe, konnte man GRUB auch erfolgreich installieren.

Nettes LDAP Werkzeug für die Shell

Standard

Soeben eher zufällig bei einem aptitude search ldap auf das Paket shelldap gestossen. Damit kann mal durch einen LDAP Baum wie durch ein Dateisystem navigieren, Einträge kopieren und verschieben, bearbeiten, ausgeben und so weiter. Das Programm ist auf jeden Fall mal ein Blick wert. Ach ja und das Killerargument warum man es einsetzen sollte:

[..] and it’s fun to say. Shelldap! Shelldap! Shelldap!

Webseite von Shelldap: http://projects.martini.nu/shelldap

Howto: Ubuntu 10.04 LTS Client mit Kerberos und LDAP

Standard

Ich habe in den letzten Tagen mal in meinem LAN das Kerberos-Zeitalter ausgerufen. LDAP habe ich schon lange im Einsatz, aber bisher nicht zu Authentifizierung. Folgende Anforderungen habe ich für mich definiert:

  1. Sichere Anmeldung am System mittels Kerberos
  2. Benutzer und Gruppeninformationen sollen aus dem zentralen LDAP-Verzeichnis kommen
  3. LDAP-Benutzer sollen automatisch Mitglieder lokaler Systemgruppen werden, um z.B. Zugriff auf Geräte zu habe
  4. Nicht existierende Home-Directories sollen beim ersten Anmelden erstellt werden
  5. Mobile Geräte müssen auch ohne Netzwerkverbindung eine Authentifizierung ermöglichen

Auf Serverseite habe ich ebenfalls ein Ubuntu 10.04 LTS laufen (mein Mediacenter System). Dort habe ich bereits Kerberos und LDAP nach der Anleitung aus dem Ubuntu Serverguide eingerichtet.

Die anderen Anleitungen des Serverguides sind leider nun dann hilfreich, wenn man nur Kerberos oder nur LDAP-Authentifizierung machen möchte. Abgesehen davon schießen sich die Tools pam-auth-update und auth-client-config gegenseitig in’s Knie, weshalb man schon genau wissen sollte was man tut. Andernfalls hat man sich schneller aus dem eigenen System ausgesperrt als man Kerberos rückwärts buchstabieren kann. Ich verwende daher ein eigenes auth-client-config Profil für die Anpassungen an der nsswitch.conf und alle Änderungen an PAM nehme ich mittels pam-auth-update vor.
Continue reading

MySQL Backups Made Easy

Standard

Using logrotate makes it very easy to create MySQL dumps regularly. Just create a file at /etc/logrotate.d/ with the following content:

/var/backups/mysql/dump.sql {
daily
rotate 14
missingok
compress
postrotate
/usr/bin/mysqldump -u -p --opt \
--flush-logs --all-databases > /var/backups/mysql/dump.sql
endscript
}

You may have to create the directory /var/backups/mysql/ manually.

LVM ein Raid1 unterschieben

Standard

Ich hab mir mal gedacht, meinen Mediacenter System mit einem KVM Gast auf dem auch dieser Blog läuft, ein wenig ausfallsicherer zu machen. Dazu also vergangene Woche eine gleich große zweite HDD gekauft. Heute habe ich dann endlich die Zeit gefunden, dem laufenden LVM ein Software RAID1 unter zu schieben. Diese Anleitung war dabei sehr hilfreich, auch wenn ein paar Aufrufe an lokale Gegebenheiten angepasst werden müssen (mein Mediacenter läuft z.B. auf Ubuntu). Insgesamt ist es schon erstaunlich wie flexibel Linux beim Umgang mit Block-Devices ist.

PKCS#12 mit keytool importieren

Standard

Gerade ein wenig mit Funambol herum gespielt. Da mein Nokia E71 ein wenig empfindlich im Bezug auf Zertifikate ist, sollte der Funambol auch das Zertifikat meines Servers haben, welches eh schon im Telefon als vertrauenswürdig hinterlegt ist (CAcert.org signed).

Natürlich ist so was bei Java immer alles nicht so einfach. Zertifikat kein Problem, aber Private Key importieren ist nicht. Aber wie ich dann raus gefunden habe, gibt es mit keytool in Java 1.6 endlich die Möglichkeit einen Private Key + Zertifikat zu importieren, wenn ein PKCS#12 File vorliegt.

Der ist ja dank Openssl recht schnell erstellt:

openssl pkcs12 -export -in /etc/apache2/server.crt -inkey /etc/apache2/server.key -out /root/server.p12

Und dann kann der Import losgehen:

keytool -importkeystore -deststorepass changeit -destkeypass changeit -srckeystore /root/server.p12 -srcstoretype PKCS12 -srcstorepass 1234 -srcalias 1 -destalias tomcat

Wichtig ist “-srcalias 1”, damit keytool auch weiß, dass es den ersten Datensatz aus dem P12 File lesen soll. Außerdem ist in meinem Fall (Funambol) noch wichtig, dass “-destalias tomcat” angegeben wird.

Nach einem Neustart des Funambol Dienstes liefert er das neu importierte Zertifikat aus.

Resizing a LUKS Encrypted Root Filesystem On LVM

Standard

As I came to work this morning, I was painfully reminded of my task to grow our fileserver’s file system. It has reached over 90% utilization two month ago, but I always delayed that task, as I was not willing to take the system down or even reboot during working time. So this morning there was no other way left than to finally resize the filesystem as it now reached 100% utilization (shame on me).

Usually there is nothing special about online resizing an EXT3 filesystem, but I never tried that with a LUKS encrypted one. I was glad to find a good how-to at ubuntuforums.org which basically points out how it works with Ubuntu 8.04. As our fileserver runs Debian Lenny I knew that some things of the how-to are outdated. So here is a short summary of the steps, neccesarry to (nearly online) resize a LUKS encrypted root filesystem on a LVM logical volume:

      1. Enlarge the partition conaining the crypted data with fdisk.
      2. Reboot – always needed after making changes to the partition table
      3. Enlarge the encrypted data with cryptsetup.
      4. Enlarge the (LVM) physical volume with pvresize.
      5. Enlarge the (LVM) logical volume with lvresize.
      6. Enlarge the file system with resize2fs.
      7. Reboot – let’s see if everything works as expected

Now here are the steps in detail:

1. Changing your partition table
Use fdisk or cfdisk and delete the partition you want to resize. Afterwards create a new partition starting at the same block as the previously deleted partition, but with a new size including the newly added free space.

2. Reboot
This is definitely required to make sure the following used utils get to know the new size of the partitions.

3. Enlarge encrypted data
The following command resizes the encrypted storage to the filesystem’s boundaries:
cryptsetup resize /dev/mapper/sda2_crypt

4. Enlarge LVM physical volume
Now the LVM physical volume can be resized with the pvresize command:
pvresize /dev/mapper/sda2_crypt

5. Enlarge the LVM logical volume
If you now run vgdisplay you will see that there are free physical extents (PE) available in the volume group where the physical volumes belongs to. To extent your logical volume to all free PEs you can use “-l +100%FREE” as parameter for the lvresize command.
lvresize -l +100%FREE /dev/mapper/hostname-root

6. Enlarge the file system
Finally it is time to resize the actual filesystem. To make sure it has no errors it is a good advise to run a filesystem check before really resizing it.
e2fsck -f /dev/mapper/hostname-root
resize2fs -p /dev/mapper/hostname-root

7. Final Reboot
Just to make sure everything works fine after all this exciting stuff.

Backup With Bacula And LUKS Encrypted USB Disks – Part 2

Standard

As promised here comes part two of my “Backup with Bacula and LUKS encrypted USB disks” howto. In part one I explained how to prepare the disks for using them with autofs and how to configure autofs itself. Now we have a good basis for Bacula to use those disks as storage for the backups.
As I said I want to use those disks as virtual tapes in a virtual tape library. This gives us the most flexibility in changing the disks or not (holidays, etc.). With vchanger you get a nice tool to emulate such a virtual tape library. After installation the vchanger binary should be available at /usr/local/bin. I created a config file called vchanger.conf at /usr/local/etc with the following content:

# changer_name  -  [required] Name of this autochanger
changer_name = "usbchanger1"
# state_dir - Directory where virtual drive state and symlinks are created
#             [Default: /var/lib/bacula/]
state_dir = "/var/lib/bacula/usbchanger1"
# logfile  -  Path to a file where errors and debugging info will be logged.
#             [Default: none]
logfile = "/var/lib/bacula/usbchanger1.log"
# slots_per_magazine  -  Number of slots each of the autochanger's magazines
#                        will have. [Default: 10]
slots_per_magazine = 10
# virtual_drives  -  Number of virtual drives to use. [Default: 1]
Virtual_Drives = 1
# magazine  -  [Required] Gives the mountpoint directory of a magazine.
#              Multiple magazine directives may be specified to define
#              a multi-magazine autochanger. Each magazine has the same
#              number of slots, so the autochanger will have
magazine = "/mnt/usbchanger1/magazine"

To use that virtual device with Bacula, modify the configuration of the Bacula storage daemon.

[..]
Autochanger {
 Name = usb-changer-1
 Device = usb-changer-1-drive-0
 Changer Command = "/usr/local/bin/vchanger %c %o %S %a %d"
 Changer Device = "/usr/local/etc/vchanger.conf"
}
#---  drive 0 of the usb-changer-1 autochanger
Device {
 Name = usb-changer-1-drive-0
 DriveIndex = 0
 Autochanger = yes;
 DeviceType = File
 MediaType = File
 ArchiveDevice = /var/lib/bacula/usbchanger1/0/drive0
 RemovableMedia = no;
 RandomAccess = yes;
}
[..]

And add this device as storage to you Bacula director’s configuration.

[..]
Storage {
 Name = usbchanger1   # same as defined by 'baculasd' in vchanger config file
 Address = hostname.of.my.baculasd.system
 SDPort = 9103
 Password = "mysecretpasswort"
 Device = usb-changer-1  # name of the Autochanger resource defined in bacula-sd.conf
 Media Type = File
 Autochanger = yes;
}
[..]

Now we can start initializing the tape library by adding the tapes. For each disk run the following commands after it has been attached to the server.

chown bacula:disk /mnt/usbchanger1/magazine/
vchanger -u bacula -g disk /usr/local/etc/vchanger.conf initmag 1
bconsole << EOF
label barcodes
yes
2
quit
EOF

Now the virtual tape changer is married with Bacula and I am sure they will have a very good time together.

All other things you need to know, e.g. how to to configure Bacula to you needs, what a good backup strategy is, do apply to any other backup media as well. So I am not handling them in this howto. I hope this helped you somehow and feedback is always welcome.