/etc/network/interfaces testen

U

Unifex

New Member
Ich habe eine zusätzliche IP in die entsprechende Datei mit Netmask und Broadcast eingetragen.

Normalerweise würde ich die Datei jetzt auf den Server überspielen und dann mit "networking restart" die neue Konfiguration einlesen.

Gibt es eine Möglichkeit die neuen Einstellungen in der Datei vielleicht einmal vor der Aktivierung zu testen?

Ich meine aus versehen ein Schreibfehler in der Datei und der Zugriff auf den Server ist erst mal weg.
Vielleicht gibt es ja eine Möglichkeit der Vorabprüfung.
 
Wie sieht die Config denn genau aus? Bei Debian sollte man zusätzliche IPs doch normalerweise per iproute eintragen - du könntest die Befehle also zuerst über Bash ausführen. Alternativ eben einfach einen Cron anlegen, der die alte /e/n/i sagen wir mal jede Minute wiederherstellt.

*/1 * * * /bin/cp /etc/network/interfaces-bak /etc/network/interfaces; /etc/init.d/networking restart
 
Last edited by a moderator:
infinitnet said:
Bei Debian sollte man zusätzliche IPs doch normalerweise per iproute eintragen
Click to expand...

Code: 
ifconfig ethx:1 IP

Irgendwo habe ich mal gelesen, dass es aber schon lange veraltet ist und man stattdessen ip nutzen soll.

Code: 
ip addr {add|change|replace} IFADDR dev STRING

Alternativ eben einfach einen Cron anlegen, der die alte /e/n/i sagen wir mal jede Minute wiederherstellt.

*/1 * * * /bin/cp /etc/network/interfaces-bak /etc/network/interfaces; /etc/init.d/networking restart
Click to expand...

Da musst du aber schnell sein und innerhalb einer Minute den Crontab wieder entfernen, da ansonsten alle Verbindungen gekappt werden und man über SSH neu verbinden muss. Wenn man etwas langsamer ist, ist es besser die Zeit etwas hoch zu setzen.

Was ich vermisse, ist ein vorab Syntax-Check für die Datei interfaces.
 
DeaD_EyE said:
Da musst du aber schnell sein und innerhalb einer Minute den Crontab wieder entfernen, da ansonsten alle Verbindungen gekappt werden und man über SSH neu verbinden muss. Wenn man etwas langsamer ist, ist es besser die Zeit etwas hoch zu setzen.
Click to expand...
Eine Minute sollte völlig ausreichend sein, um "crontab -e" auszuführen, dann ggf. ein paar Zeilen herunter zu scrollen und dann "dd" und ":wq". Dauert keine 10 Sekunden, SSH-Login nicht mitberechnet. Auch wird die SSH-Verbindung normalerweise nicht durch durch einen Restart von networking unterbrochen, sofern relativ zeitnah die IP, mit der man verbunden ist, wieder up ist.

DeaD_EyE said:
Code: 
ip addr {add|change|replace} IFADDR dev STRING
Click to expand...
Ja, das wäre die aktuell empfohlene Methode und kann man dann z.B. als "up ip addr add 1.2.3.4/32 dev eth0" in die /e/n/i unter der Config von eth0 eintragen, gefolgt von "down ip addr del 1.2.3.4/32 dev eth0".
 
infinitnet said:
Auch wird die SSH-Verbindung normalerweise nicht durch durch einen Restart von networking unterbrochen, sofern relativ zeitnah die IP, mit der man verbunden ist, wieder up ist.
Click to expand...

Wäre eher eine Sicherheitslücke, wenn SSH automatisch die Verbindung wieder aufnimmt. Die Sockets sollten in dem Moment verloren gehen, wenn die Interfaces weg sind, was normalerweise bei restart (stop, sleep, start) passiert. Ich werde es mal ausprobieren.
 
DeaD_EyE said:
Wäre eher eine Sicherheitslücke, wenn SSH automatisch die Verbindung wieder aufnimmt. Die Sockets sollten in dem Moment verloren gehen, wenn die Interfaces weg sind, was normalerweise bei restart (stop, sleep, start) passiert. Ich werde es mal ausprobieren.
Click to expand...
Bei RHEL bleibt die SSH-Verbindung auf jeden Fall bestehen, bei Debian bin ich mir gerade nicht ganz sicher - teile dann mal die Ergebnisse mit, wenn du das testest.
 
Letztens grad getestet (Debian 7.5) - Die SSH Verbindung bleibt bestehen nach einem "networking restart"
 
infinitnet said:
Wie sieht die Config denn genau aus?
Click to expand...


Die würde bei mir so aussehen:

Code: 
auto lo
iface lo inet loopback

# device: eth0
auto  eth0
iface eth0 inet static
  address   x.x.x.136
  broadcast x.x.x.159
  netmask   255.255.255.224
  gateway   x.x.x.129
  # default route to access subnet
  up route add -net x.x.x.128 netmask 255.255.255.224 gw x.x.x.129 eth0


  
auto eth0:1 
iface eth0:1 inet static
     address   x.x.x.157
     netmask   255.255.255.224
     broadcast x.x.x.159
 
Du verwendest wohl nicht die empfohlene iproute-Methode (s. ein paar Posts weiter oben). Kopiere zuerst deine jetzige /e/n/i nach -bak, also "cp /etc/network/interfaces /etc/network/interfaces-bak" und lege dann den von mir ganz oben erwähnten Cron an, dann stellst sich die ursprüngliche Config jede Minute wieder her. Dass die SSH-Verbindung dadurch zumindest im Normalfall *nicht* abbricht, haben wir inzwischen auch geklärt denke ich.
 
infinitnet said:
Du verwendest wohl nicht die empfohlene iproute-Methode (s. ein paar Posts weiter oben). Kopiere zuerst deine jetzige /e/n/i nach -bak, also "cp /etc/network/interfaces /etc/network/interfaces-bak" und lege dann den von mir ganz oben erwähnten Cron an, dann stellst sich die ursprüngliche Config jede Minute wieder her. Dass die SSH-Verbindung dadurch zumindest im Normalfall *nicht* abbricht, haben wir inzwischen auch geklärt denke ich.
Click to expand...

Ja, danke für den Hinweis.

Es wäre aber in der Tat irgendwie gut, wenn es sowas wie ein Testlauf Tool geben würde.

"Networking restart" ist ja theoretisch auch nicht die richtige Methode, da das Skript auf "Deprecated" steht.

Empfohlen wird auch die Änderungen in der Datei zu machen und dann mit dem Befehl ifup zu arbeiten.

Also z.B. ifup eth0

Ich frage mich ob das vielleicht auch für diese neue IP funktionieren würde also dann: ifup eth0:1

Hat das schon mal jemand probiert?
 
Das ist jetzt Offtopic



Das erinnert mich an folgende Situation eines klassischen Wohnzimmerspieleserverbetreibers (kein Kinderzimmerspieleserverbetreiber). Naja, eigentlich müsste es Arbeitszimmerspieleserverwebserverdedicatedundvserverbetreiber heißen.

Kollege: Ändere mal bitte die IP auf x.
Ich: Ist geändert, Server einmal neustarten (im Hinterkopf, dass ich mich selbst aussperre und den Server dann doch neustarten muss)

10 Minuten später...

Ich: Der Server ist nicht erreichbar. Gibt drei Möglichkeiten. 1. Bootet nicht, 2. falscher Eintrag, 3. Syntaxfehler

10 Minuten später...

Kollege: 4. nicht geroutet
Ich: :-D
Kollege: Was machen wir jetzt?
Ich: Gib mal die Zungansdaten von der Lara.
Kollege: Ist nicht angeschlossen
Ich : ?! waaaaas??
Ich: Ist ja erst 3 Uhr morgens und die haben einen echt super Service im RZ. Da wird sicherlich noch einer vor Ort sein, der so lieb ist und die IP nochmals ändert, bis das Netz endlich mal erreichbar ist oder du wartest halt so lange.
Kollege: Ne, kostet Geld und es ist gerade keiner da...... die Kunden warten
Ich: Du kannst auch die 200 km nach Frankfurt fahren



Ich weiß gar nicht mehr wie es ausging. Ich glaube er hat einfach gewartet. Man kann sich auch Probleme selbst erschaffen oder ihnen einfach aus dem Weg gehen und andere machen lassen.

Ich jedenfalls werde keine IPs von irgendeiner Kiste ändern, solange ich keinen direkten Zugriff habe, der unabhängig von der Netzwerkverbindung des Servers ist. Wenn man diesen Quatsch oft genug mitgemacht hat, will man IPs gar nicht mehr ändern. Vor allem dann nicht, wenn es total unorganisiert ist! Soviel Bier kann ich gar nicht trinken.
 
Last edited by a moderator:
infinitnet said:
*/1 * * * /bin/cp /etc/network/interfaces-bak /etc/network/interfaces; /etc/init.d/networking restart
Click to expand...


Wollte den Cron jetzt mal einbauen aber auf 5 Minuten setzen:
Code: 
*/5 * * * /bin/cp /etc/network/interfaces-bak /etc/network/interfaces; /etc/init.d/networking restart

Ergebnis:
Code: 
24: bad day-of-week
errors in crontab file, can't install.

Komisch, was ist den da falsch?
 
Ein wenig Selbstständigkeit wäre schon nicht schlecht. :rolleyes:

Der Fehler sagt schon alles - ich habe in meinem Beispiel ein Sternchen vergessen.
 
infinitnet said:
Ein wenig Selbstständigkeit wäre schon nicht schlecht. :rolleyes:

Der Fehler sagt schon alles - ich habe in meinem Beispiel ein Sternchen vergessen.
Click to expand...

Du hast recht aber ich war auch blind. Ist mir nicht aufgefallen.

Also um das mal zum Abschluss zu bringen fasse ich die Sache jetzt mal zusammen.

Es gibt kein Tool um die Einstellungen vor der Aktivierung zu testen.

Allerdings kann man sich zur Vorsicht einen Cron anlegen, der die alte Einstellung wieder herstellt.

Zunächst eine Kopie der Datei anlegen:

Code: 
cp /etc/network/interfaces /etc/network/interfaces-bak

Dann die neue Datei interfaces auf den Server kopieren.

Danach den Cron einrichten:
Code: 
crontab -e

Code: 
*/5 * * * * /bin/cp /etc/network/interfaces-bak /etc/network/interfaces; /etc/init.d/networking restart

Sollte also was schief gehen, wird nach 5 Minuten die Konfiguration hergestellt und der Network Adapter neu gestartet.

Danach die neue virtuelle IP aktivieren, die in die Datei eingetragen ist. In meinem Fall also:
Code: 
ifup eth0:1

Danach kann man mit ifconfig schauen, ob die neue IP aktiviert ist.

Anpingen sollte die sich jetzt auch lassen.

Jetzt sollte alles mit einer zusätzlichen IP laufen :)
 
You must log in or register to reply here.
Back
Top