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: https://github.com/mahlonsmith/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.

Backup With Bacula And LUKS Encrypted USB Disks – Part 1

Standard

I think is is time again to share some interesting stuff with you.
A few month ago, I have set up a new backup solution with Bacula and USB disks as backup media. I am not going to argue why Bacula is our preferred backup software or why USB disks are great for backups. You will have to find it out on your own. So let’s get more into detail now.

As our company policies require all media to be encrypted, no excepetion was made for the backup media of cause. This were the requirements for the new system:

      1. Attached USB disks must be accessible by the system and backup software, without the need of manual actions by the backup operator
      2. The filesystem should be in an unmounted state when detaching the USB disk to prevent data corruption. Also, no manual actions should be needed.
      3. The disks have always to be mounted to the same location for Bacula to use them
      4. The backup should be as flexible as possible, e.g. it should not really matter if the disk was changed or not. This is really important on holidays, as I do not want to update volume attributes all the time.

    The solution for the first three requirements is a combination of LUKS encryption with a keyfile and an automounter like autofs. Encrypting with LUKS and a keyfile is really easy as you will see. To fulfill the last requirement I have chosen a Bacula configuration based on a virtual tape changer. But first we have to prepare udev with some config and scripts to make a device available for autofs.

    UDEV CONFIG & SCRIPTS

    /etc/udev/rules.d/99-unlock-lucks.rules
    This rules makes UDEV call /usr/local/bin/unlock-luks with the name of the new device and the name the decrypted device should get by the device mapper (here: bacula) as parameter.

    ACTION=="add",BUS=="usb",KERNEL=="sd?1",RUN+="/usr/local/bin/unlock-luks /dev/%k bacula"

    /usr/local/bin/unlock-luks
    This script takes care if a new device was attached to the system. If UDEV calls this script and the device mapper still sees the device, this is caused by the device mapper taking a long time before dropping a detached device from its database. In case the system still thinks the device is mounted, force an umount and close the crypto device before setting up the new crypto device. If this looks very strange to you, I can appease you, It’s working pretty well for month now. Of cause this script has to be made executable.

    (
      ISATTACHED=`dmsetup ls | grep ^bacula | wc -l`
      if [ $ISATTACHED -eq 1 ]
      then
        umount /dev/mapper/$2 --force
        cryptsetup luksClose $2
      fi
      cryptsetup --key-file=/etc/luks.key luksOpen $1 $2
    )
    

    Now that UDEV is prepared let’s create some fully encrypted USB disks:

    CREATING A KEYFILE
    First of all, we need to create a good keyfile. In 2010 a 4096 bit key should be enough. To create such a keyfile dd does a good job:

    dd if=/dev/random of=/etc/luks.key bs=1024 count=4

    ENCRYPTING THE DISK
    I suppose you only have one partition on your USB disk, so encrypt it. Usually USB disks are handled by the SCSI subsystem, so it device name starts with sd. Warning: The next step overwrites any existing data on that partition.

    cryptsetup luksFormat /dev/<sd?1> /etc/luks.key

    FORMATTING THE ENCRYPTED PARTITION
    Before you really can format the partition you should unplug the disk and reattach it to the system. If your UDEV configuration and scripts work as expected, you should see the device /dev/mapper/bacula. Finally put a filesystem onto the new device with

    mke2fs -j -T largefile -L "usbchanger1" /dev/mapper/bacula

    As you can see the filesystem also gets labled with usbchanger1. This is neccesarry for the automounter to identify the filesystem. I used the largefile flag, as each volume Bacula creates is a big file of several gigabytes.

    CONFIGURING AUTOFS
    I suppose there is nothing special about the two files for you. Just create the mountpoint /mnt/usbchanger1, modify or create the two files and restart the autofs daemon.

    /etc/auto.master

    /mnt/usbchanger1    /etc/auto.usbchanger1    --timeout=10

    /etc/auto.usbchanger1

    magazine  -fstype=auto,rw  :/dev/disk/by-label/usbchanger1

    That’s all for now. You should now be able to attach an USB disk with an encrypted filesystem on it to the system and access it through the path /mnt/usbchanger1/magazine. If nothing keeps the device open it will be unmounted after ten seconds. Now you are ready to configure Bacula. I am going to explain this in part 2 of this tutorial soon.