ownCloud 9 ist da!

[maxafe]

hi maxafe,

ich habe nur feststellen können, das die Pfade sich für den Kalender und den Kontakten geändert haben. OK,das es keine Importfunktion für Kontakte gibt finde ich nicht wirklich prickelnd, aber sonst läuft alles einwandfrei.

Die nicht vorhandene Importfunktion war der Hauptgrund. Die Pfade (CalDAV, CardDAV) hab ich nicht gefunden und Farben für die Kalender gab es auch weniger?

 

[reizwolf]

kurzer Nachtrag für diesen Artikel:

CRON läuft jetzt auch unter DSM 6.0 mit owncloud 9.0.0. Der Verzeichnispfad in der crontab musste lediglich angepasst werden, siehe:

*/15 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

 

[Andy+]

Danke für den Hinweis, dann werde ich mal neue Tests machen mit dem Rescan.

 

[Andy+]

Habe ich genauso drin, nur mit Log, aber funzt leider auch nicht:

*/10 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http >> /volume1/web/owncloud/data/logs/cron_php_$(date +%Y-%m-%d).log 2>&1

 

[OdinsAuge]

Hi, Ihr schein ja mit dem Upgrade schon recht erfolgreich gewesen zu sein.
Ich versuche mich gerade daran und scheitere am occ upgrade mit folgendem Fehler: Failed to connect to the database: An exception occured in driver: could not find driver in /volume1/web/owncloud/lib/private/db/connection.php:52
Ist das ein Rechteproblem?
Nachdem ich den neuen OC folder entpackt habe hab ich natürlich meinen User als owner eingetragen, ich habe dann
chown -R http:http owncloud/lib gemacht sowie chmod 0750 so wies eingentlich in der OC DOku angegeben ist, aber der Fehler tritt imemr noch auf.

 

[maalik]

Der angepasste Pfad für Cron klappt bei mir leider auch nicht. Hat denn keiner eine Lösung dafür?

/edit: Okay, habe nichts gesagt, geht doch!

 

[Andy+]

kurzer Nachtrag für diesen Artikel:

CRON läuft jetzt auch unter DSM 6.0 mit owncloud 9.0.0. Der Verzeichnispfad in der crontab musste lediglich angepasst werden, siehe:

*/15 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

Was hast Du alles gemacht, dass das so läuft?

 

[Andy+]

Der angepasste Pfad für Cron klappt bei mir leider auch nicht. Hat denn keiner eine Lösung dafür?

/edit: Okay, habe nichts gesagt, geht doch!

Was hast Du verändert, dass das nun geht?

 

[maalik]

Ich hatte das mal in einem anderen Thread erklärt:

Hallo an alle. Nachdem ich das gleiche Problem hatte wollte ich kurz für alle anderen Laien eine Anleitung schreiben, die wie ich vorher noch nicht groß mit SSH gearbeitet haben oder das nicht ganz verstehen:

Zuerst muss wahrscheinlich über SSH der user des owncloud-Verzeichnisses auf http gesetzt werden, sonst kommt folgender Fehler:

Console has to be executed with the same user as the web server is operated
Current user: http
Web server user: admin

Das macht ihr, indem ihr folgenden Code in SSH eingebt:

sudo chown -R http /volume1/web/owncloud

(ggf. den Pfad anpassen, falls er bei euch anders aussieht)

Als nächstes müsst ihr ja den cron-job einfügen. Dafür gibt es bei SSH einen Editor, der sich vi nennt.
Öffnet mit diesem also die Datei mit folgendem Befehl:

sudo vi /etc/crontab

Dann wird die aktuelle Datei in das Fenster geschrieben, wenn ihr was ändert, ändert es das noch nicht automatisch in der Datei.
Standardmäßig könnt ihr nun den Cursor mit den Pfeiltasten bewegen. Da wir ja ganz unten was einfügen wollen, gehen wir in die letzte Zeile in der was geschrieben ist.
vi hat Befehle, mit denen ihr sagen könnt, was und wie ihr nun was schreiben wollt, eine Erklärung findet ihr hier:
http://www.synology-wiki.de/index.php/Vi

Da wir ja nun eine neue Zeile wollen, drücken wir also den Buchstaben o. ("o - (open a new line) öffnet eine neue Zeile nach der Cursorposition und bewegt den Cursor an den Zeilenanfang")

Nun schreibt ihr folgendes:

*/15	*	*	*	*	root	/bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

Achtet hierbei genau darauf, dass alles richtig geschrieben ist. Vi ignoriert Leerzeichen, ihr könnt also ruhig so viele setzen, dass die einzelnen Werte quasi in der optisch richtigten Spalte stehen.

Das */15 am Anfang steht für "alle 15 Minuten". Das könnt ihr natürlich anpassen indem ihr die 15 einfach ändert.

Wenn ihr damit fertig seid, drückt ihr die ESC-Taste. Damit kommt ihr aus dem Schreibmodus raus und könnt mit dem Befehl

:wq

und einem Enter die geschriebenen Sachen in die Datei schreiben und Vi gleichzeitig beenden.

Nun musst ihr noch Cron neustarten. Dafür folgenden Befehl nutzen:

sudo /usr/syno/sbin/synoservicectl –restart crond

Damit sollte alles funktionieren. Ihr könnt ja erstmal das */15 in */1 ändern, dann müsst ihr nicht 15 Minuten warten, ob alles funktioniert. Falls owncloud euch dann mitteilt, dass der Cron ausgeführt wurde, könnt ihr es ja wieder auf */15 ändern.

 

[reizwolf]

hmmm, bei mir reichte das Ändern des Pfades mittels MC in der crontab als root. Dann nur im owncloud-Backend Cron markiert.
Bin jetzt nur gespannt, ob der Updater von owncloud im laufenden Betrieb mit verschärften Rechten, ein mögliches Update ankündigt.
z.Z läuft noch owncloud 9.0.0.

 

[Andy+]

Ich habe die Konfiguration auch so und trotzdem gehts nicht. Das könnte an den verschiedenen Plattformen bzw. Prozessoren liegen. Ich habe gerade jetzt erst festgestellt, daß Scripte auf einer Atom D2700-Plattform laufen und auf einer Atom D2538 nicht mehr oder nur dann, wenn die Befehlsfolge etwas modifiziert ist. Von daher hilft immer nur testen.

 

[Andy+]

Ich habe nun folgende Einträge in der crontab :

*/15 * * * * root /usr/local/bin/php56 -f /volume1/web/owncloud/data/scripts/cron_lock_unlock.sh >> /volume1/web/owncloud/data/logs/cron_lock_unlock_$(date +%Y-%m-%d).log 2>&1
*/30 * * * * root /bin/su -s /bin/sh -c "find /volume1/web/owncloud/data/logs/ -name '*.log' -mmin +1440 -delete"
*/15 * * * * root /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http >> /volume1/web/owncloud/data/logs/cron_php_$(date +%Y-%m-%d).log 2>&1
0 21 * * * root crond -bS -l 0 -L cron_logging.log -c /volume1/web/owncloud/data/logs
0,30 7-23 * * * root /bin/su -s /bin/sh -c "cd /volume1/web/owncloud && /usr/local/bin/php56 -f occ files:scan rescan" http >> /volume1/web/owncloud/data/logs/cron_rescan_rescan_$(date +%Y-%m-%d_%H-%M-%S).log 2>&1
10 21 * * * root /bin/su -s /bin/sh -c "cd /volume1/web/owncloud && /usr/local/bin/php56 -f occ files:scan --all" http >> /volume1/web/owncloud/data/logs/cron_rescan_all_$(date +%Y-%m-%d_%H-%M-%S).log 2>&1

Im Grunde läuft keine dieser Zeilen automatisch. Das ist der Fehler. Starte ich die Zeilen einzeln über die Konsole, also z.B.

/bin/su -s /bin/sh -c "cd /volume1/web/owncloud && /usr/local/bin/php56 -f occ files:scan rescan" http >> /volume1/web/owncloud/data/logs/cron_rescan_rescan_$(date +%Y-%m-%d_%H-%M-%S).log 2>&1

dann erscheint mit einem male auch eine Logdatei und das Kommando wird ausgeführt. Die spannende Frage ist nun, weshalb cron diese Zeilen, und noch andere mehr, nicht automatsich ausführt, obwohl ich nach jeder Änderung selbstverständlich eingebe :

/$ /usr/syno/sbin/synoservicectl --restart crond
crond restarted.

Von daher ist dieser neu gestartet. Wie erklärt sich dieses Verhalten, was ich allerdings nur bei DSM 6 beobachten kann.

 

[Frogman]

Aufgaben in ownCloud 9

Wer bereits ownCloud 9 nutzt (aktuell 9.0.2) und auf Tasks wert legt, kann trotz der noch nicht angepaßten offiziellen Version im Store auf die DAVClient-Version im DAVClient-Branch ausweichen, die reibungslos läuft (die wird dann beizeiten in den master gemerged). Hintergründe dazu finden sich hier.
Dazu das Archiv entpacken und die Inhalte als Ordner 'tasks' in den 'apps'-Order von ownCloud kopieren und die richtigen Rechte einstellen (dazu findet man hier Infos bzw. ein Script).
Da Tasks zunächst nicht in der GUI unter den nichtaktivierten Apps auftaucht, muss man es auf der Konsole aktivieren - dazu einfach als root dort eingeben:

 /bin/su -s /bin/sh -c "/[COLOR=#b22222]volume1/web/owncloud[/COLOR]/occ app:enable tasks" http

(wobei ihr bei Bedarf den roten Teil des Pfades zum ownCloud-Verzeichnis anpassen könnt).

By the way:
Wer ein androides Smartphone nutzt und darauf bspw. aCalendar+ nutzt (also eine Kalenderapp, die Aufgaben unterstützt), der kann mit DAVdroid und OpenTasks problemlos zwischen dem Androiden und ownCloud 9 die Aufgaben synchronisieren und sich im Kalender des Smartphones anzeigen lassen.
Wichtiger Hinweis: auf dem Smartphone muss OpenTasks vor DAVdroid installiert werden!

 

[Frogman]

fail2ban mit ownCloud 9

Wer die ownCloud-Logins mit fail2ban absichern möchte (also dem Sperren von IP-Adressen bei mehrfachen fehlerhaften Login-Versuchen), kann für ownCloud 9 mit folgendem Filter in der aktuellen fail2ban 0.9.3 arbeiten:

# Fail2Ban filter for owncloud 8.2 and 9
#


[INCLUDES]

before = common.conf

[Definition]
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login  failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"}

ignoreregex =

 

[maxafe]

Bei mir zeigt der Updater nie ein Update an. Die ownCloud liegt im Web-Ordner, was anscheinend von einigen nicht empfohlen wird. Ist das ein Rechte-Probleme und wie behebe ich das bzw. mache ein manuelles Upgrade? Bei der offiziellen Anleitung zerschieß ich mir jedes Mal das System.

 

[Frogman]

Diesen Hinweis in der Dokumentation hast Du aber beachtet?

 

[reizwolf]

Bei mir wird auch schon seit x-Versionen keine neue Version vom Updater angezeigt.

Habe ebend noch einmal zum Test folgendes in der Konsole eingegeben:

chown -R http:http /volume1/web/owncloud

Dann einen Neustart der Synology gemacht. Ergebnis kein Update wird angezeigt. Im Backend habe ich mal kurz den Updatekanal gewechselt, aber auch hierbei bleibt meine 9.0.1 aktuell ???

 

[Frogman]

Und wie sieht die Ausgabe aus, wenn Du als root auf der Konsole nacheinander folgendes eingibst?

chown -R http:http /volume1/web/owncloud
/bin/su -s /bin/sh -c "/usr/bin/php -f /volume1/web/owncloud/updater/application.php" http

 

[reizwolf]

hi Frogman,

hier die Kopie der Konsole, allerdings jetzt unter verschärften Rechten:

PHP Warning: fopen(/volume1/web/owncloud/updater/update.log): failed to open stream: Permission denied in /volume1/web/owncloud/updater/app/config/container.php on line 92

Warning: fopen(/volume1/web/owncloud/updater/update.log): failed to open stream: Permission denied in /volume1/web/owncloud/updater/app/config/container.php on line 92
[Warning] Failed to init logger. Logging is disabled.
/volume1/web/owncloud/updater is not writable
Initialization failed with message:
An unhandled exception has been thrown:
exception 'Doctrine\DBAL\DBALException' with message 'Failed to connect to the database: An exception occured in driver: could not find driver' in /volume1/web/owncloud/lib/private/db/connection.php:54
Stack trace:
#0 /volume1/web/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
#1 /volume1/web/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /volume1/web/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /volume1/web/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(621): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /volume1/web/owncloud/lib/private/db/connection.php(137): Doctrine\DBAL\Connection->setTransactionIsolation(2)
#5 /volume1/web/owncloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#6 /volume1/web/owncloud/lib/private/db/connectionfactory.php(118): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#7 /volume1/web/owncloud/lib/private/server.php(366): OC\DB\ConnectionFactory->getConnection('mysql', Array)
#8 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#9 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(102): Pimple\Container->offsetGet('DatabaseConnect...')
#10 /volume1/web/owncloud/lib/private/servercontainer.php(87): OC\AppFramework\Utility\SimpleContainer->query('DatabaseConnect...')
#11 /volume1/web/owncloud/lib/private/server.php(886): OC\ServerContainer->query('DatabaseConnect...')
#12 /volume1/web/owncloud/lib/private/server.php(260): OC\Server->getDatabaseConnection()
#13 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#14 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(102): Pimple\Container->offsetGet('AppConfig')
#15 /volume1/web/owncloud/lib/private/servercontainer.php(87): OC\AppFramework\Utility\SimpleContainer->query('AppConfig')
#16 /volume1/web/owncloud/lib/private/server.php(825): OC\ServerContainer->query('AppConfig')
#17 /volume1/web/owncloud/lib/private/server.php(411): OC\Server->getAppConfig()
#18 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#19 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(102): Pimple\Container->offsetGet('AppManager')
#20 /volume1/web/owncloud/lib/private/servercontainer.php(87): OC\AppFramework\Utility\SimpleContainer->query('AppManager')
#21 /volume1/web/owncloud/lib/private/server.php(1063): OC\ServerContainer->query('AppManager')
#22 /volume1/web/owncloud/lib/private/app.php(254): OC\Server->getAppManager()
#23 /volume1/web/owncloud/lib/private/app.php(103): OC_App::getEnabledApps()
#24 /volume1/web/owncloud/lib/base.php(577): OC_App::loadApps(Array)
#25 /volume1/web/owncloud/lib/base.php(1112): OC::init()
#26 /volume1/web/owncloud/console.php(46): require_once('/volume1/web/ow...')
#27 /volume1/web/owncloud/occ(11): require_once('/volume1/web/ow...')
#28 {main}
Use upgrade:checkpoint --list to view a list of checkpoints
upgrade:checkpoint --restore [checkpointid] to revert to the last checkpoint
Please attach your update.log to the issues you reporting.

 

[Andy+]

Ihr müsst als Gruppe root und Eigentümer http setzen und rekursiv für alle Unterverzeichnisse anwenden.