Ich habe ein Problem mit einem Slackware-System das wahrscheinlich am Mangel an Hintergrundwissen liegt:
Wenn ich dhcp mit "dhcpcd -h unit3 eth0" starte, wird eine Domain ".lan" angehängt, so dass "ping unit3" nichts findet und nur "ping unit3.lan" funktioniert. Auch mit der Option "--fqdn none" lässt sich die Erzeugung dieses qualifizierten Domain Namens nicht abschalten und es ist auch nicht möglich, eine andere Domain anzugeben, z.B. "dhcpcd -h unit3.ed.home eth0" ergibt ebenfalls "unit3.lan". Die Domain ".lan" ist auf dem System nirgendwo hinterlegt und kommt daher vermutlich vom dhcp-Server (DSL-Router im Keller).
Mein Problem ist jetzt, dass ich nicht genau weiß, wo dieses ".lan" herkommt und vor allem, wie ich das ermitteln oder festlegen kann. Idee war eigentlich, dass meine Software auf "unit3" verbindet und das unter DHCP immer klappt. Jetzt habe ich aber keinen bekannten Namen mehr, sondern der wird (aus meiner Sicht) willkürlich geändert, war mir wie ein Bug vorkommt.
Die offensichtliche Frage ist also, was hat es damit auf sich und wie finde ich den richtigen Namen heraus?
Wenn man DHCP übrigens über die Datei /etc/rc.d/rc.inet1.conf mit DHCP_HOSTNAME[0]="unit3" startet, kann dhcp plötzlich doch einen unqualifizierten Namen ohne ".lan" erzeugen und genau diese Inkonsistenz hat mich gerade kalt erwischt. ;o(
Das ist noch die Default, ohne die einleitenden Bemerkungen:
# For loopbacking.
127.0.0.1 localhost
# This next entry is technically wrong, but good enough to get TCP/IP apps
# to quit complaining that they can't verify the hostname on a loopback-only
# Linux box.
127.0.0.1 darkstar.example.net darkstar
> /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search lan
nameserver 10.0.0.1
nameserver 10.0.0.1
nameserver 213.33.99.70
>> # Generated by dhcpcd for interface eth0
>> search lan
>> nameserver 10.0.0.1
>> nameserver 10.0.0.1
>> nameserver 213.33.99.70
> Ich gehe davon aus daß 10.0.0.1 die IP-Adresse des DSL-Routers ist?
Stimmt.
> Der Eintrag "search lan" sollte eigentlich dafür sorgen daß ein "nslookup
> unit3" bzw. "ping unit3" funktioniert. (es wird dann auch "unit3.lan"
> ausprobiert)
Das ist aber der Eintrag vom unit3, das muss sich eigentlich nicht selber finden. ;o)
Damit sind wir wieder am Anfang - der Steuerrechner, der auf unit3 verbinden soll, weiß nichts von "lan" und ich weiß nicht, wie der das herausfinden kann, bzw. wie unit3 den eigenen Namen setzt, ohne dass der ergänzt wird. Ich habe das noch einmal mit nmap getestet und dabei ist mir aufgefallen, dass sich der DSL-Router "dsldevice.lan" nennt. Das bestätigt meinen Verdacht, dass da das "lan" her kommt. Mein Rechner (Fedora) bekommt das aber nicht mit, so dass ein lookup nicht funktioniert.
Ich verstehe also nicht, warum sich Slackware je nach Art des dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch das abzufragen.
Ich brauche also eine Befehlszeile, die unter Slackware den dhcpcd mit einem unqualifizierten Namen aufruft (also nur "unit3" setzt), oder einen Befehl, der mir unter Fedora die Benennung des lokalen Netzwerks ermittelt, also das "lan" liefert. Ich weiß, dass ersteres über die Systemkonfiguration geht und denke, das sollte dann auch irgendwie über Befehlszeile gehen. Bei der alternativen Abfrage stehe ich völlig auf dem Schlauch.
Der dhcpcd muss dem dhcp-Server (Router) doch irgendwie sagen, ob er einen unqualifizierten Namen möchte, oder ob der Name ergänzt werden soll, das muss doch irgendwie geregelt sein?
>> Ich verstehe also nicht, warum sich Slackware je nach Art des
>> dhcp-Aufrufes mal "unit3", mal "unit3.lan" nennt und warum mein
>> Fedora-Rechner von ".lan" gar nichts weiß. Und das schießt mir gerade in
>> den Fuß, weil ich weder eine Möglichkeit finde, das festzulegen, noch
>> das abzufragen.
> Der Steuerrechner (Fedora) kann von der Domain "lan" nichts wissen.
Der freundliche Kunde, der gerade sein unit3 angestöpselt hat, weiß das auch nicht unbedingt.
> Trage auf dem Steuerrechner in der Datei /etc/resolv.conf die Domain "lan"
> in die search Liste ein.
Da der Kunde darauf aber vielleicht keinen Zugriff hat, könnte er es auch ins Steuerprogramm eintragen - falls er es weiß. Besser wäre natürlich, wenn das Steuerprogramm die Domain selbst ermittelt. Dann muß der Kunde nämlich nichts außer der Seriennummer wissen und die steht drauf. So weit war ich schon mal.
> Dein DSL-Router verwendet "lan" als Domain. Das kann man möglicherweise
> ändern, aber irgend eine Domain mußt Du verwenden.
Nein, muß ich nicht. Das mit den unqualifizierten Namen funktioniert einwandfrei. unit3 verwendet auch den unqualifizierten Namen, wenn man den direkt in die Systemkonfiguration einträgt und damit laufen schon ein paar units. Das hatte aber den Nachteil, dass für jede Änderung das gesamte System gebootet werden musste, deshalb habe ich die ganze Netzwerkeinrichtung auf dynamisch mit Befehlszeile(n) geändert. Das klappt sonst auch einwandfrei (öffnet auch zusätzliche statische Adressen), nur ist jetzt plötzlich dieses Domainproblem aufgetaucht. Das möchte ich gerne ausbügeln, um diese Arbeit zu retten.
> Dafür ist der Host aber selbst zuständig, denn im DNS wirst du kaum die
> Toplevel-Domain unit3 mit A-Record stehen haben.
Für unqualifizierte Namen im lokalen Netzwerk ist das auch nicht nötig.
> Dein Freund ist die /etc/hosts, dort eintragen den Host "unit3" auf die
> externe oder interne IP, fertig.
Das ist qualifizierte Netzwerkeinrichtung mit Admin-Rechten, die ich mir sparen will.
> Aber wenn ich ehrlich bin, hab ich dein Problem echt noch nicht
> verstanden, wer wen unter welchen Namen oder auch nicht erreichen können
> soll und welche Variablen du beeinflussen kannst in dem Szenario oder
> nicht.
Das habe ich dem Frank auch gerade noch mal erklärt. Noch mal ganz kurz:
Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen "unit3" wissen und kann damit von jedem anderen Rechner des Netzwerks eine Verbindung aufbauen. Das funktionierte, bis ich die Netzwerkeinrichtung des unit3 auf Konfiguration mit Befehlszeile umgestellt habe (was ich aber gerne beibehalten würde). Jetzt nennt sich unit3 plötzlich unit3.lan (siehe "fqdn") und ist damit nicht mehr sicher in beliebigen Netzwerken erreichbar.
Die Frage ist also, wie ich dem dhcpcd bei Aufruf mit Befehlszeile dazu bewege, den unqualifizierten Namen zu verwenden (--fqdn none ist es nicht), oder wie das Steuerprogramm die DHCP-Domain des aktuellen Netzwerks ermitteln kann.
Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
>> Damit sind wir wieder am Anfang - der Steuerrechner, der auf unit3
>> verbinden soll, weiß nichts von "lan"
> Der Steuerrechner (Fedora) kann von der Domain "lan" nichts wissen.
Ähem - das war gestern!
> Trage auf dem Steuerrechner in der Datei /etc/resolv.conf die Domain "lan"
> in die search Liste ein.
> also z. B.:
> "search lan"
Das sollte der dhcpcd ja selber machen und heute steht nicht nur "search lan" in der resolv.conf, sondern sogar "domain lan"! Dem entsprechend geht der Zugriff auf das unit3 jetzt wieder ohne FQDN. Das Problem war also mein Entwicklungsrechner, vermutlich musste nach der Umschaltung des Netzwerks auf DHCP doch besser mal gebootet werden. :o/
> Dein DSL-Router verwendet "lan" als Domain. Das kann man möglicherweise
> ändern, aber irgend eine Domain mußt Du verwenden.
Das habe ich dann wohl auch immer getan und wußte das bloß nicht, weil das lookup funktionierte, ohne mir Bescheid zu sagen. ;o)
>> Ich brauche also
>> einen Befehl, der mir unter Fedora die Benennung des lokalen Netzwerks
>> ermittelt, also das "lan" liefert.
"more /etc/resolv.conf" bzw. unter Windows "ipconfig -All" (die Software läuft auch unter Windows).
Na ja, jetzt weiß ich nicht nur, warum es funktioniert, sondern kann sogar einen FQDN in die Software eingeben - mir war ebenfalls nicht bewusst, dass ich mit meiner DHCP-Einrichtung gar nicht aus dem lokalen Netz herauskomme.
Edzard Egberts wrote:
> Die Beantwortung einer dieser beiden Fragen würde mein Problem lösen.
Glaube ich nicht. Das Problem dürfte eher die Anzahl der dhcp-Server in deinem Netz sein, und deren Verfügbarkeit abbängig vom Startzeitpunkt des zweiten.
>> Ich verbinde ein unit3 mit einem *beliebigen* DHCP-Netzwerk (das
>> wahrscheinlich nicht ".lan" ist!). Jetzt muss ich nur den Namen
>> "unit3" wissen und kann damit von jedem anderen Rechner des Netzwerks
>> eine Verbindung aufbauen. Das funktionierte, bis ich die
>> Netzwerkeinrichtung des unit3 auf Konfiguration mit Befehlszeile
>> umgestellt habe (was ich aber gerne beibehalten w rde). Jetzt nennt
>> sich unit3 pl tzlich unit3.lan (siehe "fqdn") und ist damit nicht mehr
>> sicher in beliebigen Netzwerken erreichbar.
> Aber wer macht denn das DNS dazu, damit unit3 berhaupt bekannt ist?
Na ja, mit "allgmeine Frage" lag ich schon richtig, ich hatte blo keine Ahnung. So wie ich das jetzt verstanden habe, braucht eine DHCP-Adresse immer eine Top-Level-Domain und f r den lokalen DSL-Router ist das eben ".lan". Man kann aber auch den unqualifizierten Namen benutzen, weil der dhcpcd beim Start in die /etc/resolv.conf das entsprechende search-lookup einstellt (und das ging schief).
Das wusste ich nicht und dachte, dass der unqualifizierte Name im Normalfall schon reicht. Mir w re das wohl auch nie aufgefallen, aber beim Umstellen der Netzwerkeinstellungen wurde die resolv.conf wohl nicht aktualisiert, so dass die unqualifizierten Namen pl tzlich nicht mehr funktionierten.
> Edzard Egberts wrote:
>> Na ja, mit "allgmeine Frage" lag ich schon richtig, ich hatte blo
>> keine Ahnung. So wie ich das jetzt verstanden habe, braucht eine
>> DHCP-Adresse immer eine Top-Level-Domain und f r den lokalen
>> DSL-Router ist das eben ".lan". Man kann aber auch den
>> unqualifizierten Namen benutzen, weil der dhcpcd beim Start in die
>> /etc/resolv.conf das entsprechende search-lookup einstellt (und das
>> ging schief). Das wusste ich nicht und dachte, dass der
>> unqualifizierte Name im Normalfall schon reicht. Mir w re das wohl
>> auch nie aufgefallen, aber beim Umstellen der Netzwerkeinstellungen
>> wurde die resolv.conf wohl nicht aktualisiert, so dass die
>> unqualifizierten Namen pl tzlich nicht mehr funktionierten.
> Also man kann mit DHCP auch DNS aktualisieren, aber das muss nicht so
> sein - daher habe ich dich ja gefragt, warum der DNS-Server jetzt auf
> einmal den Namen "unit3" kennt.
> Ok, also super, dass du dein Problem l sen konntest. :-)
Das hatte sich am n chsten Tag beim Einschalten des Rechners von selber gel st - neu booten hilft manchmal auch bei Linux. :o/
Beim Blick in die resolv.conf (meines Steuerrechners) wurde mir dann auch klar, warum es funktioniert. Das Hauptproblem war, dass es zwar funktionierte, ich bis dahin aber nicht wu te, warum. ;o)
