deb11.2/bullseye - ungewollte, unkonfigurierte IP // global secondary eno1 // GELOEST

[ELindemann]

Hallo @all,

neulich fragte ich hier im Forum, ob/wie/doch/nicht man mit systemd bridges/bonds/vlans konfiguriert, mehr, ob die config aus deb8 -> deb10 funkt. Mir wurde auch geholfen Wie MSFree geschrieben hat, meine interfaces mit all dem o.a Zeug wurde 1:1 uebernommen nachdem ich die vorhersagbaren Namen (statt ethx in deb8) in der interfaces konfigurierte hatte. Bisher soweit OK.
Jetzt ist schon Debian 11 raus, Debian 10 bald durch. Ich wollte nun auch wissen, wie ist es unter deb11 funkt, ob dort auch interfaces o. Kopfschmerz funktioniert. Etwas sensiblisiert, dass es nicht so sauber ist, zeigte mir diese Webseite:
<https://www.claudiokuenzler.com/blog/11 ... interfaces>

Gefrustet bin ich auch, weil deb11 hier eine Schwaeche zeigt, die man (ich, sic) so nicht in den Griff bekommt.

Meine Config:
eine Quad-Karte
eno1 ist statisch konfiguriert

eno2/3 sind Slaves eines bonds bond77
auf den eine Bridge br77 aufgesetzt ist, 802.3ad

eno4 ist eine andere Bridge br177

Einzig eno1 ist per
iface eno1 inet static
mit einer fixen IP konfiguriert, die anderen alle mit manual _ohne_ IP.

Bevor es hier heisst, das kann nicht funktionieren, kann ich diesen Einwand nicht gelten lassen, weil es _funktioniert_ unter deb8/deb10/LDME4, einwandfrei und reproduzierbar, gar unter/mit ethx-Namen. Was ich kuehn erwartete war, dass die deb10-interfaces unter deb11 zuendet.

Was mir aufgefallen ist = das Problem ist, dass mit

ip -a
eno1 ... scope global secondary eno1
scope global dynamic noprefixroute eno2

hat, sprich eine zweite per dhcp-gezogene IP. der DHCP-Server gibt diese deb11, kann ich im Log die Anfrage sehen. Ebenso hat eno2 eine IP, die so nicht gewollt ist. Also forschte ich nach einem dhcpd Client, einen Eintrag, dass dieser doch startet, obwohl es eine interfaces gibt, darin kein dhcp konfiguriert ist, gewollt ist.

Die Suche nach
apt-cache show dhcpd5
und
apt-cache show isc-dhcp-client
ergibt, dass der
isc-dhcp-client
installiert ist. Doch wo/wann startet der dhcp-Ruf, wenn nicht ueber interfaces?

Suche nach dhcp* in
/etc/systemd
/run/systemd
und auch
systemctl disable dhcpdc.service
Failed to disable unit: Unit file dhcpdc.service does not exist.

bringt nur, dass es (s.o. Suche) diesen Service nicht gibt.

Auch
systemctl list-unit-files | grep dhcp (auch nach isc)
bringt nix, sprich leer.

Also darf man annehmen, dass der dhcp-client auf dieser Einheit (eigentlich) nicht starten sollte. Sollte. Startet trotzdem, denn die enoX bekommen eine IP-Adresse, die sie auch irgendwann verlangt haben muessen.

Evtl. kommt evtl. avahi in Betracht, doch nach einem

systemctl status avahi-daemon.service

kommt

avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled; vendor preset: enabled)
Active: inactive (dead)
TriggeredBy: avahi-daemon.socket

Es sieht auch hier so aus, dass avahi _nicht_ mitspielt, weil ich es zuvor disabled hatte.

Em Ende - ums Verrecken - kriegt diese Einheit unter deb 11.2 voellig ungefragt, ungewollt auf eno1/2 (haben Kabel, eno3/4 nicht) eine IP-Adresse. Krankes Konstrukt und das bei __Debian__.

Wie o.a.
<https://www.claudiokuenzler.com/blog/11 ... interfaces>
ist auf der Webseite weiter u. ein Beispiel, dass

//
No issue whatsoever since its original configuration (Debian 10) lacking the physical interface stanzas (fun fact: when defined, the individual interfaces ended up getting an unsought address from isc-dhcpd-server
//

ist. Genau so laeuft es auch bei mir. Auch, wenn ich den Bond nach der Syntax, die dort b1001101 angibt, konfiguriere, es aendert sich leider nichts/nix. Hat jemand eine Idee, wie man dieses Problem in den Griff bekommt? Oder ist deb11

Linux deb11g8 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux

einfach nur buggy?

Danke vorab.

Gruss
ELindemann

[whiizy]

Nur ein unqualifizierter Einwurf von mir, da ich neulich ebenfalls mal über unerwartet bezogene DHCP-Adressen nach einem Upgrade gestolpert war. Es gibt ja integriert in diverse networkmanager weitere dhcp-clients, z.B. innerhalb von systemd-networkd oder connman. Den letzteren hatte ich unbemerkt installiert und dadurch eine zweite IP eingefangen. Kannste ja sicherheitshalber mal kontrollieren.

Grüsse

[bluestar]

Meine Config:
eine Quad-Karte
eno1 ist statisch konfiguriert

eno2/3 sind Slaves eines bonds bond77
auf den eine Bridge br77 aufgesetzt ist, 802.3ad

eno4 ist eine andere Bridge br177

Einzig eno1 ist per
iface eno1 inet static
mit einer fixen IP konfiguriert, die anderen alle mit manual _ohne_ IP.

Das sieht soweit schon mal richtig aus, konfigurierst du das jetzt über /etc/network/interfaces oder über systemd?

Was mir aufgefallen ist = das Problem ist, dass mit

ip -a
eno1 ... scope global secondary eno1
scope global dynamic noprefixroute eno2

Könntest du hier einfach mal den exakten Output posten, damit wir sehen können welche Adresse da wirklich dein Problem ist.

Generell ist dein Post ein ziemliches Pamphlet mit viel Frust und leider nur mit wenig brauchbarem Input um wirklich weiterhelfen zu können. Ich habe drei Gedankenansätze:

1. Du wunderst dich über IPv6 Adressen
2. Du hast von /etc/network/interfaces auf systemd-network umgestellt und die Konfig ist noch an irgendeiner Stelle unsauber.
3. Es läuft noch ein dhclient, das könntest du mitps aux|grep dhc herausfinden.

[mat6937]

... weitere dhcp-clients, z.B. innerhalb von systemd-networkd ...

BTW: Der dhcp-Client von systemd-networkd ist per default nicht aktiviert:

DHCP=
Enables DHCPv4 and/or DHCPv6 client support. Accepts "yes", "no", "ipv4", or "ipv6". Defaults to "no".

Quelle: manpage

[ELindemann]

Hallo whiizy,

Nur ein unqualifizierter Einwurf von mir, da ich neulich ebenfalls mal über unerwartet bezogene DHCP-Adressen nach einem Upgrade gestolpert war. Es gibt ja integriert in diverse networkmanager weitere dhcp-clients, z.B. innerhalb von systemd-networkd oder connman. Den letzteren hatte ich unbemerkt installiert und dadurch eine zweite IP eingefangen. Kannste ja sicherheitshalber mal kontrollieren.

Grüsse

Danke, denn connman habe ich im Nachgang auch spaeter, nach dem Posting gemerkt. Gehe ich heute an.
Wie Du sagst __unbemekrt___. Evtl. auch bei mir.

Doch, wenn Du

//
innerhalb v. systemd-network
//

schreibst, ich suchte, fand dort gar nix, auch ein Listing brachte nicht irgednwas mit dhcp, die Suche in diesen Verzeichnissen nach etwas mit dhcp auch nicht. Dabei ging ich kuehn davon aus, dass ein System(d)-Dienst, der etwas mit dhcp macht auch im Namen etwas mit dhcp fuehrt. Also nix gefunden. Was soll da noch sein?

Das Wiederspruechliche ist, dass ich _identisch_ bei deb10 vorgegangen bin, auch nur systemd, da funkt es einwandfrei, ebenso LDME4. Deb11 verhaelt sich halt komisch, eigenartig, absurd und nicht logisch zu greifen.

Ich schalte auch nach den Installation auch den networkmanager auf der GUi ab, damit es nciht zu Inteferenzen kommt. Nix halt hier geholfen.

Andersrum, so ein alter Knochen, der nur paar Sachen in deb kann, macht halt immer das Selbe, s. Deb10. Da funkt es. Der Knochen (ich) ist identisch dumm/unfaehig. Das Ergebnis ist bei anderen Distri reproduzierbar, bei deb 11 muss ich hier im Forum schreiben.
Wer ist der Geisterfahrer?

Ich koennte auch mal Ubuntu installieren, latest greatest, fastest und schauen, was/wie dort interfaces angenommen wird.

Danke Dir.
Gruss
Elindemann

[ELindemann]

Hallo bluestar,

sorry fuer meine unkundige Art optisch sauber zu zitieren, bin etwas doof dazu. Ich wuerde gerne in deiner Antwort reinschreiben, wie in den nntp, doch dieses html-Zeug ist halt zu hoch fuer mich, versuche es manuell, vllt. klappt es.

Einzig eno1 ist per
iface eno1 inet static
mit einer fixen IP konfiguriert, die anderen alle mit manual _ohne_ IP.

Das sieht soweit schon mal richtig aus,

Es ist __richtig__, denn - Du hast den beitrag in toto gelesen - es funkt auf deb8 (lassen wir mal aussen vor), deb10 und LDME4.
Beide mit systemd und mit enter/enter/benutzer + pw/.../grub/reboot/interfaces_angepasst und eingespielt.
Natuerlich brigde und ifenslave nachinstalliert. Damit sind beide deb10 u. LDME einwandfrei.

konfigurierst du das jetzt über /etc/network/interfaces oder über systemd?

Will ich so nicht sagen, Ich versuche rauszufinden, ob deb 11 sich aehnlich verhaelt wir deb10.
IMHO ist die Netzwerk-Konfiguration mit systemd eine -euphemistsich gesagt- eine Krankheit. Warum?
Sicherlich kann systemd mit dem Hund Gassi gehen und auch Kaffe kochen. _Das_ alles ist aber nicht in meinem Focus, sondern, dass ich eine best. Konfig schon so viele Jahre in der Produktion habe, dass _alles_, was ich in interfaces habe ___genauso___ funkt.
Ich bin in __einer__ Datei, ratz/fatz hat man den Fehler im Ueberblick, die Bezuege untereinander sind klar __UND___ uebersichtlich. Kurz es funktioniert, und wenn es nicht funktioniert, weiss ich auch, warum nicht, wo ich nachschauen muss.

Wenn man aber systemd kann und diese o.a. Konstrukt in systemd abbilden will, kann es bei NICs n > 4-10, dann schnell unuebersichtlich werden - Gute Nacht - welche NIC in welcher Datei ist, die wiederrum mit einer andern Datei gebonded und dann noch evtl. gebridged mit VLAN komplemetiert wird.

Denn so wie _ich_ es begriffen habe, definiert mal alle diese Sub-Instanzen einzeln und systemd setzt diese beim Booten dann richtig(?) zusammen. Vllt aber ist mein Wissen auch nur falsch.

Was mir aufgefallen ist = das Problem ist, dass mit

ip -a
eno1 ... scope global secondary eno1
scope global dynamic noprefixroute eno2

Könntest du hier einfach mal den exakten Output posten, damit wir sehen können welche Adresse da wirklich dein Problem ist.

Klar, habe ich doch auch geschrieben.
Ich habe keinen Output, der Output ist die _UN_gewollte dhcp (v. dhcp-Server gezogene) Adresse auf einer NIC, die fuer den Bond vorgesehen ist, die ____keine____ IP bekommen sollte.
Dieses Verhalten - nochmal - tritt _nicht_ bei Deb10/LDME4 auf.
Dort gibt es keine per dhcp gezogen Adresse auf diese NIC (selbe HW)

##########################
Auch, wenn ich die ersten Zeilen ohne hash konfiguriere, die second IP kommt trotzdem, war reine try/error-Aktion (s. Link vom Vorpost). Die Config ist auch einfach zu lesen, ganz unten wir eine br77 definiert, die auf einen bond77 gedunden wird. Dieser Bond besteht aus eno2/3 und soll ___keine____ IP haben, Virt. umgebung, die IP erfolgt in der virt. Einheit selbst. Es gibt auf diese NICs keine L3-Verbindung, nur L2. L3 geht auf die vm, die drauf setzt.
##########################

#auto eno2
#iface eno2 inet manual

#auto eno3
#iface eno3 inet manual

auto bond77
iface bond77 inet manual
bond-mode 4
bond-miimon 100
bond_xmit_hash_policy layer2+3
bond_lacp_rate slow
bond-slaves eno2 eno3

auto br77
iface br77 inet manual
dns-search xyz abc
dns-nameservers 192.168.xx.4 192.168.xx.1
bridge_ports bond77
bridge_stp off
bridge_fd 15
bridge_hello 2
bridge_maxage 20
bridge_maxwait 0
bridge_ageing 0
##########################

Generell ist dein Post ein ziemliches Pamphlet mit viel Frust und leider nur mit wenig brauchbarem Input um wirklich weiterhelfen zu können.

Ich fuehle mich jetzt nicht beleidigt.
Und Du hast Recht, es ist viel Frust UND es ist wenig Output (ungute Kombination ) _weil_ ich auch wenig Output habe. Andersrum, es ist etwas da (die zweite IP auf der NIC), was nicht gewollt war. Warum soll da ein Output sein?
Ich sehe es halt mit ip a, dass diese IP auf die NIC gebunden ist.
V. der Systemseite bindet deb11.2 ein zweite IP auf eine NIC, die ein Kabel, gaaaanz regulaerer Process, aber halt ungewollt.
Doch warum?

Sprich, es gibt KEINEN Fehler, die second IP ist nicht gewollt, woran sich deb10/LDME4 (beide mit systemd) halten. Deb11 halt nicht.
Was soll ich hier posten, denn in systemd selbst habe ich _nix_ veraendert (wie in deb10/lDME4), habe nur mein Interfaces in /etc/network eingeschoben.

Ich habe drei Gedankenansätze:

1. Du wunderst dich über IPv6 Adressen

Sorry, da bin ich abgerutscht, IP6 ist nicht in meinem Focus.

[*] Du hast von /etc/network/interfaces auf systemd-network umgestellt und die Konfig ist noch an irgendeiner Stelle unsauber.

Jein. Denn, wenn diese _____selbe_____ Datei unsauber konfiguriert waere (so die Logik) wuerde doch(?) deb10 u. LDME4 nicht wie erwartet funktionieren? Oder, wie erklaerst Du dieses Verhalten?
Auch in Deb10 habe ich systemd seitig *NICHTS* an der Config etc gedreht.

[*] Es läuft noch ein dhclient, das könntest du mitps aux|grep dhc herausfinden.

Nein, da irrst Du. Es laeuft auf dieser Einheit *kein* dhcp-irgendwas.
Denn auch ein

ps aux|grep dhc

zeigt nur
root 1461 0.0 0.0 6200 656 pts/0 S+ 22:41 0:00 grep dhc

Oder ein
systemctl list-unit-files -t service| grep dhcp
bleibt leer.
Also NIX. q.e.d.

Also habe ich ein deb11.2,

* wo weder in der Konfig ein dhcp gewollt/konfiguriert ist,
* der dhcp-client nicht systemd Seitig gestartet wird s.o. Posting,
* nicht mal ein Hinweis in systemd-Verz. auf einen *dhc* zu finden ist
___und____trotzdem___ wird auf einen bond eine IP gebunden, die man nicht will.

Wie alt ist die Oma?
Sprich, woher kommt die ungewollte IP?

Dann kommt nach
* x-Stunden des Studiums
* v. y-Webseiten und
* z-Reboots, auch im Vergleich zu deb10/LDME4 ein __wenig__ Frust auf.
Ja, das kann so rueber gekommen sein.

Wie gesagt, ich wuesste nicht, was hier posten soll, die Config, die in Deb10 funkt?
Der Vor-Poster hat Connman ins Spiel gebracht, heute morgen war es doch zu frueh/spaet, diese Ecke auszuleuchten.
Wenn meine Config sch...lecht waere, dann sollte auch deb10 und auch LDME4 auch dieses Verhalten zeigen, zeigen sie aber nicht.

Wenn Du mehr Infos brauchst, welche, dann sage bitte, ich poste gerne.
Du bist dran.

Danke Dir.
ELindemann

[ELindemann]

Hallo mat6937,

... weitere dhcp-clients, z.B. innerhalb von systemd-networkd ...

BTW: Der dhcp-Client von systemd-networkd ist per default nicht aktiviert:

DHCP=
Enables DHCPv4 and/or DHCPv6 client support. Accepts "yes", "no", "ipv4", or "ipv6". Defaults to "no".

Quelle: manpage

yepp, so ist es, es gibt auf dieser Einheit mit Deb11.2 __keinen__ einzigen Hinweis in Processen, in Verz. in systemd-Listings, dass ein dhcp* irgendwo/irgendwann gestartet wird.
Eeeeextrem frustend.

Gruss
ELindemann

PS: Geht um diese Inst-CD
https://cdimage.debian.org/cdimage/unof ... etinst.iso

64fa2d58c88c1859608ad8f2736b457c *firmware-11.2.0-amd64-netinst.iso

[whiizy]

Ein dhcp-client muss ja nicht unbedingt dhcp im Namen führen. Firefox heißt ja auch nicht mozilla-http-client

Kannst mögliche Kandidaten ja erstmal aussortieren.

Der systemd-networkd ist normalerweise disabled, sieht dann so aus:

Code: Alles auswählen

$ systemctl status systemd-networkd
● systemd-networkd.service - Network Service
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)

Ob z.B. der Connectionmanager connman ungewollt läuft, nach dem gleichen Muster:

Code: Alles auswählen

$ systemctl status connman

Oder auch der von vielen grafischen Desktops eingebundene NetworkManager:

Code: Alles auswählen

$ systemctl status NetworkManager

Kann den Frust zwar nachvollziehen, wenn ausgeklügelte, statische Setups aus unbekannten Gründen nicht mehr funktionieren. Aber das allein führt ja nicht richtig weiter

[ELindemann]

Hallo whizzy,

Du hast absolut Recht, die ASCII Folge muss nicht auch notwenige, zwangsweise der Name des Paketes sein.
Das jedoch nur, nachdem ich alles (mir bekannte) abgeklopft hatte, manches studiert und ausprobiert hatte. Nachdem system in den Listings keine dhcps als Service gestartet hatte, war das nur noch die Verzweiflung, ob in den ueblichen Verz. systemds doch ein dhcp-etwas haengt. Ist aber nicht.

Einzig connman ist die Baustelle (networkmanager?). Kam leider aufgrund v. Verpflichtungen nicht dazu die deb11- Thematik zu verfolgen. Muss/will ich, weil ich bei deb bleiben will, ___klar___. Beweist, belegt es immer wieder, wie toll __diese__ Plattform ist. Best of.

Jedoch, weil ich wissen wollte, wie Ubuntu reagiert, war ich doch v. LTS-Server-Setup geplaettet, das Setup sieht die Quad-NIC, klar, und bietet ein Bond an. WOW. Fehlte nur noch , dass es eine Bridge angeboten haette, doch der Bond (bei vorhandener HW) liegt naeher als die Bridge.

Da jedoch grub deb8s nicht new_xfs sieht, konnte ich dieses Ubuntu noch nicht starten, werden heute deb10 die Grub-Konfig uebergeben, deb10 sollte new_xfs sehen. Wenn nicht halt die grub2 ISO. Oder reFIND, startet ja auch alles was auf den Platten ist.

Und Du hast _auch_ Recht mit dem Frust, denn , wenn ich mich sooooooooo intensiv mich einer Thematik beschaeftige, finde ich die Loesung (s. Postings hier, handvoll in einer Dekade), einen Wuergaround, so dass ich vorangehen kann, doch so wie deb11 sich verhaelt nehme ich eher das Deb10, dann spaeter - mit einem Test zuvor - doch vllt. deb11, wenn dieses kranke Verhalten v. Tisch ist.

Das Absurde ist doch, die anderen BS installierte ich mit der selben Ausrichtung (da auch die selbe HW), sprich, die INstallation und das Problem (vor dem Monitor, also ich) sind die Konstanten im Spiel, und doch erlaubt sich deb11 dieses Verhalten. Doch auch Fehler(?) sind logisch, wenn auch es ein Bug sein sollte.
Ich behaupte mal, dass ich an best. Schrauben drehen kann, nur ein wenig. Wie macht das jemand, der mal deb11 testet und warum auch immer bei zwei NICs dieses Verhalten bekommt?
Melde rueck, was/wie es weiter ging.

Danke Dir.
ELindemann

[ELindemann]

Hallo whizzy, @all,

das Problem ist in toto geloest. In den paar Tagen, die ich an der Maschine sitzen konnte, kann ich folgendes zur o.a. Problematik berichten. Ich be-schreibe dies hier gerne, damit vllt. der Beitrag jemandem spaeter helfen kann, nicht in die selbe Falle zu tappen.

Kurz:
Wie whizzy anregte, der connmann ___und___ der NetworkManager sind das Problem gewesen.

Stellt man __beide__ ab:

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service

systemctl stop connman.service
systemctl disable connman.service

kriegt man unter deb11.2 eine Netzwerkkonfig, die man sehr gut ueber /etc/network/interfaces (wie bei deb10, ldme4) konfigurieren kann.

Man koennte auch diese o.a. Services maskieren, somit auch stillegen.

Jedoch, als Ewiggestriger laeuft man bei einer deb11-Neuinstallation in eine unschoene Falle:
* Obwohl in der Installation nicht verlangt, wird der connman installiert
* dies ___zusaetzlich__ zum Networkmanager.

Damit hat man zwei Geister, die man so nicht gerufen hat, die an den Netzwerkkarten arbeiten. Klar, der Networkmanager kommt mit, wenn man eine GUI installiert. Ich selbst gehoere auch zu der Fraktion, die den Networkmanager als erstes stillegt. Dies habe ich auch -bevor ich mich an das Forum wandte- auch getan. Tortzdem wurde auf einen Slave des Bonds eine dhcp-IP gebunden, die *nirgends* konfiguriert war. So drehte ich mich im Kreis. F... Klar, kaum macht man was richtig, schon funktioniert es.
Wie im Rahmen dieser Arbeiten ich feststellte, ist connman ins Spiel genommen worden.

<https://blog.desdelinux.net/de/connman- ... por-intel/>
<https://variwiki.com/index.php?title=Wifi_connman>

Connman kann autark, leichtgewichtig NICs konfigurieren. Der Networkmanager konfiguriert auch an den NICs.
Warum man __zwei__ haben muss, kann ich mir nur erklaeren, dass eine Neuentwicklung sicher alle Verbindungsarten mit Plugins _leichter_ (im HIntergrund) schafft zu konfigurieren, die beim Networkmanager (sofern man ihn nutzte) evtl. nur mit Klimmzuegen moeglich sind.

Bei wir war es so, dass, obwohl der Networkmanager off war, weiterhin eine dhcp-IP gezogen wurde, weil auch connman im Hintergrund arbeitete.

Also, stellt man beide services ab, s.o. ist alles gut, deb11 verhaelt sich wie erwartet und obwohl auf systemd (mit vielen einzelnen Dateien, die querverwiesen [und unueberschaubar] das Netzwerk aufbauen) kann das Netzwerk mit der alten /etc/network/interfaces nachvollziehbar, reproduzierbar ueber _eine_ Datei konfiguriert werden.

Ich bin weiterhin der Ueberzeugung, dass die systemd-Netzwerkkonfig bei zehn NICs, vier Bonds, sechs Bridges und zwei VLans nicht ueber diese Einzeldateien beherrschbar ist. Dass man einen Querverweis v. network zu netdev, zu bonds, zur bridge und dem vlan verbockt ist mehr als wahrscheinlich. Zumindest kann ich es nicht.
Die Loesung hierzu ist, s. folgendes Posting netplan, was am Ende *ohne* /etc/network/interfaces systemd-Netzwerk ueber _eine_ yaml-Datei konfigurieren kann. Sprich, jemand anders (zumindest bei Ubuntu, netplan ist v. Ubuntu) hat das bei der Netzwerkkonfig mit vielen NICs auf einem Server (und nicht auf einem NB/PC mit einer NIC + WLAN-NIC) wohl auch so gesehen.

Gruss
ELindemann

[ELindemann]

Hallo @all,

wie im Beitrag oben angekuendigt, moechte ich hier paar HInweise zur Netzwerkkonfig unter systemd, /etc/network/interfaces und netplan beschreiben.

Mein Problem war, dass ich bei

zehn NICs
vier Bonds
sechs Bridges
und
zwei VLANs

v. deb8 auf deb10, deb11 gehen wollte. Undzwar nicht mit upgrade, sondern durch eine Neuinstallation. Deb8 ist/war noch mit systemV konfigurierbar, deb10/11 nicht mehr, systemd hat dort Einzug gehalten. IMHO ist aber bei einerm Server die Netzwerkkonfig die Achilleus-Sehne, denn, wenn die nicht OK ist, ist der Server aus der produktion. Und/oder man muss im Falle, dass etwas nicht OK ist zuegig eingreifen koennen, warum der Server nicht ins Netz kommt, zudem die o.a. Konfig etwas bunter (historisch gewachsen) ist.

Im Rahmen dieses Problems habe ich zum ersten Mal (yes) den Ubuntu-Server 20.04.3 LTS (Focal Fossa) installiert. Wow, die INstalltion ist _etwas_ anders als Debian, aber an einem Punkt wirklich auch besser. Es wir ein Server installiert und die Routine sieht die QUAD-NIC und bietet einen Bond (keine Bridges) an. Wow.

So als (ungehoerte) Anregung an Debian waere eine Abfrage, wo/wie das System installiert wird auch nicht schlecht, wenn Server wird halt mehr an der Netzwerkkonfig waehrend der INstallation konfiguriert, wenn nicht (z.B. PC/NB etc) wird halt weiter klassisch installiert.
Ebenso koennte diese Abfrage solche ungewollten Geister wie den Networkmanager/connman gar nicht installieren.

Jedoch, Ubuntu macht es auch rel. elegant, in dem netplan eingesetzt wird.
<https://netplan.io/>
Eine Entwicklung v. Canonical.
Die Konfigdatei ist/liegt
/etc/netplan/00-installer-config.yaml

Am Ende der Installation des Ubuntu-Servers hatte ich eine fast aehnliche Konfig, wei ich sie zuvor unter interfaces hatte, es fehlten nur die Bridges. Netplan konfiguriert aus der yaml-Datei systemd. Eine Bridge laesst sich - der Syntax folgend - sehr zuegig konfigurieren.

Mit

netplan generate
netplan --debug apply

hat man die Netzwerkkonfig in systemd geschrieben (/etc/network/interfaces blank). Hat - wie interfaces - einen ___riesigen___ Vorteil, dass man die __ganze__ Konfig in __einer__ Datei vornimmt, uebersichtlich und zentral, statt wir unter systemd-Konfig zig-Dateien (manuell) anzulegen.

Mit yamllint laesst sich die Syntax valiieren, da Einrueckungen/Ebenen richtig positioniert werden muessen. Obwohl ich paar Stellen - laut yamllint - in der Konfig (noch v. setup) nicht korrekt waren, wurde die netzwerkkonfig trotzdem vollstaendig umgesetzt.

Sowas geht:
interfaces: [bond77]
Aber auch
interfaces:
____- bond77
(Die Unterstriche sind die Leerstellen)

yamllint /etc/netplan/00-installer-config.yaml
/etc/netplan/00-installer-config.yaml
2:1 warning missing document start "---" (document-start)
6:7 error wrong indentation: expected 8 but found 6 (indentation)
10:9 error wrong indentation: expected 10 but found 8 (indentation)
14:9 error wrong indentation: expected 10 but found 8 (indentation)
ist eine Ausgabe yamllints.

Am Ende hat man sowas (die Einrueckungen sind hier leider weg, keine Ahnung, wie ich das darstellen kann ):
##################################
# This is the network config written by 'subiquity'
network:
bridges:
br77:
interfaces: [bond77]
# addresses: [192.168.99.222/24]
# gateway4: 192.168.99.1
mtu: 1500
# nameservers:
# addresses: [8.8.8.8]
parameters:
stp: false
forward-delay: 4
dhcp4: false
dhcp6: false
bonds:
bond77:
interfaces:
- eno2
- eno3
parameters:
lacp-rate: slow
mode: 802.3ad
transmit-hash-policy: layer2
ethernets:
eno1:
addresses:
- 192.168.99.111/24
gateway4: 192.168.99.1
nameservers:
addresses:
- 192.168.99.4
- 192.168.99.1
- 192.168.99.199
search:
- fhw.zz
eno2: {}
eno3: {}
eno4:
dhcp4: false
optional: true
version: 2
vlans:
eno4.100:
addresses:
- 192.168.100.111/24
gateway4: 192.168.100.1
id: 100
link: eno4
nameservers:
addresses:
- 192.168.100.2
search:
- fhw100.zz
##################################

Netplan laesst sich auch auf deb nachziehen.

Paar Anmerkungen zum Startverhalten systemds, insbesondere zu den laaangen timeouts beim Boot, die es doch oefter gibt, wie ich im Web festellte. Wenn man die console, die Ausgabe nicht auf /dev/ttySx umlenkt, kann man im Nachgang natuerlich auch mit

systemd-analyze

Startup finished in 8.773s (kernel) + 1min 15.369s (userspace) = 1min 24.142s
graphical.target reached after 1min 13.750s in userspace

systemd-analyze critical-chain
systemd-analyze blame
systemd-analyze plot > ./systemd_boot.svg

analysieren und findet den Uebeltaeter, der das lange timeout zu verantworten hat.

Es wird gemeldet:

[ OK ] Reached target Host and Network Name Lookups.
[*** ] A start job is running for Wait for to be Configured (8s / no limit)
oder
aehnliches mit Network ... (8s / 5min)

Als Beispiel:
In meiner Bond-Config sind zwei NIC zu einem Bond gebuendelt, aber nur eine NIC hat ein Kabel (diese NIC, da verkabelt, bekam auch v. connman die dhcp-Adresse), die andere nicht. Ebenso hatte eno4 (ein ausgedachtes VLAN-Netz, auch ohne Kabel, produktiv gibt es aber VLANs auf den Servern) zu einem Timeout gefuehrt, weil halt ohne Kabel alles haengt, bis der timeout zuschlaegt, der Bootvorgang weitergeht.

Mit
journalctl -u networking

Jan 08 00:35:00 hpg8 ifup[9342]: /etc/network/if-pre-up.d/ifenslave: 65: echo: echo: I/O error
Jan 08 00:35:00 hpg8 ifup[9342]: Waiting for a slave to join bond77 (will timeout after 60s)

konnte ich sehen, warum/wieso der Bootvorgang gehangen hat.

Mit
systemctl edit --full systemd-networkd-wait-online.service

kann man den Verzoegerer -bei mir eno3/4- rausnehmen, zudem auch dort die tmeoutzeit *nur* hier auf 10s beschraenkt werden kann.
ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=eno4 --ignore=eno3 --timeout=10

Klar sollte man hier wissen, dass und was man ueberfaehrt, doch, wenn im o.a. Beispiel eine NIC defekt waere oder ein Kabel ab ist, warum sollte der Start unnoetig lang verzoegert werden?

Manchmal wird auch geraten in
/etc/systemd/system.conf

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s

auf 5s zu setzen. Das ist IMHO _keine_ gute Idee.
Wenn man _keine_ eigene Log-Datei fuehrt, was man am Server, in der Config v. den Default-Einstellungen veraendert hat, gar in der Datei selbst den alten Wert nicht hashed, nicht dort stehen laesst, nur neuen Wert hinterlegt, hat man im Fehlerfall fast keine Chance, wenn man diese systemweiten Parameter massiv veraendert hat. Spaeter weiss man nicht mehr, dass man hier eine Veraenderung eingestellt hat, der fehlerhafte Service, was auch immer wird _immer_ ueberfahren und man wundert sich, dass man im Vorfeld nichts abfangen kann.

Die o.a. Veraenderung ist nur fuer diesen Service, und nicht systemweit fuer alle andere Services.

Eine generelle Einstellung fuer das Netzwerk kann hier vorgenommen werden
/etc/default/networking

# Timeout in seconds for waiting for the network to come online.
#WAIT_ONLINE_TIMEOUT=300
WAIT_ONLINE_TIMEOUT=10
Daher kommen auch die erschreckenden 5min (s.o) beim Boot, wenn etwas mit dem Netzwerk nicht OK ist.

Kurz:
Hat man auf einem akt. System (z.B. Deb11) mehrere NICs, die mit bond/bridges/vlans noch zusaetzlich weiter konfiguriert werden, so macht es Sinn netplan auf das System zu ziehen, wenn man *nur* in systemd bleiben will, dann ist interfaces blank. Man kann die in yaml gehaltene Config sehr gut ueberschauen, alles dort (ohne extrem steiel Lernkurve) sauber konfigurieren, zudem mit yamllint die Syntax validiert werden kann.

Jedoch gibt es auch (noch?) die Moeglichkeit _nur_ mit interfaces das systemd-Netzwerk zu konfigurieren, ohne viele, querverbundene Dateien anzulegen. Diesen Kampf IMHO kann man nicht gewinnen. Wichtig - allemal fuer Server - nicht nur den NetworkManager, sondern __auch__ connman abzuschalten, stillzulegen und/oder zu loeschen. Denn beide interferieren zu interfaces, ds Ergebnis ist ein Verhalten, was nur irritiert.

Warum in deb11 connman und der Networkmanager zusammen starten, kann ich nicht beantworten. Ebenso koennte debian die Installroutine nach vielen jahren ein weing optimieren, der Ubuntu-Server zeigt, was geht.

Bleibt nur noch eins festzuhalten, wie so oft: Kaum macht man es richtig, schon funktioniert es.
Viel Erfolg.

Gruss
ELindemann

[whiizy]

Freut mich sehr, danke für die Rückmeldung. Kann ich mir auch noch Einiges abgucken. Hast deutlich mehr zurückgegeben, als Du bekommen hast!

[ELindemann]

Hallo whiizy,

schoen, wenn der Input mehr Output erzeugt.

Ich frage mich wahrlich, wareum debian 11.2 so patzt , LDME4 und auch Ubuntu-Server hingeggen nicht. Da kann man doch nur aus dem Fenster springen.

Das coole ist, ich habe es mehrfach hin/her verifiziert, ich haette das alles auf einem Fujitsu C910 absolvieren sollen, anstatt auf einem HP G8, der braucht immer sooooo lange fuer einen Boot. Ist jetzt aber auch durch.

systemd-Netzwerk ist gelinde, euphemistisch gesagt ... (ich lasse es mal leer ), netplan ist dagegen wahrlich _der_ Problemloeser fuer das systemd-Netzwerk. Wer es trotzdem braucht, das alles manuell in systemd abzubilden, ok, go ahead. Ich denke, das Leben ist zu kurz fuer sowas; netplan und ist gut.

Viel Erfolg, Spass bei Debian.
Gruss
ELindemann

[whiizy]

Also ich finde es nicht verkehrt, daß Debian mir noch die Freiheit lässt, einen beliebigen Netzwerk-Manager, gar keinen oder selbst mehrere gleichzeitig zu installieren. - Auch wenn ich dann selbst vielleicht mal patze

Was den Erhalt der Einrückungen angeht, schau doch mal hier: Code-Blöcke

Grüsse

[ELindemann]

Hallo whizzy,

Also ich finde es nicht verkehrt, daß Debian mir noch die Freiheit lässt, einen beliebigen Netzwerk-Manager, gar keinen oder selbst mehrere gleichzeitig zu installieren. - Auch wenn ich dann selbst vielleicht mal patze

Was den Erhalt der Einrückungen angeht, schau doch mal hier: Code-Blöcke

Grüsse

Du hast Recht, oft sitzt das Problem __vor__ dem Monitor. So oft.
@NetzwerkManager (NM)
Ich finde es auch OK, dass ich die Option habe einen bestimmten NM (nach) zu installieren; viele Wege fuehren nach Rom.
Was ich jedoch meinte, zwei _gleichzeitig_, die auch mit-/gegeneinander arbeiten und Quell mancher Probleme sein koennen? Who needs this?

dpkg-reconfigure lightdm
kann ich den DM auswaehlen. Sowas fuer den Netzwerkmanager, womit ich eine aktive Auswahl haette waere doch fein.

Zwei DMs kann ich nicht laufen lassen (oder doch?). Ich meine nicht, denn der X wird ueber XDMCP TCP/UDP 177 vermittelt. Da koennen doch auch nicht zwei sich um TCP/UDP 177 streiten.
Warum brauche ich zwei _gleichzeitig_ _aktive_ Netzwerkmanager?
Die Option an sich, mit welchem jeder seinen Frieden findet ist absolut OK.

Gruss
ELindemann