Nextcloud zeigt über das Kontakte Icon in der Menüleiste alle Benutzer der Serverinstanz an. Auch, wenn die Kontakte App deaktiviert ist. Das kann ein Problem darstellen, wenn man mehrer Gruppen verwaltet, die sich untereinander nicht sehen sollen.
Eine Einstellung zur Deaktivierung dieser Funktion oder einer genaueren Festlegung des Verhaltens ist bisher nicht implementiert.
Es gibt zwei Möglichkeiten.
- Man deaktiviert in den Einstellungen die Möglichkeit zur Autovervollständigung der Namen. Dann werden keine Kontakte in der Liste angezeigt. Allerdings ist dann eben auch keine Vervollständigung im Teilen Dialog vorhanden.
- Man bearbeitet die Datei /core/templates/layout.user.php und kommentiert den Bereich für das Icon aus. Dann hat man keine Möglichkeit mehr auf das Icon zuzugreifen. Allerdings besteht dann immer noch die Möglichkeit, über den Teilen Dialog alle Benutzer zu finden, indem man Teile seines Namens eingibt.
[html]
</div> [/html]
Nextcloud Undefined Function simplexml_load_file()
Um die neuste NC Version 11 nutzen zu können, muss mindestens PHP 5.6 installiert sein. Nach einem Upgrade der PHP Version von PHP 5.5 auf PHP 7.0 und dem teilweisen Upgrade auf Nextcloud 11 tritt folgender Fehler auf:
{"reqId":"0XX1AddR7FoxNPEzqO0d","remoteAddr":"","app":"PHP","message":"Error: Call to undefined function OC\App\simplexml_load_file() at /var/www/nextcloud/lib/private/App/InfoParser.php#61","level":3,"time":"2016-12-14T08:50:08+01:00","method":"GET","url":"/status.php","user":"--","version":"11.0.0.10"}
{"reqId":"6XpZ9rkTys2hBE9ffhYx","remoteAddr":"","app":"PHP","message":"Error: Call to undefined function OC\App\simplexml_load_file() at /var/www/nextcloud/lib/private/App/InfoParser.php#61","level":3,"time":"2016-12-14T08:50:40+01:00","method":"GET","url":"/status.php","user":"--","version":"11.0.0.10"}
Es fehlen nach dem PHP Upgrade noch weitere Module:
apt-get install php7.0-xml
apt-get install php7.0-zip
apt-get install php7.0-cURL
apt-get install php7.0-gd
service apache2 restart
Anschließend kann auch das Upgrade von Nextcloud durchlaufen:
su - www-data -s /bin/bash -c 'php /var/www/nextcloud/occ upgrade'
“Upgrade” auf ownCloud 9.1.1 in Nextcloud 10 stable
Ein Bug in der Nextcloud Updatemeldung führt dazu, dass in Nextcloud 10 ständig die Meldung “Kernelupgrade auf ownCloud 9.1.1” erscheint.
Die Nummerierung führt auf die interne Nummerierung in Nextcloud zurück. 9.1.0 ist die interne Nummer für NC 10.0.0.
Ein manuelles Update auf Nextcloud 10.0.1 behebt das Problem.
Ab der neuen Version ist ein neuer Updater eingebaut, der die Updates bequem über die Weboberfläche durchführt.
Manuelles Update auf Nextcloud 10.0.1
Gegebenheiten: Webserver läuft unter www-data; NC Root-Verzeichnis ist unter “/var/www/nextcloud”
Wechsel ins Webserververzeichnis und umbenennen der alten Installation
cd /var/www
mv nextcloud/ nextcloud_10
Herunterladen und Entpacken der neuen Version
wget https://download.nextcloud.com/server/releases/nextcloud-10.0.1.zip
unzip nextcloud-10.0.1.zip
Kopieren der alten Konfigurationsdatei
cp nextcloud_10/config/config.php nextcloud/config/config.php
Verschieben des data-Verzeichnisses in die neue Installation
mv nextcloud_10/data/ nextcloud/data
Setzen der Rechte und Ausführen des Upgrade Skripts
chown www-data:www-data ../nextcloud -R
su - www-data -s /bin/bash -c 'php /var/www/nextcloud/occ upgrade'
Nextcloud or one of the apps require upgrade - only a limited number of commands are available You may use your browser or the occ upgrade command to do the upgrade Set log level to debug Turned on maintenance mode Checking whether the database schema can be updated (this can take a long time depending on the database size) Done 27/27 [============================] 100% Checked database schema update Checking updates of apps Checking whether the database schema for <dav> can be updated (this can take a long time depending on the database size) Done 10/10 [============================] 100% Checked database schema update for apps Updating database schema Updated database Updating <dav> ... Fix classification for calendar objects Done 1/1 [============================] 100% Updated <dav> to 1.0.1 Drop old database tables Done 31/31 [============================] 100% Remove old (< 9.0) calendar/contact shares Done 4/4 [============================] 100% Fix permissions so avatars can be stored again Done 2/2 [============================] 100% Starting code integrity check... Finished code integrity check Update successful Turned off maintenance mode Reset log level
Setzen der Verzeichnisrechte
Nun wird das Skript für die Verzeichnisrechte erstellt und ausgeführt.
nano /tmp/perms.sh
chmod +x /tmp/perms.sh
/tmp/perms.sh
Inhalt:
#!/bin/bash
ncpath='/var/www/nextcloud'
htuser='www-data'
htgroup='www-data'
rootuser='root'
printf "Creating possible missing Directories\n"
mkdir -p $ncpath/data
mkdir -p $ncpath/assets
mkdir -p $ncpath/updater
printf "chmod Files and Directories\n"
find ${ncpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ncpath}/ -type d -print0 | xargs -0 chmod 0750
printf "chown Directories\n"
chown -R ${rootuser}:${htgroup} ${ncpath}
chown -R ${htuser}:${htgroup} ${ncpath}/apps/
chown -R ${htuser}:${htgroup} ${ncpath}/assets/
chown -R ${htuser}:${htgroup} ${ncpath}/config/
chown -R ${htuser}:${htgroup} ${ncpath}/data/
chown -R ${htuser}:${htgroup} ${ncpath}/themes/
chown -R ${htuser}:${htgroup} ${ncpath}/updater/
chmod +x ${ncpath}/occ
printf "chmod/chown .htaccess\n"
if [ -f ${ncpath}/.htaccess ]
then
chmod 0644 ${ncpath}/.htaccess
chown ${rootuser}:${htgroup} ${ncpath}/.htaccess
fi
if [ -f ${ncpath}/data/.htaccess ]
then
chmod 0644 ${ncpath}/data/.htaccess
chown ${rootuser}:${htgroup} ${ncpath}/data/.htaccess
fi
Update Owncloud 8.2 auf Owncloud 9.1
Ein direktes Update von Owncloud 8.2 auf 9.1 ist so leider nicht möglich, da man zuerst über die Zwischenversion 9.0 gehen muss.
Im Folgenden wird davon ausgegangen, dass OC direkt im Root Verzeichnis des Apache liegt. Sollte das anders sein, müssen die Pfade dementsprechend angepasst werden. Außerdem ist das Datenverzeichnis auf eine eigene Partition ausgelagert.
Update Owncloud 8.2 auf 9.0
Als erstes wechselt man in das OC Root Verzeichnis, um den Wartungsmodus einzuschalten. Das occ Skript muss dabei im Kontext des Besitzers ausgeführt werden (www-data als Apache Benutzer)
su - www-data -s /bin/bash -c 'php occ maintenance:mode --on'
Anschließend kann die neue OC Version heruntergeladen und entpackt werden.
wget https://download.owncloud.org/community/owncloud-9.0.4.zip
unzip owncloud-9.0.4.zip
Danach wird das ursprüngliche Installationsverzeichnis verschoben und das neue Verzeichnis anstelle des Alten benutzt:
mv www www-orig
mv owncloud www
Nun muss die config.php und das Datenverzeichnis (data) aus der alten Installation in das neue Verzeichnis kopiert werden. Sollte das Datenverzeichnis außerhalb des Owncloud Verzeichnisses liegen, so muss nur die Konfiguration kopiert werden:
cp www-orig/config/config.php www/config/config.php
Anpassen der Rechte:
chown www-data:www-data www -R
Ausführen des eigentlichen Upgradeprozesses:
su - www-data -s /bin/bash -c 'php occ upgrade'
Nun kann auf Version 9.1 migriert werden.
Upgradebefehle Copy & Paste:
cd /var/www
su - www-data -s /bin/bash -c 'php occ maintenance:mode --on'
cd ..
wget https://download.owncloud.org/community/owncloud-9.0.4.zip
unzip owncloud-9.0.4.zip
mv www www-orig
mv owncloud www
cp www-orig/config/config.php www/config/config.php
chown www-data:www-data www -R
cd www
su - www-data -s /bin/bash -c 'php occ upgrade'
Update Owncloud 9.0 auf 9.1
Das Upgrade verhält sich analog zum oben beschriebenen Upgradeprozess.
cd /var/www
su - www-data -s /bin/bash -c 'php occ maintenance:mode --on'
cd ..
wget https://download.owncloud.org/community/owncloud-9.1.0.zip
unzip owncloud-9.1.0.zip
mv www www-90
mv owncloud www
cp www-90/config/config.php www/config/config.php
chown www-data:www-data www -R
cd www
su - www-data -s /bin/bash -c 'php occ upgrade'
su - www-data -s /bin/bash -c 'php occ maintenance:mode --off'
Sollte dann in etwa so aussehen:
su - www-data -s /bin/bash -c 'php occ upgrade'
ownCloud or one of the apps require upgrade - only a limited number of commands are available You may use your browser or the occ upgrade command to do the upgrade Set log level to debug Checking whether the database schema can be updated (this can take a long time depending on the database size) Done 24/24 [============================] 100% Checked database schema update Checking updates of apps Checking whether the database schema for <activity> can be updated (this can take a long time depending on the database size) Done 2/2 [============================] 100% Checking whether the database schema for <dav> can be updated (this can take a long time depending on the database size) Done 10/10 [============================] 100% Checking whether the database schema for <federatedfilesharing> can be updated (this can take a long time depending on the database size) Done 1/1 [============================] 100% Checking whether the database schema for <federation> can be updated (this can take a long time depending on the database size) Done 1/1 [============================] 100% Checking whether the database schema for <files_sharing> can be updated (this can take a long time depending on the database size) Done 1/1 [============================] 100% Checking whether the database schema for <files_trashbin> can be updated (this can take a long time depending on the database size) Done 1/1 [============================] 100% Checking whether the database schema for <notifications> can be updated (this can take a long time depending on the database size) Done 1/1 [============================] 100% Checked database schema update for apps Updating database schema Updated database Updating <federatedfilesharing> ... Updated <federatedfilesharing> to 0.3.0 Updating <provisioning_api> ... Updated <provisioning_api> to 0.5.0 Updating <updatenotification> ... Updated <updatenotification> to 0.2.1 Updating <federation> ... Updated <federation> to 0.1.0 Updating <files> ... Updated <files> to 1.5.1 Updating <activity> ... Updated <activity> to 2.3.2 Updating <dav> ... Fix classification for calendar objects Done 18/18 [============================] 100% Updated <dav> to 0.2.5 Updating <files_sharing> ... Updated <files_sharing> to 0.10.0 Updating <files_trashbin> ... Updated <files_trashbin> to 0.9.0 Updating <files_versions> ... Updated <files_versions> to 1.3.0 Updating <comments> ... Updated <comments> to 0.3.0 Updating <notifications> ... Updated <notifications> to 0.3.0 Updating <systemtags> ... Updated <systemtags> to 0.3.0 Drop old database tables Done 28/28 [============================] 100% Remove old (< 9.0) calendar/contact shares Done 4/4 [============================] 100% Fix permissions so avatars can be stored again Done 2/2 [============================] 100% Starting code integrity check... Finished code integrity check Update successful Maintenance mode is kept active Reset log level
su - www-data -s /bin/bash -c 'php occ maintenance:mode --off'
ownCloud is in maintenance mode - no app have been loaded Maintenance mode disabled
Abschließend sollten die Berechtigungen auf die Dateien ordnungsgemäß gesetzt werden.
Strong Directory Permissions
Datei erstellen nano /tmp/perms.sh und befüllen:
#!/bin/bash
ocpath='/var/www'
htuser='www-data'
htgroup='www-data'
rootuser='root'
printf "Creating possible missing Directoriesn"
mkdir -p $ocpath/data
mkdir -p $ocpath/assets
mkdir -p $ocpath/updater
printf "chmod Files and Directoriesn"
find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750
printf "chown Directoriesn"
chown -R ${rootuser}:${htgroup} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/assets/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${ocpath}/data/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/
chown -R ${htuser}:${htgroup} ${ocpath}/updater/
chmod +x ${ocpath}/occ
printf "chmod/chown .htaccessn"
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
Ausführbar machen und laufen lassen.
chmod +x perms.sh
./perms.sh
Creating possible missing Directories chmod Files and Directories chown Directories chmod/chown .htaccess
Sollten eigene Themes benutzt werden, müssen die auch noch von der alten Installation in die neue kopiert werden.
Fail2Ban und Owncloud 8.2.x und 9.x
ownCloud ist eine freie Software für das Speichern von Daten (Filehosting) auf einem eigenen Server. Bei Einsatz eines entsprechenden Clients wird dieser automatisch mit einem lokalen Verzeichnis synchronisiert. Dadurch kann von mehreren Rechnern auf einen konsistenten Datenbestand zugegriffen werden.
(Quelle: Wikipedia)
Um fehlgeschlagene Anmeldungen mit fail2ban abzufangen, müssen neue Filterregeln definiert werden.
Filterdatei erstellen: /etc/fail2ban/filter.d/owncloud.conf
[Definition]
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' (Remote IP: '')","level":2,"time":".*"}
ignoreregex =
Nun kann der Filter in die Jail Definitionen aufgenommen werden /etc/fail2ban/jail.conf:
[owncloud] enabled = true filter = owncloud port = http,https logpath = /var/www/owncloud/data/owncloud.log
Es sollte darauf geachtet werden, dass, sollte der Server nicht unter der UTC laufen, die config.php von Owncloud angepasst werden muss.
/** * The default timezone for logfiles is UTC. You may change this; see * http://php.net/manual/en/timezones.php */ 'logtimezone' => 'Europe/Berlin',
Falls keine Fehlanmeldungen im Log auftauchen, muss eventuell ebenfalls das Loglevel angepasst werden:
/** * Loglevel to start logging at. Valid values are: 0 = Debug, 1 = Info, 2 = * Warning, 3 = Error. The default value is Warning. */ 'loglevel' => 2,
Fail2Ban neustarten
service fail2ban restart
Testen kann man die Konfiguration via
fail2ban-regex /var/www/owncloud/data/owncloud.log /etc/fail2ban/filter.d/owncloud.conf
