Moin, Am Di, den 23.03.2004 schrieb Henning Hucke um 22:48:
*** Joerg Rossdeutscher (ratti@gesindel.de) schrieb am Mar 22, 2004 in...:
Am Mo, den 22.03.2004 schrieb Henning Hucke um 0:12:
Was ist an "sudo less +G -S /var/log/messages" so falsch!?
Nichts. Außer, daß es unnötig kompliziert ist.
Kompliziert!? %-D
Kompliziert.
[...] Wenn ich Serverdienste konfiguriere, logge ich mich als root ein, achte darauf, was ich tue, und dann wieder raus.
Mit sudo (respektive einem "weniger komplizierten" Link) zu arbeiten, ist wie einen Vertrag zu schliessen: Man tut es nicht für den Fall, dass man keine Scherereien miteinander hat, sondern für den Fall, _dass_ man Scherereien miteinander hat. Weniger kompliziert: Du solltest nicht deshalb nicht als "root" arbeiten, weil Du etwas falsch machen kannst, wenn Du aufpasst, sondern deshalb, weil Du etwas falsch machen kannst, wenn Du gerade mal abgelenkt bist.
Vor "Ablenkung" rettet dich sudo nicht. Wenn ich abgelenkt rm /* -r eintippe, dann tippe ich auch abgelenkt sudo rm /* -r ein. Zumal Katastrophe i.d.R. nicht auftreten, weil man wirklich rm /* -r eingetippt hat, sondrn weil ein bewusst abgesetztes find | xargs oder ein Leerzeichen an der falschen Stelle das Debakel auslöst. Oder so dämliche Konstrukte wie cd /hier/kann/alles/weg rm * -r ...welches bei nicht vorhandenem Ordner das falsche eliminiert... Nichts, was ich bisher versaut habe, wäre durch sudo vermieden worden.
Aber vermutlich ist es wie offensichtlich immer: Ihr müßt erstmal ein System in den Sand gesetzt haben, bevor ihr diese Lektion lernt...
Tausend-Jahre-Erfahrung haben gesprochen.
Dein Beispiel mit /var/log/messages ist ja noch "gekauft", aber was ist, wenn ich einen Dämon neu starten will?
Joerg, Du machst mich langsam Schwach: "+ rcinn restart" (Ich habe einen Link von "~/bin/+" auf "sudo". Mann kann genauso gut einen alias oder einen Link Beispielsweise in "/usr/lobal/bin" einrichten).
Ich habe hier ein halbes Dutzend Kisten stehen, und jede hat ein anderes Linux/Unix/OSX drauf. Dazu kommen regelmässig irgendwelche Webserver von Kunden, welche nach aufspielen diverser Software und der Website meinen Wirkungsbereich wieder verlassen. Was denkst du, wie konsistent die Enviroments, im Speziellen z.B. $PATH hier ist? Ein Beispiel mit einem nahen Verwandten, su: Unter Suse und SunLinux mußt du "su -" eingeben, um sendmail, ifconfig etc in den Pfad zu bekommen, bei Debian darfst du genau das nicht tun, sondern mußt "su" ohne "-" verwenden. Das verdaddel ich schon oft genug, ich werd' einen Teufel tun und auch noch mit sudo rumhühnern, zumal auf Kisten, auf die ich zur Softwareinstallation zwar root-Zugriff habe, die mir aber nicht "gehören"... Du hast noch nicht erzählt, wo sich "sudo" wirklich lohnt. Meine root-Tätigkeiten beschränken sich i.d.R. auf Dinge wie das wiederholen von: su do{ nano -w $CONFIGFILE # braucht root /etc/init.d/$DAEMON restart # braucht root #Scheisse, geht immer noch nicht } until geht || 18 Uhr exit Ein zwischendurch angesetztes ls oder find ist nun wirklich nicht das Problem.
Gnade dir Gott, wenn fälschlicherweise eine Configdatei mal schreibbar für User ist...
"+ vi /etc/shadow" (sigh!). Es wäre dumm, eine Config-Datei als User anzulgen. Das ist in der Tat einer der Fälle, in den man den Aufruf mit root-Rechten ausstattet.
Natürlich ist es dumm. Davon reden wir ja: Das jeder mal was dummes tut, und wie wür uns vor unserer eigenen gelegentlichen Dummheit am besten schützen. Natürlich geht keiner hin und sagt "Ach, jetzt leg ich mal die httpd.conf als User an". Fehler passieren immer anders. Zum Beispiel: Bei mir ist ist das ssh-Login für root verboten. Ich muß mich immer als user anmelden. Deswegen laufen auch Kopieraktionen per scp als User. "Schnell mal die httpd.conf von der anderen Maschine kopieren, scp -l ratti /etc/apache/conf/httpd.conf meinserver:/home/ratti/", und auf der Maschine dann "mv /home/ratti/httpd.conf /etc/apache/conf/httpd.conf". Und schwupps, isses passiert.
.. Du wolltest jetzt nicht auf Teufel komm raus ein Gegenbeispiel konstruieren, oder? %-|.
Ich sage, daß Schäden mit meiner Methode angerichtet werden können oder mit deiner, und teilweise /weil/ man sich eben dieser Methode bedient - während mit der anderen Methode nix passiert wäre. Und wenn ich mir beide so angucke, dann gefällt mir meine Methode deutlich besser. Ich nutze sudo nur, um z.B. per Webinterface User anzulegen. Für echte Admintätigkeite an der Shell nutze ich su und root.
Wenn du Fehler machst, ist das System breit. So oder so.
Hmpf! Wenn ich ein "rm -rf /*" (statt beispielsweise "rm -r ../.*") als root eingebe, ist mein System platt; in der Tat. Wenn ich das als "h_hucke" tue, ist es dass in keinster Weise.
Von der PERMANENTEN Arbeit als root für JEDEN Kram war hier nirgends die Rede, sondern nur von Tätigkeiten, die rootrechte ERFORDERN. Und da besteht eben zwischen "root # $FEHLER" und "user> sudo $FEHLER" überhaupt kein Unterschied. Ich präzisiere den Satz, wie er im Rahmen der Diskussion gemeint war: "Wenn du (bei der Admintätigkeit) Fehler machst, ist das System breit. So [als root] oder so [als sudo-root]." Sieh's doch mal so: Der einzige wirkliche Vorteil von sudo liegt darin, daß man zwischen den notwendigen(!) als-root Befehlen eben auch mal sowas eintippt wie pwd oder ls oder echo $IRGENDWAS, und daß man auch damit was kaputtkriegen /kann/. Zum Beispiel, weil man sich vertippt und ".[LEERZEICHEN]*" statt ".*" eintippt. Oder weil man die Returntaste nicht richtig trifft und vorher noch das * nebenan mit erwischt. Ja. Da rettet dich sudo. Ehmmm... aber das ist deutlich konstruierter als meine Argumentation. Gruß, Ratti