[PHP] Scripts met scheduler uitvoeren

[ripexx]

Oke het probleem is als volgt:

Ik heb met behulp van wat code en mysql een redelijke scheduler opgezet. Het probleem is dat ik maar 1 cronjob mag gebruiken dus ik moest mijn eigen scheduler er om heen bouwen. Het script kijkt gewoon in de database welke scripts er uitgevoerd moeten worden. Deze scripts staan in de database met een filename en kunnen dus op verschillende manieren aangeroepen worden. Alleen wat is nu handig. De verschilelende scripts doen backups van de database, stats verwerken en mailings versturen.

Ik heb al lopen zoeken op GoT maar dan kom ik niet veel verder dan het starten van scripts via cron. Dat is het probleem niet Bij google heeft cron de overhand maar niet wat ik zoek De documentatie van PHP en scripts op Zend.com een sourceforge.net zijn ook niet echt wat ik zoek. 99% gaat over het gebruik van cron of het maken van een script dat bij elk request kijk of er iets moet worden uitgevoerd. Maar niet of er meerdere stukken moeten worden uitgevoerd.

Waar draait het dan allemaal om. Je kan in php externe bestanden op verschillende manieren aanroepen.
[list=1]
• Met behulp van include() etc.
• Met een exec(), system() etc
• Via eval()


Opzich heeft valt eval al af omdat het gewoon te veel problemen qua beveiliging en controle opleverd. Voordeel is dat ik het script in een text veld in de database kan zetten maar schrijven naar het filesystem in net zo eenvoudig.

Het uitvoeren via de command line heeft niet mijn persoonlijke voorkeur mede omdat je niet de controle over rechten hebt (execute rechten) en dat het voor een ander omgeving al compleet anders kan werken. In php heb je relatief meer controle. Include is opzich ook geen probleem maar ik vraag me af of het handig is dat ik zoveel includes maak die allemaal vast gehouden worden.

Wat had ik zelf in gedachte in pseudo code

PHP:

<?php
// bepaald welke taken er uitgevoerd moeten worden
include("script.naam.php");
start_scriptnaam();
log_results();
// ^^^ zit dan in een loop waarbij de scriptnaam en startfunctie ergens 
// van daan worden gehaald,
//  start functie kan desnoods ook in het te include scripts zitten..
?>

Heeft iemand al eens eerder met zo'n probleem te maken gehad? En hoe heb je het opgelost?

[ Voor 3% gewijzigd door ripexx op 27-10-2004 22:47 ]

[ggvw]

"Het uitvoeren via de command line heeft niet mijn persoonlijke voorkeur mede omdat je niet de controle over rechten hebt (execute rechten0 en dat het voor een ander omgeving al conpleet anders kan werken."


is_executable() -- Tells whether the filename is executable


pompiedom...

edit:

Kortom, je wilt je eigen scheduler maken in php/mysql en weet niet goed hoe je de scripts moet laten uitvoeren.

Hmm ik zelf zou toch voor de exec() of system() gaan, dat lijkt me de meest eenvoudige oplossing.

[ Voor 30% gewijzigd door ggvw op 27-10-2004 22:41 ]

[ripexx]

ggvw schreef op 27 oktober 2004 @ 22:36:
[..]
is_executable() -- Tells whether the filename is executable

Dat is ook niet het probleem maar dan moet je wel alles controleren

pompiedom...

edit:

Kortom, je wilt je eigen scheduler maken in php/mysql en weet niet goed hoe je de scripts moet laten uitvoeren.

Hmm ik zelf zou toch voor de exec() of system() gaan, dat lijkt me de meest eenvoudige oplossing.

Hmm, zal er nog eens naar kijken.

[ggvw]

Wat voor soort controles wil je precies doen per script?

[ripexx]

ggvw schreef op 27 oktober 2004 @ 22:55:
Wat voor soort controles wil je precies doen per script?

Je zal dan de output goed moeten afvangen om het resultaat te loggen. Met een include is de variabele direct beschikbaar.

[Gerco]

Je kunt natuurlijk een dynamische include gebruiken:

PHP:

// Haal $scriptnaam uit database
include($scriptnaam);

Ik weet alleen niet wat voor effect dat gaat hebben als je dit in een loop zet met meerdere uit te voeren bestanden. Het zou zomaar kunnen dat 'ie dan gewoon de eerste 'n' keer gaat doen.

Een ander idee is misschien om verschillende classes te maken die een bepaalde functie uitvoeren en dan zoiets te doen (zoals je zelf ook al ongeveer voorstelt):

PHP:

include("job.class.php");
include("backup.class.php");
include("mailing.class.php");

// Haal $actie uit database

switch($actie) {
  case "backup": 
    $job = new BackupJob();
    break;

  case "mailing":
    $job = new MailJob();
}

if($job) {
  $job->log = $logger;
  $job->execute();
  $logger->storeresults();
}

[ Voor 74% gewijzigd door Gerco op 27-10-2004 23:54 ]

[prototype]

Gerco schreef op 27 oktober 2004 @ 23:48:
Je kunt natuurlijk een dynamische include gebruiken:

PHP:

// Haal $scriptnaam uit database
include($scriptnaam);

OMFG, jij vraagt er gewoon om ;ervan uitgaan dat alles in je database safedata is

[Gerco]

prototype schreef op 27 oktober 2004 @ 23:51:
OMFG, jij vraagt er gewoon om ;ervan uitgaan dat alles in je database safedata is

mja, of je bedenkt je dat het misschien wen peudeocode kan zijn en dat de security checks en dergelijke for the sake of clarity zijn weggelaten. Maar je kunt natuurlijk ook gewoon alles letterlijk nemen

[prototype]

Gerco schreef op 27 oktober 2004 @ 23:55:
[...]


mja, of je bedenkt je dat het misschien wen peudeocode kan zijn en dat de security checks en dergelijke for the sake of clarity zijn weggelaten. Maar je kunt natuurlijk ook gewoon alles letterlijk nemen

Zelfs als je dat al in beschouwing neemt is een dynamische include uiterst onvoorspelbaar en for the sake of safety absoluut niet aan te raden.

[Gerco]

prototype schreef op 27 oktober 2004 @ 23:57:
Zelfs als je dat al in beschouwing neemt is een dynamische include uiterst onvoorspelbaar en for the sake of safety absoluut niet aan te raden.

Als je dat als uitgangspunt neemt is een statische include en een exec() of system() precies even gevaarlijk. Als ik mijn variabele controleer met een switch of in_array() include ik alleen bestanden die ik eerst zelf heb opgegeven. Dit is precies hetzelfde met de andere twee methodes.

De enige manier waarop je daar problemen mee krijgt is als iemand je include on-disk verandert en dan krijg je met alle methodes problemen. Als iemand je files kan veranderen kun je wel ophouden met secure denken, dat heeft geen zin meer.

[prototype]

Gerco schreef op 28 oktober 2004 @ 00:04:
[...]

Als je dat als uitgangspunt neemt is een statische include en een exec() of system() precies even gevaarlijk. Als ik mijn variabele controleer met een switch of in_array() include ik alleen bestanden die ik eerst zelf heb opgegeven. Dit is precies hetzelfde met de andere twee methodes.

Dat is imho geen dynamische include meer, je maakt een selectie dan uit een bestaande set. Dat is in mijn mening iets anders. Bovendien zou ik include/require enkel gebruiken als je opzettelijk mogelijke recursieve includes/requires wil uitvoeren, anders zou ik uitwijken naar include_once/require_once.

[dawuss]

prototype schreef op 28 oktober 2004 @ 00:07:
[...]


Dat is imho geen dynamische include meer, je maakt een selectie dan uit een bestaande set. Dat is in mijn mening iets anders. Bovendien zou ik include/require enkel gebruiken als je opzettelijk mogelijke recursieve includes/requires wil uitvoeren, anders zou ik uitwijken naar include_once/require_once.

Niet echt mijn gebied, maar zijn jullie nu niet een beetje de discussie aan het kapen / verschuiven? Misschien is het eerst een idee om de topicstarter wat verder op weg te helpen, om daarna het security issue aan te snijden?

Just my 2 cents

Wat betreft het topic: Misschien een idee om aan te geven wat voor taken je in gedachten had om uit te voeren? Wat vooral relevant is: Wie bepaalt die taken? Een mens? Een script?

[ripexx]

dawuss schreef op 28 oktober 2004 @ 00:26:
[...]

Niet echt mijn gebied, maar zijn jullie nu niet een beetje de discussie aan het kapen / verschuiven? Misschien is het eerst een idee om de topicstarter wat verder op weg te helpen, om daarna het security issue aan te snijden?

Security wordt wel aangedacht Script wordt in ieder geval gestart via een cron job en mag alleen op basis van enkele security rules worden start vanaf een webbrowser. Dat is dan puur en alleen als fallback.

Wat betreft het topic: Misschien een idee om aan te geven wat voor taken je in gedachten had om uit te voeren? Wat vooral relevant is: Wie bepaalt die taken? Een mens? Een script?

In eerste instantie zal het script drie belangrijke dingen gaan doen wat later zal worden uitgebreid.
- Stats uit datadump verwerken naar snel beschikbaar formaat
- Dagelijkse backup van MySQL database + versturen via mail en ftp.
- Wekelijkse mailing naar leden aan de hand van dynamische business rules

Later toevoegen
- Koppelingen met andere sites, data uitwisseling
- Rapportages en selecties van database maken.

Het probleem waarom ik eigenlijk twijfel om include() te gebruiken is het memory probleem. Ik beheer de server niet en wil dus niet dat het memory,volloopt door mijn scripts, aangezien PHP een memory limit per script kent. Voordeel van exec() etc. is dan weer dat je elk proces apart opstart.

[Gerco]

ripexx schreef op 28 oktober 2004 @ 09:22:
Het probleem waarom ik eigenlijk twijfel om include() te gebruiken is het memory probleem. Ik beheer de server niet en wil dus niet dat het memory,volloopt door mijn scripts, aangezien PHP een memory limit per script kent. Voordeel van exec() etc. is dan weer dat je elk proces apart opstart.

Er zijn sites die object georienteerd opgezet zijn (zoals React) en als je daar het aantal (geneste) includes gaat tellen kom je niet op lage getallen uit denk ik zo. Als jij vijf of zes includes wilt gebruiken kan ik me niet voorstellen dat dat een probleem is.

Nadeel van exec() is dat het niet werkt op safemode hosts, op hosts waar het los is uitgeschakeld of waar geen cli-php is geinstalleerd. Verder is het, mijns inziens, lastiger om iets zinnigs met je results te doen. Je zult altijd een tussenstap moeten hebben (opslaan in file/database, teruggeven via stdout) ipv het direct in een logobject of iets dergelijks op te slaan.

Nu moet ik zeggen dat opslaan van logs in de database ook een handige optie is, maar voor een script wat de database moet backuppen lijkt het me wat minder handig

[ Voor 8% gewijzigd door Gerco op 28-10-2004 09:39 ]

[ripexx]

Gerco schreef op 28 oktober 2004 @ 09:38:
[...]

Er zijn sites die object georienteerd opgezet zijn (zoals React) en als je daar het aantal (geneste) includes gaat tellen kom je niet op lage getallen uit denk ik zo. Als jij vijf of zes includes wilt gebruiken kan ik me niet voorstellen dat dat een probleem is.

Het aantal includes baart me ook geen zorgen. De huidig frontend heeft all een include of 6-10. Het zit meer in het werken met grotere resluts set waardoor je aan de memory limieten zal kunnen komen. Maar daar is dan ook nog wel een workaroud voor te bedenken.

Nadeel van exec() is dat het niet werkt op safemode hosts, op hosts waar het los is uitgeschakeld of waar geen cli-php is geinstalleerd. Verder is het, mijns inziens, lastiger om iets zinnigs met je results te doen. Je zult altijd een tussenstap moeten hebben (opslaan in file/database, teruggeven via stdout) ipv het direct in een logobject of iets dergelijks op te slaan.

Daarheeft een include eigenlijk wel mijn voorkeur Daarnaast zit alles dan in php en kan ik aales vandaar uit aansturen.

Nu moet ik zeggen dat opslaan van logs in de database ook een handige optie is, maar voor een script wat de database moet backuppen lijkt het me wat minder handig

De backup gaat wel via een exec() (gebruik namelijk mysqldump) en tar om te zippen.

[WormLord]

Al eens gedacht aan het gebruik van curl? Dan worden je php-scripts 'normaal' aangeroepen en kan je de uitvoer en html-header loggen.