Import der Root-Cronjobs

[l_fish]

Hallo,

heute Nacht kam das 20.0 Update auf unsere Keyhelp-Server. Dabei wurden auch bestehende Cronjobs des Users root in Keyhelp importiert. Dabei wird ja bereits darauf hingewiesen, dass Keyhelp sein Bestes versucht und man das Resultat überprüfen soll. Das habe ich mal gemacht und dabei folgendes Fehlverhalten festgestellt:

Crontab:

Code: Select all

42 3 * * *      /root/bin/backup_server
*  * * * *      /root/bin/fix_user_home_permissions

Man beachte: In Zeile 2 stehen zwischen dem ersten und dem zweiten Sternchen zwei Leerzeichen. Zeile 1 hat vor dem Befehl 6 Leerzeichen, Zeile 2 ein TAB.

Der Import ignoriert Zeile 2 komplett, Zeile 1 wird importiert. Allerdings stehen im Feld "Befehl" dann 5 Leerzeichen vor dem eigentlichen Befehl.

=> Hier wäre vermutlich ein trim vorab sinnvoll. Warum der Befehl aus Zeile 2 nicht importiert wird, wäre auch noch zu prüfen, ich vermute wegen der zwei Leerzeichen zwichen den Sternchen (auch hier evtl. ein trim ausführen?).

Vielleicht hilft das Feedback ja den Entwicklern beim Verbessern der Import-Routine

Und zu Guter letzt: Wieder einmal DANKE für das reibungslose Update dieses tollen Panels! Ich bin gespannt, was die 20.0 noch so mit sich bringt, das Changelog ist ja noch nicht ganz up-to-date


Viele Grüße,
Lars

[Tobi]

das Changelog ist ja noch nicht ganz up-to-date

Wie?
Hast du die neuen TBA Features noch nicht entdeckt?

[l_fish]

Nein, ich suche immer noch wie wild, die müssen echt gut versteckt sein...

...ich hab auch schon die Forensuche benutzt! Leider ohne Erfolg: search.php?keywords=TBA+Features
...und die relevanten Logfiles sagen leider auch nichts

...vermutlich brauche ich einfach mehr heute morgen

[Tobi]

Die relvanten TBA Logfiles findet Jolinar für dich, der ist unser Logfile-Spezialist .

[Jolinar]

Kleine Nachhilfestunde am morgen...

TBA steht für das englische "to be announced" und bedeutet "wird noch bekannt gegeben".

[Alexander]

Hallo,

Danke für das Feedback. Der Import der root-Cronjobs war eine einmalige Sache, aber trotzdem Danke
(... verdammt, im Regex fehlte ein "+")

Der Changelog konnte die Tage scheinbar nicht gespeichert werden. Mach ich jetzt gleich als Nächstes.

[mhagge]

Also das mit den Cronjobs ist schon relativ gravierend. Bei mir konnte auch ein Cronjob nicht umgestellt werden - von einem Backup-Dienst. Der hat folgendes Format:

Code: Select all

51 3 * * 0,1,2,3,4,5,6 /usr/lib/Acronis/Schedule/schedwrapper -m cron -i 1

Woran sich Keyhelp gestört hat war anscheinend die Syntax 0,1,2,3,4,5,6 - wobei man die ja hier durch * ersetzen kann (hat der Installer vom Backup-Agent so in die Root-Crontab reingeschrieben, hat funktioniert, hat mich daher nie gekümmert)

Wie auch immer: wenn die Umstellung nicht klappt wird die Crontab anscheiend nicht angerührt - alleridngs in der Keyhelp-GUI werden die umgestellten Crontabs durchaus angezeigt, alle anderen Root-Cronjobs mit Ausnahme dieses einen erscheinen dort in der Tabelle.

Verändert man nun was in der Tabelle, wird die Root-Crontab nach den Keyhelp-Einstellungen neu geschrieben - und der fehlerhafte Cronjon damit überschrieben. Wenn man das also nicht auf den Schirm hat, dass es da evtl. nicht importierte Cronjobs geben könnte besteht die Gefahr, dass die verloren gehen.

Ich hab den obigen Cronjob dann manuell in Keyhelp eingegeben, dabei habe ich dann auch bemerkt dass 0,1,2,3,4,5,6 wohl die Ursache des Problemes war - hier kein Problem, weil durch * ersetzbar, aber wenn man Cronjobs tatsächlich nur an bestimmten Wochentagen ausführen will geht das so momentan nicht, da Keyhelp manuelle Einträge in der Crontab überschreiben würde...

PS: Beim Changelog kommt jetzt ne Fehlermeldung

[mhagge]

Code: Select all

hat der Installer vom Backup-Agent so in die Root-Crontab reingeschrieben

Dabei fällt mir glatt noch ein anderes Problem auf - was passiert mit Cronjobs, die von Scripten oder Installern oder so in die Root-Crontab eingetragen werden - kommt ja durchaus mal vor? Die kennt Keyhelp dann ja nicht und bei der nächsten Änderung der Crontab würden die dann überschrieben werden.

Es müsste also zumindestens vor Veränderungen über die Gui noch einen Abgleich mit der vorhandenen Crontab geben, so dass manuell hinzugefügte Einträge noch nachimportiert werden (oder es zumindestens eine Warnmeldung gibt, dass man da ggf. etwas manuell übernehmen muss)

[Reseller4711]

Wenn ich auf meinem Keyweb-Server unter Keyweb 20.0 nun den Punkt "Geplante Aufgaben (Cronjobs)" aufrufe, erhalte ich nur einen 500 Error (domain.de/index.php?page=scheduled_tasks&sid=ktjrfbts8u30ahvu09ouqt46tq)

[Alexander]

Ich hab den obigen Cronjob dann manuell in Keyhelp eingegeben, dabei habe ich dann auch bemerkt dass 0,1,2,3,4,5,6 wohl die Ursache des Problemes war - hier kein Problem, weil durch * ersetzbar, aber wenn man Cronjobs tatsächlich nur an bestimmten Wochentagen ausführen will geht das so momentan nicht, da Keyhelp manuelle Einträge in der Crontab überschreiben würde...

Danke, das schaue ich mir nochmal an, so das auch Cronjobs mit Schemas wie "51 3 * * 0,1,2,3,4,5,6" eingebaut werden können.

Dabei fällt mir glatt noch ein anderes Problem auf - was passiert mit Cronjobs, die von Scripten oder Installern oder so in die Root-Crontab eingetragen werden - kommt ja durchaus mal vor? Die kennt Keyhelp dann ja nicht und bei der nächsten Änderung der Crontab würden die dann überschrieben werden.

Es müsste also zumindestens vor Veränderungen über die Gui noch einen Abgleich mit der vorhandenen Crontab geben, so dass manuell hinzugefügte Einträge noch nachimportiert werden (oder es zumindestens eine Warnmeldung gibt, dass man da ggf. etwas manuell übernehmen muss)

Ist leider aktuell noch ein Rechte-Problem, der Webuser der KeyHelp UI hat nicht das Recht die crontab einzusehen. Schau ich mir nochmal an.
Cronjobs von anderen Installern sollten der Regel nicht in die root crontab schreiben, sondern mit einer eigenen Datei daher kommen.
Allgemein: Man muss die root Cronjobs nicht verwenden und kann auch gern weiter die CLI nutzen. Wenn man allerdings einmal einen root Cronjob speichert, dann wären Einträge in der Datei verloren, die nicht auch in der KeyHelp UI aufgeführt sind.

Wenn ich auf meinem Keyweb-Server unter Keyweb 20.0 nun den Punkt "Geplante Aufgaben (Cronjobs)" aufrufe, erhalte ich nur einen 500 Error (domain.de/index.php?page=scheduled_tasks&sid=ktjrfbts8u30ahvu09ouqt46tq)

Kannst du mir einmal mal den php-error.log Auszug zukommen lassen (Kannst du auch über die UI jetzt einsehen unter Protokolle)

[Reseller4711]

Wenn ich auf meinem Keyweb-Server unter Keyweb 20.0 nun den Punkt "Geplante Aufgaben (Cronjobs)" aufrufe, erhalte ich nur einen 500 Error (domain.de/index.php?page=scheduled_tasks&sid=ktjrfbts8u30ahvu09ouqt46tq)

Kannst du mir einmal mal den php-error.log Auszug zukommen lassen (Kannst du auch über die UI jetzt einsehen unter Protokolle)

Leider tauchen in der Auswahl nur "Aufgaben & Wartungsprotokolle" sowie "Backup-Protokolle" auf und diese Punkte sind grau hinterlegt und nicht auswählbar.

Ferner wurde mir von Kollegen berichtet, dass es unter Benutzer / Berechtigungen jetzt einen One-Klick Installer gibt. Dieser fehlt bei mir auch.

Danke

[Alexander]

Ist der 500-Fehler bei dir reproduzierbar? Oder war es vielleicht nur ausgelöst durch einen zeitgleich durchgeführten Webserver reload.

Das One-Klick-Feature ist aktuell nur auf Keyweb-Server-Kunden beschränkt.

[l_fish]

Allgemein: Man muss die root Cronjobs nicht verwenden und kann auch gern weiter die CLI nutzen. Wenn man allerdings einmal einen root Cronjob speichert, dann wären Einträge in der Datei verloren, die nicht auch in der KeyHelp UI aufgeführt sind.

Vielleicht wäre dann ein Haken "Root Cronjobs durch Keyhelp verwalten" sinnvoll, mit dem man das ganze Feature überhaupt erst aktivieren muss. Sonst passieren meines Erachtens zu leicht Fehler. Beim Aktivieren könnte dann auch ein (Re-)Import der existierenden Cronjobs erfolgen (sofern das rechtetechnisch irgendwie noch umsetzbar sein wird).

@Jolinar: TBA war mir schon klar. Mist, da war meine Ironie nicht gut genug

[v3ng]

Das One-Klick-Feature ist aktuell nur auf Keyweb-Server-Kunden beschränkt.

Wird das Feature auch für externe Kunden kommen?
Falls ja, ist abzusehen wann?

Danke für das Update!
Wie immer, tolle Arbeit die Ihr liefert

[Reseller4711]

Ist der 500-Fehler bei dir reproduzierbar? Oder war es vielleicht nur ausgelöst durch einen zeitgleich durchgeführten Webserver reload.

Das One-Klick-Feature ist aktuell nur auf Keyweb-Server-Kunden beschränkt.

Hallo,
es ist ein Keyweb Server (i7) auch mir Remote-Hands Cronjobs ....
Reproduzieren kann ich leider nichts. Vor Panel-Update, manuell angestoßen, machte ich über Keyhelp die Updates samt reboot.

Ich habe noch einen kleinen KEyweb V-Server, dort sind sowohl die geplanten Aufgaben" als auch die "Anwendungen" verfügbar.

Den Error 500 habe ich übrigens noch auf einem externen V-Server, der bis zur Kündigung brach liegt. Dort habe ich über die Konsole update, upgrade, dist-upgrade, autoremove und reboot gemacht und dann über das Panel das Keyhelp Update angestoßen.