Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Nachwirkungen

Allerdings fordert die Namensrevolution ihre Opfer: Vor allem Programme im Enterprise-Umfeld und viele (Installations-)Skripte erwarten ein traditionelles Schema von Netzwerknamen nach dem Muster »eth*« und funktionieren auf einmal nicht mehr. In [3] findet sich als Lösungsansatz, die Datei »80-net-name-slot.rules« umzukopieren:

cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules

und die Regeln wie in Listing 1 gezeigt so zu ändern, dass sie Gerätenamen nach traditionellem Schema vergeben.

Listing 1

80-net-name-slot.rules

01 ACTION=="remove", GOTO="net_name_slot_end"
02 SUBSYSTEM!="net", GOTO="net_name_slot_end"
03 NAME!="", GOTO="net_name_slot_end"
04
05 NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_ONBOARD}", NAME="%c"
06 NAME=="", ENV{ID_NET_NAME_SLOT}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_SLOT}", NAME="%c"
07 NAME=="", ENV{ID_NET_NAME_PATH}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_PATH}", NAME="%c"
08
09 LABEL="net_name_slot_end"

In Listing 1 wird über die »PROGRAM« -Direktive ein kleines Python-Skript aufgerufen, das ein Mapping auf die alten Namen durchführt ( Listing 2 ).

Listing 2

name_dev.py

01 #!/usr/bin/env python
02 import sys
03
04 dict = {'enp2s0':'eth0', 'enp2s1':'eth1'}
05
06 if sys.argv[1] in dict:
07         print dict[sys.argv[1]]
08 else:
09         print(sys.argv[1])
10 exit(0)

Das Skript lässt sich ganz einfach durch Änderung der Schlüsselwertpaare in Zeile 4 an die eigene Umgebung anpassen. Damit werden nun die folgenden Bedingungen erfüllt:

  • Die Netzwerkkonfiguration ist nicht mehr abhängig vom Zufall.
  • Das traditionelle Namensschema wird beibehalten.
  • Die Systeme können in der Cloud beliebig oft geklont werden.

Diese Systemd-Version kann man bei Chakra Linux [6] ab 2013.01 ausprobieren; bei anderen Distributionen wird es noch etwas dauern. Fedora 19 soll diese Version ebenfalls verwenden.

Ein Workaround

Den neuen Bemühungen zum Trotz hat man es im Alltag noch oft genug mit den Generator-Regeln zu tun (siehe Tabelle 1 ). Glücklicherweise ist das Udev-Regelwerk mächtig genug, um sich selbst aus der Schlinge zu ziehen. Der folgende Trick ( Listing 3 ) nutzt den Umstand aus, dass nach erfolgter Zuweisung eines Namens für ein Gerät keine weiteren zutreffenden Regeln ausgeführt werden. Damit vergibt die Udev-Regel einfach den vom Kernel vorgeschlagenen Namen ( »eth*« ) mit der entsprechenden Ordnungszahl des Kernels ( »%n« ).

Listing 3

70-persistent-net.rules

01 Regel für KVM:
02 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:*", KERNEL=="eth*", NAME="eth%n"
03 Regel für VMware:
04 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:*", KERNEL=="eth*", NAME="eth%n"
05 Regel für Xen:
06 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:16:3E:*", KERNEL=="eth*", NAME="eth%n"

Durch das Setzen eines MAC-Adressmusters, das den automatisch generierten MAC-Adressen des Hypervisors entspricht, wird die Regel genauer spezifiziert. Fügt man dieser Regel eine passende Zuweisung voran, so ist es auch möglich, für eine VM-Vorlage eine andere Netzwerkkonfiguration zu verwenden als für die Klone. Bestehende Persistent-Net-Regeln werden weder beim Update noch durch den Net-Generator überschrieben.

Bekanntlich gibt es für jede Regel auch eine Ausnahme, so auch hier: Die Udev-Regeln gehen davon aus, dass der Hypervisor (oder die Hardware) die Geräte immer in der konfigurierten Reihenfolge aktiviert und diese damit dem Kernel in derselben Reihenfolge bekannt werden. Für KVM und VMware geht das Konzept auf – bei Hyper-V scheint das nicht der Fall zu sein (siehe dazu [7] ). Hier bleibt dann nur die Lösung über das Biosdevnames-Paket oder eben die manuelle Nacharbeit.

Im Endeffekt umgeht man mit diesen Regeln die Generatoren für die Persistent-Net-Regeln und ist damit befreit von den Nachteilen, die sie mit sich bringen. Ein weiterer Vorteil dieser Vorgehensweise ist, dass die traditionellen Gerätenamen ( »eth*« ) beibehalten werden und damit Anwendungen und Skripte, die sich exakt auf diese Namensgebung verlassen, weiterhin funktionieren. Es bleibt allerdings bei der Schwierigkeit, dass der Kernel den Geräten nach der Reihenfolge ihres Erscheinens während des Bootvorgangs entsprechende Gerätenummern vergibt. Die Regeln im Listing 3 lassen sich somit nur in Umgebungen erfolgreich einsetzen, bei denen diese Reihenfolge immer gleich ist.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023