Das von uns eingesetzte Warenwirtschaftssystem ESS (Enterprise Solution Server) der Firma Pentaprise bringt über die verschiedenen Software-Generationen und Versionen unterschiedliche Abhängigkeiten zu weiteren Software-Paketen mit, die bislang manuell von Hand nachinstalliert werden mussten.

Um dies zu vereinfachen, haben wir unser ETES-Repository mit zusätzlichen RPM-Paketen für das ESS erweitert. Diese enthalten jedoch nicht das gesamte ESS, lediglich die Abhängigkeiten zu Software-Paketen, die die jeweilige Generation des ESS benötigt. Aktuell gibt es Pakete für ESS 6.0.0.x, 6.0.2.x, 6.0.4.x und 6.0.6.x. Unser ETES-Repository gibt es zur Zeit für die für den Unternehmenseinsatz optimierte Linux-Distribution Red Hat Enterprise Linux bzw. CentOS in Version 4 und 5, sowie für den Vorreiter in Sachen Open Source Software, nämlich Fedora in Version 8, 9 und 10.

Aktiviert wird das ETES-Repository durch die Installation des RPM-Pakets etes-release (rpm -Uvh etes-release-version.arch.rpm), welches sich im entsprechenden Unterverzeichnis der oben angegebenen Adresse findet. Da sich die Paketnamen ändern können, ist hier bewusst keine direkte URL zu den RPM-Paketen verlinkt. Anschließend funktioniert die Installation wie folgt:

• ESS 6.0.6.x: yum install ess-606x
• ESS 6.0.4.x: yum install ess-604x
• ESS 6.0.2.x: yum install ess-602x
• ESS 6.0.0.x: yum install ess-600x

Kurze Zeit später fragt yum nach, ob die benötigten RPM-Pakete wirklich installiert werden sollen. Dies muss natürlich bestätigt werden und eine danach gestartete Installation des ESS funktioniert ohne die händische Nachinstallation weiterer Software-Pakete!

Note: This is the last republishing of articles from our old website. It might help you with DELL servers on which you have to install older versions of SuSE.

When you try to install SuSE 9.2 on a server with an integrated Raid controller needing the aacraid kernel module you will run in trouble. The problem is a bug in the needed kernel module aacraid. You can read more about that problem this posting. One example for servers where you’ll have this problem are the DELL PowerEdge servers with an integrated CERC SATA Raid controller.

As we had to install two servers like the one describe above, we tried to find a well working solution for this. To solve the problem we patched the aacraid kernel module with the aac-remove-handle-aif patch and created a SuSE kernel module disk for installation. The following instructions tell you how to use this disk. (We have also written a documentation how to create such a disk with fixed kernel modules for SuSE installation.)

Note: Make sure you have an internal CD and an internal floppy drive in your server. I’m not sure if the following instructions work with an external USB floppy drive.

1. Download the needed floppy disk image to a linux system.
2. Create your floppy using the following command:
3. dd if=/file/to/floppy/image of=/dev/fd0
4. Replace the /file/to/floppy/image to the real path to the downloaded file and /dev/fd0 with the device of your floppy.
5. Take CD #2 into your CD drive and boot your server. After the BIOS boot process, you’ll see the installation screen of SuSE. Choose manual setup. (And, as we prefer it, the text mode.)
6. Choose your language and keyboard settings. The following instructions are based on English as installation language.
7. Select kernel modules from the menu and then load IDE/RAID/SCSI modules.
8. You are asked to insert the modules disk #2. Do not use the disk you can create from the SuSE CD. Use the disk from step one above instead!
9. Select the aacraid module from the list and insert no parameters when you are prompted for them. The module should load without problems.
10. Continue with the normal installation.

Der Adobe Flash Player (früher auch als Macromedia Flash Player bekannt) wird leider auch in der zur Zeit aktuellen Version 10 nur als 32 Bit-Fassung von Adobe, Inc. bereitgestellt. Hat man auf dem Rechner nun ein Linux-System mit 64 Bit, so bedarf es einem kleinen Trick, damit Flash-Filme auch in einem 64 Bit-Browser funktionieren: Der Installation von “nspluginwrapper” als 32 Bit-Variante.

Bei Fedora 10 ist dies zum Beispiel einfach nachfolgender Befehl als “root” an der Konsole:

yum install nspluginwrapper.i386

Anschließend die Webbrowser neustarten und anschließend funktionieren Flash-Filme auch bei 64 Bit.

Viele SPAM-Filter, wie beispielsweise auch der von uns eingesetzte amavisd-new mit SpamAssassin markieren SPAM-Mails häufig im Betreff. Dadurch können die verdächtigen Mails dann beispielsweise auf dem nachfolgenden Mailserver oder der Seite des Clients über Regeln in entsprechende Ordner verschoben werden. Außerdem ist eine Markierung wie ***SPAM*** im Betreff in der Mailbox auf den ersten Blick erkennbar. (Bei uns werden die meisten Mails komplett abgewiesen und nur ein kleiner, nicht eindeutiger Teil an die Anwender zugestellt.)

In unseren SPAM-Samples haben wir heute ein Beispiel entdeckt, bei dem sich der Spammer durch einen fehlerhaften E-Mail-Header dieser Markierung erfolgreich entzieht. Damit steigen natürlich die Chancen nicht in einen SPAM-Ordner sortiert und auch vom Benutzer gelesen zu werden.

Dazu wurden in der E-Mail einfach zwei To-Header gesetzt. Die erste enthält den eigentlichen Betreff, während die zweite durch den SPAM-Filter markiert wird. Das sieht dann im Header so aus:


To: ***@etes.de
Subject: RE: Doctor Q&A Cassie Oneil
From: ***@etes.de
MIME-Version: 1.0
Content-Type: text/html
Subject: ***SPAM***
Message-Id: <20081110113621.8CCC81C2AE9@...>


Natürlich können wir nicht sicher sagen, dass der Spammer diesen Fehler absichtlich eingebaut hat. Aber es ist durchaus anzunehmen.

SPAM-Filter sollten also so arbeiten, dass sie in diesem Fall alle Header-Zeilen mit der SPAM-Markierung versehen um durch den falschen Header kein Vorbeimogeln an der Markierung zu ermöglichen. Für amavisd-new, der in unserem Fall für die Markierung im Header zuständig ist, werden wir einen entsprechenden Bug-Report öffnen.

Nachdem inzwischen Festplatten mit einer Größe von 1 TB (1024 GB sind 1 TB) keine Seltenheit mehr sind, kam kürzlich ein RAID-Verbund mit solch großen Festplatten bei einem Kunden zum Einsatz. Doch wie bei vielen Stellen in der IT-Welt gibt es auch hier eine Grenze, die vor einigen Jahrzehnten bestimmt worden ist. Damals, als Festplatten nur wenige Megabyte groß waren, hat man festgelegt, dass eine normale Partitionstabelle maximal eine Festplatte mit 2 TB adressieren kann – technisch natürlich begrenzt durch die allseits bekannten 32 Bit.

Selbstverständlich gibt es eine Alternative zum derzeit fast überall eingesetzten Master Boot Record (MBR), diese Alternative heißt GUID Partition Table (GPT). Nun ist das Problem, dass die Unterstützung für GPT sowohl im BIOS als auch beim Bootmanager (z.B. Grub) vorhanden sein muss. Auf x86-basierenden Systemen (üblicherweise als x86, IA32, x86_64, AMD64, EM64T bekannt) ist eine Unterstützung von GPT bislang allgemein recht selten und aktuell unterstützt keine für den Unternehmenseinsatz optimierte Linux-Distribution die GPT von Haus aus.

Natürlich könnte man einen Grub 2 (der sowieso noch Zukunftsmusik ist) selbst compilieren oder den bestehenden Grub 0.x mit einem Patch aufbohren, aber das muss hinterher selbst gepflegt sowie gewartet werden und bei Problemen ist man auf sich selbst gestellt.

Die Lösung ist nun bei einem RAID-Controller den RAID-Verbund anderst aufzubauen: Hat man z.B. nur Festplatten mit jeweils 1 TB, so plant man üblicherweise ein RAID 5 mit 5 Festplatten und einer Hotspare-Platte. Eine mögliche, funktionierende Lösung wäre ein RAID 1 aus 2 Festplatten, sowie ein RAID 5 aus 5 Festplatten und eine globale Hotspare-Festplatte. In diesem Fall müsste man einfach noch zwei weitere Festplatten dazukaufen, um die gleiche Nutzkapazität zu erreichen. Auf das RAID 1 wird das Betriebssystem mit einem MBR installiert, auf das RAID 5 wird eine GPT eingerichtet und anschließend hat man 4 TB für Nutzdaten. Und die globale Hotspare springt entweder für das RAID 1 oder das RAID 5 ein – je nach dem, wo sie bei Bedarf benötigt wird.

Bei Verwendung eines Red Hat Enterprise Linux 5 (RHEL) bzw. CentOS 5 kann eine ganz normale Installation auf dem RAID 1 durchgeführt werden. Anschließend wird das RAID 5 mit GPT eingerichtet wie folgt:

[root@tux ~]# parted /dev/sdb
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags

(parted)
(parted) mkpart
Partition name?  []? BACKUP
File system type?  [ext2]? ext3
Start? 0
End? -1
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name    Flags
 1      17.4kB  3999GB  3999GB               BACKUP

(parted)
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.

[root@tux ~]#

Anschließend kann mit mkfs.ext3 ein Dateisystem angelegt werden. Wichtig ist noch, dass fdisk aktuell nur mit MBR-Partitionstabellen und nicht mit GPT umgehen kann. Somit muss in jedem Fall zu parted (GNU Parted) gegriffen werden. Übrigens, MBR-Partitionstabellen und Partitionen größer als 2 TB lassen sich problemlos anlegen, konfigurieren und selbst ein Dateisystem lässt sich darauf anlegen. Aber sobald Daten ins Spiel kommen, geht das ganze schief. Einige Leute beschreiben zudem, dass die Beschränkung sich lediglich auf Partitionen größer als 2 TB beziehen würde und Partitionstabellen größer als 2 TB möglich wären – dies habe ich so nicht nachvollziehen können: Egal ob Partition oder Partitionstabelle, sobald die 2 TB-Grenze erreicht war, gab es bei mir Probleme.

Bei RAID beziehe ich mich überall auf ein Hardware-RAID, da ein Software-RAID zum einen immer eine schlechtere Performance als ein Hardware-RAID liefert und zum anderen, da sich dieses Problem auch nicht mit einem Software-RAID lösen lässt.

Die Verwendung eines Logical Volume Managers (LVM) wäre sicherlich auch noch eine Möglichkeit, hätte es nicht im Linux-Kernel unter Verwendung von LVM2, wie er mit allen gängigen Enterprise-Distributionen mitgeliefert wird, bis vor kurze Zeit einen schwerwiegenden Fehler gegeben, der im Extremfall bei 100% Schreibgeschwindigkeit für lediglich 50% Lesegeschwindigkeit gesorgt hat. Das Problem wurde erst mit einer Testversion des Linux-Kernels in Version 2.6.27 behoben und wird aufgrund von Inkompatibilitäten vermutlich auch in keine bestehende Version einer Enterprise-Distribution zurückportiert werden. Red Hat behandelt dieses Problem aktuell im von mir geöffneten Bugreport 147679 und geht davon aus, es mit Red Hat Enterprise Linux 6 (und damit auch CentOS 6) zu beseitigen…