Vorweg einmal kurz in einen Blick in eine typische Netzwerk-Konfigurationsdatei unter Linux:<\/p>\n\n\n\n
network:\n version: 2\n renderer: NetworkManager\n ethernets:\n eno1:\n dhcp4: false\n addresses:\n - 192.168.111.112\/27\n nameservers:\n addresses:\n - 192.168.111.1\n routes:\n - to: default\n via: 192.168.111.1<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Und mal dieselbe Netzwerk Konfiguration mal anders:<\/p>\n\n\n\n
auto eno1\niface eno1 inet static\n address 192.168.111.112\/27\n nameserver 192.168.111.1\n gateway 192.168.111.1<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Diese beiden Konfiguration tun im Endeffekt dasselbe. Das Problem: Die erste ist f\u00fcr netplan, die zweite f\u00fcr Ifupdown2. Allein aus Gr\u00fcnden der Effizienz kommt da die Frage auf: Warum nicht einfach ifupdown2 verwenden? Tja, wenn es so einfach w\u00e4re….<\/p>\n\n\n\n
Die beiden haben andere Anwendungsgebiete. W\u00e4hrend ifupdown2 bei Bare-Metal-Systemen allm\u00e4hlich zum Standard wird, ist Netplan bei Cloud Projekten und vor allem bei Kubernetes-Clustern im Einsatz. Da ein Docker-Container eh immer mit einer .yaml-Datei in ein K8s-Cluster eingebunden wird, bot sich da an, auch die Netzwerk-Konfiguration gleich mit in den .yaml-Datei zu schreiben. So entstand Netplan. <\/p>\n\n\n\n
Jetzt m\u00f6chte ich aber eine Proxmox Umgebung (meist auf Bare-Metal) in ein bestehendes Cluster einbetten, das Cluster verf\u00fcgt aber \u00fcber mehrere Netze und diese sind auch in einer Netplan-Datei verankert. Da dieses Netzwerk sich aber \u00fcber mehrere Netzwerke erstreckt, ist die Datei dann nicht mehr ganz so simpel wie das oben genannte Beispiel, sondern sieht dann eher so aus:<\/p>\n\n\n\n
network:\n version: 2\n renderer: networkd\n ethernets:\n eno1:\n dhcp4: no\n dhcp6: no\n bridges:\n br1:\n dhcp4: no\n dhcp6: no\n interfaces: [ eno1 ]\n addresses: [ 10.17.132.22\/25 ]\n routes:\n - to: default\n via: 10.17.132.1\n nameservers:\n addresses:\n - \"10.17.132.1\"\n br1001:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan1001 ]\n br1002:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan1002 ]\n br1003:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan1003 ]\n br1004:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan1004 ]\n br1101:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan1101 ]\n br1102:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan102 ]\n link-local: [ ipv6 ]\n accept-ra: false\n br1201:\n dhcp4: no\n dhcp6: no\n interfaces: [ vlan81 ]\n vlans:\n vlan1001:\n id: 1001\n link: eno1\n dhcp4: no\n dhcp6: no\n vlan1002:\n id: 1002\n link: eno1\n dhcp4: no\n dhcp6: no\n vlan1003:\n id: 1003\n link: eno1\n dhcp4: no\n dhcp6: no\n vlan1004:\n id: 1004\n link: eno1\n dhcp4: no\n dhcp6: no\n vlan1101:\n id: 1101\n link: eno1\n dhcp4: no\n dhcp6: no\n vlan102:\n id: 102\n link: eno1\n dhcp4: no\n dhcp6: no\n link-local: [ ipv6, ipv4 ]\n accept-ra: true\n vlan1201:\n id: 81\n link: eno1\n dhcp4: no\n dhcp6: no<\/code><\/pre>\n\n\n\nDas wird mal ein wenig komplexer. Und bevor ich jetzt alles aus dieser Datei in eine ifupdown2 \u00fcbertrage, mache ich das ganze doch besser via Script, weil vertippen tue ich mich zwischenzeitlich vermutlich eh.<\/p>\n\n\n\n
Nun kommt die erste H\u00fcrde: bash (die Kommando Zeile von Linux) kann eine .yaml-Datei nicht einfach so parsen, um dies zu tun, braucht man eine python3-Erweiterung namens ’niet‘. Aber nachdem dies gekl\u00e4rt ist, k\u00f6nnte ich mich jetzt hinsetzen und das Script selber runterschreiben, oder ich k\u00f6nnte ein KI-Modul zum Skripten in mein LocalAi laden und das Modul das Script f\u00fcr mich schreiben lassen. Nach dem Testen mehrerer Module ist dies das Beste, was ich bekommen habe:<\/p>\n\n\n\n
\nTo create an ifupdown2 configuration file using the niet Python library, you first need to install the niet library. If you haven’t already, you can install it using pip:<\/p>\n\n\n\n
pip install niet<\/code><\/pre>\n<\/blockquote>\n\n\n\n\nNext, you need to write a script that uses niet to generate the ifupdown2 configuration file. ifupdown2 uses a different configuration format, so you’ll need to convert your netplan configuration to ifupdown2 syntax.<\/p>\n\n\n\n
Here’s a bash script that performs this conversion:<\/p>\n<\/blockquote>\n\n\n\n
#!\/bin\/bash\n\n# Function to convert netplan to ifupdown2\nconvert_netplan_to_ifupdown2() {\n local netplan_file=\"$1\"\n local ifupdown2_file=\"$2\"\n\n # Read netplan file\n local netplan\n netplan=$(cat \"$netplan_file\")\n\n # Extract interfaces and their configurations\n local interfaces=$(echo \"$netplan\" | jq -r '.network.ethernets + .network.bridges + .network.vlans | .[] | .id')\n\n # Create ifupdown2 configuration\n local ifupdown2_content=\"\"\n for interface in $interfaces; do\n local interface_config=$(echo \"$netplan\" | jq -r --arg interface \"$interface\" '.network | select (.ethernets[$interface] or .bridges[$interface] or .vlans[$interface]) | .ethernets[$interface] or .bridges[$interface] or .vlans[$interface]')\n local address=$(echo \"$interface_config\" | jq -r '.addresses[0]')\n local gateway=$(echo \"$interface_config\" | jq -r '.routes[] | select(.to == \"default\") | .via')\n local nameservers=$(echo \"$interface_config\" | jq -r '.nameservers.addresses[0]')\n\n # Convert to ifupdown2 syntax\n local ifupdown2_entry=\"auto $interface\"\n ifupdown2_entry+=\"\\niface $interface inet static\"\n ifupdown2_entry+=\"\\n address $address\"\n ifupdown2_entry+=\"\\n gateway $gateway\"\n ifupdown2_entry+=\"\\n dns-nameservers $nameservers\"\n\n # Add to ifupdown2 content\n ifupdown2_content+=\"$ifupdown2_entry\\n\"\n done\n\n # Write ifupdown2 configuration to file\n echo \"$ifupdown2_content\" > \"$ifupdown2_file\"\n}\n\n# Main script execution\nif [ -n \"$1\" ] && [ -n \"$2\" ]; then\n convert_netplan_to_ifupdown2 \"$1\" \"$2\"\n echo \"ifupdown2 configuration created at $2\"\nelse\n echo \"Usage: $0 <netplan_file> <ifupdown2_file>\"\n exit 1\nfi<\/code><\/pre>\n\n\n\n\nExplanation:<\/p>\n\n\n\n
Function convert_netplan_to_ifupdown2:\n Reads the netplan configuration file.\n Extracts the list of interfaces.\n Converts each interface's configuration to ifupdown2 syntax.\n Writes the ifupdown2 configuration to the specified output file.\n\nMain Script Execution:\n Checks if the script is called with the correct number of arguments.\n Calls the function with the provided input and output file paths.<\/code><\/pre>\n\n\n\nUsage:<\/p>\n\n\n\n
Save the script to a file, for example, convert_netplan.sh, give it execution permissions, and run it:<\/p>\n\n\n\n
chmod +x convert_netplan.sh\n.\/convert_netplan.sh input_netplan.yaml output_ifupdown2.conf<\/code><\/pre>\n<\/blockquote>\n\n\n\n\nThis will generate an ifupdown2 configuration file from your netplan configuration. Adjust the script as needed to handle more specific configurations or to convert additional types of network configurations.<\/p>\n<\/blockquote>\n\n\n\n
Das sieht auch alles ganz lustig aus, bis man sich die Befehle mal n\u00e4her ansieht: Das Script nutzt nicht „niet“, obwohl es den Installationsvorgang noch beschreibt und einen dazu auffordert, die python Bibliothek zu installieren. Es nutzt „jq“, was, wenn man es sich genau anschaut, daf\u00fcr gebaut ist, eine .json-Datei zu parsen. Nun, eine .yaml und und ein .json Datei sind schon \u00e4hnlich, aber leider nicht dasselbe. Sprich, das funktioniert nicht.<\/p>\n\n\n\n
Den n\u00e4chsten Fehler, den das Script begeht, ist die gesamte .yaml-Datei erstmal mit cat zu parsen und in der der Variable netplan zu speichern, um mit dieser weiter zu arbeiten. Was so auch nicht funktioniert, da Formatierungen aufgehoben werden, welche in einer .yaml-Datei allerdings essentiell sind. Also, ja, ich kann die Datei zu einer Variable innerhalb des Scriptes machen. Aber die Datei an sich sollte nicht mit bash-Boardmitteln geparst werden, wenn dies ginge, br\u00e4uchte ich auch die python3-Bibliothek nicht!!<\/p>\n\n\n\n
Vorweg k\u00f6nnte man mit echo noch die Frage nach der Datei ausgeben. Entweder in demselben Verzeichnis oder mit absolutem Pfad, dann m\u00fcssen sich Script und Datei nicht in demselben Ordner befinden.<\/p>\n\n\n\n
Das, was danach gemacht werden sollte, ist die Bezeichnung des oder der Standard-Ethernetports herauszufinden:<\/p>\n\n\n\n
PS3='Bitte nennen Sie die Bezeichnung f\u00fcr ihre Netzwerkkarte: '\noptions=(\"eth\" \"enp0s1 (o.\u00e4)\" \"eno\" \"Quit\")\nselect opt in \"${options[@]}\"\ndo\n case $opt in\n \"eth\")\n eName=\"eth\"\n echo \"Die Bezeichnung f\u00fcr ihre Netzwerkkarte beginnt mit eth\"\n break\n ;;\n \"enp0s1 (o.\u00e4)\")\n eName=\"enp\"\n echo \"Die Bezeichnung f\u00fcr ihre Netzwerkkarte beginnt mit enp\"\n break\n ;;\n \"eno\")\n eName=\"eno\"\n echo \"Die Bezeichnung f\u00fcr ihre Netzwerkkarte beginnt mit eno\"\n break\n ;;\n \"Quit\")\n exit 1\n break\n ;;\n *) echo \"ung\u00fcltige Option, bitte nochmal\";;\n esac\ndone<\/code><\/pre>\n\n\n\neth, eno und enp werden genommen. swp ist noch nicht integriert, kann man aber als Option schnell intergrieren.<\/p>\n\n\n\n
Anschlie\u00dfend werden die Interfaces, Bridges und VLANs gesammelt:
(Hier das Beispiel f\u00fcr Bridges:)<\/p>\n\n\n\n
nrOfBridges=`niet \".network.bridges\" $netplan | grep br* | wc -l`\ndeclare -a bridges=()\nfor (( c = 1; c <= $nrOfBridges; c++ ))\ndo\n bridges+=(`niet \".network.bridges\" $netplan | grep br* | sed -n \"$c\"p`)\ndone<\/code><\/pre>\n\n\n\nMan sollte hier dabei daran denken, dass das die erste Variable in einem Array mit [0] adressiert wird, d.h. das die erste Bridge also bridges[0] ist.<\/p>\n\n\n\n
Als n\u00e4chstes zieht man sich die relevanten Informationen aus den Unterpunkten der .yaml-Datei
(Wieder anhand der Bridges:)<\/p>\n\n\n\n
for (( i = 1; i <= 1; i++ ))\ndo \n j=$i-1\n bridgeWrong=${bridges[$j]}\n bridgeNow=(`echo \"$bridgeWrong\" | tr -d :`)\n interface=(`niet \".network.bridges.\"$bridgeNow\".interfaces\" $netplan`)\n dhcpV4=(`niet \".network.bridges.\"$bridgeNow\".dhcp4\" $netplan`)\n dhcpV6=(`niet \".network.bridges.\"$bridgeNow\".dhcp6\" $netplan`)\n ipV4=(`niet \".network.bridges.\"$bridgeNow\".addresses\" $netplan | cut -d'\/' -f1`)\n ipV4Netmask=(`niet \".network.bridges.\"$bridgeNow\".addresses\" $netplan | cut -d'\/' -f2-`)\n defaultRoute=(\"`niet \".network.bridges.\"$bridgeNow\".routes\" $netplan`\")\n dRoute1=(`echo \"$defaultRoute\" | tr -d ' ' | tr -d \"'\" | cut -d',' -f1 | cut -d':' -f2-`)\n dRoute2=(`echo \"$defaultRoute\" | tr -d ' ' | tr -d \"'\" | cut -d',' -f2- | cut -d':' -f2- | cut -d'}' -f1`)\n nameserver=(`niet \".network.bridges.\"$bridgeNow\".nameservers.addresses\" $netplan`)\n linkLocal=(`niet \".network.bridges.\"$bridgeNow\"\" $netplan | niet \"link-local\"`)\n acceptRA=(`niet \".network.bridges.\"$bridgeNow\"\" $netplan | niet \"accept-ra\"`)\ndone<\/code><\/pre>\n\n\n\nWas man nun mit den relevanten Informationen macht, muss man schauen. Muss das in ifupdown2 eigentlich noch deklariert werden, oder kann das ignoriert werden. <\/p>\n\n\n\n
Sollten die Infos allerdings ben\u00f6tigt werden, direkt schreiben. Da hilft das Ki- generierte Script oben dann wieder.<\/p>\n\n\n\n
Aber als Fazit muss ich sagen:<\/p>\n\n\n\n
Habe ich dieses Problem h\u00e4ufig (also mindestens im zweistelligen Bereich) w\u00fcrde sich ein Script mit Sicherheit lohnen. Ansonsten w\u00fcrde ich das nach wie vor per Hand machen. Sollten die KI Modelle allerdings irgendwann besser werden, k\u00f6nnte man auch dar\u00fcber nachdenken, das \u00fcbernehmen zu lassen. <\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Vorweg einmal kurz in einen Blick in eine typische Netzwerk-Konfigurationsdatei unter Linux: Und mal dieselbe Netzwerk Konfiguration mal anders: Diese beiden Konfiguration tun im Endeffekt dasselbe. Das Problem: Die erste ist f\u00fcr netplan, die zweite f\u00fcr Ifupdown2. Allein aus Gr\u00fcnden der Effizienz kommt da die Frage auf: Warum nicht einfach ifupdown2 verwenden? Tja, wenn es … <\/p>\n