Re: Netzwerkeinstellungen im laufenden Betrieb ändern
snoofy@gmx.net schrieb:
Wie heisst du eigentlich richtig?
> die ueberlegung ist insoweit richtig, dass gewisse dienste, die nicht am
> 'localnet' oder an allen verfügbaren IP-Adressen "lauschen", natuerlich dann
> auch probleme haben, den dienst bereit zu stellen.
>
> dienste die nicht fest an eine ip-adresse gebunden sind, haben kein
> problem...
>
> 'wwwoffle' sollte eigentlich kein problem haben, wenn sich lediglich die
> netzwerkeinstellungen aendern.
Er hat aber welche. Ich habe das nicht näher untersucht; aber wenn ich
mit falscher IP-Adresse und resolv.conf starte (und wwwoffle daher
natürlich beim ersten Seitenaufruf einen Fehler meldet) und das dann
korrigiere, dann kann ich zwar den host auf der Kommandozeile mit Namen
und IP-Adresse anpingen, aber "Reload" beim wwwoffle liefert wieder die
selbe Fehlermeldung, ebenso andre Seiten, und ein Mozilla-Neustart hilft
da auch nichts. Erst ein /etc/init.d/wwwoffle restart hilft - frag mich
nicht warum.
> > 2. Außerdem ist es ja nicht ganz ungefährlich, einfach Verbindungen zu
> > kappen - es könnte ja auch etwas übers Netz gemountet sein, etc.
>
> hier kann man aber auch testen ob netzwerk-mounts bestehen und diese evtl.
> vorher deaktivieren, bevor die netzwerkkonfiguration geaendert wird. umgekehrt
> kann vor dem verbinden der mounts auch ueberpruefen ob ueberhaupt eine
> verbindung besteht.
Ja, aber das geht realistischerweise nur für einen Rechner, den man
selber administriert. Ein Programm kann da IMO nur warnen. Denn es ist
nicht abzusehen, auf welche abgefahrene Weise jemand Netzverbindungen
"mountet", z.B. wenn jemand im (X)Emacs mit tramp per ssh eine Datei auf
einem anderen Rechner editiert.
> > Andererseits wird man normalerweise diese Dinge nur verändern wollen,
> > wenn man den Rechner sowieso an einem anderen Platz eingestöpselt
> > hat, so dass klar ist, dass die Verbindungen am alten Ort nicht mehr
> > gehen können. Würdet ihr es als zumutbar ansehen, das Problem einfach
> > zu ignorieren und lediglich in der Dokumentation darauf hinzuweisen,
> > dass sich jeder da selbst drum kümmern muss?
>
> kommt drauf an was du erreichen willst. die halbherzige loesung ist es,
> keine fehler abzufangen und fehlermeldungen einfach zu akzeptieren. das mag fuer
> versierte anwender und admins in ordnung sein. der otto-normal-maus-schubser
> hat damit seine probleme.
Auch der Otto-Normal-User sollte
- die Dokumentation von Paketen lesen, die er nachträglich installiert
- sich klar machen, dass Netzwerkverbindungen nur so lange verbunden
sein können, wie eine Verbindung besteht - wenn ich das Kabel ziehe,
dann ist es vorbei. Das sollte fast allen einleuchten, außer
vielleicht WLAN-addicts.
> in jedem fall bedeutet es ein wenig scripting aufwand. da du erst die
> bedingungen pruefen musst welche dienste laufen und beendet werden muessen
> (erfahrung in zusammenhang mit einer for; if-then schleife),
Ähm, ich weiß schon wie man shell-Schleifen programmiert. Aber das ist
hier doch völlig irrelevant, auch in Perl oder Lisp geht das, aber nur
wenn es ein allgemeines Prinzip gibt, wie man die Probleme finden und
lösen kann. Und das sehe ich nicht.
> dann pruefen musst, dass
> keine prozesse auf irgendwelche mounts zugreifen, und diese evtl. beenden
> ('fuser'),
Wohl eher: Mit einer Fehlermeldung "Prozess $UID $NAME greift noch auf
$... zu".
> in diesem zusammenhang, solltest du dir vielleicht mal openAFS
> ("www.openafs.org") oder CODAfs("http://www.coda.cs.cmu.edu/";) ansehen.
>
> die unterstuetzen naemlich das trennen von serverlaufwerken und das weitere
> arbeiten als "offline-kopie" mit anschliessender synchronisierung der
> "offline" geaenderten daten.
Es geht hier doch nicht darum, dass ich _meinen_ Laptop beim
Netzwerkumstellen im Griff habe, sondern ob es möglich ist, ein Paket so
zu schreiben, dass es in allen oder zumindest den meisten unter
Debian/GNU {Linux,Hurd,BSD} denkbaren Zusammenhängen funktioniert. Und
da bin ich skeptisch und neige dazu, das dem einzelnen admin zu
überlassen. Kai hat mir zugestimmt, und in dem was du geschrieben hast
sehe ich keine wirklichen Argumente, dass man es anders machen könnte.
Gruß, Frank
--
Dr. Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: