LM v7 Walkthrough

Ich schreibe gerade an einem Walkthrough in Form eines Shell-Scriptes, um LM v7 zu installieren.

Ich nutze http://docs.linuxmuster.net/de/v7/appendix/install-on-kvm/index.html als Basis.

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.

Mein aktuelles Problem ist die Fehlermeldung:

ERROR    Requested operation is not valid: network 'default' is not active

wenn ich virt-convert laufen lasse. Irgendwelche Tipps?

Ah:

virsh net-start default

Der Befehl

virsh shutdown lmn7-server-20190724.ovf

hatte keinen Effekt, die Domain lief weiter. Ich habe destroy nutzen müssen :confused:

Hallo mdt,

um virsh shutdown nutzen zu können, muss der Gast erlauben, dass er per acpi-event heruntergefahren werden darf.

Grüße,
Sven

richtig. mein gast ist das ova von LMv7… drum sag ich’s hier :wink:

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?

Hi mdt,

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.

Ist geschmackssache…

VG, Tobias

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?

Danke! :slight_smile:

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?

Das Thema lief hier schon mal. Es ist ein Versehen und gehört nicht dahin. Ich habe übrigens auch auf allen VMs cloud-init runtergeworfen.

Hallo Michael,

Das Thema lief hier schon mal. Es ist ein Versehen und gehört nicht
dahin. Ich habe übrigens auch auf allen VMs cloud-init runtergeworfen.

hast du den Thread nochmal zur Hand?
Ich habs gerade nicht gefunden …

LG

Holger

Hi Holger.
Klar, hier war das:

Schöne Grüße
Michael

Ich habe in der Doku den Satz

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?

Hallo,

Ich habe in der Doku den Satz

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).

LG

Holger

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?

Hier ist etwas zum folgen :slight_smile:

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 :wink: :

#!/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?

Sagen wir eher zum Kommentieren:

Hallo,

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.

LG

Holger