ownCloud 9 ist da!

[Ha34Meiner]

Tommes, freu DIch, es ist wohl so weit, Owncloud 9 erscheint. Ich wünsche mir Deine ersten Eindrücke ;-) Nein, Scherz. Aber Karsten übernimmt es für uns. Er schreibt in seinem Blog:

Steht so nicht in der Featureliste auf Github, aber nach diesem Artikel von Morris Jobke, sind Kalender- und Kontaktsynchronisation wieder in ownCloud integriert. Also keine separaten Apps mehr, sondern tatsächlich Bestandteil von ownCloud.

Für mich eine sehr gute Nachricht. Scheinbar besinnt man sich bei owncloud.org wieder auf die eigenen Stärken und die Unterschiede zur – ich will es mal so nennen – Konkurrenz.
weiter lesen auf: http://www.kussaw.de/category/computer/

und das wichtigste ist:

Ich werde heute Abend das Upgrade starten und über den Erfolg oder Misserfolg berichten …

Mal sehen, wie es ihm ergeht.

 

[Tommes]

Ich wusste garnicht, das du mich so sehr in dein Herz geschlossen hast. Da werd ich ja ein klein bisschen rot

Hm, ownCloud 9 also! Aktuell dümpelt ownCloud 8 auf meInem Pi nur noch so vor sich hin und ich habe auch grade keine wirkliche Verwendung dafür. Von daher brennt es mir grad nicht wirklich unter den Nägeln, auf den ownCloud 9 Zug aufzuspringen, wenngleich mich die Symbiose von Cal- und CardDAV schon interessieren würde. Anderseits grault es mir auch wieder vor diversen und dubiosen Fehlermeldungen im Administrationsmenü und der endlosen Suche nach Lösungen um mein inneres Gleichgewicht zu bewahren

Aber trotzdem danke ich dir natürlich für diese Info, vielleicht Klatsch ich das am WE mal drauf.

Tommes

 

[goetz]

Hallo,
nach einer kleinen Updateorgie (7.?->8.0->8.1->8.2->9.0) läuft OC 9 auf der DS411+II. Jetzt heißt es die Clients testen, erste Tests waren positiv.

Gruß Götz

 

[reizwolf]

Guten Tag,

nachdem ich meiner DS214+ mit DSM6 Beta2 die RC gegönnt habe, dachte ich es wäre ein guter Zeitpunkt owncloud 9 neu zu installieren.
Die Neuinstallation setzte eine neue leere Datenbank voraus. Nach der Installation erhielt ich zwei Fehlermeldungen, einmal fehlender Memcache zum anderen das leidige HSTS-Problem seit der DSM6 Beta2 auch unter owncloud 8.2.2.

Der Eintrag in der /volume1/web/owncloud/config/config

'memcache.local' => '\OC\Memcache\APC',

beseitigte diese Fehlermeldung.

Die Fehlermeldung: Der "Strict-Transport-Security" HTTP-Header ist nicht auf mindestens "15768000" Sekunden eingestellt.... konnte ich leider noch nicht beheben.
Ich wäre dankbar, wenn mir jemand eine Problemlösung nennen würde.

Weiterhin musste ich leider feststellen, das CRON immer noch nicht unter owncloud läuft. Dies ebenfalls seit der DSM6 Beta2.

Wesentliche Neuerungen fand ich nur zum Kalender und den Kontakten. Hier wurden die Pfade neu gesetzt (XXXX=eure Angaben):

Kalender:
https://XXXXXXX.XXX/owncloud/remote.php/dav/calendars/XXXXX/default/
https://XXXXXXX.XXX/owncloud/remote.php/dav/calendars/XXXXX/contact_birthdays/

Kontakte:
https://XXXXXXX.XXX/owncloud/remote.php/dav/addressbooks/users/XXXXX/default/

Eine Importfunktion für Kontakte in owncloud, ähnlich wie im Kalender wäre ganz große Klasse.

Was mich ein wenig bei der Installation irritierte, war die auf folgender Seite beschriebene Rechtevergabe der owncloud.verzeichnisse:

https://doc.owncloud.org/server/9.0...ard.html#setting-strong-directory-permissions

Wenn ich bei mir die Rechte wie dort beschrieben setze, dann läuft bei mir schon bei

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

garnichts mehr!!!

Ich hoffe, die Community kann Tips zum HSTS-Problem und zum CRON geben.

Grüße
ReizWolf

 

[Andy+]

Mit der ownCloud 9.0.0.19 gibts aber ein paar Sachen, die erst behoben werden müssen:

https://forum.owncloud.org/viewtopic.php?f=21&t=34152&p=110008#p110008
https://github.com/owncloud/core/issues/23019

Im Zusammenhang mit DSM 6, ob Beta oder RC, läuft der File Rescan im Zusammenhang mit External Storage gar nicht, da kommt nur:

##########################################################################################################################

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:52
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(135): 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(328): OC\DB\ConnectionFactory->getConnection('mysql', Array)
#8 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(112): OC\Server->OC{closure}(Object(OC\Server))
#9 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(104): Pimple\Container->offsetGet('DatabaseConnect...')
#10 /volume1/web/owncloud/lib/private/server.php(763): OC\AppFramework\Utility\SimpleContainer->query('DatabaseConnect...')
#11 /volume1/web/owncloud/lib/private/db.php(42): OC\Server->getDatabaseConnection()
#12 /volume1/web/owncloud/lib/private/server.php(235): OC_DB::getConnection()
#13 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(112): OC\Server->OC{closure}(Object(OC\Server))
#14 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(104): Pimple\Container->offsetGet('AppConfig')
#15 /volume1/web/owncloud/lib/private/server.php(702): OC\AppFramework\Utility\SimpleContainer->query('AppConfig')
#16 /volume1/web/owncloud/lib/private/server.php(373): OC\Server->getAppConfig()
#17 /volume1/web/owncloud/3rdparty/pimple/pimple/src/Pimple/Container.php(112): OC\Server->OC{closure}(Object(OC\Server))
#18 /volume1/web/owncloud/lib/private/appframework/utility/simplecontainer.php(104): Pimple\Container->offsetGet('AppManager')
#19 /volume1/web/owncloud/lib/private/server.php(929): OC\AppFramework\Utility\SimpleContainer->query('AppManager')
#20 /volume1/web/owncloud/lib/private/app.php(259): OC\Server->getAppManager()
#21 /volume1/web/owncloud/lib/private/app.php(104): OC_App::getEnabledApps()
#22 /volume1/web/owncloud/lib/base.php(566): OC_App::loadApps(Array)
#23 /volume1/web/owncloud/lib/base.php(1081): OC::init()
#24 /volume1/web/owncloud/console.php(42): require_once('/volume1/web/ow...')
#25 /volume1/web/owncloud/occ(11): require_once('/volume1/web/ow...')
#26 {main}

###########################################################################################################################

Da gibts also auch noch Baustellen. Bei mir läuft ownCloud 8.2.2.2 zusammen mit DSM 5.2 bislang am besten .........

 

[Fusion]

@reizwolf

Bin noch unter DSM 5.2 und OC 8.1.3, aber die Probleme gab es da ja auch schon.

/etc/httpd/conf/extra/httpd-ssl.conf im Bereich virtualhost *443
<IfDefine HSTS>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfDefine>

Bei cron sicherstellen, dass keine alte Instanz des Aufrufs noch irgendwo hängt, danach habe ich den Eintrag neu angelegt in /etc/crontab (all X Minuten)
*/X * * * * root /bin/su -s /bin/sh -c "/usr/bin/php -f /volume1/web/owncloud/cron.php" http
und den cron-daemon mal neu gestartet. Seither läuft es wieder.

Import für Kontakte gibt es doch schon, oder wurde die weg-rationalisiert mit OC9?
Eingeloggt, Kontakte, unten links Zahnrad, Import.

Edit: Bezüglich Rechte Einschränkung
Du sollst auch nicht das ganze owncloud Verzeichnis rekursiv auf den Besitzer root übertragen!
Einige Unterverzeichnisse etc. verbleiben im Besitz von http. Mach dir am besten ein Script dazu und lass das laufen, dann mußt du es erstens nicht immer wieder von Hand machen und Tippfehler sind auch passe.

#!/bin/bash
ocpath='/volume1/web/owncloud'
htuser='http'

find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750

chown -R root:${htuser} ${ocpath}/
chown -R ${htuser}:${htuser} ${ocpath}/apps/
chown -R ${htuser}:${htuser} ${ocpath}/config/
chown -R ${htuser}:${htuser} ${ocpath}/data/

chown root:${htuser} ${ocpath}/.htaccess
chown root:${htuser} ${ocpath}/data/.htaccess

chmod 0644 ${ocpath}/.htaccess
chmod 0644 ${ocpath}/data/.htaccess

Oder nimm das von der von dir verlinkten Seite. Das wurde wohl etwas aufgebohrt, erweitert.

 

[Andy+]

Du musst noch zusehen, daß kein Lock besteht. Daher lass ich immer ein Unlock mitlaufen. Script wie folgt:

############################################################################################################

#!/bin/bash

if [ -f /volume1/web/owncloud/data/cron.lock ]; then

TIME=$(date +%s)
TIMESTAMP=$(date +%s -r /volume1/web/owncloud/data/cron.lock)
DIFF=$(expr $TIME - $TIMESTAMP)

if (($DIFF >= 900 )); then
rm /volume1/web/owncloud/data/cron.lock
fi

fi

/usr/bin/php -f /volume1/web/owncloud/cron.php

############################################################################################################

Ich habe die crons aktiv:

0,15,30,45 * * * * root /usr/bin/php -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

59 23 * * * root /volume1/web/owncloud/data/scripts/cron_logs_delete_all.sh

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

0 0 * * * root crond -bS -l 0 -L cron_logging.log -c /volume1/web/owncloud/data/logs

0,30 7-22 * * * root /bin/su -s /bin/sh -c "cd /volume1/web/owncloud && /usr/bin/php -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 0 * * * root /bin/su -s /bin/sh -c "cd /volume1/web/owncloud && /usr/bin/php -f occ files:scan --all" http >> /volume1/web/owncloud/data/logs/cron_rescan_all_$(date +\%Y-\%m-\%d_\%H-\%M-\%S).log 2>&1

Den user "rescan" verwende ich für ausgewählte Verzeichnisse, da ansonsten die Zeit zu lange wird, bis der Scan jedesmal durch ist.

Nunja, mit OCC 9 und/oder DSM 6 läuft ownCloud ansich schon, aber der Filescan geht nicht mehr. Abgesehen, dass mit OCC 9 wohl eine Memoryfehler besteht, ist die Folge des nicht funktionierenden Filescans, daß nur clientseitige Änderungen synchronisiert werden, dagegen serverseitige Änderungen im Dateisystem werden nun nicht mehr synchronisiert. Diesen Effekt hatte ich in Version 8.x.x.x nur dann, wenn kein Rescan lief.

Also, testen, testen, testen .............

 

[Andy+]

#!/bin/bash
ocpath='/volume1/web/owncloud'
htuser='http'

find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750

chown -R root:${htuser} ${ocpath}/
chown -R ${htuser}:${htuser} ${ocpath}/apps/
chown -R ${htuser}:${htuser} ${ocpath}/config/
chown -R ${htuser}:${htuser} ${ocpath}/data/

chown root:${htuser} ${ocpath}/.htaccess
chown root:${htuser} ${ocpath}/data/.htaccess

chmod 0644 ${ocpath}/.htaccess
chmod 0644 ${ocpath}/data/.htaccess

Läuft das dann bei Dir auch über die crontab mit Scriptdatei?

 

[Fusion]

@Andy+ - nein, das script nehme ich nur vor/nach updates. Vor dem Update lasse ich es reverse laufen, also ändere auf user root und laxere Rechte, und nach dem Update wieder normal auf http in der gezeigten Form um die Rechte wieder einzuschränken.

 

[Ha34Meiner]

Könnt Ihr dies bitte noch einmal für einen Dummie für OC genauer beschreiben.
Ihr schreibt das Script #!/bin/bash in eine text-Datei und legt es wo ab und mit was startet ihr es dann?

 

[Andy+]

Ich habe das Ganze mal so vorbereitet, ist noch nicht getestet :

##########################################################

#!/bin/bash
ocpath='/volume1/web/owncloud'
htuser='http'
htgroup='root'
rootuser='root'

#printf "Creating possible missing Directories\n"
#mkdir -p $ocpath/data
#mkdir -p $ocpath/assets

#printf "chmod Files and Directories\n"
find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750

#printf "chown Directories\n"
chown -R ${rootuser}:${htgroup} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${ocpath}/data/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/
chown -R ${htuser}:${htgroup} ${ocpath}/assets/

chmod +x ${ocpath}/occ

#printf "chmod/chown .htaccess\n"
if [ -f ${ocpath}/.htaccess ]
then
chmod 0644 ${ocpath}/.htaccess
chown ${rootuser}:${htgroup} ${ocpath}/.htaccess
fi
if [ -f ${ocpath}/data/.htaccess ]
then
chmod 0644 ${ocpath}/data/.htaccess
chown ${rootuser}:${htgroup} ${ocpath}/data/.htaccess
fi

#######################################################################

So mach ich das auch immer von Hand über WinSCP, Gruppe Root, User Http. Ich mache da keine Unterschiede, egal wann.

 

[Fusion]

Man müßte mal sehen, ob es mit /bin/sh auch läuft, wäre sauberer. Zudem liefert Synology ja nur ash im default aus glaube ich.
Kann also keine Gewähr übernehmen, dass es läuft (sollte es aber, weil die Befehle alle auch von ash unterstützt werden).

Das gepostete ist der Inhalt des Scripts (Pfade etc sind an das eigene system anzupassesn). Das script selbst habe ich ocperm.sh genannt. Es muss nur irgendwo auf der DS liegen und hat bei mir 755 für die Zugriffsrechte und gehört root.
Starten in der Konsole, als root angemeldet, via "sh ./ocperm.sh", wenn man sich im selben Verzeichnis befindet wie das script, andernfalls den Pfad mit angeben.

Noch detaillierter?

 

[Ha34Meiner]

Ne, das reicht für das erste. Die nächste Frage kommt dann, wenn ich das Script ausgeführt habe und es nicht ging.Danke für die schnelle Erklärung und Hilfe.

 

[reizwolf]

Hallo,

hi Fusion und Andy+, danke für eure Ideen.
Fusion: Dein Script ist sehr ähnlich dem von owncloud (mein Link).
doch: chown -R root:${htuser} ${ocpath}/ ergibt doch händisch ins Terminal eingegeben chown -R root:http /volume1/web/owncloud/ oder interpretiere ich das falsch.

Ich habe es mit dem originalscript aus meinem Link bereits probiert. Copy/Paste in Textdatei, dann chmod +x datei. Und dann in diesem Verzeichnis mit ./datei gestartet.
Keine Ahnung warum, aber das Script funktionierte nicht. Syntaxfehler... wurden "r" ausgegeben, die nie eingegeben waren...???

Darum habe ich es händisch versucht, habe ich da was falsch geschlussfolgert??? Wie sollten den die optimalen Angaben für eine Terminalsitzung lauten?

Zum HSTS-Problem: seit DSM6 Beta läuft NGINX als Webserver, nicht mehr Apache. Was natürlich das Suchen der richtigen Datei zum Einfügen erschwert.

Und CRON findet offensichtlich nicht den richtigen Treiber, hatte bisher jedenfalls kein .lock unter .../data/.

Mit der Bash habe ich nicht so viel Erfahrung.

 

[Andy+]

........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:52
Stack trace:
#0...........

Das Treiberproblem hat ja auch ownCloud und nicht cron. Aber die Geschichte mit Apache und NGINX könnte eine Erklärung dafür sein, weil bislang ist das Thema ungelöst .......

 

[Fusion]

ok, war mir nicht bewusst, dass sie jetzt vollständig auf nginx gewechselt sind. Da ich kein DSM 6 laufen hab kann ich da keine fundierte Aussage treffen.
Würde aber erstmal unter /etc/http und /etc/nginx suchen.
Die virtual hosts heißen unter nginx server blocks.
Bei dem server block der owncloud ausliefert muss in der config beim server der header ergänzt werden
add_header Strict-Transport-Security max-age=31536000;
Siehe auch https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

Deine Schlußfolgerung mit dem Script sind korrekt (das Script stammt ja auch von owncloud, allerdings noch aus der Anleitung von version 8). Allerdings müssen dann ALLE Befehle ausgeführt werden. Ich war davon ausgegangen, dass du NUR diesen einen rekursiven Befehl abgesetzt hast. Und das würde zu einem nicht lauffähigen owncloud führen.
Wenn wir den Fehler debuggen sollen bitte mal direkt die Konsolenausgabe posten und vorher eine "ls -l script.sh".

 

[reizwolf]

Habe mir eine Textdatei erstellt, woraus ich zeilenweise einfach die Befehle per Copy/Paste in das Terminal einfügen kann. Vorteil: man erhält sofort Feedback.
Also im Terminal zum Benutzer root wechseln mittels:

sudo -i

dann die für die Synology geltenden Werte im Terminal via Copy/Paste zeilenweise einfügen und mittels Enter bestätigen:

find /volume1/web/owncloud/ -type f -print0 | xargs -0 chmod 0640
find /volume1/web/owncloud/ -type d -print0 | xargs -0 chmod 0750

chown -R root:http /volume1/web/owncloud/
chown -R http:http /volume1/web/owncloud/apps/
chown -R http:http /volume1/web/owncloud/config/
chown -R http:http /volume1/web/owncloud/data/
chown -R http:http /volume1/web/owncloud/themes/
chown -R http:http /volume1/web/owncloud/assets/

chmod +x /volume1/web/owncloud/occ

chmod 0644 /volume1/web/owncloud/.htaccess
chown root:http /volume1/web/owncloud/.htaccess

chmod 0644 /volume1/web/owncloud/data/.htaccess
chown root:http /volume1/web/owncloud/data/.htaccess


Interessant finde ich, dass das Verzeichnis: /volume1/web/owncloud/assets/ in der owncloud-Beschreibung erwähnt wird. Bei mir wurde es weder unter Version 8.x noch 9 installiert.
Ich habe es nachträglich erstellt. Vielleicht für zukünftige Apps???

Ich wage mich leider nicht so richtig ran, ohne es genau zu wissen, einfach Werte in eine nginx-Datei einzufügen. Bin sonst kein Scripter und habe nur die eine Syno. .

 

[Andy+]

add_header Strict-Transport-Security max-age=31536000;
Siehe auch https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

Ich habe nun nicht recht verstanden, welches Problem das behebt, das von mir geschilderte? Und wenn, wo genau muß die genannte Zeile eingebaut werden?

 

[Fusion]

@Andy - das bezog sich auf das HSTS Problem. In welche config das reingehört kann ich dir noch nicht sagen, weil ich noch kein DSM6 am Laufen habe.

@reizwolf - no risk, no fun. Ohne Fleiß kein Preis. Ohne try kein Error.
Aber so schlimm ist es ja nicht. Du hast ja Zugang via SSH und kannst Änderungen wieder rückgängig machen.
Am besten einfach vorher mit "cp name name_bck" von Dateien die du ändern willst eine Kopie anlegen, dann kommst du immer wieder zurück.
Und zweitens immer nur eine Änderung zu jeder Zeit, damit du auch mitbekommst, welche Änderung die gewollte ist.
Und drittens deine Erfahrung mitteilen.

Oder du wartest, bis es jemand anderes gemacht hat und ins Netz stellt.

 

[reizwolf]

hallo,

habe soeben das HSTS-Problem auf meiner Synology gelöst.

diese Zeile am Schluss zu den anderen Headerangaben einfügen in /volume1/web/owncloud/lib/private/response.php

header('Strict-Transport-Security: max-age=15768000; env=HTTPS'); // HSTS


Keine Fehlermeldung mehr! Jetzt muss nur noch der Cron seinen Job machen dürfen in owncloud.