Die Idee ist, aus dem Script alle wichtigen Schritte ableiten zu können, die nötig sind, um eine Installation durchzuführen. Das Script soll mehrfach laufen können und Schritte die bereits erfolgreich liefen überspringen.
Ich beginne diesen Thread, falls es Interessenten oder Helfer gibt. Ich gebe das Script dann zum Download bereit, wenn es etwas weiter ist.
Es wird in der Doku eine Bridge br-server erzeugt. Das scheint mir ja das „grüne Netz“ zu sein. Eine Bridge br-red exisitiert, warum heisst diese Brdige dann nicht konsequenter Weise br-green? Oder liege ich falsch?
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?
