Problem mit kernel-remover

[melmarker]

irgendwann nach 17.00 - einfach im IRC anpingen - ich weiss auch, was passiert, nur nicht warum. Hintergrund: Bei mir wird das alles(tm) ein wenig anders verarbeitet und gesourced, ich hab zsh als shell

[DeKa]

Nur so zum Test, auto-remove Mal probieren.Bei mir bleibt der aktuelle und der letzte Kernel übrig, alle anderen werden deinstalliert.

[axt]

harley-peter und melmarker haben sich gestern über IRC kurzgeschlossen. Da wäre hier ja der Stand nach der Fernwartung sinnvoll (ich gehe davon aus, es ist gegessen).

[DeKa]

Okay, dann kann hier ja geschlossen werden.

[harley-peter]

Ja, das Problem ist Dank der Geduld und der Kompetenz von melmarker behoben mit der Anpassung diverser Konfigurationsdateien bezügl. der Pfade. Obwohl melmarker sehr bemüht war mir die Vorteile des unterschiedlichen Verhaltens zwischen su und su - zu erläutern  hat das bei mir nur bedingt gefruchtet. Im Umgang mit unterschiedlichen Nutzern mag das alles durchaus sinnvoll sein aber für mich persönlich darf es einfach keine zwei unterschiedlichen roots geben. root ist root! MIt allen Möglichkeiten und Konsequenzen und zwar egal wie ich mich einlogge.
Aber das ist nur die Ansicht eines naiven unbedarften Nutzers. 

[melmarker]

ja, ich hab mich wirklich bemüht - des Rätsels Lösung war bei harley-peter einfach die Erweiterung der PATH-Variable um /sbin und /usr/sbin in der ~/.bashrc. Ich hab mir sagen lassen, dass das durchaus legitim sein soll, weil: Wenn ein Programm da aus irgendwelchen Gründen rumlungert und als normaler User ausführbar ist, dann macht es keinerlei Sinn, das aus dem Suchpfad rauszunehmen - und wenn es erhöhte Rechte braucht, dann macht es noch weniger Sinn, den Suchpfad so kastriert zu lassen, wie mit ner login shell

Code Auswählen Erweitern


export PATH=$PATH:/sbin:/usr/sbin


[tommy2]

ist das nicht die grund fur benutzing su - ?

[melmarker]

Ganz ehrlich? Ich hab zwar gelesen, dass es da durch die Verlagerung von su von login nach util-linux auch noch ein paar Änderungen gegeben hat, hab mich aber damit noch nicht wirklich auseinandergesetzt, weil diese Änderungen in zsh nicht wirklich so durchschlagen.

[tommy2]

die - sulte die user in die /root environment shalten! "root path"

[unklarer]

Der Grund für die Benutzung von su - hat mich in diesem Zeitraum (2018) diese Erläuterung überzeugt.   

[melmarker]

Ok. Nix gegen GerBra - der weiss eigentlich genau, wovon er schreibt - macht aber in dieser Erklärung einige Denkfehler. Oder zumindest empfinde ich das, was er da von sich gibt, als solche. Verdammt, ich bin mit oder ohne login-shell root. Und in dem Fall brauch ich nicht mal mehr evilnerd heissen, um dat script direkt nach /usr/bin zu hacken - ikke darf dat

Und ja - das strippen der Umgebung hat auch einiges für sich - und einiges halt gegen sich. .Xauthority hatten wir ja schon mal angesprochen. Und Pfadsetzung auch. Ich hab leider die doofe Erfahrung machen dürfen, dasss oftmals binaries halt nach /sbin oder /usr/sbin platziert werden und dann nicht gefunden werden - weil halt der doofe User per default /sbin und /usr/sbin nich im Pfad hat - find ich nicht schick.

Von dem ganzen xdg und X-Geraffel schweigen wir mal, na klar kann man so was auch missbrauchen. Ich seh aber nicht wirklich ein, dass ich mich selbst um Möglichkeiten bringe, die meine Leben erleichtern, nur weil das in einem anderen Kontext missbraucht werden kann - in diesem Moment ist das ganz einfach: Mein Rechner, meine Regeln. Und wenn da jemand reinmanscht (KDE mit dem check auf id=0 und nem erhobenen Zeigefinger in dolphin und kwrite/kate), dann löst das bei mir nen Beissreflex aus - einhergehen mit wilden Flüchen und schneller Benutzung von Editoren und Bauscripten um den "Mist" flugs zu beseitigen - immer unter der Prämisse: Man sollte ansatzweise wissen, was man tut.

[tommy2]

Amen!

[harley-peter]

@melmarker:
+1!
Es kann nur einen root geben!