Re: Seltsame NIS-Timeouts

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.

> 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.
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.

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?

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?

Gruß,
Patrick

-- 
Scanner unter FreeBSD:   
http://phess.de.vu/FreeBSD-Scanner/FreeBSD-Scanner.html
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message