crontab -e klappt nicht

L I V E Stammtisch ab 20:30 Uhr im Chat
  • [quote='llutz','http://test.forum-raspberrypi.de/forum/index.ph…6188#post286188']
    "sudo crontab -l" zeigt dir die root-crontab


    Das heißt das funktioniert nicht?

    Wenn ich mit Vi arbeite komme ich leider hier nicht weiter:

  • <ESCAPE> :wq eingeben, oder wenn er meckert <ESCAPE> :!q


    Dann liest du beitrag #13 noch einmal crontab -e klappt nicht
    und folgst den Anweisungen.
    Wenn der User PI dann eine passende crontab hat, löscht du die von root wieder (sonst läuft dein Job doppelt)

    Code
    sudo crontab -r


    Ja, _hier_ muss das sudo davor.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. Juni 2017 um 13:06)


  • <ESCAPE> :wq eingeben, oder wenn er meckert <ESCAPE> :!q


    Dann liest du beitrag #13 noch einmal crontab -e klappt nicht
    und folgst den Anweisungen.
    Wenn der User PI dann eine passende crontab hat, löscht du die von root wieder (sonst läuft dein Job doppelt)

    Code
    sudo crontab -r


    Ja, _hier_ muss dass sudo davor.

    So, jetzt habe ich es glaube ich:

    Der Root ist weg...

    Kann ich denn jetzt irgendwo sehen ob das Skript auch wirklich jede Minute aufgerufen wird?

  • Code
    sudo journalctl -n 5 -u cron


    sollte dir Zeilen a la: ...... session opened for user pi ... ausgeben.
    Das bedeutet, dass die crontab ausgeführt wird.
    Ob dein Script richtig läuft, musst du selbst checken. Entweder über die Funktion oder mittels Logging im Script.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. Juni 2017 um 13:14)

  • Code
    sudo journalctl -n 5 -u cron


    sollte dir Zeilen a la: ...... session opened for user pi ... ausgeben.
    Das bedeutet, dass die crontab ausgeführt wird.
    Ob dein Script richtig läuft, musst du selbst checken. Entweder über die Funktion oder mittels Logging im Script.

    Was sagt der Profi? Ist das so sauber? Mich irritiert das es eine session für root ist und eine für pi?

    Code
    pi@raspberrypi:~ $ sudo journalctl -n 5 -u cron
    -- Logs begin at Di 2017-06-06 12:29:56 CEST, end at Di 2017-06-06 13:18:12 CEST. --
    Jun 06 13:17:01 raspberrypi CRON[2665]: pam_unix(cron:session): session closed for user pi
    Jun 06 13:17:01 raspberrypi CRON[2664]: pam_unix(cron:session): session closed for user root
    Jun 06 13:18:01 raspberrypi CRON[2711]: pam_unix(cron:session): session opened for user pi by (uid=0)
    Jun 06 13:18:01 raspberrypi CRON[2715]: (pi) CMD (/usr/local/bin/luefterskript.sh)
    Jun 06 13:18:01 raspberrypi CRON[2711]: pam_unix(cron:session): session closed for user pi
    pi@raspberrypi:~ $
  • Hallo Lammi !

    Ab und an hilft auch die Dokumentation, die auf jedem Linux installiert ist, Du musst nicht jeden Tastendruck aus dem Web 2,0 erfragen.

    Hast Du schon mal < man crontab > oder < apropos cron > angesehen ?


    Servus !

    RTFM = Read The Factory Manual, oder so


  • Hallo Lammi !

    Ab und an hilft auch die Dokumentation, die auf jedem Linux installiert ist, Du musst nicht jeden Tastendruck aus dem Web 2,0 erfragen.

    Hast Du schon mal < man crontab > oder < apropos cron > angesehen ?


    Servus !

    Danke, kannte ich noch nicht....

    Einmal editiert, zuletzt von Lammi1988 (6. Juni 2017 um 13:33)


  • ...
    Mit nem einfachen Browserplugin brauch ich 30 Sekunden um deinen Rechner zu übernehmen. Und nach der ersten Verwendung eines sudo-befehls sogar mit rootrechten...und ich nutze dafür dein crontabscript, was idealerweise auch noch regelmäßig maschinell gestartet wird.

    Erzähl mal...

    Der TO hat seinen RP vermutlich nicht per Portforward aus dem Internet erreichbar...

    Mal Butter bei die Fische...

  • Der TO hat seinen RP vermutlich nicht per Portforward aus dem Internet erreichbar...

    Mal Butter bei die Fische...


    Vergisses... ich habe auf solche destruktiven Quereinstiege, die sich mit nichts auf das Thread-Thema beziehen und die gleich mit einer suggestiven Verdrehung von Inhalten anfangen, wirklich keinen Bock mehr....

    Ess Deinen Fisch ohne Butter... oder besser, setz ihn wieder zurück... wenn er noch zappelt....

    Einmal editiert, zuletzt von WinterUnit16246 (6. Juni 2017 um 20:31)

    • Offizieller Beitrag


    ich habe auf solche destruktiven Quereinstiege, die sich mit nichts auf das Thread-Thema beziehen und die gleich mit einer suggestiven Verdrehung von Inhalten anfangen, wirklich keinen Bock mehr....

    ... und genau deshalb habe ich auf Deinen letzten Beitrag nicht mehr geantwortet.

  • ... und genau deshalb habe ich auf Deinen letzten Beitrag nicht mehr geantwortet.


    Weil ich Deine Frage "weshalb sollte ein normaler User in einem Systemordner Dateien ausführen dürfen?" ohne Umschweife direkt beantwortet habe und zudem erklärt habe, warum ich dieser Meinung bin? Und weil der Speicherort /usr/local/bin vs /home nicht zu diesem Script-Thema gehörte...?... obwohl von Dir selber thematisiert!

    Alles klar.... :bravo2:

    Einmal editiert, zuletzt von WinterUnit16246 (6. Juni 2017 um 21:23)

    • Offizieller Beitrag

    Nö, wegen:


    Aber jeder soll sich seine Exploits selber bauen, wie er mag. Mit nem einfachen Browserplugin brauch ich 30 Sekunden um deinen Rechner zu übernehmen. Und nach der ersten Verwendung eines sudo-befehls sogar mit rootrechten...und ich nutze dafür dein crontabscript, was idealerweise auch noch regelmäßig maschinell gestartet wird.

    Der TO fragte weshalb crontab -e nicht "klappt" und nicht ob Du meine RPis kapern kannst, zumal bei mir u.a. root ein gutes Passwort hat und weder Standarduser "pi" noch sudo auf meinen Kleinen zu finden sind.

    Irgendwie habe ich Appetit auf Popkorn... :s


  • Der TO fragte weshalb crontab -e nicht "klappt" und nicht ob Du meine RPis kapern kannst, zumal bei mir u.a. root ein gutes Passwort hat und weder Standarduser "pi" noch sudo auf meinen Kleinen zu finden sind.


    Achso... dann hat der TO also auch gefragt, wo er sein Script speichern soll ...?.... weil Du ihm vor meiner Reaktion diese Antwort gegeben hast:
    "Dein Lüfterscript gehört nicht nach /usr/local/bin sondern in das Homeverzeichnis des Users, mit dem der cronjob erstellt wurde." Und da war ich eben der Meinung, dass das überhaupt nicht ein guter Rat ist...

    Oder drehst Du Dir die Wahrheit jetzt einfach nur für Dich passend und was für Dich gilt, gilt für andere noch lange nicht? Vielleicht sind Dir ja aber auch nur die Zusammenhänge von Aktion und Reaktion gleichgültig....?

    Irgendwie habe ich Appetit auf Popkorn...


    Versuchs mal mit Fisch... aber der ist vermutlich auch schon gammelig....

    Einmal editiert, zuletzt von WinterUnit16246 (6. Juni 2017 um 22:09)

    • Offizieller Beitrag

    Also nochmal. Das die Zeitangabe im cronjob nicht funktionieren konnte ist klar. Das man mit der crontab eines normalen Users ohne sudo nicht einfach so ein Script im Verzeichnis /usr ausführen darf sollte auch klar sein, oder? Desalb das homedir, auch dafür gibt es das. https://de.m.wikipedia.org/wiki/Benutzerverzeichnis => Unixoide Systeme

    So und jetzt genug Geplänkel, ok? ;)

  • Das man mit der crontab eines normalen Users ohne sudo nicht einfach so ein Script im Verzeichnis /usr ausführen darf sollte auch klar sein, oder?

    Das ist schlichtweg falsch und du unterliegst da einem Irrtum. Selbstverständlich kann der User ein in /usr/local/bin liegendes Script ohne sudo ausführen, direkt oder via crontab... das ist völlig egal. Es wird halt nur mit den Rechten seiner UID ausgeführt. Und es gibt überhaupt keine sinnvolle Notwendigkeit, "sudo" für solcherart Crontab-Scripte zu verwenden. Ich wiederhole das noch mal, der User ruft doch immer und sowieso unzählige Programme in /bin oder /usr/bin auf..... und alle nur mit seinen Rechten und ohne sudo.... das gleiche gilt für /usr/local/bin

    Entweder das Script benötigt keine besondere Rechte, dann kann der User es einfach in seine Crontab eintragen. Oder es benötigt root-Rechte, dann trage ich es in den root-Crontab ein... in beiden Fällen muss nicht eine einzige Zeile im Script verändert werden. In beiden Fällen kann man auf diesen unnötigen sudo-Quatsch verzichten. Allein der Unterschied unter welcher UID es läuft beeinflusst, mit welchen Rechten es läuft.

    Aber ein solches Script im Wirkungsbereich des Users zu speichern, wo er selber Ändernrechte drauf hat... sorry... ich halte das für unvernünftig und ohne jeden Zweifel für fahrlässigen Leichtsinn. Solche scripte gehören imho immer nach /usr/local/bin, und zwar root:root, rwx, r-x, r-x.

    Du kannst das alles selbstverständlich trotzdem anders sehen... für mich hat das aber den gleichen Aussagewert, wie der Rat "Natürlich kann man mit 190 bei Regen über die Autobahn fahren... ich mache das schon immer so... das ist völlig unkritisch". Die Gefahr dabei ist, ein Fahranfänger kann Dir das sogar glauben.....

    Einmal editiert, zuletzt von WinterUnit16246 (7. Juni 2017 um 12:20)


  • Aber ein solches Script im Wirkungsbereich des Users zu speichern, wo er selber Ändernrechte drauf hat... sorry... ich halte das für unvernünftig und ohne jeden Zweifel für fahrlässigen Leichtsinn. Solche scripte gehören imho immer nach /usr/local/bin, und zwar root:root, rwx, r-x, r-x.

    Ich verstehe ehrlich gesagt immer noch nicht, wo da das Problem liegen soll. Wenn das Skript in einem Verzeichnis des Users liegt, dann kann jemand, der Zugriff auf den Account bekommt, durch Ändern des Skriptes beliebigen Code mit den Rechten des Users ausführen. Soweit richtig, ja. Aber kann das jemand, der Zugriff auf den Account bekommt, nicht sowieso?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!