Re: mal wieder ein Debian-netz-problem
moin, gerhard,
also - entschuldigt meine "begrenzte" fehlersuche ;-)
Da muß ich jetzt schon mal was zu sagen:
Deine Fehlersuche wae ja scheinbar *nicht* begrenzt, aber deine
Beschreibung *was* du bisher unternommen hattest - außer gepingt.
mmh - ich habe in meiner ersten mail geschrieben:
"- so, folgendes habe ich gemacht:
- die firewall deaktiviert; sie liess aber gestern abend die pings
respektive die namensauflösung noch normal durch
- die routen überprüft
- die NIC gewechselt
- den server wieder in das alte netz gehängt
- andere nameserver eingetragen (die auf anderen debian-servern im
selben netz problemlos funktionieren)
... es bewirkt alles keine veränderung.
- jetzt möchte ich gerne an dem mailsystem weiterarbeiten; das ist
aber wegen der dns-problematik schnarchend langsam.
ich habe ein apt-get update / upgrade durchgeführt => keine änderung.
zwar ging das recht zügig, aber danach hing die verbindung zu
security.debian.org erneut - on anderen servern aus geht sie normal
zügig."
- wenn meine clients / kunden mir eine dermassen umfangreiche
beschreibung an first-level-massnahmen (oder wie so was heisst) liefern
würden, wäre ich glücklich ;-)
ich verwalte unsere serverlandschaft ja schon etwas länger
selbst mit 2 jahren debian-erfahrung
...
was ja keiner von uns wissen konnte (Thema: Erfahrungsstand desjenigen
der ein Problem beschreibt).
was ja auch nichts heisst - seit fünf jahren arbeite ich mit linux,
seit 2 jahren mit debian, das ganze beruflich und oft genug noch
privat, und ich würde mich niemals als profi auf dem gebiet bezeichnen,
ganz im geneteil - ich lerne gerne noch dazu.
ich war unlängst auf einem mailserver-seminar. das mailserver-wissen
des dozenten war meinem haushoch überlegen, trotzdem kannte er z.b.
"lsof" nicht (und war umso erfreuter, als ich ihn damit bekannt machte
;-))
Sei froh, daß niemand sagte: such dir
jemand, der sich damit auskennt ;-)
das hätte mich nicht gestört - erstens siehe ebiges statement, zweitens
muss frotzelei erlaubt sein, und drittens hätte ich _zu gerne_ die
fehlersuche des- / derjenigen mitverfolgt ;-)
Ein Neustart ist genausogut wie 10 Neustarts.
definitiv nicht - jetzt jedenfalls wieder aus der windows-welt
gesprochen.
Und daß mit libs,
Prozessen und upgrades halte ich für ein Gerücht - du bist nicht der
Einzige der mit Stable Server aufsetzt.
das heisst überhaupt nichts - ich habe aktuell nervige einwahlprobleme
mit pppoe, die einige kollegen bestätigen konnten, andere nicht. also
... ?!
Wenn zu irgendeinem
Packet-Releasezyklus ein Problem mit dns/reverse-looking aufgetaucht
wäre, dann wärest du mit Sicherheit nicht der Erste der es bemerkt.
die namensauflösung ging ja
- gestern abend
- heute beim pakete ziehen mit apt-get
- heute _nicht_ bei icmp-requests
- gleichzeitig sendete mein postfix aber fleissig mails raus - und
woher sollte der die daten der nameserver wissen, wnn nicht über
abfragen der IP-adressen...?!
- heute irgendwann wieder auch bei icmp-requests
- ein problem mit dem zusammenspiel port auf dem cisco-router <=>
mailserver; sowas hatten wir gelegentlich schon mal, und unsere
cisco-experten waren damals auch ratlos - so ein phänomen verschwand
dann nach rebooten des 4500ers und des entsprechenden clients, der
netzprobleme hatte.
So etwas, bzw. einfach ein lokales Problem durch Konfig oder
Infrastruktur, ist meist die reale Ursache.
also, jetzt zum etwa fünften mal:
- ich _HATTE_ die konfigs nicht geändert !!
- ich _HATTE_ die infrastruktur ebenfalls nicht geändert
ich _HATTE_ aber auch durch ändern der infrastruktur diese extrem hohen
reaktionszeiten auf icmp-requests bzw. bei den replies nicht beseitigen
können. hatte ich aber auch alles anfangs schon erwähnt.
ich _HATTE_ auch darauf hingewiesen, dass die replies nicht besonders
auffällig waren - ca. 200 ms auf alles, was hinter dem knoten in
frankfurt steckt, sind bei unserem netz normal bzw. eher schon gut zu
nennen.
Als zuverlässiger Admin kannst du auch etwas bessere Fehlerdiagnosen
durchführen als der einfache Aufruf von ping.
Es gibt noch eine Menge an Tools und Möglichkeiten um eine
Netzwerkdagnose durchzuführen.
(dig, tracepath|traceroute, netcat, tcpdump, ...)
btw: ein traceroute ist zwar ein nettes tool, zeigt aber erstens nur
die grundsätzliche erreichbarkeit an (sofern nicht durch allzu rigide
firewalls geblockt) und arbeitet zweitens auch nur mit icmp-paketen.
und nc interessiert mich nicht mehr so besonders, wenn die pings
dermassen schnarchend reagieren - egal, ob ich den letzten server in
patagonien anpinge oder den am ersten cisco hinter unserer haustür.
übrigens hätte ich als nächstes strace auf der sorgenkiste
angeschmissen und mich dann mit unseren cisco-admins auf die suche
begeben. und ich tippe zudem auf irgendein problem von ping direkt auf
meiner kiste - und das ist in meinen augen buggy und ein grund, aufs OS
zu schimpfen - bei Windows sind wir da doch aauch nicht so zimperlich.
und wie ich gerne mal betone: wir verwalten hier etwa je ein dutzend
windows- und linux-server, und unsere *erfahrung* ist, dass beide OSe
ihre macken haben, linux tut sich da nicht rühmlicher hervor als
windows.
aber das nur am rande. jetzt läuft die kiste ja wieder, wie sie soll
bzw. meldet mir ihre icmp-rundläufe auch in annehmbarer zeit zur
konsole zurück.
das problem an der sache ist, dass ich fast den ganzen vormittag mit
fehlersuche bzw. -behebung zugebracht habe, und in dieser zeit hätte
ich den server einmal komplett neu aufgesetzt. gelernt habe ich nämlich
so auch nichts neues ;-)
gruss
lars
Reply to: