expertenaustausch > comp.os.* > comp.os.unix.linux.misc

Marc Haber (29.11.2016, 21:42)
Hallo,

in einer größeren Umgebung, die strategisch auf Red Hat Enterprise
Linux setzt und in der Server mit Kickstart aufgesetzt werden, gibt es
Wünsche, in Zukunft statt des standardmäßig verwendeten
Network-Managers systemd-networkd zu verwenden. Dabei ist gewünscht,
den Aufwand möglichst niedrig zu halten.

Dies abzuschätzen, ist ausgerechnet bei mir (15 Jahre Erfahrung mit
Debian, Red Hat und systemd gegenüber eher skeptisch eingestellt)
gelandet.

Als einfachste Lösung schwebt mir vor, einem entsprechend
ausgerüsteten Red-Hat-Installer einfach zu sagen "nimm
systemd-networkd statt Network-Manager", so dass dieser dann direkt
mit den im unveränderten Kickstartfile gelieferten Daten zu
IP-Adressen, VLANs, Bonding-Interface etc ein
systemd-networkd-gemanagetes System zu bringen.

Kann der Installer das? Gibt es ein Modul, das man nachrüsten muss?

Oder muss ich wirklich ein Tool schreiben, das mir die
Network-Manager-Konfiguration parsed, daraus eine in allen Lebenslagen
korrekte Menge aus .network und .netdev-Units erzeugt und dann den
Network-Manager mit passenden yum-Aufrufen durch systemd-networkd
ersetzt?

Eine Diskussion über das "machen oder nicht machen" brauche ich an
dieser Stelle nicht, hier geht es darum, wie aufwendig das "machen"
wird, damit danach über "machen oder nicht machen" entschieden werden
kann.

Dankeschön.

Grüße
Marc
Florian Weimer (29.11.2016, 23:38)
* Marc Haber:

> in einer größeren Umgebung, die strategisch auf Red Hat Enterprise
> Linux setzt und in der Server mit Kickstart aufgesetzt werden, gibt es
> Wünsche, in Zukunft statt des standardmäßig verwendeten
> Network-Managers systemd-networkd zu verwenden. Dabei ist gewünscht,
> den Aufwand möglichst niedrig zu halten.


Soweit ich das sehen kann, ist systemd-networkd nicht unter den
offiziell unterstützten Paketen, sondern im Optional-Kanal. Hat der
Kunde dies bereits berücksichtigt?
Peter Lemken (29.11.2016, 23:57)
Marc Haber <mh+usenetspam1118> wrote:
> in einer größeren Umgebung, die strategisch auf Red Hat Enterprise
> Linux setzt und in der Server mit Kickstart aufgesetzt werden, gibt es
> Wünsche, in Zukunft statt des standardmäßig verwendeten
> Network-Managers systemd-networkd zu verwenden. Dabei ist gewünscht,
> den Aufwand möglichst niedrig zu halten.
> Dies abzuschätzen, ist ausgerechnet bei mir (15 Jahre Erfahrung mit
> Debian, Red Hat und systemd gegenüber eher skeptisch eingestellt)
> gelandet.


Dann würde ich sagen, hat Dein Auftraggeber einen strategischen Fehler
gemacht.

Frag nach, vielleicht spendiert er Dir einen Kurs zum RHCE und
bucht dann noch 1 Woche serious engineering von Red Hat und läßt Dich
derweil büffeln und hält Dich damit von den Produktivsystemen fern.

Dürfte billiger und schmerzfreier für ihn werden.

Is this the real life, is this just fantasy?

Peter "Queen Fan" Lemken
+43-1
Oliver Sch@d (30.11.2016, 00:33)
On Tue, 29 Nov 2016 20:42:12 +0100
Marc Haber <mh+usenetspam1118> wrote:

> in einer größeren Umgebung, die strategisch auf Red Hat Enterprise
> Linux setzt und in der Server mit Kickstart aufgesetzt werden, gibt es
> Wünsche, in Zukunft statt des standardmäßig verwendeten
> Network-Managers systemd-networkd zu verwenden. Dabei ist gewünscht,
> den Aufwand möglichst niedrig zu halten.


Welcher Mehrwert wird erwartet bzw. welches Problem soll gelöst werden?
> Als einfachste Lösung schwebt mir vor, einem entsprechend
> ausgerüsteten Red-Hat-Installer einfach zu sagen "nimm
> systemd-networkd statt Network-Manager", so dass dieser dann direkt
> mit den im unveränderten Kickstartfile gelieferten Daten zu
> IP-Adressen, VLANs, Bonding-Interface etc ein
> systemd-networkd-gemanagetes System zu bringen.
> Kann der Installer das? Gibt es ein Modul, das man nachrüsten muss?


Aus meiner Sicht ist der Installer da hart verdrahtet und man muss das
selbst bauen. Ob man dann noch behaupten kann, dass das eine supportete
Lösung ist, weiß ich nicht.

> Oder muss ich wirklich ein Tool schreiben, das mir die
> Network-Manager-Konfiguration parsed, daraus eine in allen Lebenslagen
> korrekte Menge aus .network und .netdev-Units erzeugt und dann den
> Network-Manager mit passenden yum-Aufrufen durch systemd-networkd
> ersetzt?


Ich glaube, dass der Ansatz dann ja eher wäre, den Netzwerk-Teil im
Kickstart durch Konfigurations-Management zu ersetzen.

Einen Parser für Kickstart kann man natürlich auch schreiben, dassind
dann inklusive Tests ab 2 Mannwochen auf der nach oben offenen
Selbstüberschätzugs-Skala.

mfg
Oli
Burkhard Ott (30.11.2016, 04:14)
On Tue, 29 Nov 2016 20:42:12 +0100, Marc Haber wrote:

[..]
> kann.
> Dankeschön.
> Grüße Marc


Florian schrieb bereits das das aus dem optional channel kommt, da musst
Du dann halt drauf aufpassen.
Prinzipiell geht das aber, in Deiner kickstart kannst Du packages setzen
die entweder nicht installiert werden sollen oder eben wie in Deinem Fall
installiert weredn sollen. Du musst dann eigentlich nur auf die
Abhaengigkeiten achten und in der %post section schmeisst Du dann Dein
shell script code rein. Das sollte dann funktionieren solange Du bei RH7
bleibst. RH aendert ab un zu the syntax fuer kickstart gerne mal in neuen
major releases, aber wenn Du das einmal aufgesetzt hast sind da nur
geringe Aenderungen zu erwarten.
Um Deine Frage also direct zu beantworten, wenig Aufwand und sollte
funktionieren. Ob man das will oder nicht is halt im professionellen
Umfeld nicht immer eine 1 Mann Entscheidung, ist bei mir nicht anders,
aber das moegen und nicht moegen gehoert dann in einen anderen Thread.
Vielleicht noch ein Tip, anaconda installiert python (wegen yum) und
kickstart hat include sections. Wir booten alles via PXE, so kickstart
wird ausgefuehrt und includiert die skripte die dann local ausgefuehrt
werden. Die die ich geschrieben habe, testen ob es VM or physical ist und
configurieren dan die box entprechen (wenn physical dann binding). Uber
parameter beim start aufruf hole ich mir die Netinformationen (IP
addressen) und teste an jedem interface was wo ist und scheiben dann die
ifcfg dateien.
Im Prinzip mach anaconda nicht viel, ausser kickstart lesen und was Du da
drinnen hast ausfuehren, relativ flexibel.

cheers
Marc Haber (30.11.2016, 09:27)
Florian Weimer <fw> wrote:
>* Marc Haber:
>Soweit ich das sehen kann, ist systemd-networkd nicht unter den
>offiziell unterstützten Paketen, sondern im Optional-Kanal. Hat der
>Kunde dies bereits berücksichtigt?


Hat er.

Grüße
Marc
Marc Haber (30.11.2016, 09:40)
Burkhard Ott <news2009> wrote:
>Prinzipiell geht das aber, in Deiner kickstart kannst Du packages setzen
>die entweder nicht installiert werden sollen oder eben wie in Deinem Fall
>installiert weredn sollen.


Network-Manager abwählen funktioniert an dieser Stelle aber nicht.

> Du musst dann eigentlich nur auf die
>Abhaengigkeiten achten und in der %post section schmeisst Du dann Dein
>shell script code rein.


Glücklicherweise wird das Kickstart-File jetzt schon generiert. Man
könnte also zusätzlich Code in das Kickstart-File generieren, der die
notwendigen systemd-networkd-Units zusätzlich zur
Network-Manager-Konfiguration erzeugt. Das hätte den Vorteil, dass die
Netzwerk-Konfiguration an dieser Stelle bereits mundgerecht
aufbereitet aus dem vorhandenen CMDB-Ansatz vorliegt und man sich
immerhin sparen könnte, aus /etc/sysconfig/network-scripts die Dateien
zu parsen und daraus dann zu raten, ob wir es hier mit
bridge-over-VLAN-over-Bonding oder mit einem anders gebautem Stack zu
tun haben.

Dann würde man das so installierte System erstmal mit Network-Manager
booten und dann im ersten puppet-Lauf den Network-Manager und
/etc/sysconfig/network-scripts entsorgen und systemd-networkd enablen.

Und dann könnte man sogar noch Alarm schlagen, wenn sich nach dem
Start von systemd-networkd in der Ausgabe von ip link, ip addr noch
was geändert hat.

Das klingt einfach, eine Woche hat man damit allerdings sicher zu tun.

>Das sollte dann funktionieren solange Du bei RH7
>bleibst. RH aendert ab un zu the syntax fuer kickstart gerne mal in neuen
>major releases, aber wenn Du das einmal aufgesetzt hast sind da nur
>geringe Aenderungen zu erwarten.


Das ist sowieso klar, mit einer neuen Major-Version mischen sich die
Karten neu.

>Um Deine Frage also direct zu beantworten, wenig Aufwand und sollte
>funktionieren. Ob man das will oder nicht is halt im professionellen
>Umfeld nicht immer eine 1 Mann Entscheidung, ist bei mir nicht anders,
>aber das moegen und nicht moegen gehoert dann in einen anderen Thread.


Darum geht es hier auch gar nicht, wie ich schrieb geht es um die
technische Machbarkeit als Input für einen Entscheidungsprozess.

Grüße
Marc
Florian Weimer (30.11.2016, 21:04)
* Marc Haber:

> Florian Weimer <fw> wrote:
> Hat er.


Mit Support Exception oder ohne? :)
Marc Haber (30.11.2016, 22:55)
Florian Weimer <fw> wrote:
>* Marc Haber:
>Mit Support Exception oder ohne? :)


Diese Problematik wurde für die Machbarkeitsstudie descoped.

Grüße
Marc
Burkhard Ott (01.12.2016, 04:31)
On Wed, 30 Nov 2016 08:40:39 +0100, Marc Haber wrote:

> aus /etc/sysconfig/network-scripts die Dateien zu parsen und daraus dann
> zu raten, ob wir es hier mit bridge-over-VLAN-over-Bonding oder mit
> einem anders gebautem Stack zu tun haben.


Wieso raten, siehst Du doch in /proc.
Marc Haber (01.12.2016, 21:28)
Burkhard Ott <news2009> wrote:
>On Wed, 30 Nov 2016 08:40:39 +0100, Marc Haber wrote:
>> aus /etc/sysconfig/network-scripts die Dateien zu parsen und daraus dann
>> zu raten, ob wir es hier mit bridge-over-VLAN-over-Bonding oder mit
>> einem anders gebautem Stack zu tun haben.

>Wieso raten, siehst Du doch in /proc.


Da muss ich es auch parsen und raten. Kein Gewinn.

Grüße
Marc
Ähnliche Themen