staging.inyokaproject.org

Hallo,

ok, anders: der Ausgangspunkt war ja ursprünglich: "GUI Anwendung + Root = böse". Das Problem hat man auf dem Server nicht (also hoffentlich nicht 😉 ). Von daher sollte der Abschnitt "GUI Anwendung + Root = böse" im Artikel so platziert sein, das es prominent sichtbar ist. Alles anderen kann ja auch drin bleiben, keine Frage.

aber Wiki-Lesende sind ja auch oft nicht mal angemeldet. Gibt/gab es da mal Statistiken zu?

Nein, geht ja auch nicht. Ginge wenn nur über eine Umfrage. Aus der Zeit im Wikiteam kann ich nur sagen, das es kaum neuen Wikiartikel zu reinen Serverthemen und Serveranwendungen gab. Also so Sachen wie Montioring, verteilte Objektspeicher, verteilte Datenbanken, Clustering, Load Balancer etc. Kann sein, dass sich das in den letzten Jahren durch preiswerter, potentiell servertaugliche Hardware wie den Raspi 3 oder 4 ein wenig verschoben hat. Ist aber OT hier, können wir bei Bedarf in einem separatem Thread diskutieren.

Gruß, noisefloor

noisefloor schrieb:

… im Artikel so platziert sein, das es prominent sichtbar ist …

+1

… kaum neuen Wikiartikel zu reinen Serverthemen und Serveranwendungen gab…

Da wird erfahrungsgemäß auch eher bei den Tools nachgesehen, da deren Verwendung oftmals gleich ist oder Tutorials auf Basis von Debian und/oder Ubuntu angeboten werden — Serverdienste ist dennoch gut bestückt. Hier würde ich auch eher das Grundsystem erwarten. Müssen wir nicht separat diskutieren, ich war nur neugierig. Hätte ja können sein, das es sowas mal gab. Ich war nur verwundert über die Aussage und überlese mal ganz unauffällig den Teil mit „also hoffentlich nicht“ 😉

kB schrieb:

Der Dateimanager Thunar bietet keine Menüpunkte für Arbeiten als Root an.

Ein solcher entsteht aber, wenn wie vom Entwickler vorgesehen eine "Custum Action" eingerichtet wird und wofür es auch ein entsprechendes Menü gibt.

Welches Paket aus den offiziellen Paketquellen muss ich installieren, um bei Thunar eine ähnliche Funktionalität zum Arbeiten als Root angeboten zu bekommen

Eben nicht notwendig, denn es reicht die schon eingebaute Funktionalität aus, mit der eine solche "Custom Action" eingerichtet werden kann.

Newubunti schrieb:

Nur bei unkritischen Systemen darf man auch per GUI als Root arbeiten.

Ich finde die Begriffe "kritisch" und "unkritisch" sind ziemlich sinnfrei, wenn dem Leser nicht wenigstens ansatzweise erklärt wird, welche Gefahren bei welcher Art von System bei welcher Methode lauern.

Der zweite Satz ist so in der Form einfach relativ sinnlos:

Genau!

Man sollte generell nicht per GUI als Root arbeiten!

Und dann fragt sich der Benutzer, warum denn all die verschiedenen GUI-Möglichkeiten vorhanden sind, und benutzt sie eben trotzdem, ohne eine leise Ahnung davon zu haben, welche Gefahr er unter welchen Umständen bei welchem Anwendungsszenario damit herausfordert.
Das ist wie wenn in der Betriebsanleitung eines Autos stünde: "Sie sollten das eingebaute Radio generell nicht benutzen."

kB schrieb:

chroot kann man nur einsetzen, wenn man bereits root ist.

Diese Sichtweise gilt aber erst recht für die Methode M1, wo man eben schon Root im externen System sein muss um das inaktive System zu bearbeiten.
Im Grunde ist die chroot-Methode eine Abwandlung von M1, aber doch eben ziemlich anders, weil man sich mittels dem Root-Recht im äußeren System in das zu bearbeitende System quasi einschleicht. Insofern würde ich es als separate Methode M2 einfügen. Wie auch immer man die chroot-Methode sieht / einordnet, sie ist wichtig und gängig und sollte deshalb in diesem Artikel nicht unterschlagen werden.

Ich verstehe daher nicht, wieso man das als Methode verstehen könnte, root zu werden.

In M1 trifft es erst recht nicht zu, dass man im zu bearbeitenden inaktiven passiven System Root ist oder wird.

• Die Erklärungen für A1 ... A5 sollten IMHO direkt unter der Tabelle, wo sie verwendet werden, zu finden sein.

Die Liste der Aufgabenklassen wird bereit in der Einleitung benötigt zur Erläuterung, was alles unter „mit Root-Rechten arbeiten“ fällt. In der Tabelle gibt es für den vergesslichen Leser einen bequemen Link.

Der fällt einem aber erst auf, wenn man drauf gestoßen wird, so abseits wie der steht, da sind die Links zu M1..M8 schon greifbarer. Ich fände es besser, die Aufgaben direkt über der Tabelle zu platzieren – schon allein deswegen, damit man nicht immer rauf und runter scrollen muss – und dann von der Einleitung oben dahin verlinkt. Hat dann auch den Vorteil, dass der prinzipiell schon informierte Leser schneller zum Kernstück des Artikels findet.

Auch möchte ich vorschlagen, nicht nur beispielsweise "M1:" sondern den ganzen Schriftzug "M1: Root-Shell – Offline" in den Link einzubeziehen. Das fällt mehr ins Auge.

UlfZibis schrieb:

Bei der Verwendung dieser Menüpunkte wird immer ein Programm unter dem Benutzer root gestartet, entweder Nemo selbst, oder ein Editor wie Pluma oder ein anderes Programm.

Wie soll denn in einem System wie Ubuntu MATE per Caja-Kontextmenü da Nemo aufgerufen werden, wenn Nemo da gar nicht zum System gehört?

Hier fehlt ein Doppelpunkt: "[:Nautilus#Mit-Root-Rechten-arbeiten]"

Übersehen ?

UlfZibis schrieb:

Eben nicht notwendig, denn es reicht die schon eingebaute Funktionalität aus, mit der eine solche "Custom Action" eingerichtet werden kann.

bedeutet also, das in jedem Wiki-Artikel auf die Dateimanager verwiesen werden muss, weil man ja eine Custom Action einrichten kann? Schau dir mal die Möglichkeiten bei Dolphin an was das angeht: Da kannst ein ganzes OS draus machen.

Möglich ist immer vieles, der Artikel sollte sich aber auf die grundlegend sicheren Techniken beziehen und nicht auf selbstgebraute Umwege. Wird ein Weg über PolicyKit mitgeliefert → gut. Wenn nicht, dann kann das Thema im Artikel oder Unterartikel des Dateimanagers behandelt werden. Wenn du jeden erdenklichen Weg darstellen willst, wird das etwa die größe umfangreicher Lexika haben. Das kann nicht das Ziel sein.

ChickenLipsRfun2eat schrieb:

bedeutet also, das in jedem Wiki-Artikel auf die Dateimanager verwiesen werden muss, weil man ja eine Custom Action einrichten kann? Schau dir mal die Möglichkeiten bei Dolphin an was das angeht: Da kannst ein ganzes OS draus machen.

Wo habe ich das geschrieben?
Es geht hier nicht um jeden Artikel, sondern um diesen. Hier wird schon auf die Dateimanager verwiesen, muss also nicht mehr diskutiert werden. Es geht auch nicht um beliebige Möglichkeiten, sondern nur um die, ob mit eigenen Bordmitteln des DM ein Root-Zugriff möglich ist. Alle anderen DMs werden diesbezüglich richtig beschrieben, nur Thunar eben nicht.

Möglich ist immer vieles,

Es geht hier nicht um "Vieles" sondern nur um den Root-Zugriff. Der Artikel wird auch nicht umfangreicher, wenn man im Text "keine Menüpunkte" durch "Custom Actions" ersetzt.

der Artikel sollte sich aber auf die grundlegend sicheren Techniken beziehen

Und warum erwähnt er dann an 100 anderen Stellen die unsicheren Techniken ???

Wird ein Weg über PolicyKit mitgeliefert → gut.

Bzgl. der anderen DMs wird nicht nur dieser Weg erwähnt und sogar diskutiert, sondern gleich mehrere, z.B. "Lesezeichen" (im Resultat dasselbe wie eine Custom Action) und sudoedit-Konfiguration.

..., wird das etwa die größe umfangreicher Lexika haben.

Siehe zuvor, nur 2 Wörter sind auszutauschen.

Wird bei Thunar diese Root-Aktion bei der Installation mitgeliefert?

ChickenLipsRfun2eat schrieb:

Wird bei Thunar diese Root-Aktion bei der Installation mitgeliefert?

• Wird bei Caja, Nautilus, Nemo und PCMan das Lesezeichen (= die Root-Aktion) für den „Administratoren-Wurzelordner“ bei der Installation mitgeliefert?

• Wird die GUI-Editor-Konfiguration für sudoedit bei der Installation mitgeliefert?

Was hat das Lesezeichen damit zu tun? Die Funktion wird mitgeliefert und ist kein Selbstbausatz. Oder anders formuliert: Du kannst diese implementierten Fähigkeiten nutzen ohne vorher mit Rootrechten hantieren zu müssen. Und bei sudoedit gilt einfach das, was du als EDITOR in deinen Umgebungsvariablen eingetragen hast. Ich glaube nano ist bei Ubuntu als Standard hinterlegt, kann aber auch undefiniert sein.

ChickenLipsRfun2eat schrieb:

Was hat das Lesezeichen damit zu tun? Die Funktion wird mitgeliefert

Und die Funktion "Custom Action" wird nicht mitgeliefert ???

Du kannst diese implementierten Fähigkeiten nutzen ohne vorher mit Rootrechten hantieren zu müssen.

Wie kommst Du darauf, das für die Nutzung dieser implementierten "Custom Action"-Fähigkeiten mit Rootrechten hantiert werden muss ???

Und bei sudoedit gilt einfach das, was du als EDITOR in deinen Umgebungsvariablen eingetragen hast.

Und bei einer Custom Action gilt einfach das, was Du als ACTION eingetragen hast. Beides wird bei der Installation so nicht mitgeliefert.

Und wozu ist das alles sooo wichtig ???
Worum geht es Dir eigentlich wirklich ???

Ich bin mir sicher, wenn kB von vornherein "Custom Actions" statt "keine Menüpunkte" in den Text geschrieben hätte, wärest Du nicht so "engagiert". Ich bezweifle sogar, dass das Detail Dir überhaupt aufgefallen wäre.

UlfZibis schrieb:

Und die Funktion "Custom Action" wird nicht mitgeliefert ???

Die schon, aber nicht die Funktion „mit Rootrechten editieren“.

Worum geht es Dir eigentlich wirklich ???

Um den bereits ziemlich umfangreichen Artikel nicht ad absurdum zu führen indem da „Kleinkram“ mit drinsteht, der in andere Artikel gehört. Ich wäre eher bereit Dinge auszulagern. Denk mal an die Pflege eines solchen Artikels und was dafür nötig ist um den anzupassen, wenn sich etwas ändert.

Wie sähe denn deiner Meinung nach eine fertige Custom Action aus? Lässt sich das als verständlicher Einzeiler im Abschnitt „Thunar“ eintragen? Im (aktuell ungeprüften) Thunar-Artikel steht dazu zumindest nichts drin. Insofern wäre ein Eintrag von „Custom Actions“ nicht hilfreich. Und darum geht es ja bei einem Wiki-Artikel.

UlfZibis schrieb:

[…] Ich bin mir sicher, wenn kB von vornherein "Custom Actions" statt "keine Menüpunkte" in den Text geschrieben hätte, wärest Du nicht so "engagiert". Ich bezweifle sogar, dass das Detail Dir überhaupt aufgefallen wäre.

Ich habe „Menüpunkte“ geschrieben, weil ich Menüpunkte meine und eben keine "Custom Actions". Diese Menüpunkte sind bei Nemo eingebaut, bei Caja per Paket nachrüstbar, wobei dieses Paket standardmäßig installiert wird, und bei Nautilus per Paket nachrüstbar, wobei dieses Paket standardmäßig nicht installiert wird, weil Nautilus andere Bedienmöglichkeiten bereits hat. Also standardisierte Menüpunkte für die speziellen Aufgaben als Root, deren Anwendung und mögliches Gefahrenpotential etwas mit dem Thema dieses Artikels zu tun hat.

"Custom Actions" sind etwas, was jeder Benutzer seinem Exemplar des Programms zusätzlich beibringen kann. Das ist eine Fähigkeit des jeweiligen Programms, kann/darf/soll gerne beim jeweiligen speziellen Artikel beschrieben werden, hat aber nichts mit dem Thema „mit Root-Rechten arbeiten“ zu tun, obwohl natürlich jeder sich mit diesen "Custom Actions" persönliche Werkzeuge – auch für Root-Arbeiten – basteln kann. Diese persönlichen Werkzeuge haben aber nichts in diesem Artikel verloren.

kB schrieb:

Ich habe „Menüpunkte“ geschrieben, weil ich Menüpunkte meine und eben keine "Custom Actions".

Der Artikel heißt aber "Mit Root-Rechten arbeiten" und ist damit nicht auf Menüs festgelegt.
Könntest ja auch Custom(-Action)-Menü schreiben. Nichts anderes machen auch die Erweiterungs-Pakete.

Diese Menüpunkte sind bei Nemo eingebaut, bei Caja per Paket nachrüstbar, wobei dieses Paket standardmäßig installiert wird, und bei Nautilus per Paket nachrüstbar, wobei dieses Paket standardmäßig nicht installiert wird, weil Nautilus andere Bedienmöglichkeiten bereits hat. Also standardisierte Menüpunkte für die speziellen Aufgaben als Root, deren Anwendung und mögliches Gefahrenpotential etwas mit dem Thema dieses Artikels zu tun hat.

Es sollen also nur Wege erwähnt werden, die der Nutzer ohne weiteres Zutun automatisch vorfindet. ^[1] Das hat eine Logik, der ich folgen kann.

"Custom Actions" sind etwas, was jeder Benutzer seinem Exemplar des Programms zusätzlich beibringen kann. Das ist eine Fähigkeit des jeweiligen Programms, kann/darf/soll gerne beim jeweiligen speziellen Artikel beschrieben werden, hat aber nichts mit dem Thema „mit Root-Rechten arbeiten“ zu tun, obwohl natürlich jeder sich mit diesen "Custom Actions" persönliche Werkzeuge – auch für Root-Arbeiten – basteln kann. Diese persönlichen Werkzeuge haben aber nichts in diesem Artikel verloren.

Nach ^[1] hat aber dann auch weder die Erwähnung noch die Anleitung zur Einrichtung – von Lesezeichen oder sudoedit – in diesem Artikel was verloren.