BIND (named) unter Tiger

[maceis]

Hallo zusammen,

Das Starten von Daemons funktioniert unter Tiger ja deutlich anders als vorher.
Der BIND (named) wird unter Tiger vom launchd gestartet.

Nun habe ich beobachtet, dass der Server nur unter der 127.0.0.1 erreichbar ist, wenn ich nicht mit "rndc reload" die Konfiguration neu lade.
Das ist natürlich unerwünscht.

Leider konnte ich bisher nicht herausfinden, woran das liegt bzw. wie ich dafür sorgen kann, dass der named auf allen IP-Adressen lauscht.
An der Konfiguration scheint es nicht zu liegen.

Würde mich freuen, wenn jemand zur Klärung beitragen könnte.

 

[oneOeight]

schon mal die /System/Library/LaunchDaemons/org.isc.named.plist angeguckt?

ansonsten kannst du mal probieren rndc-confgen laufen zu lassen...
/etc/rndc.key und /etc/rndc.conf sind halt nicht vorhanden bei der standard installation.

 

[maceis]

schon mal die /System/Library/LaunchDaemons/org.isc.named.plist angeguckt?

Du meinst sicher "/System/Library/LaunchAgents/org.isc.named.plist";
Ja klar hab ich da reingeschaut.
Da vermute ich aber nicht das Problem.
Wenn ich named nicht beim Booten sondern mit dem selben Kommando wie launchd (named -f) von Hand starte, nachdem das System hochgefahren ist, werden Anfragen sofort auf allen Interfaces beantwortet.
Dasselbe Ergebnis erhalte ich, wenn ich named mit Hilfe von launchctl nach dem Hochfahren starte.
Andererseits wir named beim Booten ja auch gestartet (wenn die Einstellung in org.isc.named.plist das nicht verhindert); er lauscht nur nicht gleich auf allen Adressen.

ansonsten kannst du mal probieren rndc-confgen laufen zu lassen...
/etc/rndc.key und /etc/rndc.conf sind halt nicht vorhanden bei der standard installation.

rndc funktioniert ja; da hab ich (zum Glück) keine Probleme. Ich arbeite mit rndc.key.

 

[maceis]

(Mist, falsch geklickt - ich sollte schlafen gehen )

 

[cilly]

Hey Maceis, ich habe genau gleiches Problem festgestellt. Clean-Install! Das tritt nur direkt nach dem Reboot auf. Es sieht fast so aus, dass named schon gestartet wird, wenn das en0 noch nicht bereit ist? Wenn das Interface dann nach einer Stunde wieder gecheckt wird...

Werde ich gleich mal ausprobieren:

// how often should bind check for new
// interfaces to listen on. we turn
// this off by setting it to 0
interface-interval 1;

Der default ist 60, also 1 Stunde. Mal sehen was passiert, wenn ich das auf eine Minute stelle.

Was nichts gebracht hat: listen-on auf en0 setzen, oder ausschalten.

Ich vermute es ist ein Bug in launchd, der named wird zu früh gestartet.

 

[cilly]

Okay, jetzt hab ich den Beweis:

den Wert auf 2 Minuten gesetzt und nach genau 2 Minuten war der Bind da und hat geantwortet.

Das ist definitiv ein Bug, der BIND wird zu früh gestartet und erkennt das Interface en0 daher nicht. Erst beim automatischen Check wird das en0 erkannt und als listener hinzugefügt.

 

[maceis]

...
den Wert auf 2 Minuten gesetzt und nach genau 2 Minuten war der Bind da und hat geantwortet.

Das ist definitiv ein Bug,der BIND wird zu früh gestartet und erkennt das Interface en0 daher nicht.
...

Das hatte ich auch als erstes vermutet; beim Blick in"top" meinte ich aber unterhalb von named noch andere Prozesse zu entdecken, die en0 benutzen und hatte diesen Gedanken wieder verworfen.

Vielen Dank für Deinen Hinweis, den ich nächste Woche mal verfolgen werde.
Zur Zeit bin ich "auf Reisen".

Wenn Du Recht hast, wäre das nicht so gut, denn eigentlich sollte launchd dafür sorgen, dass die Prozesse in der "richtigen" Reihenfolge gestartet werden. AFAIK kann man da auch nichts beeinflussen (so wie bei den StartupItems).

 

[cilly]

Das hatte ich auch als erstes vermutet; beim Blick in"top" meinte ich aber unterhalb von named noch andere Prozesse zu entdecken, die en0 benutzen und hatte diesen Gedanken wieder verworfen.

Da müsste man genau verifizieren, wann was wie gestartet wurde. BIND logging-Verhalten auf verbose stellen...
Jedenfalls ist Fakt: Bind horcht nicht auf en0. Mein Vermutung: er erkennt das en0 nicht, weil er zu früh gestartet wird. Das schließt nicht aus, dass andere Prozesse auf en0 laufen.

AFAIK kann man da auch nichts beeinflussen (so wie bei den StartupItems).

Bei den StartupItems konnte man wohl dependencies festlegen:

cat /System/Library/StartupItems/BIND/StartupParameters.plist

{
  Description	 = "DNS server";
  Provides		= ("BIND");
  Requires		= ("Network");
  Uses			= ("Network");
  OrderPreference = "None";
}

 

[maceis]

...
Bei den StartupItems konnte man wohl dependencies festlegen:
...

So ist es.
Für launchd muss ich mir wohl selbst was basteln.
Das minütliche checken nach neuen Interfaces scheint mir denn doch zu albern.
Ich werde ein Skript schreiben (zumindest als vorläufigen workarround), das eine Minute "schläft" und dann und dann org.isc.named.plist einmal entlädt und sofort wieder neu lädt.
Zur Zeit bin ich auf Reisen und kann es erst nächte Woche testen.
Ich halt Euch auf dem Laufenden, ob es funktioniert.

 

[cilly]

Ich habe Bind veranlasst, alle 5min zu checken, folgenden Inhalt in /etc/namec.conf einfügen:

// how often should bind check for new
// interfaces to listen on. we turn
// this off by setting it to 0
interface-interval 5;

So dauert es nach einem Neustart zwar 5 Minuten, bis der Bind da ist, doch so oft wird der Server mit BIND ja auch nicht heruntergefahren.

 

[maceis]

Ich habe jetzt folgende Lösung erfolgreich getestet:
Es gibt ein Skript rndc_reload.sh:

#!/bin/sh

sleep 10     # hier würde ein sleep 2 vermutlich schon genügen
rndc -p54 reload

Dieses wird von launchd beim Hochfahren einmalig gestartet:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>domain.my.rndc_reload</string>
        <key>OnDemand</key>
        <true/>
        <key>ProgramArguments</key>
        <array>
                <string>/Library/LaunchDaemons/rndc_reload.sh</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
</dict>
</plist>

Ich finde diese Lösung etwas eleganter, da BIND damit (fast) sofort voll verfügbar ist und das überflüssige regelmäßige Suchen nach neuen Interfaces entfällt.
Schön finde ich sie trotzdem nicht - ich vermute mal, dass Apple da noch nachbessern muss/wird

Werde mal im Apple Disscussion Board nachfragen, ob das Problem bekannt ist und wie das anderenseits gelöst wird.