Buster. Keine updates möglich

[geier22]

Es wird einfach ein Stück logischer und damit einsteigerfreundlicher in der Bedienung: ohne Loginshell: altes Environment wird beibehalten, Loginshell: Environment des Zielusers wird geladen.

Jetzt habe wir aber 2 Varianten des su - oder gar mehrere Hab noch nicht alles getestet.
SU: Offensichtlich noch die Bearbeitung von Dateien möglich aber keine Installation (bzw alles, was in /sbin steht)
SU -: Installieren, update und was in sbin steht.

Was ist da einfacher? Das ist total inkonsistent und Verwirrend.
Noch ein kleines Grimmick am Rande:

Code: Alles auswählen

hans@sparkyxfce:~$ su -
Passwort: 
root@sparkyxfce:~# synaptic
Unable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt

(synaptic:1846): Gtk-WARNING **: 18:32:09.520: cannot open display: 
root@sparkyxfce:~# Abgemeldet
hans@sparkyxfce:~$ su
Passwort: 
root@sparkyxfce:/home/hans# synaptic  :mrgreen: 
root@sparkyxfce:/home/hans# 

[DeletedUserReAsG]

Wozu ist su dann überhaupt noch da?

su ist mitnichten ausschließlich dazu da, Root zu werden und auf Programme unter /sbin zuzugreifen. Es gibt übrigens auch Distris, da sieht’s so aus:

Code: Alles auswählen

lrwxrwxrwx   1 root root    7  5. Jan 2018  sbin -> usr/bin

Manchmal möchte man halt schnell was als anderer User erledigen, dabei aber das Environment des aufrufenden Users zur Verfügung haben (Library-Paths beim Bauen, etc.) – das geht nun. Leute, die’s aus Bequemlichkeitsgründen auf die alte, unlogische Art benutzt haben, müssen sich nun halt etwas umgewöhnen. Paketbauer müssen sich halt auch auf die Änderung einstellen – bis Testing Stable wird, werden sie’s schon noch auf die Reihe bekommen, da kann man ziemlich sicher von ausgehen. Und Einsteigern wird das „neue“ Verhalten deutlich sinnvoller erscheinen, weil eben nachvollziehbar. So what?

Kleine Anmerkung am Rande:

Noch ein kleines Grimmick am Rande:
[…]

Ja, so soll’s auch nicht genutzt werden. Im Gegenteil: das würde ich als „veritable Sicherheitslücke“ durchgehen lassen, wenn es ohne Weiteres ginge – vielleicht ist’s ja sogar die, von der die schwarze Schachtel geschrieben hat. Er hat sich ja leider noch nicht weiter dazu geäußert. Zumindest unter X ist’s wohl nicht zu schwierig, als User auf die von Root gestarteten Fensterprogramme zuzugreifen, wenn die unter dem xserver des Users laufen.

[schwedenmann]

Hallo

Ist dieses Verhalten jetzt normal und gewollt

als user: synaptic verweigert den Start
su - : synaptic verweigert den Start
su : synaptic startet

selbes Verhalten bei gparted

mfg
schwedenmann

[DeletedUserReAsG]

Vermutlich nicht, und vermutlich wird’s noch angepasst. Dauert halt je nach Aufwand noch etwas.

[owl102]

Früher wurde bei "su" und "su -" PATH neu gesetzt, aktuell ist dies nur noch bei "su -" der Fall. Genauso wie bei CentOS/Fedora.

Da ist definitiv falsch.
Bei einfachen su wurde nie der Pfad neu gesetzt.

Nicht der Verzeichnispfad, sondern die Umgebungsvariable PATH.

Mein Debian Stable ist folgender Meinung:

Code: Alles auswählen

$ more /etc/debian_version
9.4
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
$ su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Wie man sieht, setzt dort "su" PATH neu. Das macht Fedora/CentOS nicht und Debian Testing nun auch nicht mehr. *Das* ist die Änderung, die bei Debian Testing vollzogen wurde.

Ich muss, um etwas zu installieren, mich mit su - einloggen und lande erstmal im Root- Verzeichnis.
um mich dann wieder hoch zu hangeln oder vorher den Dateipfad aus dem Dateimanager zu kopieren. Was ein Irrsinn

Dann ändere das doch.

So unterschiedlich wird das Gehandhabt:

Aber nur, weil bei Fedora /sbin (seit 10 Jahren) per default im User-PATH steht, und bei Debian eben nicht, AFAIK noch nie.

[owl102]

Ist dieses Verhalten jetzt normal und gewollt?

als user: synaptic verweigert den Start
su - : synaptic verweigert den Start
su : synaptic startet

Ja, aktuell ist das normal. Aber daran dürfte sich eigentlich nichts geändert haben, bei Debian Stable müsste sich das genauso verhalten.

Wenn synaptic und gparted irgendwann mal an Wayland angepasst sein werden, wird sowieso folgendes (auch unter X) normal und gewollt sein:

als user: synaptic startet
su - : synaptic verweigert den Start
su : synaptic verweigert den Start

[geier22]

Ich muss, um etwas zu installieren, mich mit su - einloggen und lande erstmal im Root- Verzeichnis.
um mich dann wieder hoch zu hangeln oder vorher den Dateipfad aus dem Dateimanager zu kopieren. Was ein Irrsinn

Dann ändere das doch.

Kannst du mir mal einen Tipp geben wie ?

Nicht der Verzeichnispfad, sondern die Umgebungsvariable PATH.

Das ist mir auch klar. Trotzdem landet mein Terminal in /root wo kein Mensch hin will

Es scheint doch aber so zu sein, dass Debian hier seinen eigenen Weg geht, und es nicht so ist, dass alle es auch so machen.
su - gab es ja auch unter Debian schon immer.

[owl102]

Dann ändere das doch.

Kannst du mir mal einen Tipp geben wie ?

Du könntest die sbin-Verzeichnisse deinem PATH hinzufügen, z.B. in $HOME/.profile

Oder du machst dies für alle Benutzer. In /etc/profile ist zu finden:

Code: Alles auswählen

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

Dort könntest du in dem PATH für Benutzer die drei sbin-Verzeichnisse hinzufügen, etwa:

Code: Alles auswählen

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin/:/usr/local/games:/usr/games"
fi
export PATH

Dann hättest du hier zumindest mit dem Verhalten von CentOS/Fedora gleichgezogen.

Alternativ könnte man auch Debian sagen, man möchte gerne das alte Verhalten von "su" behalten, indem man /etc/login.defs editert: viewtopic.php?p=1180632#p1180632

Trotzdem landet mein Terminal in /root wo kein Mensch hin will

"su -" bedeutet ja quasi: Ich will meine Umgebung so, als hätte ich mich als root eingeloggt. Dementsprechend ist es logisch, daß man (wie nach dem Login) in seinem Home-Verzeichnis, also /root, landet.

Es scheint doch aber so zu sein, dass Debian hier seinen eigenen Weg geht, und es nicht so ist, dass alle es auch so machen.

Code: Alles auswählen

[owl102@fedora ~]$ pwd
/home/owl102
[owl102@fedora ~]$ su -
Passwort: 
Letzte Anmeldung: Freitag, den 17. August 2018, 07:45:50 CEST auf pts/0
[root@fedora ~]# pwd
/root

Interessant wäre mal eine Übersicht: Welche Distributionen setzen bei "su" PATH neu und welche nicht? Bei welchen Distributionen sind die sbin-Verzeichnisse mit im PATH eines normalen Benutzers? Mein Horizont ist mit CentOS/Fedora/Debian recht eingeschränkt.

Auf jeden Fall begrüsse ich die aktuelle Änderung bei Debian. Erstens ist es logischer/konsequenter: Warum wurden vorher bei "su" alle Umgebungsvariablen beibehalten, aber PATH nicht, warum diese Sonderlocke für PATH? Nun werden alle beibehalten. Und zweitens begrüße ich es sowieso, wenn sich Linux-Distributionen in ihrem Verhalten annähern.

[michaa7]

nichts gegen das angleichen von distributionen und ein konvergieren zu einen standard.

Aber Nein, Nein, Nein zu user-konfigurationsgefrickel. Bei zukünftiger fehlersuche wird es sonst notwendig archeologische forschungsunternehmungen zu starten, weil sich pathkonfigurationen von user 1 von denen von user2 unterscheiden und unterscheidliche auswirkungen haben. Meiner ansicht nach ist eine distri genau dazu da, dies zumindest für seine user eindeutig zu machen, und zwar OOTB.

Und ein programm wie gparted sollte vom user mit kenntnis des root (=admin) passwortes ohne gefrickel startbar sein. Alles andere wendet sich an informatikstudenten oder hobby-informatiker.

[DeletedUserReAsG]

Funktioniert doch bei Stable, das als einziger der dreieinhalb (wenn man Experimental mitzählt) Zweige für den Endanwender gedacht ist. Worüber beschwerst du dich noch gleich? Dass die nicht-Endanwender-Zweige nicht endanwendergerecht sind? Das erinnert so’n bisschen an die Leute, die sich ’ne Beta oder gar Early Access einer Software kaufen und sich dann bitterlich beschweren, dass ja Fehler vorhanden, oder manche Funktionen noch gar nicht implementiert sind ….

[owl102]

Meiner ansicht nach ist eine distri genau dazu da, dies zumindest für seine user eindeutig zu machen, und zwar OOTB.

Wenn etwas geändert wird, was Änderungen von mehreren Leuten an mehreren Stellen erfordert, liegt es doch in der Natur der Sache, daß es für eine Zeitlang knirscht. Sollen sich etwa alle derart abstimmen, daß alle notwendigen Änderungen quasi gleichzeitig im Repository landen? Und das nur, damit sich einzelne Testing/Sid-Anwender nicht während der Übergangszeit in den Foren auskotzen?

[Blackbox]

Und das nur, damit sich einzelne Testing/Sid-Anwender nicht während der Übergangszeit in den Foren auskotzen?

Ich bin zwar Unstable Anwender, sah aber nicht die Notwendigkeit mich übergeben zu müssen.
Ganz im Gegenteil, ich habe ein konkretes Angebot gemacht.

Aber ich gebe dir Recht, wer Testing, oder Unstable nutzt und sich dann über gelegentliches "Rumpeln" beschwert, hat den Sinn dieser zwei Releaserzweige nicht verstanden.