Zum Inhalt springen

Aktualisiert: VMware Anpassungen für LogoDIDACT als Gastsystem mit dritter Netzwerkschnittstelle

Zuletzt geändert von Jonas Mayer am 2022/05/05 09:42

Auf den Promiscuous Mode innerhalb der vSwitch-Einstellung unter VMware ESXi kann verzichtet werden, sofern man einige Anpassungen am Netzwerk-Design für den LD2.0 Server durchführt.
Im Folgenden werden die Schritte  beschrieben, um die Netzwerk-Interfaces für den ldhost sowie den logosrv-Container entsprechend anzupassen.

Wichtig: Diese Anleitung setzt mindestens die Puppet-Version 1.1.33 voraus.

1. [VMware Gasteinstellungen] Netzwerk-Interfaces für die LD2.0 VM im vSphere-Client definieren

Zunächst fügt man der LD2.0 VM eine weitere virtuelle Netzwerkschnittstelle im Netzwerkbereich „intern“ hinzu.
Insgesamt sollten es also 3 Schnittstellen für die LogoDIDACT VM sein:

- 1.    p_extern: für Internetzugang des ldhost
- 2.    intern_ldhost: für lokalen Zugriff auf den ldhost vom Schulnetz aus
- 3.    intern: physikalisch durchgereicht an den logosrv LXC-Container (derselbe Netzbereich wie intern_ldhost, d.h. lokales Schulnetz)

2. [Ubuntu 16.04 LTS] systemd-Regel im ldhost für aktuelle Installationen

Ab Ubuntu 16.04 LTS ist es einfacher (auch im Hinblick auf die zukünftige Entwicklung seitens Ubuntu), für die ganze Netzwerkkonfiguration systemd-networkd zu verwenden. Nachfolgend die jeweiligen Konfigurationsdateien, die erstellt werden müssen. Gleichzeitig sollte auch die Datei /etc/udev/rules.d/70-persistent-net.rules gelöscht werden, damit nur noch eine Stelle existiert, an der konfiguriert wird.

[Match]
MACAddress=XX:XX:XX:XX:XX:XX
[Link]
Name=intern

[Match]
MACAddress=YY:YY:YY:YY:YY:YY
[Link]
Name=intern_ldhost

[Match]
MACAddress=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
[Link]
Name=p_extern

Nach Erstellung bzw. Bearbeitung der oben beschriebenen Dateien ist noch folgender Befehl wichtig, um die Änderungen in die Initramfs zu übernehmen (wichtig für den Bootvorgang, damit die Interfaces umbenannt werden):

update-initramfs -u -k all

3. Konfigurationsänderungen im Puppeteer mittels YAML-Dateien

Nachfolgend werden zwei Anpassungen beschrieben, um die OVS-Schnittstelle v_intern auf dem ldhost zu deaktivieren sowie die Schnittstelle intern als "physical device" (d.h. das ESXi-Interface direkt) zum logosrv-Container durchzureichen.

/var/lib/ld-puppet/hiera.d/custom.d/ldhost.yaml

profile::network:
  interface:
    intern:
      ovs_type: none

/var/lib/ld-puppet/hiera.d/custom.yaml

global::network:
  overwrites:
    ldhost:
      intern:
        name: intern_ldhost
        type: phys
    logosrv:
      intern:
        type: phys

Zusätzlich kann in der vorhandenen Konfigurationsdatei nic.conf für den ldhost die nicht länger genutzte Schnittstelle p_intern auskommentiert werden.

/etc/logodidact/hosts/ldhost/nic.conf

[NIC intern]
suffix 1

#[NIC p_intern]
#vlan_mode access
#vlan_untagged ld-intern
#Type manual
#ovs_type OVSPort

Nach Änderung in dieser Datei entweder das Kommando 'map_translate' im Puppeteer ausführen oder den Verzeichnisinhalt von /etc/logodidact/ per 'git commit' abspeichern, um die Änderung zu aktivieren.

4. Shorewall Interface-Namen anpassen

Die Bezeichnung der internen Schnittstelle auf dem ldhost hat sich von v_intern auf intern_ldhost geändert. Diese neue Bezeichnung sollte im Shorewall Firewall-Dienst eingetragen werden.
Hierzu folgende beiden Befehle im ldhost eingeben.

rpl "v_intern" "intern_ldhost" /etc/shorewall/interfaces
shorewall restart

5. Puppet-Run auf dem ldhost ausführen und danach die LD2.0 VM zur Aktivierung der Einstellungen neustarten

Um die getätigten Änderung zu übernehmen, muss ein "prun" auf dem ldhost ausgeführt werden. Dieser ändert die Konfigurationsdateien gemäß den Vorgaben, unter anderem die wichtigen Dateien /etc/network/interfaces.d/ovs sowie /var/lib/lxc/logosrv/network.json. Nach dem Puppet-Run dann noch die komplette LD2.0 VM neustarten.

prun
/sbin/reboot

Während des nächsten Bootvorgangs erhält dann auch der LXC logosrv seine interne Schnittstelle direkt an den Container durchgereicht. Dies kann man übrigens daran erkennen, dass die MAC-Adresse der Schnittstelle  "intern" der MAC-Adresse entspricht, die der VMware Host für die virtuelle Maschine generiert hat.