errata

 

 

 

Ein Buch zu schreiben gelingt niemals ohne auch Fehler zu machen. Auf dieser Seite werde ich Berichtigungen zu Fehlern im Root-Server Buch veröffentlichen, sowie sie mir bekannt werden.

Sollten Sie einen Fehler finden, scheuen Sie nicht mich darauf hinzuweisen!

Letzte Änderung: 04.05.2012

Fehler und Ergänzungen

Seite 30, erste Kommandozeile:

Es sollte heißen:

linux:~ # sfdisk -H 255 -S63 -C91201 /dev/sda < parttable_sdb

An dieser Stelle noch ein Hinweis: Neuere Versionen von fdisk warnen, dass der DOS-kompatible Modus,  Partitionierungen nach Zylindergrenzen anzulegen, "deprecated" sei. Folgt man den Anweisungen und gibt vor der Partitionierung die Kommandos "c" und "u" ein, liefert die darauf folgende Partitionierung, Partitionen, die nicht mit den Zylindergrenzen der Platten übereinstimmen, was andere Partitionierer wie etwa sfdisk als Fehler ansehen.

...und eine aktuelle Ergänzung: Hinzuzufügen ist allerdings, dass jetzt (April 2012) wo Festplatten größer zwei Terrabyte nicht mehr ungewöhnlich sind, die klassische Partitionstabelle mit Master-Boot-Record (MBR) ausgedient hat. Damit können Festplatenn maximal bis 2TB adressiert werden. Alternativ steht die "GUID Partition Table" (GPT) zur Verfügung. Voraussetzung für deren Verwendung ist natürlich, dass sowohl BIOS als auch Bootmanager diese unterstützen. In der Praxis ist dies leider nicht immer der Fall. Offiziell unterstützt Grub2 GPT, allerdings habe ich auch damit schon "zur Verzweiflung treibende" Probleme gehabt. Interessant war, dass ein verzweifelter Versuch den betagten "LILO" zu testen, zum Erfolg führte.

Seite 48, "grub fallback"

An dieser Stelle muss ich mich entschuldigen. Ich hab wohl den Wald vor lauter Bäumen nicht gesehen. Ich habe in den einzelnen Grub-Menüeinträgen jeweils wieder die Option "fallback X" eingetragen. Das ist falsch. Um gezielt einen alternativen Eintrag zu starten falls der Systemstart fehlschlägt kann "savedefault X" eingetragen werden. "X" entspricht der Nummer des Alternativ-Eintrags.  Damit dies funktioniert muss es weiter oben in der menu.lst statt "default 0", "default saved" heissen.

Alternativ kann auch die mit "falback X Y Z" angegebene Bootreihenfolge abgearbeitet werden. Hierzu muss es in jedem primären Boot-Menüeintrag statt "savedefault X" einfach "savedefault fallback" heissen. In den jeweils angesprochenen alternativen Boot-Menüeinträgen muss einfach nur "savedefault" eingetragen werden. Dies setzt den zuletzt gestarteten Eintrag als Standard.

Unabhängig davon, welche Möglichkeit gewählt wird, muss bei erfolgreichem Start des Standard-Systems der gespeicherte Default-Eintrag wieder auf "0" gesetzt werden.

Dies wird über das Kommando:

linux:~ # grub-set-default 0

bzw. unter openSUSE

linux:~ # grubonce 0

erreicht werden. Dies sollten Sie automatisieren, in dem Sie das gezeigte Kommando etwa in  das init-Script "boot.local" eintragen.

Weitere Infos zum Thema gibt es hier.

Wird, was in den meisten Fällen als Notfall-Option ausreicht, lediglich ein Fallback-Eintrag benannt., lässt sich der gesamte Mechanismus deutlich vereinfachen. In unserem Fall geht es ja ausschließlich darum von der zweiten Platte zu booten, wenn die erste beschädigt ist.Die Vorgehensweise:

Es bleibt beim fixen Default-Eintrag:

default 0

Darauf folgt ein Fallback-Eintrag, der auf die zweite Platte verweist. Im Buchbeispiel wäre dies der dritte Eintrag (Nr. 2, grub beginnt die Zählung ja bei 0)

fallback 2

In den einzelnen Boot-Menüeinträgen muss keine "savedefault" Option gesetzt werden.

Noch ein Hinweis zur Situation: Die verschiedenen Dokumentationen die zu Grub zu finden sind, sind häufig ohne Hintergrundinformationen und teils widersprüchlich. Dies liegt nicht zuletzt daran, dass die einzelnen Distributionen Grub selbst mit Funktionserweiterungen und Veränderungen versehen und dies nicht immer dokumentieren. (Dies soll keinesfalls meinen Fauxpas entschuldigen) Ich möchte Sie lediglich dazu bewegen Ihre Grub-Konfigurationen erst im Trockenen zu testen, bevor Sie diese auf Servern, die hunderte Kilometer entfernt in einem Rechenzentrum stehen, einsetzen und Gefahr laufen sich mit einem nicht startenden Computer herum schlagen zu müssen.

Kapitel DNS S. 131

Das Beispiel für die Include-Anweisung muss natürlich mit einem Semikolon abgeschlossen werden. Darüber hinaus sollte der angegebene Pfad möglichst in Anführungszeichen gesetzt werden.

include                 "/etc/named.keys";

Kapitel DNS S. 133

Im Konfigurationsbeipiel für die DDNS Update-Policy hingegen, war ich mit dem Semikolon ein wenig zu übereifrig. Die mit "grant" und "name" beginnenden Zeilen werden jeweils nicht mit einem Semikolon abgeschlossen, da sie genaugenommen eine Zeile bilden, die mit dem "A" abgeschlossen wird.

Stattdessen werden die Namen der Vollständigkeit halber mit einem Punkt abgeschlossen.

grant homeserver.invis-server.net.

name homeserver.invis-server.net.

A;

Damit DDNS-Updates funktionieren muss das Verzeichnis "/var/lib/named/master" in dem sich die Zonendateien befinden der Gruppe "named" gehören und für diese beschreibbar sein.

Kapitel LAMP S. 143/144

Es wurde versäumt zu erwähnen, dass lokale Verbindungen zum MySQL-Daemon häufig auch über sogenannte "Sockets" laufen. Sockets sind, vereinfacht ausgedrückt "Dateien" die von zwei Seiten gelesen und geschrieben werden können. An einer Seite steht dabei der MySQL-Dienst, der den Socket zur Verfügung stellt und auf der anderen Seite der SQL-Client.

Standardgemäß ist der MySQL-Daemon so eingerichtet, dass dieser einen Socket zur Verfügung stellt. Wo der Socket angelegt wird, wird über die Datei "/etc/my.cnf" (openSUSE) konfiguriert.

Die Kommunikation über einen MySQL-Socket ist deutlich performanter, als über die localhost-Schnittstelle, da bei Verwendung des Sockets die Nutzung des TCP/IP-Stacks komplett überflüssig ist.

Kapitel LAMP S. 143

Das hat bei mir schon Tradition. Beim ersten Setzen des MySQL-Root-Passwortes wird die Option "-p" natürlich nicht benötigt. Da ja noch kein Passwort gesetzt ist, muss es auch nicht abgefragt und eingegeben werden.

Kapitel LAMP S. 147

Hier sollte es natürlich:

linux:~ # /etc/init.d/apache2 force-reload

heissen.

Kapitel LAMP S. 160

Der zweite Eintrag in der "DirectoryIndex" Zeile muss "index.htm" lauten. "index.html" zweimal aufzuführen macht selbstverständlich keinen Sinn.

Kapitel LAMP S. 161

Das Konfigurationsbeispiel für die Einrichtung einer Dummy-Netzwerkschnittstelle ist einen Absatz zu weit nach oben gerutscht. Im Erläuterungstext zur Konfiguration sollte die Schnittstelle passend zum Beispiel "ifcfg-net0" benannt werden.

Kapitel LAMP S. 163/164

In die Beipielkonfigurationen für die Apache vHosts sind jeweils in den "ServerName" Zeilen versehentlich Anführungszeichen abgedruckt. Diese sind überflüssing.

Seite 240 -- Konfiguration

Hier fehlt hinter "reject_unauth_destination" das Komma am Ende der Zeile.

Seite 245 -- SMTP-Auth

In der dargestellten Kofiguration sind in der Zeile "smtpd_sasl_security_options" die darauf folgenden Werte mit Kommata zu trennen:

smtpd_sasl_security_options = noanonymous, noplaintext, cram-md5, digest-md5

Seite 249 -- Konfiguration des verschlüsselten Mailversands

Im Hinweis im unteren Drittel der Seite weise ich zwar auf die Unterschiede der Konfiguration zwischen Mail-Annahme (smtpd) und Mail-Versand (smtp) hin, zeige aber keine Konfiguration des Zugriffs auf Schlüssel für den Versand. Dies sei hiermit nachgeholt:

smtp_tls_key_file = /etc/ssl/private/ms-rs2.fspisp.de.pem

smtp_tls_cert_file = /etc/ssl/private/ms-rs2.fspisp.de-cert.pem

Die Nutzung der Schlüssel ist notwendig, wenn sich unser Client am zuständigen Mailserver per Schlüssel authentifiziert. Für die Konbination aus SASL-gestützter Anmeldung und TLS-gesicherter Verbindung werden keine Schlüssel auf der Client-Seite benötigt.

Erwarten wir im Umkehrschluß, dass sich auch der Server an den wir Mails einliefern bei uns mit Schlüsseln identifiziert, müssen wir Zugriff auf dessen CA-Zertifikat in Form einer CA-Datei haben. Die CA-Datei muss alle Zertifikate von uns als vertrauenswürdig und bekannt eingestuften Mailserver enthalten.

smtp_tls_CAfile = /etc/postfix/CAcert.pem

Weitere Infos dazu in der Manpage:

linux:~ # man 5 postconf

Ergänzung zu den Erläuterungen zum Thema Dovecot-Login (S. 276 - 281)

sowie SMTP-Auth mit Postfix (S. 244 - 247)

Im Buch wurde versucht eine möglichst flexible und sichere Anmeldung an den vorgehaltenen Postfächern und für den Mailversand zu erreichen. Es werden die verschiedensten Kombinationen aus Klartext-Anmeldung und TLS-Verschlüsselung oder Passwortverschlüsselung für unverschlüsselte Verbindungen angesprochen und beschrieben.

Wir haben die Postfix-Konfiguration so gestaltet, dass über die Konfigurationsoption:

smtpd_sasl_tls_security_options = noanonymous

Klartextanmeldungen bei TLS-verschlüsselten SMTP-Sitzungen erlaubt sind. Dies lässt sich etwa beim Mailclient Thunderbird auch wunderbar nutzen, indem als Passwortübertragungsmethode "normal" angegeben wird.

Anders sieht es aus, wenn ein anderes Postfix als SMTP-Client auftritt. Hier handeln beide Postfix-Server ungeachtet der Erlaubnis ein unverschlüsseltes Passwort zu übertragen, automatisch die bestmögliche Passwortverschlüsselungsmethode aus, die von beiden Partnern unterstützt wird. Bei einem Test meinerseits war dies DIGEST-MD5. Liegt jetzt das Passwort des Clients über einen anderen Algorithmus  (etwa SSHA) verschlüsselt in /etc/dovecot/passwd vor schlägt der SMTP-Auth-Login zwangsläufig fehl.

Hier bleibt nur die Möglichkeit alle Passwörter im Klartext in /etc/dovecot/passwd anzugeben oder dies individuell für jeden Client festzulegen. Letzteres dürfte ab einer gewissen Nutzerzahl ein recht aufwändiges Unterfangen sein.

Seite 402/403 "nmap"

Im Text wurde zur Unterdrückung eines Ping-Tests die Option -P0 angegeben. Ergänzend dazu, kann alternativ auch -PN angegeben werden. Sie sorgt dafür, dass der Zielhost ohne Test als "online" angesehen wird.