Nextcloud Kontakte Icon deaktivieren

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.

  1. 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.
  2. 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]

Advertisements

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',

https://github.com/owncloud/

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,

https://github.com/owncloud/

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