PHP-CLI soll Script für unterschieldiche DOCUMENT_ROOTs ausführen

[TS]

Hallo und guten Tag Ihr Selfer,

ich brauche mal eine Idee:

ein per Cronjob über PHP-CLI aufgerufenes PHP-Skript soll weitere PHP-Skripte jeweils für eigene DOCUMENT_ROOTs ausführen. Das beinhaltet auch, dass die "Subskripte" auch die lokalen Ini-Einstellungen benutzen sollen.

Ist sowas überhaupt möglich und wie könnte man es dann am elegantesten lösen?

Grüße
TS

[Google weiß alles]

Schreib das Verzeichnis in die Umgebung ...

$_ENV

<?php
## test_env.php
echo 'TestVar: "' , $_SERVER['testvar'] , "\n";
?>

Ausführen:

~> testvar='ich teste' php test_env.php
TestVar: "ich teste"

Variante:

~> export testvar='ich teste';
~> php test_env.php
TestVar: "ich teste"

Bei älteren PHP-Versionen steht die Umgebung in $_ENV.

[Mitleser]

Schreib das Verzeichnis in die Umgebung ...

Ich weiß nicht... Auch wenn dann unter PHP womöglich der Verzeichniskontext / die ini stimmt, fehlt immer noch Webserverkontext und das Script wird womöglich auch im falschen Userkontext ausgeführt.

[Google weiß alles]

Schreib das Verzeichnis in die Umgebung ...

Ich weiß nicht... Auch wenn dann unter PHP womöglich der Verzeichniskontext / die ini stimmt, fehlt immer noch Webserverkontext und das Script wird womöglich auch im falschen Userkontext ausgeführt.

Jaja, Die Forderung nach der anderen php.ini erfüllen meine anderen Vorschläge. Den "Usercontext" kann man "bearbeiten", in dem man mit sudo crontab -eu www-data die richtige crontab bearbeitet...

[Mitleser]

Ist sowas überhaupt möglich und wie könnte man es dann am elegantesten lösen?

Via CLI kann ich mir das nicht sauber vorstellen, weil schlicht der Webserverkontext fehlt.

Wenn Du den Webserverkontext brauchst, solltest Du das IMHO auch über diesen laufen lassen, z.B. mittels wget, bzw. innerhalb Deines crontab.php dann per CURL o.ä.

[TS]

Hallo und guten Tag,

Ist sowas überhaupt möglich und wie könnte man es dann am elegantesten lösen?

Via CLI kann ich mir das nicht sauber vorstellen, weil schlicht der Webserverkontext fehlt.

Stimmt, so weit war ich auch schon ;-)
Es gibt ab PHP-CLI 5.4.x die Möglichkeit, dafür einen internen Webserver aufzurufen, also das geforderte Verhalten damit "durch die Brust ins Auge" herbeizuführen.

Wenn Du den Webserverkontext brauchst, solltest Du das IMHO auch über diesen laufen lassen, z.B. mittels wget, bzw. innerhalb Deines crontab.php dann per CURL o.ä.

Das war eben auch mein nächster Denkschritt. Einfach ein einheitliches Skript in alle Dokument-Roots legen, das dann durch das gemeinsame Startskript aufgerufen wird. Damit damit kein Schindluder betrieben wird, wird es mit den Rechten 440 und root:www-data belegt und im Skript werden $_SERVER['REMOTE_ADDR'] und $_SERVER['SERVER_ADDR'] gegeneinander abgeglichen. Der Aufruf erfolgt durch "wget <DOMAIN>/skript.php > /dev/null".

Das funktioniert scheinbar sogar so.

Ist mir jedoch noch zu holzhackerisch :-O

Vielleicht gibt es eine bessere Lösung? Stichworte wären dabei:

• Domain-Kontext
• lokale ini-Einstellungen des jeweiligen Virt-Hosts
• unkompliziertes Handling beim Hinzufügen oder Ändern/Entfernen von Virt-Hosts.

Grüße
TS

[Google weiß alles]

Das beinhaltet auch, dass die "Subskripte" auch die lokalen Ini-Einstellungen benutzen sollen.

Dann bietet es sich an, vor dem Ausführen des Skriptes, also dem Start von PHP schlicht und einfach in das Verzeichnis zu wechseln:

cd /sonstwohin; php skript.php

Das kann auch im crontab formuliert werden!

oder:

php -c /pfad_mit_php.ini

Also dem Verzeichnis. php --help hätte Dich weiter gebracht:

Usage: php [options] [-f] <file> [--] [args...]
   php [options] -r <code> [--] [args...]
   php [options] [-B <begin_code>] -R <code> [-E <end_code>] [--] [args...]
   php [options] [-B <begin_code>] -F <file> [-E <end_code>] [--] [args...]
   php [options] -S <addr>:<port> [-t docroot]
   php [options] -- [args...]
   php [options] -a

  -a               Run interactively
  -c <path>|<file> Look for php.ini file in this directory
  -n               No php.ini file will be used
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -f <file>        Parse and execute <file>.
  -h               This help
  -i               PHP information
  -l               Syntax check only (lint)
  -m               Show compiled in modules
  -r <code>        Run PHP <code> without using script tags <?..?>
  -B <begin_code>  Run PHP <begin_code> before processing input lines
  -R <code>        Run PHP <code> for every input line
  -F <file>        Parse and execute <file> for every input line
  -E <end_code>    Run PHP <end_code> after processing all input lines
  -H               Hide any passed arguments from external tools.
  -S <addr>:<port> Run with built-in web server.
  -t <docroot>     Specify document root <docroot> for built-in web server.
  -s               Output HTML syntax highlighted source.
  -v               Version number
  -w               Output source with stripped comments and whitespace.
  -z <file>        Load Zend extension <file>.

  args...          Arguments passed to script. Use -- args when first argument
                   starts with - or script is read from stdin

  --ini            Show configuration file names

  --rf <name>      Show information about function <name>.
  --rc <name>      Show information about class <name>.
  --re <name>      Show information about extension <name>.
  --rz <name>      Show information about Zend extension <name>.                                                                                                                                                                             
  --ri <name>      Show configuration for extension <name>. 

[TS]

Hallo und guten Tag,

Das beinhaltet auch, dass die "Subskripte" auch die lokalen Ini-Einstellungen benutzen sollen.

Dann bietet es sich an, vor dem Ausführen des Skriptes, also dem Start von PHP schlicht und einfach in das Verzeichnis zu wechseln:

cd /sonstwohin; php skript.php

Dadurch wird es doch aber nicht mit den lokalen INI-Einstellungen der zugehörigen Domain (des Virt Hosts) ausgeführt? Das wäre aber die Voraussetzung!

Grüße
TS

[Google weiß alles]

Dann bietet es sich an, vor dem Ausführen des Skriptes, also dem Start von PHP schlicht und einfach in das Verzeichnis zu wechseln:

cd /sonstwohin; php skript.php

Dadurch wird es doch aber nicht mit den lokalen INI-Einstellungen der zugehörigen Domain (des Virt Hosts) ausgeführt? Das wäre aber die Voraussetzung!

Wenn es in /sonstwohin eine php.ini gibt, die für den ausführenden Benutzer lesbar ist, dann laut Doku schon:

Seit PHP 5.3.0 bietet PHP Unterstützung für Konfigurations-INI-Dateien auf Verzeichnisebene an. Diese Dateien werden nur nur durch die CGI/FastCGI-SAPI verarbeitet. Durch diese Funktionalität wird die htscanner-PECL-Erweiterung obsolet.

Hint: phpinfo() zeigt auch die gelesenen ini-Dateien an.

Hast Du Zweifel, dann ist php -c /verzeichnis/mit_php.ini/ oder php -c /pfad/zur/ini-Datei eine stabile Lösung.

[TS]

Hallo und guten Tag,

Dann bietet es sich an, vor dem Ausführen des Skriptes, also dem Start von PHP schlicht und einfach in das Verzeichnis zu wechseln:

cd /sonstwohin; php skript.php

Dadurch wird es doch aber nicht mit den lokalen INI-Einstellungen der zugehörigen Domain (des Virt Hosts) ausgeführt? Das wäre aber die Voraussetzung!

Wenn es in /sonstwohin eine php.ini gibt, die für den ausführenden Benutzer lesbar ist, dann laut Doku schon:

Seit PHP 5.3.0 bietet PHP Unterstützung für Konfigurations-INI-Dateien auf Verzeichnisebene an. Diese Dateien werden nur nur durch die CGI/FastCGI-SAPI verarbeitet. Durch diese Funktionalität wird die htscanner-PECL-Erweiterung obsolet.

Hint: phpinfo() zeigt auch die gelesenen ini-Dateien an.

Hast Du Zweifel, dann ist php -c /verzeichnis/mit_php.ini/ oder php -c /pfad/zur/ini-Datei eine stabile Lösung.

Leider nicht so stabil, wie ich sie benötige. Ich muss sicherstellen, dass die PHP-Direktiven aus der Virtual Host Konfiguration berücksichtigt werden und davon diejenigen, die als php_admin_value und php_admin_flag gekennzeichnet wurden, auch nicht geändert werden können durch den Anwendungsprogrammierer.

Aber sonst wäre das sicherlich eine schlankere Lösung, als meine Holzhackermethode ohoh.

Grüße
TS