Arne P. Böttger

Eine praktische Erfindung sind DNS-Wildcard-Einträge, um z.B. bei einer Domain nicht alle Subdomains manuell konfigurieren zu müssen. Aber es gibt dabei Stolperfallen, in die auch erfahrene Sysadmins manchmal tappen.

Kurz zu den Grundlagen: Eine Zeile des Zonefiles besteht aus folgenden Teilen:

• name, z.B. www
• ttl, z.B. 300
• class, z.B. IN
• rr, z.B. A
• type-specific-data, z.B. 192.0.2.1

Nun kann man für name auch Wildcards benutzen, also z.B. solche Einträge machen, ein Beispiel-Zonefile wäre:

example.com        IN MX 10 mail.example.com.
*.example.com      IN MX 10 mail.example.com.
mail.example.com   IN A     192.0.2.1
*.example.com      IN A     192.0.2.2
*.demo.example.com IN A     192.0.2.3

Soweit ist alles klar. Ruft jemand im Browser kunde1.example.com auf, landet er auf 192.0.2.2, bei kunde1.demo.example.com auf 192.0.2.3, und alle E-Mails an info@kunde1.example.com werden über mail.example.com zugestellt. Aber was ist mit Mails an info@kunde1.demo.example.com?

Jetzt kommt das überraschende: Der MX-Eintrag *.example.com greift hier nicht. Warum? Nun, es wird der spezifischere Eintrag *.demo.example.com gefunden, für den es nur einen A-Record gibt. Sollen auch Mails an *.demo.example.com zugestellt werden, muß auch hierfür ein MX-Eintrag angelegt werden.

Und noch eine Stolperfalle: Gibt es eine zweite Sammel-Subdomain prod.example.com funktioniert dies mit der oben genannten Konfiguration, und kunde1.prod.example.com zeigt auf 192.0.2.2 – solange, bis jemand auf die Idee kommt für kunde2.prod.example.com ein SSL-Zertifikat zu benötigen und dieses auf 192.0.2.4 zu installieren.

Jetzt funktioniert plötzlich kunde1.prod.example.com nicht mehr – denn es gibt ja jetzt explizit prod.example.com, mit einem einzigen Eintrag: kunde2. Und kunde1 guckt in die Röhre. Also muß das Zonefile um die folgenden Einträge erweitert werden:

*.prod.example.com      IN A     192.0.2.2
kunde2.prod.example.com IN A     192.0.2.3
*.prod.example.com      IN MX 10 mail.example.com.
*.demo.example.com      IN MX 10 mail.example.com.

Details finden sich in rfc1034 Abschnitt 4.3.3.

Ich habe schon oft gehört daß Apple-Notebooks sich immer grösserer Beliebtheit bei Netzwerkadmins erfreut. Als langjähriger Apple-User kann ich das sehr gut nachvollziehen.

Allerdings kommt oft die Frage auf, welches Programm man denn benutzen kann um mit Hilfe von USB-Seriell-Adaptern auf die Console-Ports eines Routers zuzugreifen. Auf meinem ersten iBook habe ich damals tip von OpenBSD mit ein paar kleinen Änderungen kompiliert – da ich dummerweise die Änderungen nicht dokumentiert hatte konnte ich nur das Binary weitergeben.

Auf meinem ersten Intel-Mac stellte sich mir dann erneut diese Frage, und da wurde ich auf eine extrem simple Lösung gestossen. Das Programm screen lässt sich nicht nur als Ersatz für virtuelle Terminals und für die Ausführung von langen Prozessen auf entfernt stehenden Servern verwenden. Nein, es ist auch eine erstklassige Terminal-Emulation.

Der Aufruf

screen /dev/tty.usbserial-FTBA75T3

öffnet die serielle Console des angehängten Gerätes.
Optional können noch weitere Parameter folgen, am ehesten benötigt man die Angabe der Geschwindigkeit.

Auch ein Break lässt sich senden, per “^A b”. Wenn man fertig ist kann man per “^A ^\” gefolgt von “y” die Sitzung beenden.

Viele Firmen vernachlässigen ihr Corporate Design auf sträfliche Art. Andere geben sich viel Mühe, daß ihr Logo nicht nur überall gleich gut aussieht, sondern auch ja immer richtig herum erscheint. Problematisch ist sowas bei Notebooks – soll das Logo bei geschlossenem oder geöffnetem Display richtig herum sein?

Cisco hat sich für seine WLAN-Accesspoints etwas besonderes einfallen lassen: ein drehbares Logo!

Zitat aus dem Cisco 521 Wireless Express Access Point Quick Start Guide: “The logo should always be easy to read.“

Kürzlich gelesen: Da hat jemand einen Eintrag in die Crontab gemacht für ein Skript, das nur einmal in der folgenden Nacht ausgeführt werden sollte.
Zum Glück hat er am nächsten Tag daran gedacht den Eintrag wieder zu entfernen, sonst hätte das lustig enden können. Ich empfehle die Lektüre von at(1)

Bei der Suche, ob sich eine bestimmte Warnung des Apache-Webservers deaktivieren lässt bin ich über ein Konstrukt gestolpert, das ich einfach krank finde – man kann im Apache VHost Teile der Konfiguration dynamisch in Perl-Code ausdrücken.

Als Beispiel wird der Fall eines Webserver-Clusters genannt, bei dem alle Server die identische Konfigurationsdatei verwenden sollen, aber jeder mit seinem individuellen Server-Namen arbeiten soll:

<Perl>
  $ServerName = `hostname`;
</Perl>

Dummerweise berücksichtigt das Beispiel nicht, daß bei einem Webserver-Cluster auch andere Details wie die ListenAddress individuell konfiguriert werden sollte…

Weitere Infos, falls man es sich antun möchte, findet man in der Doku zu mod_perl.