Servus
> Nun k�nnte ich da einfach noch eine Debian-Variante einbauen, ich sehe
> aber zwei Probleme:
f�r Debian reicht /etc/init.d/network restart... die (standard)routen,
werden
im gegensatz zu SuSE automatisch gesetzt.
> 1. M�glicherweise reicht es nicht aus, einfach nur das Netzwerk neu zu
> initialisieren, sondern man muss auch anderes ber�cksichtigen. So
> l�uft z.B. wwwoffle offenbar mit festem Nameserver, und man muss auch
> diesen restarten.
> Ich vermute, es gibt keine Debian-zentrale Stelle, an der man sehen
> kann, welche Programme das w�ren? Als L�sung dachte ich an eine
> Konfigurationsdatei, in der die entsprechenden init-Skripte manuell
> eingetragen werden m�ssten.
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. sollte der externe mail-server der gleiche
bleiben, die routen auch korrekt sein, dass dieser trotz aenderung erreichbar ist,
sollte das tool funktionieren.
etwas anderes ist es, wenn z.B. ein 'apache' betrieben wird, aber auch hier
ist es von der konfiguration des apache abhaengig. (stichwort: virtuelle
server!)
mit dem befehl 'lsof -i' kannst du dir alle prozesse anzeigen lassen, die
eine netzwerkverbindung "nutzen". unter "name" wird dir auch angezeigt wie der
dienst konfiguriert ist (am interessantesten sollten fuer dich die "LISTEN"
objekte sein. das schema ist wie folgt:
<ip an dem der dienst angeboten wird>:<port an dem der dienst angeboten
wird>
*:80 bedeutet daher, das der dienst an Port 80 auf allen IPs angeboten wird.
solche dienste sollten eigentlich unbeeindruckt sein, wenn sich die lokale
netzwerkkonfiguration aendert. eigentlich deshalb, weil evtl. funktionen des
dienstes auf andere hosts verweisen, nur einmal pro start die "/etc/hosts"
lesen, die zum start gueltige ip-adresse gespeichert haben usw.... hier hilft
leider nur ausprobieren...
> 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.
> 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.
generell bedeutet aber ein haeufiger wechsel von einstellungen auch
probleme, die, wie du ja schon festgestellt hast, haeufig von einander abhaengen.
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), dann pruefen musst, dass
keine prozesse auf irgendwelche mounts zugreifen, und diese evtl. beenden
('fuser'), dann die mounts beenden, dann das netzwerk beenden, die
einstellungen aendern, netzwerk wieder hochfahren, dienste wieder hochfahren, sofern
diese nach der aenderung benutzbar sind, mounts wieder herstellen, sofern auch
diese wieder benutzbar sind.
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.
so long
snoofy
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
