Von Weboberfläche Aufgaben ans System - wie vermitteln?

dev

Registered User
Hallo,

vielleicht hat jemand eine Anregung für mich: Es läuft ein Webdienst, der u. a. systemadministrative Aufgaben erstellt.

Da ich den Webdienst sicher nicht als root-User laufen lasse, muss ich die Aufgaben irgendwie delegieren und per Cronjob mit einem anderen Skript unter anderem User abarbeiten lassen.

Wie löst das man am Besten? Aufgaben definieren, in eine DB schreiben und dort vom Cronjob abholen lassen, abarbeiten und den Status in der DB auf "done" setzen?

Danke!
 
vielleicht einfach vom Webserver ein Skript aufrufen lassen, welches dann die Aufgabe mit sudo ausführt?
 
Du liegst garnicht so weit weg mit deiner Datenbanklösung. SysCP löst das zum Beispiel so. Da werden die Jobs in eine DB geschrieben. Alle 15 Minuten wirdern diese von einem Skript ausgelesen. Jeder Job der erledigt ist, wird dann aus der DB gelöscht.

Solltest du das ganze noch in echtzeit lösen wollen, kann man das entweder tun indem man das über xinit.d löst und dies über PHP angesprochen wird (SysCP-Lösung) Oder man ruft das oben bezeichnete Skript über PHP auf.
 
Danke!

vielleicht einfach vom Webserver ein Skript aufrufen lassen, welches dann die Aufgabe mit sudo ausführt?

Da bin ich noch nicht drüber gestolpert: Wie kann der Apache z. B. Skripte direkt aufrufen bzw. aufgrund bestimmter Bedingungen? Da wäre noch ganz interessant, dass man auf die Apache-Errors reagieren kann, und zwar mit einem Skript und nicht mit einem Webdienst.

Habe mir gerade mal den Quellcode von SysCP angesehen: In der Tat gibt es da ein cron_tasks.php Skript, das die DB abfragt.

@Mordor

Wegen der Echtzeit muss ich noch einmal nachhaken:

Solltest du das ganze noch in echtzeit lösen wollen, kann man das entweder tun indem man das über xinit.d löst und dies über PHP angesprochen wird (SysCP-Lösung) Oder man ruft das oben bezeichnete Skript über PHP auf.

Kannst Du noch ein bisschen konkreter für beiden Lösungen werden? Wer ruft das oben bezeichnete Skript auf? Und über xinet.d - das ist dann Porttriggering?
 
Ja, das mit xinit.d ist Portriggerin.

Zum Beispiel mit shell_exec (http://php.net/manual/de/function.shell-exec.php) kannst du Befehle auf der Shell ausführen, unteranderem könntest du damit auch ein cron_tastk.php Skript starten, was dann die Daten wieder aus der DB ausliest.

Ich persönlich würde nicht aus einem Skript heraus im System rumwerkeln, was über einen Browser ausgeführt wird. Da finde ich eben die Version mit dem cron_tasks.php Skript von SysCP nicht verkehrt. Auch wenn man es direkt aus einem Skript für den Brwoser aufrufen kann. Das Cronskript kann man ja dann so bauen, dass es sich die nötigen Rechte beispielsweise über sudo besorgt.
 
Ahh, ok. Die Bash/Shell soll über shell_exec angesprochen werden, diesen Weg kenne ich natürlich. Das will ich aber in jedem Fall vermeiden, dass ich durch den Browser direkt im System rumfuchteln kann, auch wenn ich definierte Rechte vergebe via sudoer etc..

Ich werde es dann über die DB-Abstraktion als Puffer machen: Das Backend schreibt rein, das Cronskript liest aus und gibt eine Statusmeldung zurück in die DB. So kann ich im Backend auch sehen, ob es Fehler etc. gibt.

Allerdings nehme ich kein PHP...
 
Last edited by a moderator:
Was machst du bei deiner Lösung wenn die Aufgabe noch nicht abgearbeitet ist und die 15 Minuten rum sind?

Ich würde mir Beanstalkd anschauen. Clients gibt es fast für jede Sprache. Einen Daemon in Ruby geschrieben ist mehr als einfach, auch für nicht-Ruby-Sprecher.

CronJobs sind dafür m.E. nicht geeignet.
 
Ruby ist sowieso meine Wahl, für das bereits existierende Webbackend und die Cronskripte.

Wenn ein Job angestossen ist, kann ich den von "active" auf "working" im Model setzen. Abgearbeitet werden nur die "active" und das abarbeitende Skript setzt nach Beendigung den Status von "working" auf auf "done".

Jetzt schaue ich mir beanstalkd mal an...

EDIT: Ok, so weit ich das sehen kann, ist der Daemon ein schwarzes Loch, in das ich Aufgaben reinkippe und eine Endlosschleife holt sie wieder raus bzw. arbeitet sie ab. Damit umgehe ich das DB-Geraffel. Persistenz bei "Strom aus" kann der Daemon auch. Und ist in Echtzeit.

Sieht ganz interessant aus die Lösung und ich bleibe in einem Ökosystem. Danke für den Hinweis.

So, hiermit wird beanstalkd richtig rund, da hat jemand 'nd DSL Lib zu beanstalk entwickelt: http://adam.heroku.com/past/2010/4/24/beanstalk_a_simple_and_fast_queueing_backend/
 
Last edited by a moderator:
Back
Top