Debian 10 bleibt bei der Migration zu /usr

[MSfree]

Wenn ich mir so die Berechtigungen in /sbin ansehe (hab ich bisher noch nie gemacht), kann man da als user ja praktisch alles ausführen

Ausführen kannst du vieles, das System verändern jedoch nicht.

Zwar kann ich mir z.B. mit

Code: Alles auswählen

ifconfig -a

auch als Benutzer die Netzwerkschnittstellen anzeigen lassen.

Code: Alles auswählen

ifconfig enp2s0 down

Darf ich aber nur als root.

So schlecht sind diese Systemprogramme also nicht, um zwischen eine Benutzer und root zu unterscheiden. Also keine Panik, dann brauchst du auch kein Face-Palm

[Radfahrer]

Es gilt auch hier:

Nur gucken, nicht anfassen!

[TomL]

Vielleicht hat er nur die net-tools nicht installiert?

Pass auf, dass TomL nicht vorbeischaut!

Also ich bekreuzige mich nicht, wenn jemand "net-tools" sagt und jetzt kommt der Kracher, es ist sogar heute noch unter Buster immer noch eines der ersten Pakete, welches beim Setup hier installiert wird. Leider kenn ich nämlich keine Alternative zu "netstat -tulpn". Also müssen die net-tools weiterhin und bis auf weiteres immer noch drauf auffen Rechner.

Nach dem Basic-Setup durch den Installer wird hier immer als erstes rsyslog, ntp, sudo, dhcpcd5 und der avahi-kram deinstalliert ... sofern sich davon irgendwas auf den Rechner geschlichen hat. Und als nächstes wird kontrolliert, wer sich auf welchen Ports weiterhin ums Zuhören bemüht.... und da wird dann auch rigoros aufgeräumt, bis die Liste leer ist. Und erst ab da beginnt mein eigentliches Rechner-Setup bis zum fertigen Desktop-Environment. Also wie gesagt, im Moment gehts wohl nicht ohne die net-tools.

Was das Paket noch so drin hat... und welche Alternative es gibt, sieht man ganz gut hier:
https://dougvitale.wordpress.com/2011/1 ... lacements/

[guennid]

[dufty2]

Leider kenn ich nämlich keine Alternative zu "netstat -tulpn".

Mmmh, also den Unterschied in der Ausgabe zwischen

Code: Alles auswählen

# netstat -tulpn

und

Code: Alles auswählen

# ss -tulpn

würd' ich jetzt mal als nicht so groß ansehen ...

[TomL]

[Mmmh, also den Unterschied in der Ausgabe zwischen

Der Unterschied liegt nicht in der Ausgabe, sondern darin diese Alternative zu kennen.... wie ich sagte... ich kannte das vorher nicht. Dieses ss sehe ich überhaupt jetzt zum ersten Mal. Gehört das zum Paket iproute-2 oder ist das was eigenes oder war das schon immer da oder ist das was ganz neues?

[JTH]

[Mmmh, also den Unterschied in der Ausgabe zwischen

Gehört das zum Paket iproute-2 oder ist das was eigenes oder war das schon immer da oder ist das was ganz neues?

Ja genau, das Tool gibt es dort seit frischen 15 Jahren

Wenn ich mich richtig erinnere, werden die net-tools schon lange quasi nicht mehr weiterentwickelt, passen teilweise nicht mehr zu „modernen“ Netzwerkszenarien, sind langsam, weil sie vieles „manuell“, statt über vorhandene, spezialisierte APIs machen, sind seit langem gegenüber iproute2-Werkzeugen nicht mehr empfohlen etc. Aber wie das so mit alten Gewohnheiten ist …

[TomL]

Wenn ich mich richtig erinnere, werden die net-tools schon lange quasi nicht mehr weiterentwickelt, passen teilweise nicht mehr zu „modernen“ Netzwerkszenarien

Ja, richtig, ich vermeide schon seit jessie, das Paket zu nutzen und verwende auschließlich die Programme aus iproute-2... nur die Alternative mit netstat kannte ich noch nicht. Das die net-tools deprecated ist, hatte ich vor Jahren hier schon mal gepostet: https://lists.debian.org/debian-devel/2 ... 00780.html

So lernt man immer wieder neu dazu...

[KP97]

Gehört das eigentlich noch zum Ursprungsthema?

[ThorstenS]

`lsof -ni` find ich idR ausreichend.

[novalix]

Eine bemerkenswerte Konsequenz aus der symbolischen Verlinkung auf Verzeichnisebene (im Gegensatz zu per Datei).

Auf einem Buster ohne usrmerge:

Code: Alles auswählen

root@tristam:~# file /usr/bin/which 
/usr/bin/which: symbolic link to /bin/which
root@tristam:~# file /bin/which 
/bin/which: POSIX shell script, ASCII text executable
root@tristam:~# ls -l /usr/bin/which
lrwxrwxrwx 1 root root 10 Nov  2  2016 /usr/bin/which -> /bin/which
root@tristam:~# ls -l /bin/which
-rwxr-xr-x 1 root root 946 Jan 21 22:12 /bin/which

Auf einem neu aufgestzten buster mit usrmerge:

Code: Alles auswählen

root@dabase:~# file /usr/bin/which 
/usr/bin/which: POSIX shell script, ASCII text executable
root@dabase:~# file /bin/which 
/bin/which: POSIX shell script, ASCII text executable
root@dabase:~# ls -l /usr/bin/which
-rwxr-xr-x 1 root root 946 Jan 21 22:12 /usr/bin/which
root@dabase:~# ls -l /bin/which
-rwxr-xr-x 1 root root 946 Jan 21 22:12 /bin/which

Vergleicht man also einfach nur auf der Dateiebene, dann erscheinen die Programme unter "/bin/" als normale physisch vorhandene Dateien, so wie sie es vor usrmerge ja auch gewesen sind.
Erst der Inode-Schalter von ls (oder stat) liefern einen Hinweis darauf, dass dem nicht so ist:

Code: Alles auswählen

root@dabase:~# ls -il /usr/bin/which
396365 -rwxr-xr-x 1 root root 946 Jan 21 22:12 /usr/bin/which
root@dabase:~# ls -il /bin/which
396365 -rwxr-xr-x 1 root root 946 Jan 21 22:12 /bin/which

Man muss also im Hinterkopf haben, dass das übergeordnete Verzeichnis in Gänze verlinkt ist.

Code: Alles auswählen

root@dabase:~# ls -l /bin
lrwxrwxrwx 1 root root 7 Feb 11 19:02 /bin -> usr/bin

rkhunter kennt sich z.B. mit usrmerge noch nicht so richtig aus und meldet eine Warnung darüber, dass "/usr/bin/which" eine reguläre Posix Shell Datei sei.
Unbedarfterweise könnte man bei der Analyse der Gegebenheiten auf Dateiebene jetzt zu dem Schluss kommen, dass man "/usr/bin/which" ruhig weghauen kann, um die Warnung zu umgehen. "/bin/which" ist ja vorhanden.

Holzauge sei wachsam.