Re: Seltsame NIS-Timeouts

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Thu, 12 Feb 2004 02:24:18 +0100

On Thu, Feb 12, 2004 at 12:18:03AM +0100, Patrick Hess wrote:
> Hallo,
>
> Bernd Walter schrieb:
> > Betreibe einen eigenen Nameserver.
>
> Hmm, eigentlich versuche ich ja, möglichst wenige Dienste laufen zu
> lassen. Man muß sich ja auch fortlaufend drum kümmern. Hättest du
> da vielleicht eventuell eine Software-Empfehlung? Ich muß zugeben,
> daß ich ein BIND-Buch auf der Arbeit habe und mich nach Möglichkeit
> um den BIND drücke... Ich hätte gerne was Simples, das man ohne
> viel Aufwand laufen lassen kann. Viel können müßte das Teil nicht.

Den bind aus dem OS brauchst du blos starten.
Wo du da viel Aufwand siehst kann ich nicht nachvollziehen.
Wobei ich viel lieber den bind9 benutze, da muss man noch ein
bischen Hand anlegen, wie z.B. einen Key für den rndc erzeugen.

> > Alles andere ist beim Einsatz von mehr als einem Rechner albern.
>
> Ich habe es halt so gelöst, daß ich alle internen IPs in der
> /etc/hosts des NIS-Servers habe und dann über NIS auf die Clients
> verteile. Jetzt bekomme ich bestimmt Prügel von allen Seiten :-)
>
> > Zumal du ja sowieso den NIS Server dauernd brauchst.
> > Außerdem hast du ja vermutlich Intra-IPs im Gebrauch, zu denen
> > ein externer Nameserver sowieso nichts sinnvolles berichten kann.
>
> Genau, 192.168.0.0/24 ist intern in Gebrauch. Namensauflösung ist
> auf dem Server wie folgt konfiguriert:
>
> server:~ > cat /etc/host.conf
> # $FreeBSD: src/etc/host.conf,v 1.6 1999/08/27 23:23:41 peter Exp $
> # First try the /etc/hosts file
> hosts
> # If you have YP/NIS configured, uncomment the next line
> # [Die Abfrage nach dem NIS-Server ist nur auf den Clients
> # aktiviert]
> #nis
> # Now try the nameserver next.
> bind
>
> Über seine /etc/hosts kann der Server alle internen IPs auflösen.

Im Prinzip kann man das auch per NIS machen, aber NIS hat da Nachteile,
so kommt der nicht mit mehreren Ergebnissen auf einen Namen zurecht.
Zudem musst du höllisch aufpassen, das der NIS Server nicht selber
den DNS befragt - hier könnte ein möglicher Grund liegen.
Das Problem ist nämlich, dass ein hängender Request nach draußen den
NIS Server blockiert.
Aber das funktioniert eh nicht sauber, da der NIS Server das Ergebniss
von druaßen verstümmeln muss, damit es in die NIS Antwort passt.
Ziemlich doof bei DNS Round-Robin und einem defekten Server - da
merkt dein Rechner nicht mal, dass er auch eine Alternative hätte.
Host auflösungen über NIS ist eher was für Netze ohne externen Kontakt
und selbst da kann man besser auf DNS setzen, da es mehr Möglichkeiten
hat und von mehr Clients unterstützt wird.
Wegen der verstümmelung fragt der Sendmail übrigens zuerst per DNS,
er bekommt über hosts und NIS nämlich MX Records vorenthalten, welche
er schlicht braucht.
Eine Absenderprüfung, bei der der Absender nur einen MX hat wird er
per NIS nicht als gültig erkennen können.

> Sollte der Fetchmail also, aus welchem Grund auch immer, eine
> interne IP auflösen wollen, sollte die schon aus der lokalen
> /etc/hosts ermittelt werden können.
>
> Und wenn man dort nicht fündig wird, wird der DNS-Server von
> T-Online angequatscht, der über nicht-Intranet-IPs Auskunft geben
> sollte. Warum ich bei dieser Geschichte einen NIS-Timeout bekomme
> - keine Ahnung.

Ich bin mir auch noch nicht wirklich sicher, dass das was mit DNS zu
tun hat, aber dein Dial-Up Server hat natürlich auch eine externe IP,
deren Resultat immer extern zu befragen ist, da du ja keinen Cache
dafür hast.
Nur macht es Sinn die Möglichkeiten der Reihe nach auszuschließen und
hier solltest du so oder so was ändern.

> Kann es vielleicht auch an etwas anderem als dem DNS liegen? Daß ich
> das Problem seit der Umstellung auf einen anderen DNS-Server habe,
> mag vielleicht auch Zufall sein. Denn wie gesagt, NIS wird auf dem
> Server eigentlich nicht zur Namensauflösung genutzt. Aus dem NIS
> sollte der Server nur UIDs und GIDs benötigen. Der Fetchmail prüft
> ja nun die Zugriffsrechte auf die ~/.fetchmailrc und andere Sachen,
> da werden UIDs und GIDs gebraucht, weil die Benutzer nur im NIS
> vorhanden sind. Vielleicht ist das ein Ansatzpunkt?

Nun das ist ein Grund fürs Auslösen, da der NIS oft gefragt wird.
Mal abgesehen davon, dass ich fetchmail nicht mag, aber das wird kaum
der Grund sein.

> Aber ich weiß halt einfach nicht, was der Fetchmail ab und zu anders
> macht als alle anderen Programme und dadurch einen NIS-Timeout
> hervorruft. Und an welcher Stelle genau es eigentlich klemmt. Kann
> jemand aus diesen Beschreibungen eine Vermutung aufstellen?

Ohne genauer den Traffic zu überwachen kann man nur Spekulieren.
Ich würde erst mal ein bischen rumprobieren und die aufwendige Methode
für den Moment aufbewaren wenn alles andere Versagt hat.
Die Namensauflösung per NIS scheint mir ein guter Ansatzpunkt zu sein,
nicht zuletzt, da der Fetchmail beim spoolen der Mails sicherlich
etliches von druaßen wissen will.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 12 Feb 2004 - 02:30:48 CET

search this site