Aus dem Rechenzentrum

Immer wieder habe ich Anlass, nach diesem Zitat zu suchen, und weil ich mir regelmäßig einen Wolf suche, packe ich es jetzt mal ins Blog. Es geht darum, wie man gute Supportanfragen stellt. Dazu kann man natürlich das informative How To Ask Questions The Smart Way bemühen. Man kann aber auch die Bernstein’sche Kurzform nehmen, die alles Wichtige auf diesen Schnipsel reduziert:

Your message should give complete answers to the following three questions:

1. What exactly did you do?
2. What exactly did the computer do?
3. What exactly did you expect the computer to do?

Es ist kaum vorstellbar, wieviele Supportanfragen sich auf (um mal ein griffiges Thema exemplarisch herauszugreifen) „Ich kann keine Mails versenden – warum nicht?“ reduzieren. Schon die Frage danach, welche Fehlermeldung man denn erhält, provoziert häufig nur große Augen, wenn nicht gleich überraschende Antworten wie „die war auf Englisch, hab ich nicht verstanden“. Ebenfalls nicht ohne Grund bitten wir immer wieder darum, uns Fehlermeldungen nicht am Telefon vorzulesen, sondern uns im Originalwortlaut weiterzuleiten. Nicht selten hören wir am Telefon Dinge wie „Da steht, den Empfänger gibt’s nicht“ – die tatsächliche Meldung hingegen lautete „User over quota“, was nun eben mal etwas völlig anderes ist.

Selbstverständlich bemühen wir uns, Supportanfragen soweit wie möglich zu qualifizieren. Wir bewegen uns ja hier nicht im Bereich von Community-Support, sondern im Bereich bezahlter Unterstützung – dass wir da Kunden nicht „maßregeln“ oder „erziehen“, versteht sich schon von selbst. Aber manchmal ist das Maß der uns vor die Füße geworfenen Informationen wirklich so gering, dass wir da beim besten Willen nichts extrahieren können, was zur Beantwortung einer Anfrage vonnöten wäre. Teamintern ist dann schon mal die Rede davon, dass wir unsere Glaskugel leider schon für ihren Einsatz an Ostern bemalt haben. Nach außen hin fragen wir natürlich einfach nur freundlich nach weiteren Daten. :-)

Aber bitte: So schwer ist das mit den drei Fragen nun wirklich nicht. Und sie helfen uns enorm dabei, Supportanfragen zügig und korrekt zu beantworten, ohne uns mit langwierigen Zwischenfragen aufzuhalten oder aufgrund der allzu sparsamen Informationen in eine ganz falsche Richtung zu denken und dann auch zu antworten. Von daher: Herzlichen Dank im Voraus, wenn Sie mit dazu beitragen, damit alles zügig in Ihrem Sinne funktioniert.

Manchmal erstaunt mich wirklich, welche „Klopper“ sich so im Kleingedruckten von Software verstecken, und das schließt freie Software nicht aus.

Auf Wunsch eines Kunden installierten wir das Webmail-System Roundcube auf seinem Server. Der „runde Würfel“ unterstützt unter anderem die Möglichkeit, seine Mails vor dem Absenden durch eine Rechtschreibprüfung zu jagen. An sich kein großes Problem; bietet Linux mit aspell, hunspell oder dem älteren pspell doch genug verbreitete Tools, um einen solchen Check zu realisieren.

Nach einem genaueren Blick auf die config/main.inc.php.dist, die im Tarball enthalten ist und somit die Vorgabe-Konfiguration darstellt, fiel mir doch glatt die Kinnlade herunter. Ich stelle mal die entsprechenden Punkte mit auf die wesentlichen Punkte gekürzten Kommentare zusammen:

// Make use of the built-in spell checker. It is based on GoogieSpell.
$rcmail_config[‚enable_spellcheck‘] = TRUE;

// Set the spell checking engine. ‚googie‘ is the default.
$rcmail_config[’spellcheck_engine‘] = ‚googie‘;

// Leave empty to use the Google spell checking service, what means
// that the message content will be sent to Google in order to check spelling
$rcmail_config[’spellcheck_uri‘] = “;

Also, nochmal im Klartext: Wenn man in einer Standardinstallation von Roundcube die Rechtschreibprüfung benutzt, werden alle Mailinhalte zur Prüfung an Google gesendet. Wer hätte das gedacht? (Zum Hintergrund: Es wird hierbei jene Google-API angesprochen, die primär von der in die Google Toolbar integrierten Rechtschreibprüfung genutzt wird.)

Relevant ist dieser Punkt nicht zuletzt bei Installationen, die man nicht nur für eigene Zwecke benutzt, sondern auch Dritten zur Verfügung stellt. Hier bedürfte es nämlich eines entsprechenden Datenschutzhinweises, wenn man die Mailinhalte jener Dritten ungefragt an einen externen Dienstleister sendet, der somit Kenntnis von den Mailinhalten erlangt.

Das passt doch wie die Faust aufs Auge zum sehenswerten Beitrag The Beast File: Google, von dem ich just gestern via Fontblog erfuhr. Anschauen!

(Diese Aufforderung gilt natürlich nach wie vor auch für Google Epic 2015, und das nicht nur wegen der betörenden Stimme von Franziska „Scully“ Pigulla.)

Wer sich manchmal fragt, was der inhaltliche Unterschied zwischen Fedora und Red Hat Enterprise Linux bzw. CentOS ist: Fedora bekommt in kurzen Zyklen haufenweise Updates und stellt eher eine „Spielwiese“ dar. In RHEL/CentOS fließen in Fedora erprobte Änderungen dann nach Stabilisierung und Tests ein.

Nicht ohne Grund verwenden wir auf unseren Servern in der Regel CentOS. Auf meinem Netbook für unterwegs, in dem auch ein UMTS-Modul eingebaut ist, benutze ich allerdings Fedora – und damit ergab sich kürzlich ein schönes Beispiel, das den Unterschied in der Stabilität verdeutlicht.

Für den Aufbau von PPP-Verbindungen ist das Paket pppd zuständig, das bei Fedora zunächst in Version 2.4.4 vorlag, dann aber auf 2.4.5 aktualisiert wurde.

Die UMTS-Verbindungen können natürlich von Hand eingerichtet werden; der „offizielle“ grafische Weg ist aber die Konfiguration im NetworkManager. Dieser bringt ein entsprechendes Plugin mit, mit dessen Hilfe er den pppd ansteuern kann.

Dummerweise wurde das Plugin nicht mit aktualisiert, so dass das System nun vor folgender Situation stand:

$ rpm -ql NetworkManager | grep pppd
/usr/lib/pppd/2.4.4/nm-pppd-plugin.so

$ rpm -q ppp
ppp-2.4.5-2.fc12.i386

Sprich, das Plugin hat nicht mit dem Update mitgezogen – mit der Folge, dass der NetworkManager keine UMTS-Verbindungen mehr aufbauen konnte. Das ist natürlich besonders ärgerlich, wenn man gerade unterwegs ist und UMTS die einzige Möglichkeit wäre, ins Netz zu kommen. Erst ein Update des NetworkManagers hat dieses Problem dann beheben können. Siehe auch:

NetworkManager pppd plugin does not work with latest pppd

Nur mal so am Rande: Wie funktioniert das eigentlich, dass ich beim Kauf eines Druckers für den Versand per UPS 9,90 Euro Versandkosten bezahle; wenn ich dann aber diesen Drucker wiederum verschicken will (Paketmaße: 97×94×96 cm), behauptet UPS, es könne so ein großes Paket nicht verschicken?

Das Paket überschreitet die Beschränkungen für die maximale Größe von 419 cm (Länge + Gurtumfang, wobei der Gurtumfang 2 x Breite plus 2 x Höhe ist)

Und wenn ich die Sendung über irgendeinen anderen der unzähligen Paketdienste verschicken will, lautet die Auskunft entweder auch dort „zu groß“, oder der ermittelte Preis beläuft sich auf (zum Teil weit) über 100 Euro.

Ich meine, sicher, ein Hardwareversandhändler wird entsprechende Rahmenverträge haben, viel verschicken, „Mengenrabatt“ etc., aber bitte: Der Preis, den ich für einen einzelnen Versand bezahlen soll, kann dabei doch nicht zehn bis fünfzehn Mal so hoch sein? Segmentierte ich das Paket in vier kleinere (was bei einem Drucker zugegebenermaßen keine so gute Idee wäre), läge die Summe der DHL-Paketpreise für diese vier „normalen“ Pakete nur bei etwa einem Drittel des ansonsten von DHL veranschlagten Preises von 154,90 Euro. Erstaunlich!

Da nehme ich die Sendung doch lieber zum Anlass, beim Empfänger mal wieder persönlich reinzuschauen. Mit dem Zug nach Berlin hin und zurück ist nämlich günstiger als den Drucker per Paketdienst zu verschicken …

Direkt vorab: Unsere Bitte um Entschuldigung gibt’s weiter unten. Für die technisch Interessierten aber erstmal die Hintergrundgeschichte.

Ein durchaus angenehmes Feature von tinydns, den von uns eingesetzten DNS-Server, ist die Möglichkeit, Wildcard-Records im DNS zu definieren. So legen wir für die meisten Hosts standardmäßig an:

+domain.tld:1.2.3.4
+*.domain.tld:1.2.3.4

Mit letzteren sind dann alle Varianten von www.domain.tld über ftp.domain.tld bis zu admin.domain.tld automatisch abgedeckt. Sollen einzelne Subdomains davon abweichen, definitiert man sie einfach separat:

+admin.domain.tld:1.2.3.5

So löst admin.domain.tld korrekt auf 1.2.3.5 auf; irgendwas.domain.tld aber weiterhin per Wildcard auf 1.2.3.4. So weit, so gut. Die Dokumentation von tinydns-data formuliert dies so:

Information for *.fqdn is provided for every name ending with .fqdn, except names that have their own records

Nun, ich hätte wohl auch das zweite darunterliegende Beispiel lesen sollen, und zwar sehr genau. Es verrät nämlich im Vorbeigehen eine wichtige Falle, über die wir heute gestolpert sind. Unser bisheriges Verständnis ließe sich etwa so formulieren:

Gibt es für den Hostnamen H einen Record vom Typ T, so übergeht dieser alle Wildcard-Records, die ansonsten auf den Hostnamen H und den Typ T gepasst hätten.

Leider ist das ein Irrtum. Die korrekte Formulierung muss nämlich heißen:

Gibt es für den Hostnamen H einen Record irgendeines Typs, so übergeht dieser alle Wildcard-Records, die ansonsten auf den Hostnamen H und irgendeinen Typ gepasst hätten.

Nicht sofort verstanden? Kein Problem. Konkretes Beispiel. Wir hatten in unserer data-Datei Folgendes stehen:

+*.jonaspasche.com:82.98.82.13

Hinter der IP 82.98.82.13 steht einer unserer Server namens wally, der mit vollständigem Namen also wally.jonaspasche.com heißt. Über obigen Wildcard-Record wurde er immer schon korrekt aufgelöst.

Nun hat mein Kollege Christopher heute SSHFP-Records angelegt, so dass nun folgendes in der data-Datei stand:

+*.jonaspasche.com:82.98.82.13
:wally.jonaspasche.com:44:[...]

Und nun die Falle: Fragt man den DNS-Server nun nach dem A-Record von wally.jonaspasche.com, liefert er nichts mehr zurück. Die dahinterstehende Logik ist laut (nun endlich richtig verstandener) Dokumentation: Da es irgendeinen Record gibt, der spezifisch für den Hostnamen wally.jonaspasche.com gilt (nämlich den SSHFP-Record), werden alle ansonsten auf eine Anfrage im Prinzip passenden Wildcard-Records ignoriert, und zwar unabhängig davon, ob sie auch zum gewünschten Typ des angefragten DNS-Records passen oder nicht.

Das finde ich persönlich absolut nicht intuitiv, und ich bin noch nicht ganz mit mir übereingekommen, ob ich es zumindest jetzt, wo ich es verstanden habe, zumindest sinnvoll finde. Ich tendiere zu nein. Aber ich muss zähneknirschend zugeben, dass es eben kein Bug ist, sondern dokumentiert ist – nur wenngleich eben so, dass die entsprechende Stelle missverständlich ist und man schon das Beispiel mit dem Nachsatz sehr genau interpretieren muss.

Da war ich doch fast schon der Meinung, in Sachen tinydns nun wirklich schon seit Jahren ein alter Hase zu sein, dem man so schnell nix mehr vormacht. Denkste. Aber es ist sicherlich nicht das Schlechteste, das eigene Wissen durchaus auch nach Jahren ruhig nochmal hinterfragen zu lassen.

Es tut uns leid.

Wir bitten alle Kunden um Entschuldigung, die aufgrund dieses Vorfalls vorübergehend Probleme mit dem Abruf und Versand von E-Mails hatten. Ärgerlicherweise waren hierbei primär jene Kunden betroffen, die für ihre Mail-Verbindungen SSL-Verschlüsselung benutzen und daher dann auch wally.jonaspasche.com als Hostname – weil das SSL-Zertifikat auf diesen Namen ausgestellt ist. Wer als Mailserver seine eigene Domain angegeben hat, was (an sich „leider“, im konkreten Fall aber „zum Glück“) die überwiegende Mehrheit ist, dürfte keine Probleme festgestellt haben.

Nachdem wir nun den entsprechenden Erkenntnisgewinn hatten, können wir beschämt sagen: Kommt nicht wieder vor. Das nicht. Wir bitten darum, den Vorfall als positives Zeichen dafür anzusehen, dass auch wir nur Menschen und keine Götter sind. Herzlichen Dank.

Ich hatte neulich mal wieder das Problem, daß mir ein Server quasi unter den Händen abgestürzt ist (keine Sorge: es war kein Kundenserver) und ich per SSH nicht so recht wußte, wie ich ihn noch halbwegs geordnet neustarten kann, da er auf Befehle wie reboot und shutdown -r now bereits nicht mehr reagierte, bzw. diese blockiert wurden. In diesem Moment wünschte ich mir am Server zu sitzen und ihn über die Tastatur mit SysRQ neustarten zu können. Eine flinke Suche mit Google später wußte ich, daß ich SysRQ auch über eine Konsole oder gar SSH auslösen kann, indem ich nach /proc/sysrq-triger schreibe. Nachdem mir also mit SysRQ wiedereinmal geholfen war und ich diese Funktion inzwischen sehr schätze, habe ich das zum Anlaß genommen, hier mal etwas darüber zu schreiben:

SysRQ ist ein viel zu unbekanntes Feature des Linux-Kernels. Hinter dem etwas sperrigen Namen verbirgt sich die Fähigkeit des Kernels, über bestimmte Tastenkombinationen direkt Notfall- und Debuggingbefehle entgegenzunehmen. (In der offiziellen Dokumentation wird auch gerne von magischen Tastenkombinationen gesprochen. Da ich auf das Wort Magie im Zusammenhang mit Software allergisch reagiere — dahinter verbirgt sich meiner Erfahrung nach fast nie etwas so geniales und nützliches wie SysRQ — lasse ich diese Umschreibung hier mal unter den Tisch fallen.)

Wenn man z.B. bemerkt wie einem ein lausiger Graphikkartentreiber eines der beiden großen Weltmarktführer das System in den Abgrund reißt, dann kann man mit SysRQ versuchen den Schaden zu minimieren, etwa indem man den laufenden Programmen befielt sich zu beenden, den Kernel anweist die Dateisystemcaches zu leeren (in anderen Worten: die darin vorhandenen Daten auf die Festplatten zu schreiben) und die Dateisysteme zu unmounten bzw. schnell read only zu remounten. Das ganze ist auch sehr nützlich, wenn ein System aus anderen Gründen kaum noch oder gar nicht mehr zu reagieren scheint. Ein Versuch lohnt sich allemal, denn ein kontrollierter Absturz ist immer noch besser als ein unkontrollierter.

Ob SysRQ auf einem System aktiviert ist kann man sehr leicht mit folgendem Befehl abfragen:

cat /proc/sys/kernel/sysrq

Lautet die Antwort 0 ist SysRQ ausgeschaltet, lautet sie 1 ist es aktiviert.

Dementsprechend kann man es sehr leicht einschalten:

echo 1 > /proc/sys/kernel/sysrq

und ebenso leicht ausschalten:

echo 0 > /proc/sys/kernel/sysrq

Will man es dauerhaft einschalten, sollte man in seiner /etc/sysctl.conf die Zeile

kernel.sysrq = 1

eintragen, bzw. eine eventuell schon vorhandene Zeile für kernel.sysrq entsprechend anpassen.

(Dauerhaft ausschalten geht wieder mit kernel.sysrq = 0.)

Hat man SysRQ aktiviert, muß man sich damit befassen wie man es auslösen kann. Auf typischen PCs mit normalen Tastaturen mit deutschem Layout ist die Tastenkombination für SysRQ Alt+Druck. Den meisten PC-Besitzern und Laptop-Usern sollte damit geholfen sein, es gibt aber gerade in letzter Zeit immer mehr Modelle, bei denen die Druck-Taste nicht direkt vorhanden ist (also etwa nur durch zusätzliches Halten einer fn-Taste oder dergleichen ausgelöst werden kann, z.B. bei Netbooks) oder ganz fehlt (z.B. bei den Intel-basierten MacBooks und MacBookPros von Apple – die alten PowerBooks und iBooks mit PPC hatten SysRQ nur auf einer anderen Taste). Das ist sehr ärgerlich und es gibt keine wirklich guten Lösungen für dieses Problem. Mit einer Xmodmap ist einem nicht geholfen, da sie nur für den X-Server und nicht für den Kernel gilt. Mit den in der offizellen Dokumentation empfohlenen Tools showkey und setkeycodes ist einem nur bei PS/2-Tastaturen geholfen (die meisten Laptops binden Tastaturen schon lange per USB an) und den Treiber für USB-Tastaturen werden nur die wenigsten Leute selbst patchen wollen. Wenn ich jemals einen Weg finde, der auch mit modernen USB-Tastaturen funktioniert, wird mir das hier garantiert einen weiteren Artikel wert sein.

Immerhin: Es gibt eine Methode, die auf jeder Architektur und Tastatur funktioniert: Wenn man auf dem System eine Konsole offen hat (zur Not tut es auch eine Verbindung per SSH, auch wenn man dann vorsichtig sein sollte, welche SysRQ-Befehle man sendet), dann kann man den entsprechenden SysRQ-Befehl in /proc/sysrq-trigger schreiben, etwa so:

echo s > /proc/sysrq-trigger

Für die Freunde der Seriellen Konsole gibt es noch die Möglichkeit einen BREAK zu senden und binnen 5 Sekunden einen SysRQ-Befehl hinterher.

Nun zu den SysRQ-Befehlen:

Die Tastenkombination Alt+SysRQ und die anderen Wege um SysRQ auszulösen allein genügen nicht, man muß sie immer mit bestimmten Befehlen kombinieren, die über Buchstabentasten abgekürzt sind (bzw. man muß bei seriellen Verbindungen den jeweiligen Buchstaben binnen 5 Sekunden nach einem BREAK schicken oder über proc den Buchstaben eingeben).

Einige SysRQ-Befehle sind nur für Entwickler interessant, wer sich damit beschäftigen möchte, dem empfehle ich die oben verlinkte offizielle Dokumentation. Hin und wieder kommen auch neue Befehle hinzu und ganz selten verändern Befehle ihre Funktion. Wer wissen möchte welche SysRQ-Befehle sein Kernel unterstützt, kann es mit Alt+SysRQ+h leicht herausfinden. Die für die allgemeine Benutzung nützlichsten Befehle sind:

Von diesen Befehlen ausgehend haben sich mit der Zeit ein paar Rezepte durchgesetzt, deren Benutzung zum halbwegs kontrollierten Neustarten eines abstürzenden Systems empfohlen wird. Die häufigsten Varianten sind REISUB oder RSEISUB, für die es die Merksätze „Raising Elephants Is So Utterly Boring“ und „Raising Skinny Elephants Is So Utterly Boring“ gibt (für REISUB gibt es noch die Eselbrücke, daß es das englische Wort busier rückwärts geschrieben ist). Von dem Merksatz mit den Elephanten leitet sich auch die Bezeichnung „raising elephants“ für das Benutzen von SysRQ ab.

Man sollte nach dem Absetzen jedes Befehls einen Moment warten und dem System Zeit zum Handeln lassen, insbesondere nach den Befehlen Alt+SysRQ+E, Alt+SysRQ+I und vor dem Befehl Alt+SysRQ+B.

Um es nochmal am Bespiel zu erklären, die Befehlsfolge RSEISUB hat zur Folge, daß zunächst die Tastatur in den RAW-Modus versetzt wird und ein weiterer Zugriff auf den Kernel über die Tastatur damit sichergestellt ist. Dann werden die Dateisysteme auf die Festplatten synchronisiert. Als nächstes werden alle laufenden Prozesse außer init freundlich aber bestimmt mit dem Signal SIGTERM dazu aufgefordert sich zu beenden. Wer sich einige Sekunden später immer noch nicht beendet hat, wird mit SIGKILL auf die harte Tour beendet. Dann folgt eine weitere Synchronisation der Dateisysteme auf die Festplatten (damit von den Programmen beim Beenden geschriebene Daten und Logs auch auf der Platte landen). Schließlich werden die Dateisysteme in den read only Modus gebracht und nachdem ihnen so nichts mehr passieren sollte, wird das System ohne weiteres Federlesen neugestartet.

Wenn man diese Schritte befolgt, kann man mit etwas Glück Datenverlust vermeiden und sich oft sogar das lästige Überprüfen der Dateisysteme sparen. (Wenn Synchronisation und Remount im read only Modus geklappt haben, sollten Dateisysteme keinen Schaden davontragen beim Reboot. Sollte das System beim Neustart trotzdem auf einer Überprüfung der Dateisysteme bestehen, dann sollte man es gewähren lassen.)

Bei einem Kundenprojekt stand ich in der Verlegenheit, eine zurückhaltend gestaltete Tabelle zu entwerfen, bei der die einzelnen Zeilen nur mit einer Linie separiert sind, wobei die Tabelle aber keinen Rahmen haben soll – sprich, es soll auch keine Linie über dem ersten bzw. unter dem letzten Eintrag geben. Hacks wie z.B. der ersten bzw. letzten Zeile eine abweichende CSS-Klasse zuzuweisen verboten sich schon von daher, weil die Zeilen der Tabelle in einer Schleife im Template dynamisch generiert werden. Ein border-top bzw. border-bottom erzeugt aber eben immer die entscheidende Linie zuviel. Ein auf dem table-Tag gesetztes border: none hatte ebenfalls keine Wirkung.

Zeit, um nach etwas Googlen eine mir bis date nicht bekannte Einstellung zu finden: border: hidden in Zusammenhang mit dem collapsing border model. Bei jenem geht es darum, die Rahmen verschiedener Elemente zusammenfallen zu lassen, so dass z. B. der rechte Rand einer Zelle und der linke Rand der rechts danebenliegenden Zelle nur eine einzelne Linie ergeben und nicht zwei.

Das collapsing border model hat gelegentlich Konflikte zu klären, nämlich wenn zwei Rahmen zusammenfallen sollen, die aber unterschiedlich aussehen. Das W3C hat dafür aber ein standardisiertes Regelwerk entwickelt, und dessen erste Regel lautet:

Borders with the ‚border-style‘ of ‚hidden‘ take precedence over all other conflicting borders. Any border with this value suppresses all borders at this location.

Wie praktisch – ein border: none auf der Tabelle erzeugt außenherum nämlich einen Rahmen, der in Konflikt mit dem border der Tabellenzellen steht, und da border: none die niedrigste Priorität hat (im Gegensatz zu border: hidden, was wie beschrieben die höchste hat), wirkt es nicht.

Das Ergebnis der Bemühungen:

table#example {
  border: hidden;
  border-collapse: collapse;
}
table#example td {
  border-top: solid 1px;
  padding: 0.5em;
}

<table id="example">
  <tbody>
    <tr>
      <td>A1</td>
      <td>A2</td>
      <td>A3</td>
    </tr>
    <tr>
      <td>B1</td>
      <td>B2</td>
      <td>B3</td>
    </tr>
  </tbody>
</table>

Und so sieht’s aus:

(Eine demütige Entschuldigung an alle User, die sich den Quellcode der Seite ansehen: WordPress entfernt beim Speichern aus mir nicht bekannten Gründen die style-Tags um das produktive CSS-Beispiel, so dass es nicht mehr funktioniert. Ich musste daher die Elemente einzeln direkt stylen. Sorry.)

Ich stehe häufiger vor dem Problem, daß ich Software installiere und den Pfad zu den Binaries gerne der Umgebungsvariable PATH hinzufügen möchte. Nun könnte ich dies — z.B. nach der Installation von qmail — sehr bequem erreichen, indem ich einfach in meinem Userprofil der Datei /.bashrc eine Zeile wie diese hier hinzufüge:

export PATH=$PATH:/var/qmail/bin

Damit habe ich das Problem aber nur für mich gelöst. Nun könnte ich eine entsprechende Datei auch in /etc/skel/ ablegen, aber das hilft nur neu angelegten Usern. Ich könnte auch die /etc/profile editieren, aber diese Datei wird nur für Login-Shells berücksichtigt und ist so zum Beispiel keine Hilfe für User die gerne screen nutzen (außerdem wurde sie von der Paketverwaltung angelegt und wenn ich sie ändere, bekomme ich in Zukunft bei jedem Update dieser Datei eine /etc/profile.rpmnew angelegt und muß den Versionskonflikt händisch lösen). Eine /etc/bashrc gibt es leider nicht und die Bash würde sie auch nicht berücksichtigen, wenn es sie gäbe. Wie ist also nun die Vorgehensweise um unter CentOS eine Umgebungsvariable global zu setzen oder zu verändern?

Die Antwort ist /etc/profile.d/. In diesem Verzeichnis kann man sehr bequem globale Umgebungsvariablen einrichten und dabei auf die verschiedenen installierten Shells eingehen. So liest die Bash z.B. nur auf .sh endende Dateien in diesem Ordner ein und die CSH liest nur ausführbare und auf .csh endende Dateien ein. Ein weiterer Vorteil ist, daß man die bereits in diesem Ordner liegenden Dateien einfach in Ruhe lassen kann und nur neue anzulegen braucht, die Wahrscheinlichkeit von Konflikten mit der Paketverwaltung ist dadurch schonmal verringert.

Um beim Beispiel qmail zu bleiben, lege ich mir also eine /etc/profile.d/qmail.sh mit dem gewünschten Inhalt an:

export PATH=$PATH:/var/qmail/bin

Die Datei muß (anders als bei CSH) nicht ausführbar gemacht werden und muß keinen Shebang enthalten.

Und schon habe ich /var/qmail/bin ab sofort in der Umgebungsvariable PATH jeder neuen Bash-Shell die ich öffne — systemweit und bei jedem User.

(Noch besser: Auch die Manpages für qmail werden jetzt automatisch gefunden.)

Eben aus meinem Maileingang gefischt:

Hallo Ihre Email ist Bei Mir Auf Dem PC Angekommen!
Gruss [entfernt]
ps: automatisch Erstellte Email bitte Nicht antworten gibt endlos schleife!

Da kann ich ja nur hoffen, dass andere Autoresponder diesen lieb gemeinten Hinweis auch berücksichtigen. Einen technischen Hinweis darauf, dass obige Mail selbst ein Autoresponder ist, beispielsweise einen Precedence:-Header, gibt es nämlich nicht. Und so gilt dann wohl: Wie es in den Wald hineinschallt, …

Auf meine zugegebenermaßen ordentlich genervte Kritik daran, dass ein früher von uns genutzter Domainregistrar plötzlich noch mehr/andere Dokumentation will, als die DENIC es vorschreibt, habe ich nun folgende „erhellende“ Antwort erhalten.

Herr Pasche,

wir vom Support aus sind so verpflichtet zu arbeiten.
Fuer weitere Fragen zu dieser „Methode“ haben vielleicht die Vorsitzende bessere Antworten.

Ein inhaltlich unbegründetes „wir sind so verpflichtet zu arbeiten“ ist nun wirklich die ärgerlichste aller möglichen Antworten, zumal ein bisschen Gedrängel meinerseits ja schon gereicht hatte, dass man nun wohl doch nicht so sehr verpflichtet ist, diese „Methode“ einzuhalten.

Gut, dass wir da weg sind.