Raspbian bekommt keine statische IP über Ethernet

Hallo,

normalerweise laufen alle meine Netzwerkgeräte über eine statische IP, das soll jetzt auch bei meinem aktuellen Pi so sein. Ich habe die /etc/network/interfaces so eingerichtet wie andere Linux-Rechner auch, sie sieht so aus:

Quote

#source-directory /etc/network/interfaces.d

auto lo

iface lo inet loopback
iface eth0 inet static
address 192.168.10.34
netmask 255.255.255.0
gateway 192.168.10.1
dns-nameserver 192.168.10.1

allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Display More

Die IP *.34 gibt es nicht doppelt und sie liegt nicht im DHCP-Bereich meines Routers. In der Netzwerkübersicht des Routers taucht keine ältere IP *.34 auf. Dennoch erhält der Pi immer eine DHCP-IP. Ihc hatte versucht hier nur WLAN zu betreiben, aber der Pi schafft den Bluetooth- und WLAN-Stick nicht. Über WLAN klappte die statische IP (auch mit der *.34). Auch wenn ich eine andere IP beim Ethernet versuche, bekommt er immer eine per DHCP (immer die gleiche).

Was mach ich falsch? Nutzt Raspbian noch Netzwerkeinstellungen an anderer Stelle die hier dazwischenfunken? Die 1. Zeile ist standardmäßig nicht auskommentiert. Was sie macht weiß ich nicht. Ich hab es mit und ohne die Zeile versucht. Ich habe auch versucht DHCPCD zu deaktivieren, aber danach konnte ich gar keine SSH-Verbindung mehr erstellen und musste erst die Pi an den Monitor anschließen und den wieder einschalten. Laut hier (Lösung 2) https://www.elektronik-kompendium.de/sites/raspberry-pi/1912151.htm geht wohl auch statische IP über DHCPCD, das muss doch aber auch über die interfaces gehen - beim WLAN klappte es ja auch einmal.

Richard

Quote from Richard

Was mach ich falsch? Nutzt Raspbian noch Netzwerkeinstellungen an anderer Stelle die hier dazwischenfunken?

Möglicherweise..... wie sagt Duncan Mac L. noch "Es kann nur einen geben!". Wenn Du noch einen Network-Manager installiert hat, der imho bei einem stationären System eigentlich völlig über ist, wird der den Interessen-Konflikt mit der /etc/network/interfaces wohl gewinnen. Und soweit ich mich erinnere, ist Wicd im Desktop-Environment per default installiert. Also /etc/init.d/networking UND Wicd wird wohl nicht funktionieren.

Quote from adora

da noch keiner geantwortet hab mach ich das mal, obwohl ich diese dämliche netzconfig nicht benutze weil kein ich kein raspbian benutze.

Die braucht man auch unter raspian nicht.... die ist sowas von über......

Quote from adora

ja, steht 100fach so im inet, lt. einem beitrag vor ca. 2wochen ist das veraltet und man benutzt dafuer jetzt die dhcp-client config. empfhelung, hier im forum nach statische ip suchen, da stehst dann irgenwo genauer

Auch das würde ich nicht machen, sondern alles einfach über systemd-networkd konfigurieren..... und fertig isses.....

Quote from adora

genau das meinte ich, jeder sagt was anderes.

Ja, richtig, je nach Ära, in der die jeweiligen Kenntnisse erworben wurden. Das aktuelle Jessie setzt auf systemd und beinhaltet demgemäß mehrere Systemd-Dienste - unter anderem eben auch systemd-networkd.... und das funktioniert für die Netzwerk-Konfiguration eines statischen Computers geradezu perfekt, sowohl via eth als auch via wlan.

Quote from adora

die debian netzwerk config ist schrott.

Nein, isses nicht... ich vermute, Du weisst nicht wirklich tiefgehend, worüber Du sprichst... denn in Wirkllichkeit funktioniert die Debian-Netzwerk-Unterstützung perfekt. Das Problem ist halt, dass es bei Debian mit Jessie einen gravierenden Wechsel innerhalb des Systems gegeben hat, dem die Web-Dokus leider nicht schnell genug folgen konnten. Und darüber hinaus, dass es gleich 3 Alternativen zur Netzwerkkonfiguration beinhaltet/anbietet, eben die /etc/init.d/networking, den NWM übers Desktop-Environment und dann noch systemd-networkd. Wer dann auf alte Dokus "hereinfällt", hat entweder Pech gehabt oder er folgt entsprechenden Ratschlägen (z.B. in den div. Foren) und sucht dann in neuer Richtung.

@ ThomasL

Und was wäre jetzt für mich der einfachste Weg die statische IP einzurichten? Du hast die 3 Wege aufgezählt, da fehlt die /etc/network/interfaces aber. Wozu ist die dann noch da?

Quote from Richard

Und was wäre jetzt für mich der einfachste Weg die statische IP einzurichten? Du hast die 3 Wege aufgezählt, da fehlt die /etc/network/interfaces aber. Wozu ist die dann noch da?

Der einfachste Weg (und auch der richtige) ist der über systemd-networkd. Dazu musst Du Dir aber folgende Rahmenbedingungen bewusst machen:

1. Das ist primär geeignet für eine stationäre Netzwerkanbindung. Das heisst, für die wechselnden WISP eines Laptops empfiehlt sich dann doch eher ein NWM, wie z.B. wicd. Da es sich hier aber anscheinend um einen stationären PI handelt, ist das die perfekte Lösung.

2. Du darfst keine konkurrierenden Netzwerkeinstellungen bzw. -Daemon konfigurieren. Das heisst, wenn Du das Netzwerk über systemd-networkd konfigurierst, musst Du den NWM deaktivieren, ebenso wie /etc/init.d/networking.

BTW: Die von dir angefragte /etc/network/interfaces ist keine weitere Option, sondern die Konfiguration für /etc/init.d/networking. Und dieses Script ist ein Überbleibsel aus der Zeit sysvinit, welches nicht notwendig ist. Also, entweder einen NWM (bei mobilen Systemen) oder systemd-networkd (bei stationären Systemen)

Nur allein systemd-networkd zu enablen reicht nicht aus. Du benötigst dafür zusätzlich noch systemd-resolved, die in gleicher Manier enabled wird und in der Datei

/etc/systemd/resolved.conf

konfiguriert wird.

Dann, noch vor dem restart von resolved muss diese Conf noch gesymlinked werden:

[ -f /etc/resolv.conf ] && rm /etc/resolv.conf
ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Im gleichen Zuge würde ich auch noch ntp vom Rechner entfernen und stattdessen systemd-timesyncd (ebenfalls in gleicher Manier) enablen. timesyncd wird in dieser Datei

/etc/systemd/timesyncd.conf

konfiguriert. Bei mir hat sie diesen Inhalt:

[Time]
Servers=0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org iburst 3.de.pool.ntp.org

Merke dir als Nachschlagewerk die Seiten von
https://wiki.archlinux.org/index.php/systemd-networkd
und
https://wiki.ubuntuusers.de/Startseite/
die meiner Meinung nach wirklich umfassend und gut sind.

Und speziell zu systemd die Seiten von
https://www.freedesktop.org/software/systemd/man/
Automatisch zusammengefügt:

Quote from adora

aber immer treffe auch arogante debian-pseudo-experten die immer ziemlicheen Stuss von sich geben.

Deswegen überlasse ich jetzt Fachleuten wie Dir das Feld.... freundlich, höflich, über die Maßen kompetent, mit hoher Gesprächskultur.... ein echter Glücksfall .... also dann mal viel Erfolg.

Ich hab es jetzt wie hier https://www.elektronik-kompendium.de/sites/raspberry-pi/1912151.htm (Variante 2) beschrieben in der dhcpcd.cong gemacht. Läuft. Dennoch Danke.

Moin

Quote from DG8BR

Und nun dürft ihr mich verprügeln!!!

Nö, wozu soll das gut sein? Das ist nur das Verhalten von Dummköpfen, die es nicht gelernt haben, bei divergierenden Standpunkten trotzdem ein konstruktives Gespräch auf sachlicher Ebene zu führen. Ich ziehe es vor, mich sachlich mit einem Thema zu beschäftigen.... zumindest ich kann dabei immer mehr lernen, als bei anderem Gesprächsverlauf.

Quote from DG8BR

Raspbian Jessie ist zur Zeit auf einen Scheideweg zwischen sysinit und systemd. Kann sich aber noch nicht ganz entscheiden.

Da habe ich eine andere Sichtweise. Es gibt keinen Scheideweg. sysvinit ist Geschichte... mit anderen Worten "depricated". Und die Entscheidungen für das derzeitige und künftige Startsystem sind eindeutig und lauten "systemd". Das Problem ist hier m.M.n., dass es nicht geschafft wurde, alle unter sysvinit etablierten Startskripte dergestalt zu portieren, dass sie eben via systemd-service-units gestartet werden können und gleichzeitig den Ansprüchen der Parallelisierung beim Start gerecht werden Aus dem Grund war es notwendig, in systemd eine Rückwärtskompatibiltät zu sysvinit zu integrieren. Und zwar unter anderem, das für das alte update-rc.d beim Einrichten eines Startsscriptes durch systemd heute über einen Auto-Unit-Generator eine service-unit erzeugt wird. Das gleiche passiert ja auch für die fstab... auch dort generiert systemd jeweils mount-units. Soll heissen, systemd macht so weit ich das durchschaue, sowieso schon alles.... nur braucht es halt für den ganzen ollen Kram Adapter/Wrapper/WasWeissIch, ums ans Laufen zu bringen. Vermutlich wird sich der Anteil an speziellen Startscripten in der Zukunft ein wenig reduzieren, weil die meines Erachtens total überflüssig sind.
Ob es nun OpenVPN ist, oder Hostapd, oder varlog hier aus dem Forum, oder eigene Daemons oder Services, ganz egal, ich schreibe heute alles um auf systemd-service-units. Gerade (z.B.) bei OpenVPN ist der Vorteil der "Reduzierung" gravierend. Installiere mal OpenVPN und schau Dir an, was alles auf Deiner Platte landet. Bei mir ist es NUR NOCH das OpenVPN-Binary und eine Service-Unit... fertig.... und das aktuelle Binary selber lade ich zuvor von der Project-Seite als Source runter und kompiliere es mir passend zu meiner Architektur. Ebenso verhält es sich mit dem Netzwerk. Unter systemd sinds ein paar Zeilen und es läuft, egal für welches Interface. Wenn ich da an diesen komplizierten Wheezy-Mist denke, grauts mir noch heute.

Quote from DG8BR

Fakt ist, wenn man eine feste IP einstellen will, greift dhcpcd um Besten.

Nein, eben nicht. Wenn ich auf einem rein stationären System eine fest IP will, deinstalliere ich einfach DHCP-Client und trag die statische IP in eine systemd-networkd-Conf ein. Und wenn ich ein mobilen Rechner habe, trage ich die statische eth0 wie zuvor in die systemd-networkd-Conf ein und für die WISP-IP rufe ich bei Bedarf eben manuell den dhcp-Client auf. Ich habe mir dazu einen kleinen Bash-NWM geschrieben, der kein Daemon ist, der WISP scannen kann, verbundene WISP speichert und zur Auswahl anbietet, sich wie wpa_supplicant mit einem WISP verbinden kann und bei Bedarf einfach den dhcp-Client startet.

Quote from DG8BR

Eine Einstellung mit systemd muss mit vielen "fremden" Aufrufen und Einstellungen gehandelt werden.

Was meinst Du damit? Ich empfinde systemd als grandios einfach, wenn man es einmal verstanden hat. Das war meiner Meinung nach ein Riesenschritt nach vorne zum Guten hin. Über fremde Aufrufe und Einstellungen mache ich mir gar keine Gedanken, das funktioniert im Regelfall einfach. Die einzigen mir bekannten Probleme sind, dass diese alten Mist-sysvinit-Scripte oft nicht wirklich gut mit der Parallelisierung beim Start klarkommen. Unter sysvinit war ein Achten auf Abhängigkeiten nicht notwendig, unter systemd isses das sehr wohl. Das heisst, früher hat ein Script solange in einer ordentlichen Schlange am Eingang gestanden, bis ihm der Türsteher die Tür zum Einlass geöffnet hat. Eine falsche Reihenfolge war gar nicht möglich, wenn das Script "rein durfte", konnte es sich darauf verlassen, dass alle notwendigen anderen Scripte vorher schon eingelassen wurden. Systemd startet aber (gemäß der Before/After/Required/WantedBy-Statements) ansonsten alles gleichzeitig. Das heisst, Tür auf, wer nicht selber explizite Abhängigkeiten definiert hat kann gleichzeitig mit allen anderen rein. Und die Probleme entstehen zum Teil dadurch, dass die Scripte nicht selber prüfen und darauf warten, dass ihre Abhängigkeiten (z.B. das Netzwerk für ein Remote-Laufwerk) verfügbar ist .... google z.B. mal nach stopjobs und mount beim Shutdown. Die alten Scripte sind eine eindeutige Schwachstelle. Und da, wo ich kann, schmeiss ich die konsequent raus und erstelle mir service-units, die den Dienst oder Job direkt starten. Und immer genau ab dem Moment gehören Probleme der Vergangenheit an. BTW, an der Stelle muss ich aber auch gestehen, dass ich auf keinem unserer Systeme eine Standard-Installation nutze...... sondern überall eine eigene (sowas wie ne) Custom-Distri installiert habe. Ich habe mir das System (sowohl Debian als auch Raspian) so "zusammengeschraubt", dass es für mich derzeit (mit Blick auf Windows oder Apple) geradezu alternativlos ist. Eine Verbesserung zu Debian kann ich mir momentan kaum noch vorstellen

Quote from DG8BR

Dazu komm das man einiges aus der "alten" Welt löschen muss.

Man muss nicht, ich tue das nur überall dort, wo mir systemd eine bessere Alternative bietet, wie z.B. bei rsyslog, ntp oder eben "networking" beim Netzwerk.

Quote from DG8BR

Auf der anderen Seite ist eine Einstellung über /etc/network/interfaces auch nicht mehr sicher, weil man nicht weiss welche "neuen" Programme da schon reinspielen.

Ich halte das für absolut "depricated" und gehe davon aus, dass neue Programme da nicht mehr reinspielen. Betrachte einfach mal das übliche und in der Vergangenheit obligatorische Kommando ifconfig aus den Net-Tools... das ist heute bereits alt und nur als Entgegenkommen den Gewohnheiten der User den Distris noch beigelegt....eine Verwendung würde ich jedenfalls nicht mehr empfehlen.

Quote

Und nun dürft ihr mich verprügeln!!!

Wie schon gesagt: Nö! So bin ich nicht. Allerdings, wenn ich mir anschaue, wie manche Leute hier auftreten, dann denke ich mir, dass Dein Hinweis schon gewisse Erfahrungen/Kenntnisse aus der Vergangenheiut beinhaltet und vielleicht auch für eine gewisse Erwartungshaltung verantwortlich ist. Und auch ich denke mir immer öfter, dass es eh das Beste wäre, mich um anderer Leute Probleme überhaupt nicht mehr zu kümmern. Denn, viel Bock habe ich mittlerweile (aus gleichem Grund) dazu auch nicht mehr.....