HalbOT: client132 != client132.dns-domain bei tcpd.

[Pierre Bernhardt]

Moin,

ich habe ein kleines aber feines Problem.

Per hosts.allow und hosts.deny soll über den tcpd ein Zugriff
per ftp erfolgen.

In der hosts.deny wird mit ALL allen erst mal der Zugriff verboten.

In der hosts.allow wird dann selektive einzelnen IP-Adressen der
Zugriff gewährt.

z.B. 10.0.1.132

Soweit so gut.

Der Rechner ist in eine NIS-Domäne, die zugreifenden Clients in
einer anderen Domäne.

In der nsswitch.conf steht für hosts die Reihenfolge:

files nis dns

Der Rechner selber ist durch NIS erreichbar unter dem einfachen
hostnamen, aber über dns auch über den dns-hostnamen erreichbar:

Auf diesem Rechner selber funktioniert:

ping hostname
ping hostname.dns-domain

Von einem beliebigen Client funktioniert das ebenfalls.

Leider funktioniert es im tcpd so aber nicht:

warning hostname/hostname mismatch client132 != client132.dns-domain

Ein getent hosts client132 auf dem Server liefert:

getent hosts client132
	10.0.1.132	client132.dns-domain

das gleiche gilt für getent hosts 10.0.1.132.

Wenn ich nun den Rechner einfach in die hosts eintrage:

	10.0.1.132	client132

liefert getent nun

	10.0.1.132	client132

und der Client bekommt den Zugriff über den tcpd.

Ich will aber nun nicht jeden Rechner auch noch zusätzlich in die
hosts aufnehmen.

Laut der manpage von tcpd wird unter der Sektion HOST NAME VERIFICATION
geprüft, ob hostname -> ip-adresse = ip-adresse -> hostname ist.

Man muss das beim kompilieren wohl extra einschalten (mit -DPARANOID),
ein neukompilieren kommt hier allerdings leider nicht in Frage.

Allerdings scheint tcpd trotzdem Unterschiede zurück zu bekommen, da
ja die Fehlermeldung des tcpd lautet:

client132 != client132.dns-domain

Vielleicht suche ich hier an der falschen Stelle und der tcpd sucht
doch was anderes.

Habt Ihr eine Idee, wo der tcpd den client132 ohne dns-domain her
bekommen könnte, wenn er nicht in der hosts eingetragen ist?

MfG...
Pierre Bernhardt