Archive for Januar, 2009

Stolperfallen bei DNS-Wildcard-Einträgen

Donnerstag, Januar 22nd, 2009

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.

Cronjobs richtig schreiben

Montag, Januar 19th, 2009

In meinem Job als Systemadministrator bei einem ISP werde ich von unseren Kunden oft mit dem Wunsch nach einem Cronjob konfrontiert, dabei kann man sich viele Eigenschaften des Cron-Daemons zunutze machen und somit Arbeit sparen, ausserdem erhöhte Sicherheit erreichen.

Folgende Punkte sollte man beachten:

  1. in der crontab MAILTO setzen
  2. Ausgabe in den Scripten nur bei Fehlern, und nach STDERR
  3. nicht wget oder curl verwenden, sondern direkt z.B. php-cli
  4. keine Webserver-Variablen (in PHP z.B. $_SERVER) verwenden, sondern z.B. $HOME

Damit erreicht man einiges und spart sich Arbeit. Zu allererst muss man nicht selber eine E-Mail generieren, sondern kann es dem Cron-Daemon überlassen. Ausserdem wird, wenn man 2. beachtet, nur dann eine E-Mail erzeugt, wenn ein Fehler auftritt. Dadurch wird eine Gewöhnung vermieden (vorausgesetzt man behebt die Fehler die gemeldet werden konsequent) und sichergestellt, daß Fehler nicht im Grundrauschen untergehen.

Durch Berücksichtigung von 3. kann man die Skripte ausserhalb des per Webserver aufrufbaren document_root ablegen, und verhindert damit daß User der Webseite Cronjobs zu ihren Gunsten aufrufen. Ein Beispiel wäre eine Community, bei der jeder User am Tag eine Punktzahl bekommt. Ausserdem senkt es die Anzahl der für einen Cronjob gestarteten Prozesse immens. Bei Verwendung von z.B. curl sind es bis zu vier: cron startet eine Shell, diese startet Curl, der Request beschäftigt einen Webserverprozeß und eventuell einen PHP-Prozeß. Ohne diesen Umweg kann man es durch Setzen der Shell-Variablen auf einen reduzieren: PHP.

Allerdings muss man seinen Quellcode dann unabhängig von Variablen, die nur vom Webserver gesetzt werden, schreiben, wie z.B. das oben genannte $_SERVER.

serielle Console auf Mac OS X

Donnerstag, Januar 15th, 2009

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.

Corporate Design bei Cisco

Montag, Januar 12th, 2009

prod_small_photo0900aecd8060c68a.jpgViele 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.“

Useless use of Cron

Freitag, Januar 9th, 2009

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)

Kranke Sache: Perl-Code in Apache VHosts

Mittwoch, Januar 7th, 2009

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.