[Nextcloud] Cron mit PHP 7

[maalik]

Hallo zusammen,

bei mir läuft Nextcloud 11.0.1, Apache 2.4 und PHP 7.0

Der bisherige Cron sieht folgenderweise aus:

/bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/nextcloud/cron.php" http

Da PHP 5.6 noch akiv ist, funktioniert der auch noch. Generell ist es ja aber wünschenswert, das auf PHp 7.0 umzustellen. Dabei funktioniert aber leider weder

/bin/su -s /bin/sh -c "/usr/local/bin/php70 -f /volume1/web/nextcloud/cron.php" http

noch

/bin/su -s /bin/sh -c "/usr/local/etc/php70 -f /volume1/web/nextcloud/cron.php" http

Andere Ideen?

lg

 

[maalik]

Keiner?

 

[Fusion]

Kannst mal verraten, was du wo alles eingestellt hast um Apache2.4/Php7 zum laufen zu bekommen?

Schaue mir aktuell das docker wonderfall image an mit nginx/php7.1, weil mir die Suche in den Untiefen der syno-webserver config langsam zu blöd wird.

 

[maalik]

Habe beides installiert, auf PHP7 umgestellt und unter Web Station bei PHP-Einstellungen unter PHP7.0 die open_basedir angepasst:
/tmp:/var/services/tmp:/var/services/web:/var/services/homes:/volume1/owncloud/:/dev/urandom:/volume1/nextcloud/:/volume1/web/joomla:/proc/meminfo

sowie alle Erweiterungen aktiviert bis auf folgende:
dba, exif, mailparse, pdo_pgsql, pdo_sqlite, pgsql, sqlite3, ssh 2

 

[Fusion]

Geht das noch ein wenig ausführlicher bitte?

Habe ein vHost mit Apache 2.4 /PHP 7, passender open_basedir für PHP 7 und es endet in einem File not found (http://IP/apps/files/) sobald die Grundeinrichtung durch ist und er sich das erste mal als Admin einloggen will.

Habe alle 3 webserver und beide php Versionen installiert
Backend habe ich auf nginx/php7
Für php56/7 habe ich open_basedir und module gesetzt
vHost mit Apache22/php56 und nextcloud 11.0.1 läuft ohne Probleme (mein Produktiv-Host)
vHost mit Apache24/php70 und nextcloud 11.0.1 endet im genannten File not found von Nextcloud gemeldet
vHost mit nginx/php7 endet in 404 (glaube erst nach erstem Setup), aber das verwundert mich jetzt nicht.

 

[maalik]

Ich nutze keinen vHost, vielleicht liegt es daran? Pack doch Nextcloud mal nach domain.tld/nextcloud

Ansonsten wüsste ich nicht, was ich genauer beschreiben kann. Mach doch mal ein Screenshot von deiner Konfiguration.

 

[OdinsAuge]

@Fusion, kann man denn das Docker Image auf jeder DS installieren? Es gibt doch ein Docker Package von Synology selber aber das gibts ja nicht für jede DS.

Ich lauf mit der Nextcloud auch auf Apache 2.4 und php 7.
@Fusion ich hatte die selben Probleme wie du, jetzt gehts aber, keine Ahnung was jetzt anders ist als vorher. Ich hab auch nur devurandom und den pfad zu meinem Nextcloud Data verzeichnis zu open base dir hinzugefügt und die module aktiviert wie auch unter php 5.6

 

[Fusion]

Die Syno muss Docker an sich unterstützen, was du danach für Images einsetzt ist egal / beliebig. Deine DS215+ unterstützt leider Docker an sich schon nicht.

Hast du einen vHost damit laufen, welche Einstellung am allgemeinen Backend, etc?

 

[OdinsAuge]

Ich hab derzeit noch keinen vHost. Meine DOmain zieht gerade um, sobald das erledigt ist, werd ich mal einen vHost einrichten und testen obs dann immer noch geht und davon berichten.

 

[Handfest]

@Fusion: Kann es sein dass dein Nextcloud-data-Directory ausserhalb des Nextcloud-web-Directorys liegt (sollte ja so sein)
Ich habe den von dir beschriebenen Effekt auch. Mein Nextcloud-web-Directory liegt in einem Subdirectory in /volume1/www (auf das in der vhosts verwiesen wird), mein Nextcloud-data-Directory liegt im Root von volume2 (/volume2/nextcloud_data)

Ich habe mich bislang nicht intensiv damit beschäftigt, aber die oberflächliche Suche hat nichts ergeben was nicht passt.

Gruß Handfest

 

[Fusion]

@Handfest - ja, data ist auch ausgelagert, innerhalb von Volume 1 auf eine andere Freigabe.
Aber geht mir ähnlich. Für eine Tiefensuche hatte ich noch keine Zeit und mit der "oberflächlichen Inspektion" noch nichts gesehen.

 

[kerku]

Hallo zusammen,

bei mir läuft Nextcloud 11.0.1, Apache 2.4 und PHP 7.0

@maalik: hast du mittlerweile herausbekommen, ob und wie der Cronjob mit php 7.0 funktioniert?

 

[maalik]

Hey kerku,

nein, leider nicht. Habe mich aber seitdem auch nicht mehr mit beschäftigt.

 

[TomSt]

Nextcloud Cron ...

geht entweder mit WebCron:

DSM->Systemsteuerung->Aufgabenplaner

Befehl: curl https://nextcloud.example.com/cron.php bzw. curl https://example.com/nextcloud/cron.php
Zertifikatsprobleme ggf. mit Option --insecure zwischen curl und dem Pfad ausräumen.

oder mit systemeigenen Cron:

DSM->Cronjob Editor:

Who = root
Command = /bin/su http -s /bin/sh -c '/usr/local/bin/php70 -c /usr/syno/etc/packages/WebStation/php70/conf.d/user_settings.ini -f /var/services/web/nextcloud/cron.php'

wobei zu beachten ist, dass erstens für PHP7 mit der Option -c die Lokation der php.ini mitgegeben wird (/usr/syno/etc/packages/WebStation/php70/conf.d/user_settings.ini), da PHP hier unter CLI läuft und lediglich die Standardmodule aus /lib/php/modules lädt (da ist dann kein pdo_mysql dabei, wodurch der Job dann leider keinen Zugriff auf die MySQL-DB hat, zusätzliche open_basedir Einstellungen fehlen dann ebenso)
und zweitens bei Euch der Pfad zum Nextcloud Cron anders aussehen kann (statt /var/services/web/nextcloud/cron.php z.B. /var/services/web/cron.php wenn direkt ins Stammverzeichnis installiert wurde).

Liebe Grüße,

der Tom

 

[maalik]

Hey Tom! Danke für die Antwort. Den zweiten Teil am Ende verstehe ich, aber was meinst du mit "(...) da PHP hier unter CLI läuft und lediglich die Standardmodule aus /lib/php/modules lädt (...)"

Verstehe da leider nicht alles ganz genau.

 

[TomSt]

siehe http://www.php-cli.com/

Auf der Kommandozeile rufst Du quasi ein "nacktes" PHP auf, welches ohne weitere Konfigurationsoptionen nur nur einige wenige Standardmodule kennt. Die Konfigurationseinstellungen, die für den Betrieb der Webserveranwendung notwendig sind werden in der Webstation unter PHP-Konfiguration für die einzelnen PHP Varianten gepflegt. Dort wird für Nextcloud z.B. pdo_mysql eingeschaltet, wenn Nextcloud mit MySQL laufen soll oder im Feld open_basedir der Zugriffspfad für ein außerhalb des Webverzeichnis liegendes DATA-Verzeichnis ergänzt. Diese Konfiguration kennt php auf der Kommandozeile nicht, ergo wäre beim Aufruf ohne Hinweis auf die zu nutzenden Konfigurationsdaten spätestens beim ersten DB-Zugriff auf MySQL oder Zugriffsversuch aufs Datenverzeichnis der Cronjob mit Fehler beendet. Deshalb soll hier beim php70 Aufruf der Parameter -c mit der genannten absoluten Pfadangabe zur php.ini (=user_settings.ini) mitgegeben werden. Für Verwendung von php 5.6 ersetzt Du einfach die 70 durch 56, es gilt dann eben auch die in der Webstation gepflegte Konfiguration für php 5.6.

Hoffe es war halbwegs verständlich, viele Grüße, Tom

 

[imforumman]

[...]mit systemeigenen Cron:

DSM->Cronjob Editor:

Who = root
Command = /bin/su http -s /bin/sh -c '/usr/local/bin/php70 -c /usr/syno/etc/packages/WebStation/php70/conf.d/user_settings.ini -f /var/services/web/nextcloud/cron.php'

YES! Danke, das hätte ich alleine nicht raus gekriegt. Vielen, vielen Dank. (ist so doch eleganter als über webcron)

(für Andere, bei mir lautet der Befehl dann "/bin/su http -s /bin/sh -c '/usr/local/bin/php70 -c /usr/syno/etc/packages/WebStation/php70/conf.d/user_settings.ini -f /volume1/web/nextcloud/cron.php"

 

[Andy+]

Vielleicht mal etwas mehr facts:

Grundsätzlich sollte man im Betrieb mit ownCloud und nextCloud die komplette open_basedir im Webserver anhaken und leeren oder "none" reinschreiben.

Dann, die Philosophen sollen zwischen ownCloud 10 oder nextCloud 12 entscheiden, verhalten tun sich beide Installationen gleich in solchen Dingen, beides läuft mit Apache 2.4 und PHP 7.0 klaglos und ohne Einschränkungen, beides im Webserver aktivierbar. Ob dann noch andere APPs funktionieren, sagen nur Tests.

Zu guter letzt, und das gilt wieder für beide Installationen, laufen crontab-Einräge nur mir php56-Verweisen, z.B.

0,10,20,30,40,50 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http && /bin/echo $(/bin/date +"ok am \%Y-\%m-\%d um \%H-\%M-\%S Uhr") >> /volume1/Sicherungen/Protokolle/ownCloud_cron_php__$(/bin/date +\%Y-\%m-\%d).log 2>&1

oder

0,10,20,30,40,50 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/occ files:cleanup" http >> /volume1/Sicherungen/Protokolle/ownCloud_cleanup__$(/bin/date +\%Y-\%m-\%d).log 2>&1
1,11,21,31,41,51 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/occ files:scan rescan" http >> /volume1/Sicherungen/Protokolle/ownCloud_scan_rescan__$(/bin/date +\%Y-\%m-\%d).log 2>&1

achtet jedoch auf Feinheiten, wie

statt "%d.%m.%Y um %H:%M:%S", besser "\%Y-\%m-\%d um \%H-\%M-\%S" usw.

Jedenfalls liefen bei mir beide Installationen, sogar auf derselben DS, ohne Probleme und unter Beachtung der genannten Feinheiten auch alle crontab-Einträge. Vergleichend kann ich jedoch nur sagen, dass ownCloud eine deutlich bessere Performance hat, nextCloud 12 ist ungewöhnlich träge, weshalb, ist mir unklar.

 

[imforumman]

Vielleicht mal etwas mehr facts:

Grundsätzlich sollte man im Betrieb mit ownCloud und nextCloud die komplette open_basedir im Webserver anhaken und leeren oder "none" reinschreiben.

Dann, die Philosophen sollen zwischen ownCloud 10 oder nextCloud 12 entscheiden, verhalten tun sich beide Installationen gleich in solchen Dingen, beides läuft mit Apache 2.4 und PHP 7.0 klaglos und ohne Einschränkungen, beides im Webserver aktivierbar. Ob dann noch andere APPs funktionieren, sagen nur Tests.

Zu guter letzt, und das gilt wieder für beide Installationen, laufen crontab-Einräge nur mir php56-Verweisen, z.B.

0,10,20,30,40,50 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http && /bin/echo $(/bin/date +"ok am \%Y-\%m-\%d um \%H-\%M-\%S Uhr") >> /volume1/Sicherungen/Protokolle/ownCloud_cron_php__$(/bin/date +\%Y-\%m-\%d).log 2>&1

oder

0,10,20,30,40,50 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/occ files:cleanup" http >> /volume1/Sicherungen/Protokolle/ownCloud_cleanup__$(/bin/date +\%Y-\%m-\%d).log 2>&1
1,11,21,31,41,51 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/occ files:scan rescan" http >> /volume1/Sicherungen/Protokolle/ownCloud_scan_rescan__$(/bin/date +\%Y-\%m-\%d).log 2>&1

achtet jedoch auf Feinheiten, wie

statt "%d.%m.%Y um %H:%M:%S", besser "\%Y-\%m-\%d um \%H-\%M-\%S" usw.

Jedenfalls liefen bei mir beide Installationen, sogar auf derselben DS, ohne Probleme und unter Beachtung der genannten Feinheiten auch alle crontab-Einträge. Vergleichend kann ich jedoch nur sagen, dass ownCloud eine deutlich bessere Performance hat, nextCloud 12 ist ungewöhnlich träge, weshalb, ist mir unklar.

Sorry, aber die Aussagen leuchten nicht ein, weswegen ich dies nicht einfach so stehen lassen kann:

mit PHP7 laufen auch die Scheduled tasks es wie von TomSt angeleitet super, zumindest bei NextCloud 12 (die bei mir wesentlich flotter läuft als OC10).

 

[Andy+]

Dann nimmst Du wohl den Aufgabenplaner, auch interessant. Ich komm ja aus der DSM 4-er und 5-er Zeit, da ging das Ganze nur im crontab. Vielleicht kannst Du mal ein paar Infos senden, wie die Einträge aussehen....