staging.inyokaproject.org

Hallo zusammen,

Tema Weiterleitungen auf diesen Artikel:

U.a. Root-Rechte, Root Rechte, Rootrechte, etc. (sowie ihre kleingeschriebenen Pendants) existieren ja bereits.

Ich würde mir wünschen (die kleingeschriebenen Pendants kämen ja automatisch mit dazu):

• Root (es gäbe wohl keine Verwechslungsgefahr mit Archiv/ROOT, oder?)

• Root-Rechten, Root Rechten, Rootrechten; also die Plural-Formen der oben aufgeführten Weiterleitungen

Der Grund für meine Vorschläge ist, dass dadurch m.E. das Erstellen von (indirekten) Links auf mit Root-Rechten arbeiten in Wiki-Artikeln erheblich erleichtert würde. Und nein, nicht immer stellt das Setzen eines Ankers auf einen etwaigen Wissens-Block-Artikel à la mit Root-Rechten arbeiten die praktikabelste / beste Lösung dar. 😎

Kann man machen. Wenn niemand aus dem Wikiteam widerspricht, setze ich das Ende der Woche um.

Hallo,

(sowie ihre kleingeschriebenen Pendants)

Interne Links sind bei Inyoka nicht case-sensitive. D.h. ein Link wie MIT ROOT-RECHTEN ARBEITEN funktioniert auch.

Root (es gäbe wohl keine Verwechslungsgefahr mit Archiv/ROOT, oder?)

Nein, gäb's nicht. Aber root ist ein (bei Ubuntu nicht-existierender) Benutzer, von daher müssten der Redirect richtigerweise hierhin gehen.

Der Grund für meine Vorschläge ist, dass dadurch m.E. das Erstellen von (indirekten) Links auf mit Root-Rechten arbeiten in Wiki-Artikeln erheblich erleichtert würde

Wenn du die Zeit nicht hast, dann hast du IMO sowie nicht genug Zeit, um hier im Forum zu posten bzw. einen Wikiartikel vernünftig zu schreiben.

Von daher: -1 für den Vorschlag.

Gruß, noisefloor

linux_joy schrieb:

[…] Root-Rechte, Root Rechte, Rootrechte […] also die Plural-Formen

„Root-Rechte“ etc. ist bereits Plural Nominativ. Zusätzlich, wie vorgeschlagen, die Pluralformen im Akkusativ als Link einzuführen, erscheint mir überflüssig und ungebräuchlich. Schließlich soll das Wiki ja kein Wörterbuch der Deutschen Sprache werden. Nur in Wörterbüchern macht es Sinn, zusätzlich zum Nominativ auch noch die Akkusativ-Form zu nennen.

Wenn man das Wiki aber dennoch mit solchen zusätzlichen Links überfrachten möchte, muss man es in konsequenter Weise für jeden Artikel machen und darf natürlich auch den Genitiv und den Dativ nicht diskriminieren. Erscheint mir daher aberwitzig!

Danke für speziell diese Klarstellung, kB

Korrekt erkannt!

Von mir ebenfalls ein

-1

für den Vorschlag der ganzen redirects. Nach genauerem Hinschauen bleibt keiner übrig, für den ich einen richtigen Grund sehe.

Gruß BillMaier

Hallo zusammen!

noisefloor schrieb:

(...)

Root (es gäbe wohl keine Verwechslungsgefahr mit Archiv/ROOT, oder?)

Nein, gäb's nicht. Aber root ist ein (bei Ubuntu nicht-existierender) Benutzer, von daher müssten der Redirect richtigerweise hierhin gehen.

OK.

Der Grund für meine Vorschläge ist, dass dadurch m.E. das Erstellen von (indirekten) Links auf mit Root-Rechten arbeiten in Wiki-Artikeln erheblich erleichtert würde

Wenn du die Zeit nicht hast, dann hast du IMO sowie nicht genug Zeit, um hier im Forum zu posten bzw. einen Wikiartikel vernünftig zu schreiben.

Von daher: -1 für den Vorschlag.

Gruß, noisefloor

Ich dachte z.B. an Autostart (Abschnitt „Fuer-alle-Benutzer-2“):

Dazu erstellt man sich im Ordner /usr/local/bin mit Root-Rechten ein Shell-Skript test.sh mit dem problematischen Befehl und macht die Datei nach dem Speichern ausführbar. Beispiel ^[1][2]:
(...)

Aber gut; da jetzt ja wohl feststeht, dass das Setzen eines Ankers auf einen Wissens-Block-Artikel à la mit Root-Rechten arbeiten die praktikabelste / beste Lösung darstellt, werde ich es mir zukünftig eben ersparen, im Text bei von mir neu erstellten Wiki-Artikeln die m.E. überflüssigen Worte "mit Root-Rechten" zu verwenden. 😉

Und ebenfalls: Dank an kB für seine Klarstellung! Sehr informativ. Dass „Root-Rechte“ bereits Plural ist, das ist mir nach dem schreiben meines Postes irgendwann (ich glaube, am nächsten Tag, aber jedenfalls, ohne kB's Post gelesen zu haben) schon selber klargeworden, aber das mit Nominativ und Akkusativ habe ich bestenfalls geahnt...

In diesem Artikel vermisse ich einen Warnhinweis, das man

sudo GUI-Programm 

niemals benutzen sollte. (Trotz einiger inzwischen eingebauten Sperren für solches Tun.)

Gibt es dafür einen besonderen Grund?

Lt. der Info von marant... in diesem Thread soll das Problem mit dem Verbiegen der Recht nicht mehr bestehen. Berlin_1946 hatte dort in seiner Antwort: einen Link zu askubuntu –> sudo -H.

Ob das in der Praxis wirklich keine Probleme mehr verursacht, kann ich jedoch nicht beurteilen und nutze deswegen nach wie vor zur Sicherheit die bisherigen Methoden.

Gruß, Holger

charly-ax schrieb:

[…] soll das Problem mit dem Verbiegen der Recht nicht mehr bestehen

sudo selbst schreibt nach wie vor unter bestimmten Umständen Dateien in das Benutzerverzeichnis des aufrufenden Benutzers. Die Option -H setzt lediglich die Umgebungsvariable HOME (und damit auch ~) für das danach aufgerufene Programm auf das Benutzerverzeichnis des anderen Benutzers (idF. also root). Ob man die Option explizit aufruft oder ob diese per Vorgabe immer gesetzt ist, ist gleichwertig. Sicherer ist es natürlich, die Option immer selbst zu setzen.

Die Verwendung der Option -H entschärft also zwar die Problematik mit dem Verbiegen der Rechte, beseitigt sie aber nicht vollständig.

Nach wie vor ist es auch in 2021 noch eine gute Idee, auf

sudo GUI-Programm 

zu verzichten.

Auch bei Nicht-GUI-Programmen bringt die Option -H weniger als man glauben mag:

$ sudo pwd
/home/klaus
$ sudo -H pwd
/home/klaus
$ sudo -i pwd
/root

Hallo,

es steht im Artikel drin, wie man es benutzen sollten (nämlich mit -H). Also quasi positiv statt negativ ausgedrückt.

Gruß, noisefloor

Habe im Artikel die fehlerhaften Aussagen zu "sudo -H" korrigiert, einen Warnhinweis vor "sudo (-H) GUI-Programm" angebracht und das Beispiel "sudo -H gparted" gelöscht. Das Wiki sollte kein Beispiel zum Aufruf eines GUI-Programms mit sudo enthalten und gparted benötigt sowieso kein sudo, weil es sich die von ihm benötigten Root-Rechte per PolKit beschafft.

Hallo,

ist mir eben noch aufgefallen: es fehlt jetzt ein explizites Beispiel, wie man ein Programm mit GUI mit Root-Rechten aufruft. Das wird z.B. im Artikel Editor aber referenziert. Ist halt ab und an notwendig, dass man eine Datei (z.B. unterhalb von /etc) mit Root-Rechten und ggf. einem Editor mit GUI editiert.

Gruß, noisefloor

noisefloor schrieb:

[…] es fehlt jetzt ein explizites Beispiel, wie man ein Programm mit GUI mit Root-Rechten aufruft. Das wird z.B. im Artikel Editor aber referenziert.

Das Standardverfahren dafür ist sudoedit alias sudo -e, was immer funktioniert. GNOME kennt darüber hinaus auch noch das Verfahren über das URL-Schema //admin: (siehe: https://en.wikipedia.org/wiki/List_of_URI_schemes). Andere Desktops mögen funktional ähnliches eingebaut haben, da bin ich aber überfragt.

Ich baue das gerne ein, aber wo? In mit Root-Rechten arbeiten oder in Editor oder neuer Artikel?

Ist halt ab und an notwendig, dass man eine Datei (z.B. unterhalb von /etc) mit Root-Rechten und ggf. einem Editor mit GUI editiert.

Ich verwende: SUDO_EDITOR=gedit sudo -e DATEI

kB schrieb:

noisefloor schrieb:

[…]

Das Standardverfahren dafür ist sudoedit alias sudo -e, was immer funktioniert. GNOME kennt darüber hinaus auch noch das Verfahren über das URL-Schema //admin: (siehe: https://en.wikipedia.org/wiki/List_of_URI_schemes). Andere Desktops mögen funktional ähnliches eingebaut haben, da bin ich aber überfragt.

Ich baue das gerne ein, aber wo? In mit Root-Rechten arbeiten oder in Editor oder neuer Artikel?

sudoedit und admin:// sind ja schon im Artikel eingebaut und auf sudo (Abschnitt „Editieren-von-Dateien-unter-Sudo-Rechten-sudoedit“) wird auch verwiesen, ich wüsste nicht, was da noch groß ergänzt werden sollte.

Habe jetzt die Reihenfolge der Abschnitte sudoedit und pkexec vertauscht und im Abschnitt sudoedit vermerkt, dass GUI-Editoren einsetzbar sind. Außerdem intern auf admin:// verlinkt. So sollte dem Leser nun klarer werden, dass sudo gedit & Co. nicht verwendet werden sollen und wie man das ersetzen kann.