ubuntuusers.de

Hallo,

tja... da habe ich seit gestern noch nicht zu Ende drüber nachgedacht 😉

Tendenziell: Archiv +1

Gruß, noisefloor

Hallo,

erst einmal vielen Dank für den schönen Guide! Hat mir super beim Aufsetzen meines frisch erstandenen Alix 2d13 geholfen.

Ein kleine Ergänzung würde ich dann aber doch gerne machen - und zwar zum Punkt "Netzwerk":

In der beispielhaften /etc/network/interfaces wird vom IF "eth0" ausgegangen. Nun hat etwas das sich "Predictable Network Interface Names" schimpft dazu geführt, dass Netzwerk-Schnittstellen zunehmend Bezeichner wie "enp0s3" erhalten.

So auch in meinem Fall (Ubuntu 16.04): Mit "eth0" als IF-Bezeichner in der /etc/network/interfaces passiert beim Boot dann Folgendes (Quelle: /var/log/syslog/):

1
2

Mar 21 14:37:42 xxx ifup[428]: Cannot find device "eth0"
Mar 21 14:37:42 xxx ifup[428]: Failed to bring up eth0.

Dem selben Log-File (alternativ auch: /var/log/kern.log) lassen sich allerdings die nachfolgenden Zeilen entnehmen:

1
2
3

Mar 21 14:37:39 xxx kernel: [    7.674296] via-rhine 0000:00:09.0 enp0s9: renamed from eth0
Mar 21 14:37:39 xxx kernel: [    7.724716] via-rhine 0000:00:0b.0 enp0s11: renamed from eth2
Mar 21 14:37:39 xxx kernel: [    7.761745] via-rhine 0000:00:0a.0 enp0s10: renamed from eth1

Um anderen Linux-Noobs das Debugging zu vereinfachen, könntest du eventuell einen entsprechenden Hinweis in den Guide aufnehmen.

Grüße

Hi!

Erstmal: Willkommen im Forum!

Können wir also aus deinem Post schließen, dass der Artikel im Prinzip so wie er ist, auch für 16.04 funktioniert? Hinweise auf 16.04 waren ja sowieso schon drin, ohne dass die getestet Box entsprechend aktualisiert worden ist...

Konkret musstest du also in /etc/network/interfaces überall enp0sX statt eth0 eintragen? Gibt es noch eine andere Möglichkeit, diese Namen herauszufinden, als im Nachhinein die /var/log/syslog/ zu durchforsten?

so long
hank

Heinrich_Schwietering schrieb:

Hi!

Erstmal: Willkommen im Forum!

Können wir also aus deinem Post schließen, dass der Artikel im Prinzip so wie er ist, auch für 16.04 funktioniert? Hinweise auf 16.04 waren ja sowieso schon drin, ohne dass die getestet Box entsprechend aktualisiert worden ist...

Konkret musstest du also in /etc/network/interfaces überall enp0sX statt eth0 eintragen? Gibt es noch eine andere Möglichkeit, diese Namen herauszufinden, als im Nachhinein die /var/log/syslog/ zu durchforsten?

so long
hank

Hi Hank,

und danke für das Willkommen-heißen.

Ich denke man kann festhalten, dass man unter Verwendung des richtigen Images (und der angegebenen 16.04 Packages) ein funktionierendes System aufbauen kann. Hier noch mehr "Proof":

1
2
3
4

admin@xxx:~$ uname -a
Linux xxx 4.4.0-non-pae #1 SMP Sun Feb 26 23:46:55 GMT 2017 i586 i586 i586 GNU/Linux
admin@xxx:~$ cat /etc/issue
Ubuntu 16.04 LTS \n \l

Die zweite Frage übersteigt dann leider auch schon meinen (zugegeben sehr kleinen) Linux-Horizont. Ich habe nach entsprechenden Quellen für die Benennung von Interfaces gesucht. Dabei bin ich über https://askubuntu.com/questions/628217/use-of-predictable-network-interface-names-with-alternate-kernels gestolpert. Dort werden mehrere Übeltäter benannt. Ich entnahm dem Thread jedenfalls, dass ich auf Kernel(-modul)ebene suchen muss - daher /var/log/kern.log.

Konkret musstest du also in /etc/network/interfaces überall enp0sX statt eth0 eintragen?

Korrekt.

Wo wir gerade dabei sind: Beim Versuch mich per SSH auf den Kasten zu schalten, bekam ich ständig "Permission denied"-Fehler. Nach kurzer Recherche wurde klar: root und sshd vertragen sich nicht ohne Weiteres, wie auch https://askubuntu.com/questions/497895/permission-denied-for-rootlocalhost-for-ssh-connection suggeriert. Allerdings habe ich am Ende gegen den root-User und für einen zweiten User "admin" entschieden (durch Anpassung der visudo bekommt auch dieser SU-Privilegien).

Grüße

Hi!

Und mit

grep enp0s /var/log/kern.log 

sollte man ja auch einigermaßen übersichtliche Angaben zu den verwendeten Namen bekommen.

k4iuw3 schrieb:

Wo wir gerade dabei sind: Beim Versuch mich per SSH auf den Kasten zu schalten, bekam ich ständig "Permission denied"-Fehler. Nach kurzer Recherche wurde klar: root und sshd vertragen sich nicht ohne Weiteres, wie auch https://askubuntu.com/questions/497895/permission-denied-for-rootlocalhost-for-ssh-connection suggeriert. Allerdings habe ich am Ende gegen den root-User und für einen zweiten User "admin" entschieden (durch Anpassung der visudo bekommt auch dieser SU-Privilegien).

Das wäre dann war für die "Probleme und Lösungen"-Sektion im Artikel.

so long
hank

Hi!

Hab einen Hinweis zu den Predictable-Namen eingebautt - so in Ordnung?

Bei der Installation-des-Basissystems ist nur die trusty-Version angegeben , läuft unter Xenial entsprechend?

Wo die Problemlösung hingehört,, kann ich nicht wirklich sagen, schau doch noch mal, wo das deiner Meinung nach am besten hinpassen würde.

so long
hank

Heinrich_Schwietering schrieb:

Hi!

Und mit

grep enp0s /var/log/kern.log 

sollte man ja auch einigermaßen übersichtliche Angaben zu den verwendeten Namen bekommen.

Das sollte funktionieren. Eventuell müsste man den Pattern nach dem man grept etwas anpassen. Im verantwortlichen Skript heißt es:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

* Predictable network interface device names based on:
*  - firmware/bios-provided index numbers for on-board devices
*  - firmware-provided pci-express hotplug slot index number
*  - physical/geographical location of the hardware
*  - the interface's MAC address
*
* http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
*
* Two character prefixes based on the type of interface:
*   en -- ethernet
*   sl -- serial line IP (slip)
*   wl -- wlan
*   ww -- wwan
*
* Type of names:
*   b<number>                             -- BCMA bus core number
*   ccw<name>                             -- CCW bus group name
*   o<index>[d<dev_port>]                 -- on-board device index number
*   s<slot>[f<function>][d<dev_port>]     -- hotplug slot index number
*   x<MAC>                                -- MAC address
*   [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]
*                                         -- PCI geographical location
*   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
*                                         -- USB port number chain

Je nach physischer Location des Netzwerkinterfaces könnte das gesuchte IF folglich auch anders benannt sein. (z.B. wlpxxx für WLAN-Karten auf PCI-Basis.)

k4iuw3 schrieb:

Wo wir gerade dabei sind: Beim Versuch mich per SSH auf den Kasten zu schalten, bekam ich ständig "Permission denied"-Fehler. Nach kurzer Recherche wurde klar: root und sshd vertragen sich nicht ohne Weiteres, wie auch https://askubuntu.com/questions/497895/permission-denied-for-rootlocalhost-for-ssh-connection suggeriert. Allerdings habe ich am Ende gegen den root-User und für einen zweiten User "admin" entschieden (durch Anpassung der visudo bekommt auch dieser SU-Privilegien).

Das wäre dann war für die "Probleme und Lösungen"-Sektion im Artikel.

Richtig.

so long
hank

Heinrich_Schwietering schrieb:

Hi!

Hab einen Hinweis zu den Predictable-Namen eingebautt - so in Ordnung?

Find ich gut, nur hier nochmal nachbessern: "durchgängig ei EIntrag". 👍 Eventuell noch den Hinweis bzgl. des grep Patterns aus meinem letzten Post verwursten.

Bei der Installation-des-Basissystems ist nur die trusty-Version angegeben , läuft unter Xenial entsprechend?

Läuft entsprechend lediglich das Kommando muss angepasst werden z.B.:

1

debootstrap --arch=i386 xenial /ubuntu_xenial_1604 http://archive.ubuntu.com/ubuntu/

Gut, und die sources.list sollte ebenfalls angepasst werden, um die richtige Repos anzuzapfen. Grundlegend ausreichend:

1
2
3
4
5
6
7
8
9

###### Ubuntu Main Repos
deb http://de.archive.ubuntu.com/ubuntu/ xenial main 
deb-src http://de.archive.ubuntu.com/ubuntu/ xenial main 

###### Ubuntu Update Repos
deb http://de.archive.ubuntu.com/ubuntu/ xenial-security main 
deb http://de.archive.ubuntu.com/ubuntu/ xenial-updates main 
deb-src http://de.archive.ubuntu.com/ubuntu/ xenial-security main 
deb-src http://de.archive.ubuntu.com/ubuntu/ xenial-updates main 

Bei der Lokalisierung habe ich statt dem angegebenen Kommando (Warum eigentlich das englisches Layout?) dpkg verwendet:

1

dpkg-reconfigure locales

Wo die Problemlösung hingehört,, kann ich nicht wirklich sagen, schau doch noch mal, wo das deiner Meinung nach am besten hinpassen würde.

Da mein Vorschlag sich ja direkt auf die SSH Verbindung bezieht würde eventuell ein kleiner Hinweis im entsprechenden Kapitel ausreichen. (a la: "Für die Benutzung des root-Nutzers, muss dies und das...")

Hi!

Wenn es auch andere Möglichkeiten der Umbenennung von eth0 gibt, wäre wohl die Suche nach ethX sinnvoller? Wo kommt genau kommt das von dir angeführte "verantwortliche Skript" her? Darauf könnte man dann auch direkt verweisen.

k4iuw3 schrieb:

Wo die Problemlösung hingehört,, kann ich nicht wirklich sagen, schau doch noch mal, wo das deiner Meinung nach am besten hinpassen würde.

Da mein Vorschlag sich ja direkt auf die SSH Verbindung bezieht würde eventuell ein kleiner Hinweis im entsprechenden Kapitel ausreichen. (a la: "Für die Benutzung des root-Nutzers, muss dies und das...")

Kannst du das bitte übernehmen? Bei dem "dies und das" muss ich nämlich leider passen 😉

so long
hank

Heinrich_Schwietering schrieb:

Hi!

Wenn es auch andere Möglichkeiten der Umbenennung von eth0 gibt, wäre wohl die Suche nach ethX sinnvoller? Wo kommt genau kommt das von dir angeführte "verantwortliche Skript" her? Darauf könnte man dann auch direkt verweisen.

Der Kernel spuckt Zeilen à la

1

enp0s9: renamed from eth0 

aus. Den Pattern müsste man entsprechend wählen ("renamed" / "eth" / "enp" / etc.).

Hier die "Wiki"-Seite zum Thema: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Und hier der Link zum eigentlichen Script: https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c

Eventuell könnte man auch direkt auf dem eigentlichen System nachsehen: systemd/src/udev/udev-builtin-net_id.c

k4iuw3 schrieb:

Wo die Problemlösung hingehört,, kann ich nicht wirklich sagen, schau doch noch mal, wo das deiner Meinung nach am besten hinpassen würde.

Da mein Vorschlag sich ja direkt auf die SSH Verbindung bezieht würde eventuell ein kleiner Hinweis im entsprechenden Kapitel ausreichen. (a la: "Für die Benutzung des root-Nutzers, muss dies und das...")

Kannst du das bitte übernehmen? Bei dem "dies und das" muss ich nämlich leider passen 😉

Ich habe leider keine Möglichkeit gefunden die Wiki-Seite direkt zu bearbeiten. Stattdessen habe ich hier einen kleinen Hinweis formuliert:

Hinweis:

Standardmäßig ist der SSH Remote Shell-Zugriff für den Benutzer root gesperrt. Jeglicher Versuch sich per root auf die Maschine zu schalten resultiert deshalb in

1	Permission denied, please try again.

Um die entsprechende Berechtigung zu erteilen muss in

1	/etc/ssh/sshd_config

folgende Anpassung vorgenommen werden:

1	PermitRootLogin prohibit-password

muss in

1	PermitRootLogin yes

geändert werden.

Anschließend muss mittels

1	sudo systemctl restart sshd

der SSH-Daemon neu gestartet werden. Danach kann mit dem Root-User per SSH eine Remote Shell geöffnet werden.

Im tatsächlichen Einsatz wäre es allerdings ratsam einen zweiten User mit eingeschränkten Privilegien anzulegen. Gute Gründe dafür gibt es hier: https://unix.stackexchange.com/a/82639

Hi!

k4iuw3 schrieb:

Ich habe leider keine Möglichkeit gefunden die Wiki-Seite direkt zu bearbeiten.

Hm? Im Artikel auf den Reiter "Bearbeiten" klicken, und dann öffnet sich ein Editor mit den Rohtext... Aber egal, inhaltlich ist der Hinweis wunderbar (soweit ich das beurteilen kann 😉), syntaxmäßig müsste eh etwas nachgearbeitet werden. Baue ich also ein, bei Erster Start sollte ja passend dafür sein. Wenn nicht, bitte genauer spezifizieren...

Stattdessen habe ich hier einen kleinen Hinweis formuliert:

Habe ihn als Grundlage für die Hinweisbox verwendet.

Ich hoffe, jetzt passt im Artikel alles.

Besten Dank, so long
hank

Hallo,

habe eine "fehlerhaft" Box ergänzt, weil im Artikel noch Upstart-Verzeichnisse erwähnt werden. Xenial nutzt aber systemd.

Was dann auch die Gründlichkeit der "getestet: Xenial" Markierung in Frage stellt.

Gruß, noisefloor

Hallo,

Xenial ist aus dem Getestet-Block raus. Der Artikel ist somit ungetestet.

LG
tuxifreund

Seit längerem ungetestet → archiviert.

Gruß, noisefloor