Neuere Distributionen, z.B. das Ubuntu das ich hier gerade verwende, formatiert die Festplatten richtig. Man kann das ganz einfach mit sfdisk überprüfen.

$ sfdisk -d /dev/sda
[...]
/dev/sda1 : start= 2048, size= 195313, Id=83, bootable

Die 1. Partition meiner SSD beginnt bei 1 MB, also bei LBA-Adresse 2048. Die Nummer der Start-Sektoren können ohne Rest durch 2048 dividiert werden.

CentOS formatiert die Festplatten auf die Startadresse 63 – wie bei 512-byte:

$ sfdisk -d /dev/sda
[...]
/dev/sda1 : start= 63, size= 208782, Id=fd

In einem Wiki-Eintrag von Thomas Krenn wird das alles noch mal im Detail beschrieben.

Beim Administrator’s Blog erschien heute ein Artikel der über die schlechte Performance der WD20EARS-Festplatten berichtet. Western Digital nennt die 4KB-Sektoren “Advanced Format”. In meinem letzten Blog-Eintrag ging es u.a. um die WD20EADS-Festplatten, die bei Manitu eingesetzt werden. Eigentlich – und das bestätigen meine Tests bei Manitu – sollten diese Festplatten 0,5kb Sektoren verwenden. Im Datenblatt steht dazu nichts, genauso wenig wie zu der MTBF, aber das ist ein anderes Thema. Google ist sich dazu auch nicht sicher.

Ich formatiere inzwischen alle System auf Startadresse 2048. Der Artikel beim Administrator’s Blog zeigt aber auch, dass man i.d.R. keine Desktop-Festplatten für einen Server verwenden sollte, zumindest wenn einem etwas an Reliabilität oder Performance liegt…

Native Virtualisierung

Gemeinschaft ist eine Asterisk Distribution der Firma Amooma GmbH. Die Virtualisierung eines Asterisk-Servers bietet sich durch die typischerweise geringe Hardwareanforderung und das Bedürfnis nach hoher Verfügbarkeit geradezu an. Zumindest wenn man davon ausgeht, dass man ein Mediagateway für die Umsetzung IP <> ISDN verwendet. Die Virtualisierung einer PCI-Karte ist keine wünschenswerte Aufgabe, das macht keinen Spaß!

Citrix XenServer ist in einer kostenlosen Version auch für den kommerziellen Einsatz nutzbar. Mit der Software erhält man eine ausgereifte Virtualisierungslösung out of the box.

Paravirtualisierung

In diesem Artikel wird erklärt, wie man eine vollständig virtualisierte Linux Distribution in ein paravirtualisiertes System überführt. Gemeinschaft nutzt ein Debian Lenny; die Vorgehensweise unterscheidet sich nicht grundlegend zu anderen Distributionen.

1. Für die Installation der VM muss “Other install media” als Template und der Gemeinschaft Installer als ISO-Image ausgewählt werden.
2. Nach der Installation werden die XenServer Tools und der XenServer Kernel installiert. Dazu die CD mounten oder den Inhalt über scp auf die VM kopieren:
dpkg -i Linux/xe-guest-utilities_5.5.0-458_i386.deb
dpkg -i Linux/debian-generic/linux-image-2.6*

3. Mit der Paravirtualisierung wird sich das Blockdevice der Festplatte von hda in xvda ändern. In /etc/fstab und /boot/grub/menu.lst die entsprechenden Vorkommnisse ändern. Die Datei /etc/fstab ist selbsterklärend, in menu.lst an der folgende Stelle:
   title Debian GNU/Linux, kernel 2.6.29-xs5.5.0.14
root (hd0,0)
kernel /boot/vmlinuz-2.6.29-xs5.5.0.14 root=/dev/xvda1 ro quiet
initrd /boot/initrd.img-2.6.29-xs5.5.0.14

4. Wahrscheinlich wird im XenCenter der login prompt nicht mehr erscheinen, in der Datei /etc/inittab tty1 durch hvc0 ersetzen:
   # Format:
# :::
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty 38400 hvc0

5. Die VM mit poweroff herunterfahren.

Unter der Konsole des XenServers wird die eigentliche Virtualisierungsmethode umgestellt. Das muss übrigens nicht zwingend auf dem Pool Master durchgeführt werden.

1. Jeder VM ist einer UUID zugeordnet, diese kann mit dem Kommando xe vm-list herausgefunden werden.
2. Jetzt folgt die eigentliche Umstellung der Virtualisierungsmethode:
   xe vm-param-set uuid=<uuid> HVM-boot-policy=""
xe vm-param-set uuid=<uuid> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid> PV-args="-- quiet console=hvc0"

3. Die virtuelle Festplatte ist noch nicht zum Booten bereiten. Für die Aktivierung wird die VBD-UUID benötigt, das Kommando xe vm-disk-list uuid=<uuid> liefert eine Liste der Blockdevices:
   Disk 0 VBD:
uuid ( RO) : <vb-uuid>
vm-name-label ( RO): Other install media (1)
userdevice ( RW): 0Aktivierung des Blockdevices:
   xe vbd-param-set uuid=<vb-uuid> bootable=true

Fertig! Viel Glück mit der Umsetzung.

…ich bin im Ausland und habe einen Rechner mit, der keine Windows Lizenz hat. Es ist ein Linuix installiert…

Es ging daraum, dass er mit diesem Rechner nicht auf XYZ Backoffice Software zugreifen kann. Recht hat er, aber mit einem Windows Terminalserver und rdesktop ist das nicht wirklich ein Problem.

/dev/sdb:
Timing cached reads:     2 MB in  4.03 seconds = 508.50 kB/sec
Timing buffered disk reads:    2 MB in  3.42 seconds = 598.48 kB/sec

/dev/sdb:
HDIO_GET_32BIT failed: Invalid argument
HDIO_GET_UNMASKINTR failed: Invalid argument
HDIO_GET_DMA failed: Invalid argument
HDIO_GET_KEEPSETTINGS failed: Invalid argument
readonly      =  0 (off)
readahead     = 256 (on)
geometry      = 2432/255/63, sectors = 39070080, start = 0

Die Formatierung mit FAT32 funktionierte, testweise konnte ich auch einen Podcast auf die Festplatte kopieren. SMART zum Testen der Festplatte funktioniert allerdings nicht.

Ich bin mal gespannt, wie lange die Platte bei den Vibrationen und Temperaturen in dem Handschuhfach noch laufen wird.

Auf meinem neuen Laptop hatte ich ursprünglich Fedora 7 oder 8 installiert und habe direkt nach der Veröffentlichung von 9 ein Upgrade (yum) durchgeführt.

Zuerst sah es gar nicht schlecht aus, aber es gibt doch viele Probleme. In letzter Zeit überlege ich ernsthaft, ob ich wieder auf 8 bzw. direkt auf Ubuntu wechseln soll.

Hier mal eine Liste der Dinge, die mit Fedora 8 funktioniert haben:

• Suspend2Ram funktioniert manchmal, meistens aber nicht. Wenn er mal funktioniert hat, ist der Mauszeiger vom Touchpad derart langsam, dass man damit nicht arbeiten kann. Ich muss dann immer den X-Server neu starten.
• Ich habe ein Software-Raid 1 über zwei USB-Festplatten, mdadm schmiert sofort ab, sobald ich das Raid starten will. Unter systemrescue lässt sich das Raid ohne Probleme starten. Allerdings habe ich das mit den letzten Kernel-Updates noch nicht ausprobiert.
• Synchronisation mit meinem Nokia N73 über multisync. Anscheinend gibt es das Paket in Fedora 9 nicht mehr, jedoch habe ich auch das noch nicht weiter untersucht.

Seit einige Zeit geht jetzt mein WLAN nicht mehr, der NetworkManager hat nach einem Update den Dienst eingestellt. Auch bei einer LAN-Connection passiert es jetzt oft, dass keine Verbindung aufgebaut werden kann, killall dhclient && dhclient eth0 hilft sofort.

Es ist schon sehr enttäuschen, dass es im Gegensatz zu Fedora 8 mit dem neuen Release so schlecht läuft.

Meine nächsten Schritte werden sein, dass ich das automatische Update deaktiviere und in längeren Abständen ein Update über yum mache. So habe ich das mit den vorherigen Versionen auch gemacht. Danach werde ich Fedora 9 ganz frisch von der DVD installieren, obwohl ich mich nach dem Upgrade um die .rpmnew- Dateien gekümmert habe.

Auf der Firewall werde ich doch etwas schwermütig:

18:57:15 up 519 days, 22:36, 2 users, load average: 0.08, 0.11, 0.04

Aus Interesse habe ich mal ein hdparm ausgeführt:

/dev/hda:
Timing cached reads: 484 MB in 2.00 seconds = 241.55 MB/sec
Timing buffered disk reads: 120 MB in 3.06 seconds = 39.26 MB/sec

Die Festplatte geht ja noch, aber die cached reads…mein Notebook schafft locker 2-3GB/s. Bei der FW handelt es sich übrigens um einen P3 mit 1000Mhz auf einem Intel 815 Chipsatz.

Man könnte natürlich jetzt mit der CD/DVD das Fedora installieren, doch muss das System dann auch wieder konfiguriert werden. Eine Alternative wäre einfach ein Image von einem anderen Rechner einspielen, allerdings ist Fedora 9 noch sehr frisch und ich hatte noch kein Fedora 9 System.

Der Standard-Weg (fedora-release installieren und yum update) ist wegen den ganzen Abhänigkeiten wahrscheinlich umständlicher als eine Neuinstallation.

Ich habe mich für eine “brutale” Methode entschieden.

Als erstes benötigt man die Fedora Packages (~3.6GB), mit rsync und 16Mbit DSL liegt das Ganze recht schnell auf der Festplatte:

rsync --archive --verbose --progress rsync://ftp.crc.dk/Fedora/linux/releases/9/Fedora/x86_64/os/Packages/ .

Vielleicht hätte man sich ein rpm -qa von einem anderen Rechner holen sollen, aber wie gesagt, es war noch kein Fedora 9 System verfügbar.

rpm -Uvh * --nodeps --force

Vorher sollte rpm aber ohne –nodeps laufen, damit die Abhängigkeiten manuell geprüft werden können, bei mir kam es nur bei einigen unwichtigen Paketen zu Fehlermeldungen.

Während RPM die Pakete installiert treten viele Fehler auf, die Pakete werden nicht in der richtigen Reihenfolge installiert. Ich hab rpm einfach zweimal ausgeführt.

Wenn alles funktioniert hat, kann man noch die $config.rpmnew nach $config verschieben, sollte man bei /etc/passwd aber besser nicht machen

Man sollte beachten, dass nach dem Upgrade auch PATA-Festplatten sd*-Devices werden. Wenn es in Centos 5 eine Festplatte (/dev/hda3) gibt, wird diese in Fedora zu /dev/sda.

diss: Mach *das* mal mit Windows

Auf einem Mailserver von mir werden 70% der Anfragen direkt über eine RBL geblockt. Die restlichen E-Mails werden auf Spam mit Spamassassin und Viren über Sophie mit Sophos gescannt. Viren werden direkt abgelehnt, Spam E-Mails ab einer Score von 20.

Dlog analysiert die Logfiles von qmail und liefert verwertbare Daten, diese Daten können wir mit einem Monitoring-System (z.B. Munin) in eine grafische Darstellung verwandeln. Dlog unterstützt die Anzahl der Anfragen pro Sekunden und die Hits in einer RBL.
Viren -und Spam E-Mails werden von Dlog nicht ausgewertet, mit einem kleinen Patch lässt sich das aber ändern. Nachdem Dlog gepatcht und neu kompiliert wurde, muss das Munin-Plugin noch angepasst werden.

Fertig sieht das ganze so aus:

• Patch für Dlog
• Patch für das Dlog Munin Plugin dlog_qsmtp

Die verwendete Dlog Version ist 0.9.9.

Mit zwei RBLs (eine lokale Kopie von der ix- Liste und Spamcop) werden schon fast 85% aller SMTP-Connections direkt abgewiesen, der lokale DNS-Cache (dnscache) ist über 1GB groß. Die Connections, die jetzt noch übrig sind, werden mit Spamassassin geprüft, Mails mit einer Score über 20 werden auch direkt abgelehnt. Viren E-Mails machen kaum noch etwas aus, aber die werden schon vor Spamassassin rejected.

Im Endeffekt landen ca. 1-2% aller E-Mails, die auf das System prasseln, im Postfach. Das System mit 6 Platten (Raid0 + Raid 10 SAS), 4GB Ram und zwei Dual Core Xeons (2.0GHz) bewältigt mehr als 500.000 Mails am Tag problemlos, Flaschenhals ist und bleibt IO, aber in das Gehäuse gehen nicht mehr Platten rein.

Nach ein paar Tagen im produktiven Einsatz und ohne Apache restart, produzierte der Apache über 150 Prozesse (MaxClients). Danach war eine Connection nicht mehr möglich und brach mit einem Timeout ab. Auch mit dem tuning der Prefork-Optionen ließ sich das Verhalten nicht ändern.

Ein Umstieg auf eine threaded MPM kam nicht in Frage, die Konfiguration auf dem Server benötigt mod_php und die Migration auf eine moderne Apache Installation (FastCGI) ist ein bisschen zu viel des Guten (don’t touch a running system ). Der Server hat auch irgendwas mit 500 Vhosts.

Die Lösung war ganz einfach und innerhalb von wenigen Minuten implementiert:

Jetzt könnt ihr mal raten ab wann der Apache 1.3 lief.