Chez JL

Accueil > Informatique > Applications > Nextcloud - Faire son nuage personnel

Nextcloud - Faire son nuage personnel

samedi 31 janvier 2015, par JL

 Liens

https://nextcloud.com/
https://fr.wikipedia.org/wiki/Nextcloud
https://doc.ubuntu-fr.org/utilisateurs/bcag2/nextcloud

 Installation

Sous Debian, je préfère faire l’installation depuis les sources plutôt que depuis les paquets apt, pour avoir une version plus à jour.

Ancienne méthode avec owncloud (à déplacer)
D’après https://www.howtoforge.com/owncloud-7-installation-
and-configuration-on-debian-7-wheezy

cd /tmp
wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key
apt-key add - < Release.key
echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list
apt-get update
apt-get install owncloud
# paquets suggéré :   clamav clamav-daemon libreoffice-writer libav-tools ffmpeg php5-ldap php5-apcu php-apc (je ne mets pas tout)
apt-get install libreoffice-writer ffmpeg

apt-get install mysql-server # Définir le mot de passe root pour mysql
mysql -u root -p
CREATE DATABASE owncloud;
GRANT ALL ON owncloud.* to 'owncloud'@'localhost' IDENTIFIED BY 'database_password';
exit

http://www.mondomaine.fr/owncloud

Définir la connexion à la base et le premier compte utilisateur (qui est aussi administrateur).

 Configuration

https://doc.owncloud.org/server/6.0/admin_manual/installation/installation_source.html#web-server-configuration

Pour avoir les tâches automatiques :

Si on veut gérer avec "cron" (utilie pour plugin news - suivi rss) :

interface web -> administration -> paramètres de base -> tâches de fond -> cocher cron
Sur le serveur :

# crontab -u www-data -l
*/15  *  *  *  * php -f /var/www/nextcloud/cron.php > /dev/null 2>&1

Sécurisation par activiation des fichiers .htaccess

éditer /etc/apache2/sites-available/default-ssl

Ajouter vers la fin du fichier les infos sur , comme suit

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
       ServerName YourServerName
       ServerAdmin webmaster@localhost
       DocumentRoot /var/www
       <Directory />
               Options FollowSymLinks
               AllowOverride None
       </Directory>
       <Directory /var/www/>
               Options Indexes FollowSymLinks MultiViews
               AllowOverride None
               Order allow,deny
               allow from all
       </Directory>
       ErrorLog ${APACHE_LOG_DIR}/error.log
       LogLevel warn
       CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
       SSLEngine on
       SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
       SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
       <FilesMatch "\.(cgi|shtml|phtml|php)$">
               SSLOptions +StdEnvVars
       </FilesMatch>
       <Directory /usr/lib/cgi-bin>
               SSLOptions +StdEnvVars
       </Directory>
       BrowserMatch "MSIE [2-6]" \
               nokeepalive ssl-unclean-shutdown \
               downgrade-1.0 force-response-1.0
       BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
       <Directory /var/www/owncloud>
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               Allow from all
               # add any possibly required additional directives here
               # e.g. the Satisfy directive (see below for details):
               Satisfy Any
       </Directory>
</VirtualHost>
       <IfModule mod_headers.c>
         Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
       </IfModule>

</IfModule>
a2enmod headers
systemctl restart apache2

Pour le paramétrage du memcache, cela a fonctionné avec php7 (pas avec php5) (debian9) (voir ici pour installation LAMP avec php7)

apt install php-apcu

Ajouter dans le fichier config/config.php

'memcache.local' => '\OC\Memcache\APCu',
i /etc/php/7.0/apache2/php.ini

Section [opcache] ajouter :

v
[opcache]

; conseil pour nextcloud
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Sécurisation pour déplacement du répertoire data

https://forum.owncloud.org/viewtopic.php?f=17&t=7118

- service apache2 stop
- Check if your config.php already contains a datadirectory entry. If it does, remember that location (let’s assume it’s ’/var/www/owncloud/data’ for now).
- Change or create the "datadirectory" entry in config.php file, so that it points to wherever you want to have your data from now on. Assuming the directory you want to move the data folder to is ’/media/usbdisk/ocdata’, your config.php should look like this after the change :

       <?php
       $CONFIG = array (
         'datadirectory' => '/media/usbdisk/ocdata/',
         'dbtype' => ...


- Make sure the "ocdata" subdirectory doesn’t exist yet (or the command in the following step will move your data folder in a subdirectory of it)
Move all the existing files of the original data (/var/www/owncloud/data in our example) to that new location, e.g. under linux :


       mv /var/www/owncloud/data /media/usbdisk/ocdata


- Make sure the permission/ownership of the new folder is set up correctly, and that all files contained in it have the user running php as owner (see e.g. here for Linux how to find out which user that is). Let’s assume your apache runs as "www-data" (as it e.g. would under Ubuntu). Then you should change all folders/files to be owned by that user, like so :

     
chown -R www-data:www-data /media/usbdisk/ocdata


- service apache2 start
- vérifier que les fichiers sont accessibles depuis l’interface web de ownclou

Pour changer le nom du répertoire d’nstallation

- renommver /var/www/owncloud
- voir le fichier /etc/apache2/conf-available/owncloud.conf
- config/config.php
- service apache2 reload
Mais il ne vaut mieux pas le faire car lors d’une mise à jour par paquet, cela va poser problème. Ou alors, avant de faire la mise à jour créer un lien symbolique :

ln -s /var/www/onwcloudrenomme /var/www/owncloud

faire la mise à jour (voir plus bas) puis le supprimer après.

rm /var/www/owncloud

Jeu de caractère UTF8

vi /etc/php5/apache2/php.ini
default_charset = "UTF-8"
service apache2 reload

 Applications - Extensions - plugins

- Appel vidéo : Video Calls ou Talk phttps://apps.nextcloud.com/apps/spreed

 Administration

version

Pour voir le numéro de version de owncloud installée

cat owncloud/version.php

remarque : au passage à la 8.0.0.8, le fichier indique toujours 8.0.0.7, sûrement une erreure, mais bizarre.

Sinon se connecter avec un compte administrateur, aller dans le menu en haut à droite, puis administration, puis la version apparait en bas, m’y ais il n’y a pas le détail.

Sauvegarde

D’après : http://doc.owncloud.org/server/8.0/admin_manual/maintenance/backup.html

Sauvegarde du répertoire d’installation

rsync -Aax owncloud/ owncloud-dirbkp_`date +"%Y%m%d"`/

Sauvegarde de la base de données

mysqldump --lock-tables -h [server] -u [username] -p[password] [db_name] > owncloud-sqlbkp_`date +"%Y%m%d"`.bak

Pour supprimer les sauvegardes de plus de 15 j :

find /chemin/de/sauvegarde -mtime +15 -exec rm -f {} \;

Logs

Les logs sont dans : data/owncloud.log (mais on ne voit pas l’heure)
On les retrouve aussi dans l’interface web, dans administration (moins pratique pour défiler, mais il y a l’heure).

Pour limiter la taille de logs :

Dans config/config.php

’log_rotate_size’ => 104857600,

(100 megabytes = 100 * 1024 * 1024 bytes)

La rotation se ferait sur 2 fichiers...

’loglevel’ => 2, (niveau warning, celui par defaut)

Cookies

autoriser l’utilisation des cookies pour owncloud (sinon connexion impossible).

 Mise à jour

http://doc.owncloud.org/server/8.0/admin_manual/maintenance/upgrade.html

Mise à jour non majeure

voir doc maj nextcloud

puis se connecter à l’interface web d’owncloud, elle demande de cliquer faire finir d’effectuer la mise à jour.

Mise à jour majeure

Toutes les données sont dans la base de données, dans le répertoire data et dans le fichier config/config.php. L’idée est donc de renommer l’ancien répertoire owncloud en owncloud2, de faire la mise à jour majeure (passage de 7.0 à 8.0) par aptitude, qui créé un nouveau répertoire owncloud. Il faut ensuite recopier le contenu du répertoire data/ et le fichier config/config.php

 Ajout plugin/apps

liste de plugins https://apps.owncloud.com/?xsortmode=high

télécharger le plugin, fichier *.zip

décompresser dans owncloud/apps/
évenutellement renommer, par exemple ocsms-1.5 en ocsms (sinon l’activation de l’application peut ne pas fonctionner)
mettre les propriétaires www-data:www-data

Depuis interface web, menu "application -> Déscativés" : le plugin apparait, cliquer sur "activer".

 Https

Utiliser Let’s encrypt ! mettre ailleurs la doc sur le certificat autosigné.

/usr/share/doc/apache2.2-common/README.Debian.gz

http://www.it-connect.fr/securiser-owncloud-par-httpsssl/

http://doc.ubuntu-fr.org/tutoriel/securiser_apache2_avec_ssl

a2ensite default-ssl
a2enmod ssl
service apache2 restart

On peut forcer le https, en redirigeant le http vers https, deux solutions :
- Dans la page d’administration, cocher "forcer le https"
- sinon, dans le fichier PHP dans Owncloud pour forcer l’accès en HTTPS. Dans “/var/www/config/config.php“, ajouter : ‘force ssl’ => true.

Pour l’application DAVDroid, pour utiliser le https il faut que le CA soit enregistré (voir plus bas, autre paragraphe) pour accepter le certificat. Si ce n’est pas fait, il faut utiliser http, ce qui n’est pas recommandé car les données peuvent être facilement piratées à ce qu’il paraît.

 Certificat auto-signé

On crée un autorité de certification, pour pouvoir créer un certificat qui sera signé par cette autorité.

J’ai mis le certificat sur www.mondomaine.fr et non domaine.fr , car j’avais un problème avec le DNS. Il est nécessaire que le nom du domaine du certificat soit bien également au nom de domaine utilisé dans l’adresse https.

Tout est bien expliqué ici :
http://jeyg.info/des-certificats-signes-par-votre-autorite-de-certification-avec-openssl/

Je reprends les grandes lignes :
(de mon côté, repetoire créé dans /mnt/ddusb)

# aptitude install openssl
$ mkdir -p certificate-authority/{private,certs,newcerts,crl}
$ touch index.txt
$ echo "01" > serial
$ cp /etc/ssl/openssl.cnf ca-config
[ CA_default ]

dir = . # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/certs/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
#crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/ca.key # The private key

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = FR
countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = LANGUEDOC ROUSSILLON

localityName = Locality Name (eg, city)
localityName_default = MONTPELLIER

0.organizationName = Organization Name (eg, company)
0.organizationName_default = JEYG

organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =

commonName = Common Name (eg, YOUR name)
commonName_max = 64

emailAddress = Email Address
emailAddress_max = 64

default_days = 365 # how long to certify for

[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Pour que le certificat soit accepter par Dacdroit il faut que le "flag CA" soit à true.
basicConstraints=CA : à TRUE dans la section [ usr_cert ]

Création de l’autorité de certification

$ openssl req -new -x509 -extensions v3_ca -newkey rsa:4096 -keyout private/ca.key -out certs/ca.crt -config ca-config

Si vous ne voulez pas chiffrer la clé privée, ajoutez l’option -nodes.

Création du Certificate Signing Request (CSR)

$ openssl req -new -nodes -newkey rsa:2048 -keyout private/webserver.key -out webserver.csr -config ca-config

Bien renseignné le common Name en mettant l’URL web du serveur (www.domaine.fr ou domaine.fr selon l’adresse utilisée...)

Création du certificat signé

openssl ca -config ca-config -policy policy_anything -out certs/webserver.crt -infiles webserver.csr

S’il y a un message d’erreur "TXT_DB error number 2", c’est que 2 certificats sont créés avec le même DN...
http://www.admin-linux.fr/?p=1076

Si toutefois vous devez impérativement créer deux certificats ayant le même sujet (même DN), passez la valeur “unique_subject” à “no” dans le fichier “index.txt.attr” de votre autorité de certification.

Voir un certificat

openssl x509 -in certs/webserver.crt -noout -text | more

Vérifier une certificat :

openssl verify -CAfile certs/ca.crt certs/webserver.crt

Ajouter le certificat du CA dans le système

# cp certs/ca.crt /usr/share/ca-certificates/
# dpkg-reconfigure ca-certificates

Modification de /etc/apache2/sites-available/default-ssl


      SSLCertificateFile    /chemin/certificate-authority/certs/webserver.crt
       SSLCertificateKeyFile  /chemin/certificate-authority/private/webserver.key
apachectl configtest
service apache2 restart

Lorsque l’on se connecte au site, une alerte nous informe que le site est autosigné. On peut consulter le certificat, dans la partie "issuer" on retrouve les informations renseigné plus haut "FR, département, ville...". Accepter le certificat de manière permanente.

remarque : La commande suivant serait censé tout faire, mais je n’ai pas trouvé ou était généré le certificat (c’est peut être les fichiers ssl-cert-snakeoil.*)

aptitude install ssl-cert

Ajout sur Android

Pour pouvoir installé le certificat il faut avoir défini un système de sécurité à l’ouverture de l’ordipoche (code pin ou autre), sinon android refusera de l’installer..

Il s’agit de récupérer d’une manière ou d’une autre le fichier ca.cert par le réseau

méthode 1 :
- par exemple utiliser l’apps CAdroid http://cadroid.bitfire.at/ installé depuis F-Droid (il faut d’abord installer f-droid en téléchargeant le paquet apk depuis leur site, pour l’installer il faut autoriser les sources tiers dans Android, une fois les applications installé on peut revoir le paramétrage des sources tierces). Ne pas installer de puis le google play, car l’appli plante (ca me l’a fait au moins sur un ordiphone). Juste après l’installation f-droid plante, mais cadroid est quand même bien installé.
- mettre l’adresse du serveur web : https://www.domaine.fr
- les infos du certificat s’affiche, faire next
- un chemin est donnée : /storage/emulated/0/X.crt, faire next
- aller sur "open android settings", qui redirige vers paramètre système -> général -> sécurités
- gestion des certificats
- installer depuis la "mémoire de stockage", il est directement à dedans
- mettre un nom au certificat (mettre www.domaine.fr)
- dire que pour VPN et application
- taper le mot de passe pour les tites de compétence du stockage
- android bug #31101, et pour android 4.4 bug #62644

- vérifier qu’apparait dans : paramètre système -> général -> sécurités -> certificats de confiance -> utilistateur

méthode 2 :
- en cas de problème avec cadroid, on peut mettre le fichier dans un répertoir de owncloud puis utiliser le client owncloud pour le récupérer, en cliquant dessus le système propose d’installer le certificat

méthode 3 : peut être avec firefox

Ajouter le CA dans le navigateur

- copier le ca.cert sur le poste conserné (par exemple avec scp)
- aller dans Iceweasel -> menu -> préférences -> avancé -> certificats -> afficher les certificats -> voir l’onglet "Autorité"
- importer : et aller chercher le fichier ca.crt

Le certificat est alors classé dans la liste d’après le nom de organizationName

Il y a un problème avec iceweasel 31 :
http://blog.dob.sk/2014/07/23/firefox-31-self-signed-certificate-sec_error_ca_cert_invalid/

 Clients, accès aux fichiers

Client web
- utiliser l’interface Web

Client owncloud
- utiliser le client owncloud : https://doc.owncloud.org/desktop/1.7/installing.html

Permet un accès hors ligne.

apt install owncloud-client -t jessie-backports

J’ai mis la version des backports car sinon j’avais une erreur d’authentification.

Sur le client, pour que le certificat soit accepter, pour assurer j’ai mis le certificat de l’autorité de certification et le certificat du serveur web (peut être pas besoin de deuxième).

cp ca.crt webserver.crt /usr/share/ca-certificates
dpkg-reconfigure ca-certificates

Cette dernière erreur ne doit faire de message d’erreur, ou bizarre (j’avais un message qui faisait added, puis removed...et ça ne marchait pas)

Clients webdav

Ne permet pas d’avoir accès hors ligne.

Plusieurs solutions
faire une connexion WebDav

Voir dans la documentation : depuis l’interface web, bouton utilisateur en haut à droite, Aide, Documentation utilisateur, après c’est en anglais "Accessing ownCloud Files Using WebDAV"

Depuis Nautilus

- http://doc.ubuntu-fr.org/owncloud#utilisation_avec_nautilus
- Nautilus -> Fichier -> se connecter à un serveur
- webdav https
- depuis owncloud aller dans les fichiers, récupérer dans le paramtrage du répertoir, le lien associé, du genre :
https://www.mondomaine.fr/owncloud/remote.php/webdav/
- mais remplacer https par davs
- puis mettre nom d’utilisateur et mot de passe
- mettre un signet pour ne pas avoir à refaire la manipulation à l’avenir

point de montage davfs
source :
- http://lesaventuresdeyannigdanslemondeit.blogspot.fr/2013/01/utilisation-de-webdav-en-ligne-de.html
- http://doc.ubuntu-fr.org/davfs2

Depuis le compte root

aptitude install davfs2
dpkg-reconfigure davfs2
Autoriser les utilisateurs non privilégiés à monter les ressources WebDAV ?  # répondre oui
adduser $USER davfs2    # puis déconnecter et reconnecter l'utilisateur en question
sudo
vi /etc/fstab
...
https://serveur:port/owncloud/remote.php/webdav/   /home/votre_nom/votre_répertoire        davfs        rw,user,noauto        0        0
...

Depuis le compte utilisateur

mkdir $HOME/owncloud_fichiers
mkdir ~/.davfs2
cp /etc/davfs2/davfs2.conf ~/.davfs2
sudo cp /etc/davfs2/secrets ~/.davfs2
sudo chown $USER ~/.davfs2/secrets
vi ~/.davfs2/secrets
/home/utilisateur/owncloud_fichiers        identifiant_webdav        mot_de_passe_webdav

Le mot de passe n’est pas obligé d’être renseigné, il sera demandé lors du montage

mount /home/utilisateur/owncloud_fichiers

importer un calendrier dans owncloud

- faire l’export au format ical depuis l’ancien calendrier
- transfert le fichier ical dans les Fichiers de owncloud
- depuis owncloud cliquer sur le fichier, il propose alors de faire l’import.

 Synchro Android

Comme il arrive que le serveur soit joint depuis le résau local, il faut que la résolution de nom DNS de l’ordinateur de poche renvoi l’adresse ip locale. Pour cela :
- mise en place d’un serveur DNS sur un serveur du réseau local (le serveur owncloud par exemple)
- sur l’ordi de poche, ajout d’un appli pour modifier le serveur DNS du Wifi. Attention car l’appli demande peu d’autorisation lors de l’installation, mais ensuite, les mises à jour suivantes demande des autorisations qui ne sont pas nécessaire, je décide donc de ne pas mettre les mises à jour.
- Installatio de owncloud : installer d’abord F-Droid (en téléchargeant le paquet apk depuis leur site, pour l’installer il faut autoriser les sources tiers dans Android, une fois les applications installé on peut revoir le paramétrage des sources tierces), puis installer owncloud avec F-Droid : il demande un tas d’autorisation, je me demande s’il a vraiment besoin de tout.
- pour tester le serveur DNS depuis l’ordinateur poche, j’utilise les applications : terminal et le keyboard complet, et aussi connectBot pour accès au serveur en ssh depuis l’ordi de poche.

L’application permet de synchroniser les documents.

Il vaut mieux utiliser https, mais pour que cela fonctionne il faut conifgurer le serveur (voir ailleurs dans l’article), et autoriser le certificat dans android, pour cela voir la documentation dans la faq : https://davdroid.bitfire.at/faq/entry/importing-a-certificate
Il faut accepter le certificat (voir ailleurs dans l’article).

Pour la synchro des contacts et du calendrier utiliser Davdroid. Il faut déclarer alors le compte pour le calendrier et le compte pour les contacts. Retrouver les liens dav depuis owncloud
- calendrier et contacts et tâches : https://www.mondomaine.fr/nextcloud/remote.php/dav

Aller ensuite de le carnet d’adresse, et dans le paramétrage régler les contacts à afficher (cocher la source défini précédement).

 Synchro icedove

Calendrier

Pour le calendrier, sous Debian, utiliser icedove avec l’extension lightning.
Remarque : pas besoin du sogo connector pour le calendrier.

Suite à un problème, j’ai voulu reparamétrer tous les agendas, en me désabonnant de tous les agendas réseau, le problème est que lightning ne laisse pas désabonner du dernier agenda, j’ai dû créer un agenda local temporaire pour me désabonner du dernier agenda réseau.

Pour ajouter un agenda, récupérer l’adresse depuis l’interface web de nextcloud, qui ressemble à :

Ajouter chaque agenda avec sa propre adresse (récuypérer le lien depuis l’interface web nextcloud, sur l’icone "lien" du calendrier), du genre :
https://www.mondomaine.fr/nextcloudremote.php/dav/calendars/utilisateur/personnel/

Pour info, l’adresse générique ne fonctionne pas :
https://www.mondomaine.fr/nextcloud/remote.php/dav/

Depuis lightning :
- bouton droit dans la colonne de gauche sous l’agenda
- Nouvel agenda
- Sur le réseau
- Caldav
- mettre l’adresse
- indiquer le nom (n’est pas récupéré)
- indiquer la couleur (n’est pas récupéré)

Contacts

Pour importer des contacts de icedove vers nextcloud : les exporter au format CSV, puis faire un import dans owncloud, l’interface est intuitive.

Pour synchroniser de nextcloud vers icedove :
- télécharger le plugin SOGo qui correspond à la verrsion de thunderbird, par exemple fichier sogo-connector-31.0.3.xpi
https://sogo.nu/download.html#/frontends

Choisir "sogo connector" pour lightning.

- Installer le fichier dans icedove, depuis la gestion des modules complémentaire, faire "installer depuis un fichier". Redémarrer Icedove, il y a alors un nouveau menu qui apparait : carnet adresse -> fichier -> nouveau -> carnet d’adresse disant
- indiquer l’URL, ressmble à : https://www.mondomaine.fr/nextcloud/remote.php/dav/addressbooks/users/identifiant/contacts/
- Puis "bouton droit" sur lágenda, "synchroniser". On peut ajouter le bouton "synchroniser" dans la barre dóutils.
- voir info ici :
https://docs.nextcloud.com/server/9/user_manual/pim/sync_thunderbird.html
- il m’est arrivé que le sogo connector ne me demande pas le couple identifiant/mot de passe, mais c’est normal car ils avaient déjà été enregistré dans icedove lors de la configuration de la connexion au calendrier avec lightning (si on supprime le mot de passe enregistré, sogo demande bien le mot de passe, ce qui est bien normal)

Problème

J’ai eu un problème de synchro avec les contacts depuis icedove : j’ai modifier un contact (changer de carnet d’adresse), la synchro faisait une copie du contact, mais ne faisait pas la suppression, la synchro suivante refaisait une copie... je n’ai pas trouvé comment arrêter la copie à chaque synchro, il y avait un message d’erreur dans les logs sur carddav... j’ai supprimer le carnet d’adresse distant dans icedove, puis l’ai recréé.

 Roundcube

Synchro avec roundcube
Tentative de synchro des contacts avec roundcube, en utilisant les plugins "​CardDAV Backend " ou "CardDAV-Plugin", mais c’est un échec... à revoir plus tard. Je ne vois pas de nouveau menu apparaitre dans roundcube.

Intégration roundcube

Il existe un plugin roundcube pour owncloud, qui permet d’accéder à la lecture des méls une fois connecté à owncloud par l’interface web (on peut enregistrer les identifiants et mots de passe).

téléchargement :
https://apps.owncloud.com/content/show.php/roundcube?content=151523

https://github.com/hypery2k/owncloud/wiki/Roundcube-OC-Installation-and-usage

https://github.com/hypery2k/owncloud/wiki#roundcube

Dans owncloud/config/config.php mettre conformément à doc :
'xframe_restriction' => true,

paquet curl installé

Télécharger le fichier (exemple : 151523-roundcube_v2.6.0.306.zip)

Pour ajouter le plugin, voir la partie "ajout plugin" de cette page.

Cela ajout un menu dans la page de configuration de l’administrateur. Paramatérer ici l’adresse de roundcube : il s’agit en fait de la fin de l’adresse, le nom de domaine devant être commun avec celui de owncloud (c’est plus simple).

Par exemple si roundcube est accessible par https://www.mondomaine.fr/courriel et owncloud par https://www.mondomaine.fr/owncloud alors mettre dans la case /courriel/

Pour un certificat auto signer il faut cocher la case :
- Disable SSL verification, e.g. for self-signed certificates
Sinon on aura une erreur :
Opening url https:\/\/www.domaine.fr\/courriel\/ failed with SSL certificate problem: certificate has expired"

Il faut que roundcube soit configuré pour faire une connexion sur le domaine en question :

vi /etc/roundcube/main.inc.php
...
$rcmail_config['default_host'] = 'mondomaine.fr';

Si ce paramètre est laissé vide, cela permet de laisser le choix lors de la connexion à roundcube, mais ce n’est pas bon pour une connexion depuis owncloud.

On peut choisir "autologin", il faut pour cela que les utilisateurs aient les mêmes identifiants et mot de passe entre owncloud et roundcube, et ainsi ils seront automatiquement connectés à roundcube lorsqu’il passeront par owncloud pour y accéder.

Cela ajoute aussi un menu supplémentaire "Webmail", ainsi qu’un menu configuration par utilisateur (pour mettre identifiant et mot de passe de la messagerie électronique).

A ce jour, j’ai l’erreur suivante :

Failed to refresh the RC
OC_RoundCube_App.class.php->showMailFrame(): There were login errors",
"OC_RoundCube_App.class.php->showMailFrame(): RoundCube can not login to roundcube due to a login
:"Not rendering roundcube iframe view due to errors"
Got the following error code: 1

En attendand, on va se connecter au webmail sans passer par owncloud.

Sinon, voir l’application "mail" pour owncloud.
- https://apps.owncloud.com/content/show.php?content=169914
- https://github.com/owncloud/mail

 Problème avec contact

J’ai eu un problème avec les contacts, je crois suite à une désactivation réinstallation de l’application. Tous les contacts n’étaient plus synchroniser avec davdroid, seulement une partie. Pour corriger j’ai exporter tous les contacts dans un fichier *.vcf, puis en regardant les UID j’ai vu qu’elle n’était pas toute de la même forme :
- UID:02144285-dd56-4444-883d-34444444
- ou UID:02144285-dd56-4444-883d-344444445@www.mondomaine.fr

J’ai supprimer touts les terminaisons "@www.mondomaine.fr", à voir ce que ça donne.

 Fail2ban

Modifier le fichier /chemin/owncloud/config/config.php
Le loglevel ne doit pas être supérieur à 2 pour que les tentatives de login soient enregistrées dans le log !
le logtimezone doit être accordé avec l’heure de votre serveur (Europe/Brussels). Sinon fail2ban pensera toujours que la connexion est ancienne et ne bannira rien.

On a donc :

’loglevel’ => ’2’,
’logtimezone’ => ’Europe/Brussels’, ou ’UTC’ ?

Créer un nouveau filtre pour fail2ban dans /etc/fail2ban/filter.d/owncloud.conf : (regex pour owncloud >8, ok pour 9.1)

Pour owncloud 8.1.9 (il y a un guillement en moins après le HOST...le log devait être mal construit)

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

Pour owncloud 9.1 :

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

La règle se "comprend" en regardant le fichier owncloud.log après avoir fait une erreur de connexion, on a une ligne qui ressemble à :

{"reqId":"+wQnQ6yLqRpBk7OV0JUp","remoteAddr":"1XXXX","app":"core","message":"Login failed: 'blabla' (Remote IP: XXXXXX')","level":2,"time":"2016-12-10T14:08:13+01:00","method":"POST","url":"\/xxxx\/index.php\/login","user":"--"}

Créer une nouvelle règle dans /etc/fail2ban/jail.local :

[owncloud]
enabled  = true
port     = http,https
filter   = owncloud
logpath  = /home/data_owncloud/owncloud.log
maxretry = 3
systemctl restart fail2ban

Pour tester la règle :

fail2ban-regex /home/data_owncloud/owncloud.log /etc/fail2ban/filter.d/owncloud.conf

Pour vérifier le statut de la règle : fail2ban-client status owncloud

Pour tester, faite 3 erreurs de connexion, à la 4ème la page d’accueil ne s’affichera plus, on a une erreur "Connexion échouée".

Pour débloquer une IP :
voir l’ip bloqué :

# iptables -L | grep reject-with
REJECT     all  --  192.168.0.13           anywhere             reject-with icmp-port-unreachable

# fail2ban-client set owncloud unbanip 192.168.0.13

Remarque :
- fail2ban ne gère pas "encore" l’ipv6