Guten Morgen, Der normale Benutzer hat kaum mehr als eine Fritzbox und ein Netzwerkkabel, aber viele PCs haben 2 oder mehr Netzwerkbuchsen. Es sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. Kann man dafür ein Script oder Programm bauen? Bei der Debian-Installation wird es festgelegt, aber man darf später nicht umstecken. Per DHCP könnte das gerade aktive Interface eine Adresse bekommen, aber der Interface-Name ändert sich. Mit einem networkmanager reicht das vielleicht, aber es muss auch ohne funktionieren und ohne DHCP. Ideal wäre, wenn ich das jeweils aktive Interface in "lan" oder "eth0" umbenennen könnte. Ich brauche den Namen z.B. für ssh mit Link Local Adressen. Ganz zu Anfang hat man nur ein paar Namen aus /proc/net/dev oder /sys/class/net/* oder ip link. Bis auf "lo" sagen die Namen garnichts. WLAN kann man wahrscheinlich erkennen, weil es /sys/class/net/*/wireless/ gibt. Bluetooth ist auch wireless, aber gibt es da dieses Verzeichnis? CAN ist nicht wireless, kann man das unterscheiden? Mir fehlt ein eindeutiges Kennzeichen, ob hinter dem Namen RJ45-Buchsen stecken. Game Over? /sys/class/net/*/carrier sagt mir, wo das Kabel steckt. Aber dazu muss das Interface UP sein und ich möchte nicht versehentlich WLAN oder noch was schlimmeres einschalten.
Bauform B. schrieb: > Es > sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. Nein, genau das sollte es NICHT. Wenn Dich die zu vielen RJ45-Buchsen überfordern, steck Staubschutzkappen in die nicht benötigten rein.
Harald K. schrieb: > Bauform B. schrieb: >> Es sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. > > Nein, genau das sollte es NICHT. Das restliche Netzwerk würde gelegentlich eine andere Mac-Adresse sehen, aber sonst? > Staubschutzkappen Zweifellos sehr vernünftig, aber beim ersten Mal muss man trotzdem die richtige Buchse finden. Das ist kein Spaß, es gibt ja noch mehr Möglichkeiten, warum es nicht funktioniert.
Bauform B. schrieb: > Kann man > dafür ein Script oder Programm bauen? So mal am Rande: Windows wäre das egal ;-) Davon ab: Wenn du per SSH auf den Rechner willst, dann nützt dir weder der Ordner etwas wo die Interfaces aufgelistet sind, noch sonstetwas. Wenn das für dich wirklich ein Problem am entfernten Rechner darstellen sollte, das jemand das Kabel in die "falsche" Nic steckt, dann hergott vergib doch an das Interface die gleiche IP. Aber wirklich richtig machst du es, wenn du dem Rechner eine eindeutige Netzwerkkennung gibst - dann kann das Ding 20 Nics haben, du kommst darüber halt immer per SSH drauf - so wird das richtig gemacht.
Wenn mich nicht alles taeuscht, kann man dem Koernel per Parameter eine Namensvorgabe fuer drahtgebundene Netzwerkinstanze mitgeben aus der dann die Interfacenamen abgeleitet werden.
Rene K. schrieb: > So mal am Rande: Windows wäre das egal ;-) Das heißt, die Benutzer finden es selbstverständlich, dass es in jeder Buchse funktioniert? Na ganz toll. Dann muss ich die Staubschutzkappe festkleben ;) > Wenn das für dich wirklich ein Problem am entfernten Rechner darstellen > sollte, das jemand das Kabel in die "falsche" Nic steckt, dann hergott > vergib doch an das Interface die gleiche IP. Es geht eher um die umgekehrte Richtung und um den Zustand, wenn es (noch) keine "normale" Adresse gibt. Ein besseres Beispiel: rdate kann auch per Link Local Adresse die Uhr stellen, braucht aber z.B. "%eth0" hinter der Adresse. Wenn der Name bekannt und fest ist, kann man rdate einfach in einem Script benutzen. Motopick schrieb: > Wenn mich nicht alles taeuscht, kann man dem Koernel per Parameter > eine Namensvorgabe fuer drahtgebundene Netzwerkinstanze mitgeben > aus der dann die Interfacenamen abgeleitet werden. Das macht doch der udevd, nicht der Kernel? Außerdem hätte ich ja immer noch 4 verschiedene Namen.
Wer einen PC mit mehr als einer Netzwerkbuchse braucht, der sollte schon das nötige Wissen mitbringen. Ansosten w.o. vorgeschlagen: Staubschutzkappe oder noch besser: Heisskleber und ab ins Forum "quick an dirty" ;) ;) ;)
Bauform B. schrieb: > Das macht doch der udevd, nicht der Kernel? Außerdem hätte ich ja immer > noch 4 verschiedene Namen. Einen Namen haben sie wohl vorher schon. Es muss ja schliesslich auch ohne den udevd funktionieren. Es steht dir ja auch frei, fuer jedes Interface DHCP einzustellen. Und mit ein wenig haendischen Gefickel, koenntest du sogar fuer jedes Interface die selbe MAC-Adresse einstellen. :) Wo ist eigentlich das Problem?
Motopick schrieb: > Einen Namen haben sie wohl vorher schon. > Es muss ja schliesslich auch ohne den udevd funktionieren. Ja. Es funktioniert ohne udevd sogar viel einfacher. Dann gibt es eth0, eth1... und es ist klar, dass es eins davon sein muss. Dann brauche ich nur cat /sys/class/net/eth*/carrier und das rename. Aber X11 braucht den udevd. > Wo ist eigentlich das Problem? PC Nr. 1 holt sich die Zeit von einem NTP-Server und in der config steht "rdate -anv fe80::a00:c0ff:fe09:c82a%enp1s0". Das funktioniert auf einem anderen PC nicht, weil das Interface einen anderen Namen hat. Und das, obwohl beide nur 1 (ein) Interface haben. Damit man die config einfach kopieren kann, könnte man mit nameif(1) oder ifrename(1) einen festen Namen benutzen. Und wenn das mal funktionieren würde, könnte es die alle-Interfaces-sind-gleich Idee gratis geben...
Bauform B. schrieb: > Der normale Benutzer hat kaum mehr als eine Fritzbox und ein > Netzwerkkabel, aber viele PCs haben 2 oder mehr Netzwerkbuchsen. Es > sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. Kann man > dafür ein Script oder Programm bauen? Mach doch eine Bridge auf, füge die 4 Ports zur Bridge hinzu und gebe der Bridge eine IP (statisch oder per DHCP ist ja egal). Dann ist es wirklich egal. fchk
Frank K. schrieb: > Mach doch eine Bridge auf Nett! Aber auch das geht nicht automatisch, weil ich immer erst rausfinden muss, wie die echten Interfaces heißen.
Bauform B. schrieb: > Frank K. schrieb: >> Mach doch eine Bridge auf > > Nett! Aber auch das geht nicht automatisch, weil ich immer erst > rausfinden muss, wie die echten Interfaces heißen. Die Namen findest Du mit networkctl list raus
1 | IDX LINK TYPE OPERATIONAL SETUP |
2 | 1 lo loopback carrier unmanaged |
3 | 2 eth0 ether routable configured |
4 | 3 enp7s0 ether routable unmanaged |
5 | |
6 | 3 links listed. |
ip a spuckt noch mehr aus
1 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 |
2 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 |
3 | inet 127.0.0.1/8 scope host lo |
4 | valid_lft forever preferred_lft forever |
5 | inet6 ::1/128 scope host |
6 | valid_lft forever preferred_lft forever |
7 | 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 |
8 | link/ether 96:00:00:a3:7c:f9 brd ff:ff:ff:ff:ff:ff |
9 | inet xxx.xxx.xxx.xxx/32 metric 100 scope global dynamic eth0 |
10 | valid_lft 52199sec preferred_lft 52199sec |
11 | inet6 xxxx:xxxx:xxxx:xxxx::1/64 scope global |
12 | valid_lft forever preferred_lft forever |
13 | inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link |
14 | valid_lft forever preferred_lft forever |
15 | 3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000 |
16 | link/ether 86:00:00:17:aa:b3 brd ff:ff:ff:ff:ff:ff |
17 | inet 10.0.0.2/32 brd 10.0.0.2 scope global dynamic enp7s0 |
18 | valid_lft 47559sec preferred_lft 47559sec |
19 | inet6 fe80::8400:ff:fe17:aab3/64 scope link |
20 | valid_lft forever preferred_lft forever |
Umbennen https://www.tech-island.com/kb/netzwerk-interface-nic-umbenennen
:
Bearbeitet durch User
Stephan S. schrieb: > Die Namen findest Du mit networkctl raus, für > Etherenet-Schnittstellen > networkctl list en* Naja, fast. Aber wie finde ich raus, dass es hier und jetzt "en" heißt? Außerdem scheint mir networkctl nur ein abgespecktes ip zu sein und "ls /sys/class/net" liefert ungefähr dasselbe.
Bauform B. schrieb: > ... Aber X11 braucht den udevd. Wofuer das denn? Ein X-Server braucht kein udevd. > "rdate -anv fe80::a00:c0ff:fe09:c82a%enp1s0" Bei mir fragen die einfach nach dem NTP-Server per IPV4. Das funktioniert auf anderen PC auch vorzueglich. Auch per ntpd. Systeme die NTP nicht koennen (wollen), bekommen von einem Spezialdaemon ein ausfuehrbares Script geliefert: time 15:19:52 date 24/10/10 Und die ganz anderen Systeme holen sich die Zeit beim Login per (Netware-)Client. Und so ist an alle gedacht. :)
Motopick schrieb: >> ... Aber X11 braucht den udevd. > > Wofuer das denn? Ein X-Server braucht kein udevd. Ja, der läuft auch mit statischer config. Aber wenn jemand die Tastatur absteckt ist Game Over. Ich hab' auch schon probiert, genau den Teil selber zu bauen...
Bauform B. schrieb: > Stephan S. schrieb: >> Die Namen findest Du mit networkctl raus, für >> Etherenet-Schnittstellen >> networkctl list en* > > Naja, fast. Aber wie finde ich raus, dass es hier und jetzt "en" heißt? > Außerdem scheint mir networkctl nur ein abgespecktes ip zu sein und "ls > /sys/class/net" liefert ungefähr dasselbe. https://unix.stackexchange.com/questions/134483/why-is-my-ethernet-interface-called-enp0s10-instead-of-eth0 https://www.thomas-krenn.com/en/wiki/Predictable_Network_Interface_Names
:
Bearbeitet durch User
4 Bunte Kabel 4 Bunte Aufkleber und Abmahnung androhen wenn Farbenblind.
Beitrag #7751658 wurde vom Autor gelöscht.
Rüdiger B. schrieb: > 4 Bunte Kabel 4 Bunte Aufkleber und Abmahnung androhen wenn Farbenblind. 9% der maennlichen Bevoelkerung hat eine rot-Gruen-Schwaeche, waehrend die weibliche Bevoelkerung nur eine Wahrscheinlichkeit von 0.8% fuer die Rot-Gruen-Schwaeche hat (ob deswegen Maenner im wesentlichen rote Ampeln ueberfahren: keine Ahnung). Komplett sinnlose und irrelevante Information. Zum Problem des TO: Mir fehlt das Problem. Er hat ein spezielles Geraet (vier gleiche Ethernet-Ports), will per Hand konfigurieren, also leb mit den Konsequenzen. Man koennte natuerlich einen Aufkleber neben dem Port kleben oder Staubschutzkappen verwenden. Oder einfach dokumentieren (Verschriftlichung, so retro). Und wenn jetzt Jay Random Loser alle vier Ports mit der Fritzbox (auch vier Ports) verbindet? So dass er 4GB/s hat?
Vielleicht nochmal zur Erläuterung: das neue Namenschema wurde extra deswegen eingeführt, damit (als Beispiel) die linke Buchse immer enp2s0 und die rechte immer enp2s1 wurde. Vorher war eth0 die Buchse in die zuerst eingesteckt wurde und eth1 die Buchse danach, usw
Thomas W. schrieb: > Zum Problem des TO: Mir fehlt das Problem. Er hat ein spezielles Geraet > (vier gleiche Ethernet-Ports), will per Hand konfigurieren, also leb mit > den Konsequenzen. Ja, es ist ein Luxus-Problem. Aber es kommt noch schlimmer: Es soll auf verschiedenen PCs funktionieren, mit 1 bis x Ports. Für immer die gleiche Hardware und udev-Version würde ich es einmal fest einstellen und fertig. > Und wenn jetzt Jay Random Loser alle vier Ports mit der Fritzbox (auch > vier Ports) verbindet? So dass er 4GB/s hat? Das wäre das kleinste Problem. Den Unterschied zwischen 4GBit und 100MBit merkt der sowieso nicht. Stephan S. schrieb: > why-is-my-ethernet-interface-called-enp0s10 Warum das so ist, habe ich schon verstanden. Warum das so sein muss, eher nicht. Ein kleiner Schritt auf dem Weg zur Weltherrschaft? Stephan S. schrieb: > Vorher war eth0 die Buchse in die zuerst eingesteckt wurde > und eth1 die Buchse danach, usw Das wäre ja perfekt. Mein Traum. Leider nur ein Traum.
Bauform B. schrieb: > Das wäre ja perfekt. Mein Traum. Leider nur ein Traum. Ich hab's nicht probiert, sieht zumindest gut aus: https://derlinuxwikinger.de/wiederherstellung-der-alten-neztwerk-interface-namen/ hättest Du übrigens leicht selber finden können ...
:
Bearbeitet durch User
Stephan S. schrieb: > Bauform B. schrieb: >> Das wäre ja perfekt. Mein Traum. Leider nur ein Traum. > > Ich hab's nicht probiert, sieht zumindest gut aus: > net.ifnames=0 Das habe ich jahrelang benutzt, es funktioniert gut, auch ohne biosdevname - aber wie lange noch? Weil: das macht nicht der Kernel. Ich rechne damit, dass jemand die Phantasienamen so toll findet, dass bald nur noch die erlaubt sind.
Stephan S. schrieb: > Vielleicht nochmal zur Erläuterung: das neue Namenschema wurde extra > deswegen eingeführt, damit (als Beispiel) die linke Buchse immer enp2s0 > und die rechte immer enp2s1 wurde. Vorher war eth0 die Buchse in die > zuerst eingesteckt wurde und eth1 die Buchse danach, usw eth0 wurde das Interface, dass bei einem statisch kompiliertem Koernel zuerst "geprobt" wurde. Das naechste bekam dann eth1 uswusf. Das waere ja ganz was neues, wenn das von "gesteckten" Netzwerkkabeln abhaengen wuerde. In einer meiner Ultra 10 steckt auch eine Karte mit 4 Interfacen. Probleme mit der Benummerung habe ich aber nicht. Da laueft ja auch das gute™ Solaris drauf.
Motopick schrieb: > eth0 wurde das Interface, dass bei einem statisch kompiliertem > Koernel zuerst "geprobt" wurde. Das naechste bekam dann eth1 uswusf. Es ist aber nicht festgelegt, in welcher Reihenfolge. Das beseitigt das neue System indirekt.
Stephan S. schrieb: > Motopick schrieb: >> eth0 wurde das Interface, dass bei einem statisch kompiliertem >> Koernel zuerst "geprobt" wurde. Das naechste bekam dann eth1 uswusf. > > Es ist aber nicht festgelegt, in welcher Reihenfolge. Das beseitigt das > neue System indirekt. Im Makefile. :) 3Com kommt eben deutlich vor Zyxel. Gewuerfelt wird bei gleichnamigen Karten. Was uebrigens auch beim Laden eines Kernelmoduls passiert. Bei Virtualisierern gibt es dafuer kleine Helferlein, die fuer Ordnung sorgen. Auf richtiger Hartware koennte dann udevd doch vllt nuetzlich sein. Schoenes WE!
Bauform B. schrieb: > Mir fehlt ein eindeutiges Kennzeichen, ob hinter dem > Namen RJ45-Buchsen stecken. Also: Praktisch findet man die Info mit "dmesg | grep eth". Interessant ist die Zeile mit der MAC-Adresse, die stammt direkt von echter Ethernet-Hardware. Das dürfte ausreichend zuverlässig sein. Der Name eth wird sich kaum ändern und wenn der Kernel ein Interface eth nennt, sollte das Netzwerk damit funktionieren. Wer eine konstante Adresse haben will, sollte sich die aus dmesg merken. Falls das Interface per Software eine neue bekommt, findet man die echte praktisch nirgends mehr. Aber was meint Harald damit? Harald K. schrieb: > Bauform B. schrieb: >> Es sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. > > Nein, genau das sollte es NICHT. Und: erwarten Windows-User wirklich, dass es egal ist? Rene K. schrieb: > So mal am Rande: Windows wäre das egal ;-)
Bauform B. schrieb: > Aber was meint Harald damit? Na, genau das: Deine Vorstellung, daß sich, wenn von vier NICs nur einer genutzt wird, dieser sich verhalten soll wie alle anderen auch, d.h. ein und dieseble Netzwerkadresse verwendet wird. Das wäre grober Unfug. Vier NICs sind, anders als vier USB-Ports, keine "Mehrfachsteckdose", wo es egal ist, wo etwas reingesteckt wird.
Technisch könnte das möglicherweise über einen Layer für Redundanz und Bandbreitenerweiterung realisierbar sein. Indem man also auf N physikalische Schnittstellen eine Pseudo-Schnittstelle setzt, die mit eigener Adresse arbeitet. Gibt es zweifelsfrei auch in Linux, ich habe damit jedoch keine Erfahrung, zumal je nach Implementierung der Switch mitspielen muss. Ist allerdings mit Kanonen auf Spatzen geschossen.
Eine weitere Möglichkeit wäre systeminternes Routing einer Pseudoschnittstelle über eine der physikalischen Schnittstellen. die Pseudoschnittstelle hätte dann einen festen Namen mit fester IP, die physikalischen freilich nicht. Diese Kanone hat aber mindestens das gleiche Kaliber, weil auch entsprechend Kenntnisse in Networking erforderlich sind.
:
Bearbeitet durch User
Die MAC-Adresse ist frei definierbar, die ihm von Haus aus zugeordnete Adresse ist nicht zwingend die genutzte. Wenn man es also schafft, jedem Interface die gleiche zu verpassen, ohne dass der Kernel meckert, hat man gewonnen. Wär dann aber besser, man steckt wirklich nur ein Kabel rein, nicht mehrere.
:
Bearbeitet durch User
Danke euch allen. Dann muss eben so etwas ins Handbuch: "Nur eine der Netzwerkbuchsen funktioniert, probieren Sie bitte aus, welche". Ein Ausrede hätte ich: wenn alle funktionieren sollen, gibt es für den Benutzer immer nur eth0, aber der Kernel hatte die ursprünglich z.B. eth2 genannt. Das wäre ja viel zu verwirrend. Die Staubschutzstopsel helfen auch nicht, weil zunächst alle Buchsen verstopft sein sollten. Wer Netzwerk per Kabel braucht, wirft einen Stopsel weg.
:
Bearbeitet durch User
Bauform B. schrieb: > Dann muss eben so etwas ins Handbuch: "Nur eine der > Netzwerkbuchsen funktioniert, probieren Sie bitte aus, welche". Das klingt wirr. Bei bislang jedem Gerät mit mehreren NICs, das mir untergekommen ist, ist die Zuordnung eindeutig. Vielleicht liegt das Problem ja doch eher ganz woanders?
Harald K. schrieb: > Bei bislang jedem Gerät mit mehreren NICs, das mir > untergekommen ist, ist die Zuordnung eindeutig. Davon gehe ich auch aus, sonst wird's noch chaotischer. Aber ganz einfach: ich benutze nur eth0 und das ist immer dieselbe Buchse. Aber woher soll der Benutzer wissen, welche das ist?
Bauform B. schrieb: > Aber woher soll der Benutzer wissen, welche das ist? Meist steht an den Ports eine Kennung dran, etwa eine Nummer. Und wenn das Device-Mapping nicht jedes Mal neu würfelt, bleibt eth0 auf Port Nummer 1 oder so. Immerhin schaffen es meisten Autofahrer auch ohne Sitzverschiebeautomatik, bereits beim ersten Versuch die richtige Tür zu finden. Und sogar links und rechts können viele Menschen unterscheiden. Ich habe freilich einen Server, dessen Linux zumindest früher die Reihenfolge mehrerer Disks tatsächlich frei auswürfelte, weil die Erkennung über die verschiedenen Adapterwege parallel erfolgte und es damit auf die Reaktionszeit ankam. Analog eine andere Kiste, deren 2 TV-Adapter bei jedem Systemstart vertauscht werden.
:
Bearbeitet durch User
(prx) A. K. schrieb: > sogar links und rechts können viele Menschen unterscheiden. Naja... da würde ich mich eher auf "nimm die neben der Monitorbuchse" verlassen ;)
Bauform B. schrieb: > Ich brauche den Namen > z.B. für ssh mit Link Local Adressen. Dein Szenario ist also in etwa folgendes: ein beliebiger Nutzer soll Dein Gerät in sein Netzwerk hängen und dan soll das Gerät dort SSH per link-local Adresse machen? ip -6 addr Sollte Dir jedenfalls alle Interfaces liefern, auf denen IPv6 tatsächlich läuft. Gerade auf einem Raspi getestet, da kam ohne angeschlossenes Kabel-Ethernet nur wlan0; sollte also bei mehreren RJ45 Buchsen auch nur genau die liefern, an denen ein Kabel (mit Gegenstelle) hängt. Wenn da mehr als genau eines (abgesehen vom loopback) rauskommt, dann kannst Du ohnehin nur reihum probieren oder eine Fehlermeldung schmeißen, weil Dein Gerät ja nicht wie gedacht verwendet wird.
Michi S. schrieb: > Dein Szenario ist also in etwa folgendes: ein beliebiger Nutzer soll > Dein Gerät in sein Netzwerk hängen und dan soll das Gerät dort SSH per > link-local Adresse machen? Ja genau so, und nicht nur SSH, auch NTP funktioniert so, aber man muss eben das Interface angeben. > ip -6 addr > Sollte Dir jedenfalls alle Interfaces liefern, auf denen IPv6 > tatsächlich läuft. Und bei denen sieht man dann unter /sys/class/net/*/carrier wo ein Kabel steckt. Das sieht gut aus. Man könnte auch bei "ip -6 addr" nach "NO-CARRIER" suchen. Allerdings: Steht der Name immer in der ersten Zeile zwischen den ersten beiden ':'? Textausgabe, die für Benutzer gedacht ist, kann sich doch jederzeit ändern. Seit den code of conduct Geschichten rechne ich ja mit Sachen wie: "NO" ist zu negativ, der Leser könnte Depressionen bekommen ;)
Nachdem ich mir den Thread zwei mal durchgelesen habe verstehe ich das ganze Problem immer noch nicht. Für mich klingt es so, als ob durch eine Bastelei - von der wir nichts wissen - es plötzlich ganz wichtig ist wie die NICs heißen. Ist es aber für einen normalen Benutzer nicht, und es wird doch schon im Ausgangsposting von einem normalen Benutzer geredet. Nicht von einem Benutzer der den Host zum Routing oder noch wilderen Dingen braucht. Also, DHCP Client auf alle NICs starten. Fertig ist das Setup für den normalen Benutzer. Dann passiert folgendes: * Kabel wird in irgend eines Schnittstelle reingesteckt * DHCP für diese Schnittstelle ist erfolgreich ** NIC und damit die Kiste hat eine IP-Adresse und Maske ** Routing-Tabelle wird automatisch mit den DHCP-Infos angepasst (next hop ...) ** Resolver wird automatisch mit den DHCP-Infos angepasst (DNS Server) ** Time-Server und was immer sonst noch so in den DHCP-Daten steht und vom jeweiligen Client unterstützt wird, wird automatisch angepasst -> Kiste ist im Netz Also zumindest wenn man sich sein aktuelles Linux für einen *normalen Benutzer* nicht kaputt konfiguriert hat. Man kann sich auch wirklich Probleme herbeireden oder - durch eine andere Fehlkonfiguration, die uns nicht verraten wird - schaffen wo eigentlich keine sind.
Hannes J. schrieb: > DHCP Client auf alle NICs starten. Will er aber ausdrücklich nicht müssen. Des Menschen Wille ist sein Himmelreich.
:
Bearbeitet durch User
Hannes J. schrieb: > ...es plötzlich ganz wichtig ist wie die NICs heißen. > Also zumindest wenn man sich sein aktuelles Linux für einen *normalen > Benutzer* nicht kaputt konfiguriert hat. Eher im Gegenteil, ich möchte so wenig wie möglich an der Debian Standard-Installation ändern. Allerdings soll mein Programm in ganz unterschiedlichen Netzwerkumgebungen funktionieren, über meine "Benutzeroberfläche" konfigurierbar, DHCP oder feste Adresse, Gateway oder nicht, oder... Auch ganz ohne Konfiguration funktioniert NTP über Link Local Adressen, das ist sehr angenehm, aber dafür brauche ich die Namen. Testen kann ich jetzt nicht viel. Zum Beispiel, weil mein einziger PC mit 2 NICs nicht mehr bootet und der Ersatz ist am Donnerstag 04:19 "in der Region des Empfängers angekommen". Übrigens, danke für die Erinnerung, dass ich DHL anrufen sollte ;)
Bauform B. schrieb: > Ideal wäre, wenn ich das jeweils aktive > Interface in "lan" oder "eth0" umbenennen könnte. Ich brauche den Namen > z.B. für ssh mit Link Local Adressen. Ich denke du brauchst eher ein Nameserver/hosts Datei Einträge, welche den SSH Server unter einen Namen statt einer IP bekannt machen, deine Idee halte ich für Bescheiden, was ist zum Beispiel, wenn du 2 aktive Netzwerke gleichzeitig hast? Aber wenn du es unbedingt willst, Systemd/udev vergibt seit v197 vorhersehbare Netzwerknamen des Schema en* , der Stern wird mit dem Bus und Slot substituiert an welchen das Interface angeschlossen ist. Zum Beispiel enp1s0. Natürlich kannst du auch für Debian deine eigenen udev Regel schreiben, um so andere Namen zu vergeben. Ein Netzwerkmanager stört dann aber eher. Alternativ könntest du auch mit einer Bridge alle Netzwerkkarten im Bonding zu einer virtuellen Karte zusammenfassen. So was wird zum Beispiel von Openwrt gemacht, um alle LAN Ports als Switch zu bedienen.
Oliver schrieb: > Bauform B. schrieb: >> Ideal wäre, wenn ich das jeweils aktive >> Interface in "lan" oder "eth0" umbenennen könnte. Ich brauche den Namen >> z.B. für ssh mit Link Local Adressen. > > Ich denke du brauchst eher ein Nameserver/hosts Datei Einträge, welche > den SSH Server unter einen Namen statt einer IP bekannt machen, Das nützt garnichts, an der Stelle / zu der Zeit gibt es kein DNS, alles passiert eine Schicht tiefer. > deine Idee halte ich für Bescheiden, was ist zum Beispiel, wenn du > 2 aktive Netzwerke gleichzeitig hast? Das ist in der Anwendung nicht vorgesehen, hoffentlich bleibt das so. Aber gerade dann brauche ich den Namen wirklich. Woher soll der Kernel sonst wissen, welches Kabel ich benutzen will?. Ohne Konfiguration gibt es ja keine Routing Tabelle. Mit nur einem Interface könnte man ihn theoretisch weglassen; dafür ist jetzt die Syntax einheitlich. > Aber wenn du es unbedingt willst, Systemd/udev vergibt seit v197 > vorhersehbare Netzwerknamen des Schema en* , der Stern wird mit dem Bus > und Slot substituiert an welchen das Interface angeschlossen ist. Sehr witzig, "vorhersehbar" sind die Namen wirklich nicht. Erstens hat jeder PC andere Hardware, wenigstens hängt der Chip an einem anderen Bus. Zweitens haben sich die Regeln, wie die Namen gebildet werden, mehrmals geändert. Warum sollten die in Zukunft stabil bleiben? Drittens können sich die Namen mit einem BIOS-Update ändern. Oder wenn auf einem PC nachträglich eine zweite SSD eingebaut wird :) https://lists.debian.org/debian-user/2022/03/msg01016.html https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable Die ganze Automatik ist auch sehr benutzerfreundlich ;)
1 | How to migrate to this scheme on upgraded systems |
2 | It's advisable to do this as a separate migration in its own right, |
3 | not as part of a general distribution upgrade. However, if your PC |
4 | only has one network interface and not much is at stake you can try: |
5 | Strategy A |
6 | wait until udev breaks your networking... |
https://wiki.debian.org/NetworkInterfaceNames > Natürlich kannst du auch für Debian deine eigenen udev Regel schreiben, > um so andere Namen zu vergeben. Ein Netzwerkmanager stört dann aber > eher. Siehe oben. Die Regeln, wie man Regeln schreibt, haben sich auch geändert, wenigstens das Verzeichnis. Auch die Regeln, wie man die ganze Automatik abschaltet, haben sich geändert. Das wird natürlich nie wieder vorkommen ;) Ein Netzwerkmanager stört auch, selbst der dhcpcd kann stören, wenn er eine MAC-Adresse ändert. Aber das eigentliche Problem ist systemd-udev. Natürlich gibt es Rechner, wo man wegen der Hardware stabile Namen braucht. Die sind deshalb "vorhersehbar", weil sie der Admin festlegt. Das funktionierte schon, bevor jemand von udev geträumt hat. Und es war extrem simple, man musste nicht einmal den alten Namen kennen (siehe nameif(1)). > Alternativ könntest du auch mit einer Bridge alle Netzwerkkarten im > Bonding zu einer virtuellen Karte zusammenfassen. So was wird zum > Beispiel von Openwrt gemacht, um alle LAN Ports als Switch zu bedienen. OK, das könnte wirklich funktionieren.
:
Bearbeitet durch User
Bauform B. schrieb: > Es geht eher um die umgekehrte Richtung und um den Zustand, wenn es > (noch) keine "normale" Adresse gibt. Ein besseres Beispiel: rdate kann > auch per Link Local Adresse die Uhr stellen, braucht aber z.B. "%eth0" > hinter der Adresse. Wenn der Name bekannt und fest ist, kann man rdate > einfach in einem Script benutzen. Dann kann das Script ja auch herausfinden, welches Interface "up" ist.
Bauform B. schrieb: > Testen kann ich jetzt nicht viel. Zum Beispiel, weil mein einziger PC > mit 2 NICs nicht mehr bootet und der Ersatz ist am Donnerstag 04:19 "in > der Region des Empfängers angekommen". Übrigens, danke für die > Erinnerung, dass ich DHL anrufen sollte ;) Ich habe fuer solche Test-Aufbauen eine kleine Maschine mit alten Platten, einen Hypervisor (Proxmox weil ich faul bin) und habe eben eine Debian12.5 mit vier Ethernet-Interfaces angelegt. Es fragt schoen ab welches Interface das erste fuer die Installation sein soll. Wenn das ein wirkliches Problem ist (und nicht nur ein Hoax oder Troll-Versuch) dann waere halt der Weg die Hardware zu verkaufen (vulgo ein System oder gar ein System-Produkt und nicht ein Programm [oder App]). Leben ist das viel einfacher. Und wenn solche Probleme fuer Dich schon ein Problem ist: Viel Spass mit den Endverbrauchern ("Das FAX geht nicht!" "Einschalten hilft!"). Und richtig viel Spass bei verschiedenen Desktoepfen (Gnome, KDE und wie sie immer heissen). Aber: Wenn der Nutzer dann eine nicht unterstuetzte Konfiguration einsetzt, muss der Nutzer was fuer BSP bringen (https://www.youtube.com/watch?v=7Df3vRcoA50) Hier eine Ausgabe von "ip a" bei einer Maschine mit vier Ethernet-Interfaces, eines nur angeklemmt. Das liesse sich sehr leicht parsen.
1 | tom@4eth:~$ ip a |
2 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 |
3 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 |
4 | inet 127.0.0.1/8 scope host lo |
5 | valid_lft forever preferred_lft forever |
6 | inet6 ::1/128 scope host noprefixroute |
7 | valid_lft forever preferred_lft forever |
8 | 2: ens18: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 |
9 | link/ether xx:xx:11:8d:ba:c4 brd ff:ff:ff:ff:ff:ff |
10 | altname enp0s18 |
11 | 3: ens19: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 |
12 | link/ether xx:xx:11:14:fd:a9 brd ff:ff:ff:ff:ff:ff |
13 | altname enp0s19 |
14 | 4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 |
15 | link/ether xx:xx:11:f6:54:40 brd ff:ff:ff:ff:ff:ff |
16 | altname enp0s20 |
17 | inet 111.222.333.444/24 brd 111.222.333.444 scope global dynamic ens20 |
18 | valid_lft 86221sec preferred_lft 86221sec |
19 | inet6 2003:ea:xxxx:xxxx:xxxx:xxxx:xxxx:5440/64 scope global dynamic mngtmpaddr |
20 | valid_lft 7022sec preferred_lft 1112sec |
21 | inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link |
22 | valid_lft forever preferred_lft forever |
23 | 5: ens21: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 |
24 | link/ether xx:xx:11:fc:ca:9e brd ff:ff:ff:ff:ff:ff |
25 | altname enp0s21 |
Bauform B. schrieb: > Das nützt garnichts, an der Stelle / zu der Zeit gibt es kein DNS, alles > passiert eine Schicht tiefer. Dann versuch es halt mit mDNS oder Link-Local Multicast Name Resolution. Thomas W. schrieb: > Hier eine Ausgabe von "ip a" bei einer Maschine mit vier > Ethernet-Interfaces, eines nur angeklemmt. Das liesse sich sehr leicht > parsen. es geht noch leichter wenn das ip-Kommando hinreichend neu ist, dann hat es schon den "-j[son]" Parameter und man kann die Informationen aus einen JSON Objekt auslesen.
Bauform B. schrieb: > Guten Morgen, > > Der normale Benutzer hat kaum mehr als eine Fritzbox und ein > Netzwerkkabel, aber viele PCs haben 2 oder mehr Netzwerkbuchsen. Es > sollte aber egal sein, wo Kabel steckt, ungefähr wie bei USB. Kann man > dafür ein Script oder Programm bauen? Konfiguriere eine Bridge über alle Interfaces.
Oliver schrieb: > es geht noch leichter wenn das ip-Kommando hinreichend neu ist, dann hat > es schon den "-j[son]" Parameter und man kann die Informationen aus > einen JSON Objekt auslesen. Eigentlich lese ich man pages, aber den kannte ich nicht, danke! Und mega cool: -j -p[retty], endlich Menschen-lesbares json :) Leider finde ich auch da keinen Hinwies, ob es WLAN oder Kabel ist. Aber egal, "dmesg | grep eth" macht das und liefert auch gleich die echte Hardware-MAC-Adresse.
Bauform B. schrieb: > endlich Menschen-lesbares json :) Das Programm jq(1) kann nicht nur lesbares JSON mit und ohne Farbe, sondern noch viel mehr. Für YAML und XML gibt es zudem yq(1) und xq(1). Warum Du nicht einfach den NetworkManager nehmen willst, hat sich mir auch nach mehrmaliger Lektüre des Threads leider nicht erschlossen.
Ein T. schrieb: > den NetworkManager es gibt nur einen? Geh' weg, von dem hab' ich so viel schlechtes gelesen, der ist nicht einmal einen Versuch wert. Es gibt auf dem Rechner keine Gnome o.ä., der muss einfach nur funktionieren - idealerweise auch noch nach einem Update. Aber vielen Dank für den jq xq Tipp!
Bauform B. schrieb: > Ein T. schrieb: >> den NetworkManager > > es gibt nur einen? Ja, diesen [1]. [1] https://networkmanager.dev/ > Geh' weg, von dem hab' ich so viel schlechtes > gelesen, der ist nicht einmal einen Versuch wert. Ich hab' auch schon viel Schlechtes über den gelesen. Das meiste davon kam von Leuten, die entweder das Thema Netzwerk nicht verstanden hatten oder die keine Dokumentation lesen wollten. > Es gibt auf dem > Rechner keine Gnome o.ä., der muss einfach nur funktionieren - > idealerweise auch noch nach einem Update. Der NetworkManager funktioniert bei mir seit Jahren auf etlichen Rechnern wunderbar und automatisch, über Updates hinweg, und manuelle Eingriffe sind dermaßen selten nötig, daß ich den letzten schon wieder vergessen habe. Es gibt einen Kommandozeilenclient namens nmcli(1), im KDE ist "plasma-nm" ein Frontend in die Systemeinstellungen ("systemsettings") integriert. Nebenbei: der NetworkManager ist Open Source Software und kann nicht nur all die Dinge, die Du Dir wünschst, sondern noch viel mehr. Wenn Du trotzdem unbedingt Deine eigene Software entwickeln möchtest, könntest Du natürlich einfach in den Quellen des NetworkManager abschauen, wie er das macht. > Aber vielen Dank für den jq xq Tipp! Gerne.
Ein T. schrieb: > Es gibt einen Kommandozeilenclient namens nmcli(1) Und nmtui für Konfiguration per Text-Formular, wenn keine GUI vorhanden.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ein T. schrieb: >> Es gibt einen Kommandozeilenclient namens nmcli(1) > > Und nmtui für Konfiguration per Text-Formular, wenn keine GUI vorhanden. OK, Gnome war eine schlechte Ausrede ;) Nun ist es allerdings so, dass mein "Problem" überhaupt erst durch solche Tools verursacht wird, in diesem Fall udevd. Ohne den hätte ich immer, auf jedem PC, und vom Start weg ein eth0. Mit mehr Tools gibt es mehr Fehlerquellen und ich muss mehr lernen. Wie es unten drunter funktioniert, muss ich ja trotzdem verstehen. Generell wird alles zerbrechlicher, je weiter man sich von den Kernel-Schnittstellen entfernt. Ein T. schrieb: > Wenn Du trotzdem unbedingt Deine eigene Software entwickeln möchtest, > könntest Du natürlich einfach in den Quellen des NetworkManager > abschauen, wie er das macht. Ja, von schlechten Vorbildern kann man auch lernen ;) Eine kleine Zusammenfassung: 1.) unberechenbare Namen wie enp7s17 müssen in eth0 umbenannt werden 2.) bei der Gelegenheit könnte man alle RJ-45 gleichberechtigt machen Schon in der allerersten Antwort hat Harald mir 2.) verboten, also erledigt. Das Umbenennen selbst geht so: man sucht mit klogctl(2) nach "eth" und findet dabei auch die MAC-Adresse und meistens(?) auch den neuen Namen. Die Adresse sucht man in "/sys/class/net/*/address" und findet so den aktuell gültigen Namen. Damit geht dann
1 | ip link set enxxx down |
2 | ip link set enxxx name eth0 |
3 | ip link set eth0 up |
Der dhcpcd vergibt u.U. eine zufällige MAC, dann findet man die (echte) Adresse so nicht. Falls man aber den neuen Namen im logbuffer gefunden hat, versucht man es damit. Wenn das auch nicht klappt: "Sorry, no eth0" ;) An der Stelle könnte man noch basteln.
Bauform B. schrieb: > Mit mehr Tools gibt es mehr Fehlerquellen und ich muss mehr lernen. Wenn nmtui aufwändig lernen musst, was macht du dann erst in Windows? Einen 3-Tage-Kurs? :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Bauform B. schrieb: >> Mit mehr Tools gibt es mehr Fehlerquellen und ich muss mehr lernen. > > Wenn nmtui aufwändig lernen musst, was macht du dann erst in Windows? > Einen 3-Tage-Kurs? :) Keine Chance, Windows und ich sind nicht kompatibel. Aber im Nachbardorf gibt es ein Reparatur-Cafe, da kann ich fragen. Gerade am Freitag war ich mit einem USB-Stick da und wollte wissen, ob Windows den lesen kann. Aber die Feiglinge haben sich strikt geweigert :) Vor ein paar Jahren hab' ich einen PC mit vorinstalliertem Windows gekauft. Die Installation war aber nur halb fertig und ich hätte irgendwas eingeben müssen -- keine Chance. Den müsste ich jetzt direkt mal einschalten, weil, hier gibt's ja gerade einen Thread über SSDs, die jahrelang keinen Strom bekommen.
Bauform B. schrieb: > Ein T. schrieb: >> Wenn Du trotzdem unbedingt Deine eigene Software entwickeln möchtest, >> könntest Du natürlich einfach in den Quellen des NetworkManager >> abschauen, wie er das macht. > > Ja, von schlechten Vorbildern kann man auch lernen ;) Abgesehen davon, daß das Ding auf etlichen mir sehr bekannten Maschinen prima funktioniert und ich es deswegen nicht für ein schlechtes Vorbild halte, mußt Du doch nur herausfinden, wie und woher es genau jene Informationen bezieht, die Du auch für Deinen Eigenbau brauchst. > Eine kleine Zusammenfassung: > 1.) unberechenbare Namen wie enp7s17 müssen in eth0 umbenannt werden In neueren Versionen mußt Du das Interface nicht einmal umbenennen, sondern kannst ihm einen zusätzlichen Namen geben, IIRC funktioniert das mit
1 | |
2 | ip link property add dev <device> altname <alias> |
Eine andere Alternative könnte es sein, Deine Ethernet-Geräte mittels Bonding in ein logisches Gerät zu aggregieren. Dann sollte es egal sein, in welchen Ethrnet-Port Dein User sein Netzwerkkabel stopft. HTH.
Beide Ideen finde ich eigentlich sehr nett, aber wenn das Interface mal nicht umbenannt wurde, ist ein alias "eth0" auch verwirrend, genau wie "br0", wenn es nur einen Port gibt. Irgendwas ist immer... Apropos Staubschutz: gibt es auch abschließbar :) https://www.reichelt.de/port-schloss-rj45-12-stueck-pink-sk-nl03p1pk-p363189.html?&nbc=1
:
Bearbeitet durch User
Bauform B. schrieb: > Beide Ideen finde ich eigentlich sehr nett, aber wenn das Interface mal > nicht umbenannt wurde, ist ein alias "eth0" auch verwirrend, genau wie > "br0", wenn es nur einen Port gibt. Irgendwas ist immer... Eine Bridge muss auch nicht den Namen "br0" da geht auch "Rumms47" als Name. Und eine Bridge ist auch am einfachsten wenn man VMs auf den Kisten hat. BTW: Hast du eigentlich mal gecheckt ob eine Bridge deinen Vorstellungen am nächsten kommt? Solange Spanning-tree läuft kann man damit auch Redundanz bekommen.
G. K. schrieb: > Solange Spanning-tree läuft Eher nicht, denn Bauform B. schrieb: > Der normale Benutzer hat kaum mehr als eine Fritzbox
(prx) A. K. schrieb: > G. K. schrieb: >> Solange Spanning-tree läuft > > Eher nicht, denn > > Bauform B. schrieb: >> Der normale Benutzer hat kaum mehr als eine Fritzbox Das ist ziemlich egal weil switche ohne SPT die SPT-Pakete forwarden. Merke: Nicht jeder switch muss SPT beherrschen damit SPT funktioniert, natürlich nicht für jede Topologie, aber ein einziger Plaste Router in der Topologie wird da keine Probleme machen.
:
Bearbeitet durch User
Bauform B. schrieb: > Bei der Debian-Installation wird es festgelegt vielleicht ist da nmcli eine Hilfe.. damit habe ich einen vertauschten adapter umbenannt wenn ich mich richtig entsinne. Ich habe Dual Wifi, es wurde immer der richtige Adapter ausgewählt, aber beim Boot umbenannt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.