Hallo, Leute!
Ich habe einen Server mit Ubuntu Lucid 10.04 installiert. Dort ist auch Samba (2:3.4.7~dfsg-1ubuntu3.10) installiert.
Nun, der Server hatte bis letzte Woche die IP 192.168.1.13 (und ein Hostname, skynet.firma.intra, den ich immer benutzt habe). Dienstag mussten wir einige Wartungsarbeiten durchführen, und das Netz 192.168.1.0/24 wurde abgeschafft. Jetzt hat der Server die IP 192.168.0.1. Der Hostname wurde natürlich angepasst, so daß skynet.firma.intra der richtigen IP zeigt.
Die IP 192.168.1.13 ist NICHT MEHR im Betrieb. Ein PING auf die IP zeigt auch, daß sie nirgendwo benutzt wird.
ABER: wenn ich mit smbclient die IP anspreche, kriege ich eine Antwort, und zwar die selbe Antwort, wie wenn ich skynet.firma.intra kriege. Ich rufe smbclient -L //192.168.1.13 und kriege das selbe Ergebnis von smbclient -L //skynet obwohl 192.168.1.13 nicht mehr benutzt wird...
Warum denn? Hat jemand eine Erklärung?
Besten Dank Luca Bertoncello (lucabert@lucabert.de)
Moin Luca,
On Thu, Nov 15, 2012 at 09:08:44AM +0100, Luca Bertoncello wrote:
Die IP 192.168.1.13 ist NICHT MEHR im Betrieb. Ein PING auf die IP zeigt auch, daß sie nirgendwo benutzt wird.
ABER: wenn ich mit smbclient die IP anspreche, kriege ich eine Antwort, und zwar die selbe Antwort, wie wenn ich skynet.firma.intra kriege. Ich rufe smbclient -L //192.168.1.13 und kriege das selbe Ergebnis von smbclient -L //skynet obwohl 192.168.1.13 nicht mehr benutzt wird...
Warum denn? Hat jemand eine Erklärung?
Kann es sein dass der Samba-Client versucht zu dem Namen "192.168.1.13" eine IP aufzulösen, und zufälligerweise etwas darauf mit der neuen IP antwortet. Ich würde wohl jetzt mit strace und wireshark nachsehen, was da wirklich passiert.
Ein evtl einfacher Fix wäre IMHO, den Samba-Server durchzustarten.
Passiert das eigentlich nur, wenn du smbclient lokal auf dem Server ausführst oder auch woanders im Netz?
Gruß, Andre
Andre Klärner kandre@ak-online.be schrieb:
Kann es sein dass der Samba-Client versucht zu dem Namen "192.168.1.13" eine IP aufzulösen, und zufälligerweise etwas darauf mit der neuen IP antwortet. Ich würde wohl jetzt mit strace und wireshark nachsehen, was da wirklich passiert.
Nein, es gibt im Netz keinen Rechner mit IPs in dem Netz 192.168.1.0/24.
Ein evtl einfacher Fix wäre IMHO, den Samba-Server durchzustarten.
Schon gemacht, nicht geholfen.
Passiert das eigentlich nur, wenn du smbclient lokal auf dem Server ausführst oder auch woanders im Netz?
Eigentlich habe ich bisher noch nicht vom dem Server selbst smbclient benutzt. Bisher habe ich nur von den verschiedenen PCs im Netz...
Danke Luca Bertoncello (lucabert@lucabert.de)
Hej Luca!
Jetzt hat der Server die IP 192.168.0.1. Der Hostname wurde natürlich angepasst,
ABER: wenn ich mit smbclient die IP anspreche, kriege ich eine Antwort, und zwar die selbe Antwort, wie wenn ich skynet.firma.intra kriege. Ich rufe smbclient -L //192.168.1.13 und kriege das selbe Ergebnis von smbclient -L //skynet obwohl 192.168.1.13 nicht mehr benutzt wird...
Hab schon seit einem Jahrzehnt keinen Samba mehr angefasst, meine Erinnerungen mögen mich täuschen, aber ich entsinne mich dunkel, dass der Server unter Umständen als zentrale Auskunftei agiert und ziemlich viel im Cache behält.
Trenn mal den Client (künstlich) vom neuen Server und ruf auf'm Client smbclient -L alter_server auf. Versucht er jetzt eine (nunmehr fehlschlagende) Anfrage an den neuen Server, um von diesem als zentralem Auskunftsdienst was über alter_server zu erfahren?
(Der Server hat einfach bemerkt, dass (a) du ihn umbenannt hast, antwortet daher selbst für alter_server oder (b) ihn andere für alter_server halten und er selbst denkt, dass das seine Richtigkeit hat oder (c) er hat mal routinemäßig rumgefragt, wen die Clients so alles kennen und von einem Client den alten Eintrag erhalten.)
Beste Grüße Fabian
On Thursday 15 November 2012, Luca Bertoncello wrote:
ABER: wenn ich mit smbclient die IP anspreche, kriege ich eine Antwort, und zwar die selbe Antwort, wie wenn ich skynet.firma.intra kriege. Ich rufe smbclient -L //192.168.1.13 und kriege das selbe Ergebnis von smbclient -L //skynet obwohl 192.168.1.13 nicht mehr benutzt wird...
Warum denn? Hat jemand eine Erklärung?
Ich hatte schon mit einigen Programmen massive Probleme, die etwas voreilig oder langsam bei der Auflösung von IP-Adressen waren.
langsam: es sind noch Sachen in einem Cache, die längst veraltet sind - da smbclient jedesmal neu gestartet wird sollten interne Caches kein Problem sein - bleiben eventuelle WINS-Server, DNS-Caches (nscd), oder Samba selbst (smbd, nmbd)
voreilig: besonders .NET-Programme (wegen eines Designfehlers in .NET) fragen nicht nur nach der IP zu einem Hostnamen, sondern versucht dann alle passenden Namen und deren IPs zu erfahren, bis sie nur noch identische Antworten erhalten -- das ist ein Problem falls Namen- und IP-Updates nicht synchron passieren, z.B. bei DHCP-Setup-Fehlern; Beispiel:
meinhost hatte gestern 10.0.0.1, also: meinhost IN A 10.0.0.1 10.0.0.1 IN PTR meinhost
heute hat er 10.0.0.2, aber DHCP ist faul: meinhost IN A 10.0.0.2 10.0.0.2 IN PTR meinhost aber wir haben noch: 10.0.0.1 IN PTR meinhost
oder schlimmer: meinhost IN A 10.0.0.2 10.0.0.2 IN PTR alterhost 10.0.0.1 IN PTR meinhost alterhost IN A 10.0.0.2
Fragt jetzt jemand nach dem "Hostnamen" "10.0.0.2" und übertreibt dann kommt folgendes raus: "10.0.0.2" ist eine IP 10.0.0.2 dazu gehören die Namen "meinhost" und "alterhost" und die zusätzlichen IPs 10.0.0.1 und 10.0.0.2 (Dopplung wird später eliminiert)
Kurzfassung:
0) was sagen ping und dig zum Thema?
1) checke ob irgendwelche WINS Server oder DNS Caches rumdümpeln, die noch kein Update haben - starte sie neu
2) starte alle lokalen Caches neu (nscd)
3) checke dass im DNS nicht noch irgendwelche veralteten Reverse- oder Forward-Auflösungen sind
Konrad
Konrad Rosenbaum konrad@silmor.de schrieb:
- was sagen ping und dig zum Thema?
Dass 192.168.1.13 nicht mehr antwortet
- checke ob irgendwelche WINS Server oder DNS Caches rumdümpeln, die noch
kein Update haben - starte sie neu
Naja, der Server wurde nach der Änderung des Netzes neu gestartet. Und alle PCs werden jeden Abend ausgeschaltet. Es sollte also keinen WINS-Server oder DNS-Cache da sein.
- starte alle lokalen Caches neu (nscd)
Gemacht, zusammen mit dem Server
- checke dass im DNS nicht noch irgendwelche veralteten Reverse- oder
Forward-Auflösungen sind
Alle Zone wurden geändert und Bind ist zusammen mit dem Server auch neugestartet worden...
Grüße Luca Bertoncello (lucabert@lucabert.de)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Luca,
Schuß ins blaue: Hast Du vielleicht irgendwo in /etc/ die alte IP noch hart verdrahtet?
Was bringt denn ein: grep '192.168.1.13' /etc/* -rn
ansonsten hilft dann wirklich nur noch tcpdump, um zu schauen aus welcher Ecke das kommt.
On 15.11.2012 22:37, Luca Bertoncello wrote:
Konrad Rosenbaum konrad@silmor.de schrieb:
- was sagen ping und dig zum Thema?
Dass 192.168.1.13 nicht mehr antwortet
- checke ob irgendwelche WINS Server oder DNS Caches rumdümpeln,
die noch kein Update haben - starte sie neu
Naja, der Server wurde nach der Änderung des Netzes neu gestartet. Und alle PCs werden jeden Abend ausgeschaltet. Es sollte also keinen WINS-Server oder DNS-Cache da sein.
- starte alle lokalen Caches neu (nscd)
Gemacht, zusammen mit dem Server
- checke dass im DNS nicht noch irgendwelche veralteten Reverse-
oder Forward-Auflösungen sind
Alle Zone wurden geändert und Bind ist zusammen mit dem Server auch neugestartet worden...
- -- Mit freundlichen Grüßen / With kind regards
Jan Leonhardt
IT-Dienstleistungen IT-Konsultant Administration Softwareentwicklung
Hi Luca,
Luca Bertoncello lucabert@lucabert.de wrote:
ABER: wenn ich mit smbclient die IP anspreche, kriege ich eine Antwort, und zwar die selbe Antwort, wie wenn ich skynet.firma.intra kriege. Ich rufe smbclient -L //192.168.1.13 und kriege das selbe Ergebnis von smbclient -L //skynet obwohl 192.168.1.13 nicht mehr benutzt wird...
Warum denn? Hat jemand eine Erklärung?
Ich würde ebenfalls tcpdump zur Diagnose verwenden, sonst ist das eher ein fischen im Trüben.
Zusätzlich kannst du auch mal "net cache flush" auf deinem samba versuchen.
Anschließend könntest du mit "findsmb" (baut aber auch auf smbclient auf) schauen, unter welcher IP skynet angezeigt wird.
Viele Grüße, Martin
lug-dd@mailman.schlittermann.de