ich würde dir gerne folgen und befürworte dein walkthrough.
Ich habe die doku geschrieben.
br-red ist noch ziemlich eindeutig: das netz außerhalb der linuxmuster.net, bei manchen Belwue-Adressen, bei manchen, was sie von der Fritzbox oder anderen Routern bzw. ihren Providern bekommen.
„ROT“ war die Farbe im IPFire dafür und das ist irgendwie tradition.
„GRÜN“ war die Farbe im IPFire fürs interne Netz.
Jetzt ist es aber so, dass das interne Netz schon für manche nicht mehr nur ein Netz ist, sondern subnetze eingerichtet worden sind. Dann gibt es viele „grüne“, die alle in etwa dieselben Berechtigungen haben, aber nicht alle „br-green“ heißen können. In diesem Bild ist der Server und die OpnSense nur in einem Servernetz, daher „br-server“.
Wer kein Subnetting einsetzt, könnte das auch weiterhin „br-green“ nennen, hast du vollkommen recht.
Bloß weil ich subnetting einsetze, heißt es auch nicht, dass das die Mehrheit oder alle Neuinstallierer machen.
Im Moment hänge ich an der virsh edit lmn7-opnsense, die nur schwer zu automatisieren ist. XML ist einfach Grütze. Man könnte einen xpath nutzen um die Dinge in das XML einzufügen, aber das ist sehr wackelig… hast du einen Tip?
Nach letztem Reboot ist das Anmelden extrem zäh, ich schaue nach und sehe, dass da unattended-upgrades läuft. Ich halte solche Automatismen für gefährlich, kann ich das gefahrlos deinstallieren? Warum ist es enthalten?
Bei einer Migration wird empfohlen den früheren Bereich zu behalten,
alleine schon um eine Umkonfiguration der Netzwerkswitche zu vermeiden.
gefunden und halte ihn für falsch. Ein Switch arbeitet auf Layer 2,
IP-Adressen gibt es da nicht, eine Änderung interessiert den Switch
nicht, oder?
der Satz bezieht sich auf Netzwerke die gesubnettet sind (wie meines).
Wäre ich im Adressbereich umgestiegen von 10.16.0.0/12 auf 10.0.0.0/16
so hätte ich tatsächlich alle (ca. 15) Switches umkonfigurieren müssen
und an all diesen Swithces alle VLANs (ich habe ca. 20 VLANs).
Naja, dann geht es ja um die Änderung der Topologie, nicht der IPs. Du kannst in den VLANs IPs haben wie du willst. Und wenn du die Topologie nicht änderst, musst du auch keine VLANs ändern, oder?
Ich habe da auch noch einen anderen Fehler gefunden: Der „Bereich“ wird mit 10.0.0.0 - 10.0.255.255 angegeben, aber …0 und …255 sind ja keine validen IPs. Wenn man schon von „Bereichen“ spricht (ich habe „…/16“ lieber), sollte man lieber 10.0.0.1 - 10.0.255.254 dokumentieren, oder?
Ich habe versucht, die Änderungen im XML (virsh edit ...) zu automatisieren. Die Idee ist, dem Kommando über das Environment ein Script als $EDITOR unterzujubeln, das ein paar Befehle von xmlstarlet enthält um die Änderungen verlässlich vorzunehmen. Wer noch Argument braucht, warum XML unbrauchbar ist :
#!/bin/sh -e
cat $1 |
#<disk type='block' device='disk'>
xmlstarlet ed -d '//domain/devices/disk[1]/@type' |
xmlstarlet ed -i '//domain/devices/disk[1]' -t attr -n type -v block |
#<source dev='/dev/host-vg/opnsense'/>
xmlstarlet ed -d '//domain/devices/disk[1]/source/@file' |
xmlstarlet ed -i '//domain/devices/disk[1]/source' -t attr -n dev -v /dev/host-vg/opnsense |
#<target dev='vda' bus='virtio'/>
xmlstarlet ed -d '//domain/devices/disk[1]/target/@bus' |
xmlstarlet ed -i '//domain/devices/disk[1]/target' -t attr -n bus -v virtio |
#<address .../> <-- löschen
xmlstarlet ed -d '//domain/devices/disk[1]/address' |
#<interface type='bridge'>
xmlstarlet ed -d '//domain/devices/interface[1]/@type' |
xmlstarlet ed -i '//domain/devices/interface[1]' -t attr -n type -v bridge |
#<source bridge='br-server'/>
xmlstarlet ed -d '//domain/devices/interface[1]/source/@network' |
xmlstarlet ed -i '//domain/devices/interface[1]/source' -t attr -n bridge -v br-server |
#<interface type='bridge'>
xmlstarlet ed -d '//domain/devices/interface[2]/@type' |
xmlstarlet ed -i '//domain/devices/interface[2]' -t attr -n type -v bridge |
#<source bridge='br-red'/>
xmlstarlet ed -d '//domain/devices/interface[2]/source/@network' |
xmlstarlet ed -i '//domain/devices/interface[2]/source' -t attr -n bridge -v br-red |
#<interface type='bridge'>
xmlstarlet ed -d '//domain/devices/interface[3]/@type' |
xmlstarlet ed -i '//domain/devices/interface[3]' -t attr -n type -v bridge |
#<source bridge='br-dmz'/>
xmlstarlet ed -d '//domain/devices/interface[3]/source/@network' |
xmlstarlet ed -i '//domain/devices/interface[3]/source' -t attr -n bridge -v br-dmz |
cat > temp
mv temp $1
(so läuft das wegen der eingestreuten Kommentare natürlich nicht, es soll nur die Vorgehensweise illustrieren zum Korrekturlesen) @Tobias: was hälst du von so einer Vorgehensweise?
Naja, dann geht es ja um die Änderung der Topologie, nicht der IPs. Du
kannst in den VLANs IPs haben wie du willst. Und wenn du die Topologie
nicht änderst, musst du auch keine VLANs ändern, oder?
die Switches haben bei mir eine IP im ServerVLAN, damit ich sie von dort
aus erreichen kann.
Ich müßte also bei jedem Switch die IP im Server VLAN ändern.
Das macht schon mal keinen Spass.
Und dann kommt aber noch der große Brocken: ich müßte alle VLANs im L3
Switch anpassen, weil der muß wissen welche IP Range in welchem VLAN
gilt und welche IP er selbst in eben jenem VLAN hat.
Ich kack mal Korinten: Nein, der Switch hat keine IP, sein „Managment“ hat die Von der Theorie kann ein Switch keine IP haben, er arbeitet auf einem Layer in dem IPs unbekannt sind.
In dem Switch ist nichts weiter als ein kleiner Rechner, der ein Betriebssystem mit einem IP-Stack und ein paar Programmen hat. Er hängt gleichberechtigt mit jedem anderen Rechner den du an den Switch hängst an eben jenem.
Ein Layer-3-Switch ist kein Switch sondern ein Router. Der Begriff ist eine Marketing-Ente. Layer-3 impliziert Router. Switch impliziert Layer-2.
Ich find’s wichtig, korrekt zu sein. Besonders wo wir an Schulen arbeiten und unser Wissen weitergeben.
Aber keine Frage, es ist viel Aufwand, 15 Switches und 20 VLANs zu administrieren. Aber vielleicht lohnt der Wechsel und die administration lässt sich automatisieren?
Der nächste Schritt ist die Einrichtung der Clients.
Die Doku benennt dazu den Befehl linuxmuster-client list-available der nicht vorhanden ist und das Paket linuxmuster-client-servertools, das nicht installiert ist und nicht existiert.
Und nun?
Ich habe auf einem anderen System die Tools erzeugen wollen und erhalte (nach hinzufügen des Pub-Keys) die Meldung:
W: GPG error: https://archive.linuxmuster.net lmn7/ Release: Detached signature file '/var/lib/apt/lists/partial/archive.linuxmuster.net_lmn7_Release.gpg' is in unsupported binary format
Das klingt, als sei die Signatur auf dem Server kaputt?
das ist schon OK, mir ist korrekte Sprache auch sehr wichtig (als
Naturwissenschaftler und Mathematiker).
Nein, der Switch hat keine IP, sein „Managment“
hat die Von der Theorie kann ein Switch keine IP haben, er
arbeitet auf einem Layer in dem IPs unbekannt sind.
ja: sein Management hat eine IP und um ihn zu erreichen muß er die
richtige IP im richtigen VLAN haben.
Ein Layer-3-Switch ist kein Switch sondern ein Router. Der Begriff ist
eine Marketing-Ente. Layer-3 impliziert Router. Switch impliziert Layer-2.
ja, sehe ich auch so: er ist ein Router.
Aber keine Frage, es ist viel Aufwand, 15 Switches und 20 VLANs zu
administrieren. Aber vielleicht lohnt der Wechsel und die administration
lässt sich automatisieren?
warum sollte sie in einem andern IP set besser zu managen sein?
Ich hab mich für das bleiben entschieden, weil es mir in einer
kritischen Phase (migration Ende der Sommerferien) Zeit erspart hat.
Tatsächlichhab ich ziemlich fix mein Netzwerk wieder an den Start
bekommen: dafür dass alles neu nwar: Server, Firewall, alle
Cleintbetriebsysteme.
Die Migration hat wahrlich Wunder bewirkt.
Da war das Anpassen an äußere Gegebenheiten ein kleines Ding.
das ist emin Verschulden.
IN Essen vor 3 Wochen wurde besprochen wie das gemacht werden soll in
der 7er.
Dass da noch nichts weiter passiert ist liegt an mir, weil der nächste
Schritt wäre, dass ich das Defautlcloop nochmal verändere und dann
hochlade auf den Vereinsserver.
Dann könnten die Entwickler der client-servertools weiter machen …
Asche auf mein Haupt: das wird auch nix vor nächster Woche…
Ich bin noch am rotieren mit den Bestellungen für zwei Einrichtungen…
Die Signatur scheint mir kaputt zu sein (Kann das jemand bestätigen?)
Das Paket |linuxmuster-client-servertools| exisitiert garnicht.
Die Images sind noch nicht da (das ist, wie ich verstanden habe, was
du hochladen wolltest).
Stimmt meine Sicht? Und wenn ja, wer macht die andren zwei Teile?
die werden erst gemacht, wenn ich das Image hochgeladen habe: dann
erstellen sie das linuxmuster-client-servertools Paket für die lmn7.
Die Signaturen des lmn7 Paketservers sind aus meiner Sicht nicht kaputt:
meine Server meckern da nicht.
Bedeutet das, dass die v7 so noch gar nicht nutzbar ist? Oder gibt es
einen anderen Weg, weiterzukommen?
die linuxmuster-client-servertools sind „so“ noch nciht benutzbar.
Willst du das default.cloop haben, dann bekommst du ein .zip von mir mit
Anleitung und cloop drin.
Das kannst du hier herunterladen (bis Weihnachten):
: