Unterschied zwischen service networking restart und Neustart eines servers

[cosinus]

Ich habe doch nie geschrieben dass ich den Server ständig die IP ändern muss.

Soviel zum Thema richtig lesen. Ich hab das "ständig" bewusst in Klammern geschrieben und dann ein Fragezeichen dahinter!

Derjenige der Hilfe sucht bemüht sich, so denke ich, doch sein Problem darzustellen.

Klar doch, so wie du, der im Eingangsposting ungenau/unvollständig das Vorgehen beschreibt?

[MSfree]

Da du ja scheinbar auf Nachfragen ein wenig allergisch zu reafieren scheinst, und ich mich ehrlich gesagt nicht mir Proxmox auskenne, werfe ich mal folgendes in den Raum:

Das Netzwerk ist folgendermaßen aufgesetzt: https://wiki.hetzner.de/index.php/Proxm ... tem_Routed

Ehrlich, das werde ich jetzt nicht durchlesen.

Und wenn man da eine neue Ip für eine Gast hinzufügen möchte muss man das ja irgendwie aktivieren.

Richtig, das muß man aber im Gast aktivieren, der Host hat doch damit gar nichts zu tun.
Also: neuen Gast aufsetzen und starten, sich im Gast einlogen und dann dort die neue IP vergeben. Dem Host ist die IP des Gastes egal.

Nur das Networking neu zu starten führt eben zu keinem Erfolg.

Doch, wenn man das Networking des Gastes neu startet.

Wie gesagt, ich kenn Proxmox nicht. Die VMs, die ich bisher verwendet habe, habe ich im bridged Modus konfiguriert. Jeder Gast, der gestartet wird, schafft einfach eine Netzwerkbrücke auf das vorhandene physikalische Netzwerkinterface des Hosts. Wenn der Host nun sein Netzwerk neu startet, sind die Brücken weg und die Gäste sind nicht mehr im Netz. Für mich eigentlich völlig logisch.

Durch einen Systemneustart werden auch die Gäste neu gestartet, die Brücken wieder eingerichtet, et voila, alles ist wieder so wie es soll.

[KP97]

Auch wenn ich Proxmox nicht kenne und auch keinen Server betreibe, aber einen Hinweis hätte ich.
Stretch läuft nun komplett mit systemd und hat natürlich auch alle Services für die Steuerung des Netzwerks integriert. So ist z.B. der networking.service noch eine "Altlast" der init.d Scripte.
Diese Scripte werden auch noch gelesen, werden aber intern von systemd in eine Unit umgewandelt und ausgeführt. Das ist aber eigentlich doppelt und evtl. rührt daher der Fehler (wenn es denn einer ist).
Der eigentliche Service ist systemd-networkd mit der Abfrage

Code: Alles auswählen

systemctl status systemd-networkd 
und auch networkctl status 

Probiere doch mal ein

Code: Alles auswählen

systemctl enable systemd-networkd
und anschließend
systemctl disable networking.service 

und dann die weiteren Abfragen.
Auf jeden Fall auch die sehr umfangreichen manpages zu systemd lesen.

[etron770]

Und wenn man da eine neue Ip für eine Gast hinzufügen möchte muss man das ja irgendwie aktivieren.

Richtig, das muß man aber im Gast aktivieren, der Host hat doch damit gar nichts zu tun.

Nun es ist routed aufgesetzt und das nicht mit Subnetz also muss ich auf dem Host zumindestens die neue IP eintragen.
Die Ip ist ohne den Eintrag auf dem Host für den Gast nicht verfügbar.

Also: neuen Gast aufsetzen und starten, sich im Gast einlogen und dann dort die neue IP vergeben. Dem Host ist die IP des Gastes egal.

Nur das Networking neu zu starten führt eben zu keinem Erfolg.

Doch, wenn man das Networking des Gastes neu startet.

Genau das hat nicht funktioniert deshalb der versuch das Netzwerk neu zu starten, aber wie KP97 schreibt ist das service networking restart bei Stretch veraltet.

[cosinus]

man kann den service command aber immer noch verwenden vgl. https://askubuntu.com/questions/903354/ ... nd-service

[MSfree]

Nun es ist routed aufgesetzt und das nicht mit Subnetz also muss ich auf dem Host zumindestens die neue IP eintragen.

So, wie ich das nach kurzem überfliegen deines Hetzner-Links verstanden habe, wird in diesem Fall für jede neue VM ein neues Interface nach dem Schema vmbr* erzeugt.

Es müßte auf dem Host also reichen, ifup vmbrX auszuführen, nachdem du die /etc/network/interfaces geändert hast.

Genau das hat nicht funktioniert deshalb der versuch das Netzwerk neu zu starten, aber wie KP97 schreibt ist das service networking restart bei Stretch veraltet.

Daß service veraltet ist, ist zwar richtig, service ist aber nur ein Shellscript, das letztlich den neuen Befehl systemctl restart networking ausführt. Du solltest dich also an die neue Funktion systemctl gewöhnen, mit sevice machst du aber nichts falsch und nichts anders.
systemctl restart networking würde das Netzwerk deiner VMs genauso hinstellen.

Allerdings soltle nach dem "Hinstellen" des Netzwerks ein ifup -a das Netz wieder verfügbar machen. Ich kann dir aber nciht sagen, ob es den VMs gefällt, wenn deren Netzwerkschnittstelle im Betrieb unterm Hintern weggezogen wird.

[etron770]

Ohne jetzt die Manpage durchzulesen:
Mit wie gewünscht funktionierendem System:
networkctl status

Code: Alles auswählen

networkctl status
WARNING: systemd-networkd is not running, output will be incomplete.
  

systemctl status systemd-networkd ergibt , wenn alles wie gewünscht läuft

Code: Alles auswählen

systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
    

Und dann die Frage warum erst systemctl enable systemd-networkd dann wieder disable?
Aber egal in welcher Reihenfolge, es führt zu keiner Änderung erst nach reboot steht eine neu IP für den Gast zur verfügung , bzw die andern Gäste wieder erreichbar

[etron770]

Nun es ist routed aufgesetzt und das nicht mit Subnetz also muss ich auf dem Host zumindestens die neue IP eintragen.

So, wie ich das nach kurzem überfliegen deines Hetzner-Links verstanden habe, wird in diesem Fall für jede neue VM ein neues Interface nach dem Schema vmbr* erzeugt.
Die Anleitung ist hat viele Möglichkeiten beschrieben (auch die mit verschiedenen Interfaces) . Ich habe

Code: Alles auswählen

# fuer Einzel-IPs
auto vmbr0
iface vmbr0 inet static
  address <Haupt-IP>
  netmask 255.255.255.255
  bridge_ports none
  bridge_stp off
  bridge_fd 0
  up ip route add <erste Zusatz-IP>/32 dev vmbr0
  up ip route add <zweite Zusatz-IP>/32 dev vmbr0

Also ein Interface für alle VMs (bzw ein zweites für die die nur über VPN zu erreichen sind)
systemctl restart networking würde das Netzwerk deiner VMs genauso hinstellen.
Allerdings soltle nach dem "Hinstellen" des Netzwerks ein ifup -a das Netz wieder verfügbar machen.

Egal wie ich es versuche die VMs sind danach von außen tot - nicht so schlimm ich werde die Ips wohl nicht mehr ändern und selten eine hinzufügen . Warum das so ist müsste ich eventuell mal bei Proxmox nachfragen , die haben ja u.a auch einen eigenen Kernel.

[TomL]

wo ist der Unterschied zwischen service networking restart und kompletten Neustart eines Servers?Der Hintergrund der Frage:....

Beim Lesen in diesem Thread bin ich jetzt echt einigermaßen irritiert, wie man sich so über eine Fragestellung echauffieren kann.... die meines Erachtens absolut präzise gestellt ist und die imho auch völlig ausreichende Information enthält. Also, etron, keep cool... ist nicht Dein Problem, wenn manche schon die Frage nicht verstehen, braucht man da auch nicht auf Anworten hoffen... s.c.n.r.

Ich jedenfalls finde die Fragestellung interessant, kann allerdings auch nur rätselraten. Was passiert eigentlich, wenn Du anschließend nach dem "service networking restart" das gleiche auf der VM tust? Fängt sich die VM wieder oder ist sie danach immer noch nicht erreichbar? Und ich würde ggf. auch mal den Resolver auf der VM kontrollieren... nicht das der vielleicht ein Problem hat, weil kurzzeitig die Verbindung gekapert wurde. Laufen da noch iptables...?... wenn ja, würde ich die nach "service restart" auch mal flushen und neu laden. Dann würde ich auch mal ein Auge auf den dhcp-Client auf der VM werfen.... das wäre sowieso einer der Kandidaten, den ich mal genauer im Auge behalten würde. Und ich würde alle Dienste NICHT mehr über "service" starten/restarten/stoppen, sondern direkt über systemctl und die entsprechende Unit.

Das das alles nach einem kompletten Neustart funktioniert, leuchtet mir ein... ansonsten kann man nur Stück für Stück probieren und gucken, ob einer der Dienste nach dem Service-Restart Schluckauf hat.

[cosinus]

wo ist der Unterschied zwischen service networking restart und kompletten Neustart eines Servers?Der Hintergrund der Frage:....

Beim Lesen in diesem Thread bin ich jetzt echt einigermaßen irritiert, wie man sich so über eine Fragestellung echauffieren kann.... die meines Erachtens absolut präzise gestellt ist und die imho auch völlig ausreichende Information enthält. Also, etron, keep cool... ist nicht Dein Problem, wenn manche schon die Frage nicht verstehen, braucht man da auch nicht auf Anworten hoffen... s.c.n.r.

Aha - aber dass man sich als Hilfesuchender über Rückfragen so aufregt und absichtlich Stilmittel wie eingeklammertes mit Fragezeichen falsch versteht ist natürlich völlig normal.
Und jetzt kommen von dir auch etliche Nachfragen, na mal sehen ob dem TO das schmeckt

[etron770]

Ich jedenfalls finde die Fragestellung interessant, kann allerdings auch nur rätselraten. Was passiert eigentlich, wenn Du anschließend nach dem "service networking restart" das gleiche auf der VM tust?

Nein das hilft auch nicht, auch nicht der Shutdown und Restart der VM. Aber ich frage mal bei Proxmox nach, ob jemand weiss warum das so ist.
Viele Grüße Knut

[cosinus]

Knut, du hast deine Netzwerkadapter ja über die /etc/network/interfaces konfiguriert. Wenn service networking restart bzw systemctl restart networking nicht greifen, solltest du mal prüfen, ob die entsprechenden Schnittstellen mit auto "aktiviert" sind also zB so:

Code: Alles auswählen

auto enp1s0
iface enp1s0 inet static
	address 192.168.1.2/24
	gateway 192.168.1.1

Das war bei mir immer der erste Aufhänger wenn die neue IP-Konfig zwar nach reboot wirksam war, aber nicht nach restart des Dienstes 'networking'.

[etron770]

ja ist Auto:

Code: Alles auswählen

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp6s0
iface enp6s0 inet static
  address yy.yy.zz.18
  netmask 255.255.255.192
  gateway yy.yy.zz.1
  pointopoint yy.yy.zz.1

iface enp6s0 inet6 static
 address 2a01:4f8:130:516e::2
 netmask 64
 gateway fe80::1
 up sysctl -p
# ----------------- original ende   --------------
# --------------------- VM config -------------
auto vmbr0
iface vmbr0 inet static
 address yy.yy.zz.18
 netmask 255.255.255.255
 bridge_ports none
 bridge_stp off
 bridge_fd 0
  up ip route add yy.yy.zz.32/32 dev vmbr0
  up ip route add yy.yy.zz.55/32 dev vmbr0
  up ip route add yy.yy.zz.57/32 dev vmbr0
  up ip route add yy.yy.zz.59/32 dev vmbr0
  up ip route add yy.yy.zz.60/32 dev vmbr0
  up ip route add yy.yy.zz.62/32 dev vmbr0

#-------- VPN -----------------
auto vmbr111
iface vmbr111 inet static
  address 10.8.0.1
  netmask 255.255.255.255
  bridge_ports none
  bridge_stp off
  bridge_fd 0
     up ip route add 10.8.0.110/32 dev vmbr111
     up ip route add 10.8.0.111/32 dev vmbr111
     up ip route add 10.8.0.112/32 dev vmbr111
     up ip route add 10.8.0.113/32 dev vmbr111
     up ip route add 10.8.0.114/32 dev vmbr111
     up ip route add 10.8.0.115/32 dev vmbr111
     up ip route add 10.8.0.116/32 dev vmbr111

[cosinus]

Also seh ich das richtig, dass ein restart networking die routen wie zB diese hier:

Code: Alles auswählen

 up ip route add yy.yy.zz.32/32 dev vmbr0

nicht neu setzt, aber ein reboot schon? Werden die auch tatsächlich gesetzt, mal geprüft mit ip route und/oder netstat -rn?
Ich find das allgemein schon recht ungewöhnlich, dass man an der IP-Konfig des Wirts herumschrauben muss, wenn man einem Gast eine IP geben und damit "erreichbar" machen will. Aber gut, du hast halt so ein Setup wie du schreibst.