Autant sur un pc avec toutes ses photos synchronisées on s’en passe… Mais sur un smartphone ou tablette on va principalement prendre que les photos qui nous intéressent. Attendre la génération des aperçus miniatures est vraiment long si vous hébergez sur une minimachine ou un VPS pas cher.

C’est pour cela qu’il est préférable d’avoir générés tous ces aperçus juste après la mise en place de votre nextcloud et vos données. Cette première étape va prendre du temps, il va falloir que vos CPU travaillent un peu. Pour votre installation perso ce n’est pas grave, mais pour une mise en prod pensez à le faire avant.

Selon la quantité de CPU et de photos à traiter, une tâche de nuit ne suffira peut-être pas Vous ne voudriez pas que vos utilisateurs vous tapent dessus parce que votre nouveau système de gestion de documents est lent.

Dans mon utilisation personnelle, sur un Atom x5-z8350 (4×1.44Ghz), cela à pris 12h pour générer les miniatures de presque 11.000 photos pour 120Go. Pour chacune de ces photos, il y a 13 fichiers aperçus, on atteint presque les 150.000 fichiers et 20Go d’aperçu. Pensez-y au moment de choisir le nombre d’inodes de votre système de fichiers ext4!

Dans un second temps, vous allez mettre une tâche cron afin de générer les aperçus miniatures automatiquement pour les nouvelles images. S’il n’y en a pas, le cron prend 2 secondes d’exécution. Cette tâche peut très bien tourner tous les soirs, voir toutes les heures si vous en avez le besoin.

Rassurez vous, si vous voulez générer les miniatures sur une installation existante, c’est possible de lancer la tâche en plusieurs fois, sans repasser sur les répertoires déjà scannés, afin d’étaler le travaille sur plusieurs nuits

Je vous explique donc les différentes étapes nécessaires…

Installation des composants Nextcloud des miniatures

Par le passé, un module était inclu de base pour générer les miniatures, mais ce n’est plus le cas si vous disposez de la version Nextcloud 12 ou supérieur. La documentation fournie sur le wiki est obsolète et n’est valable que pour les anciennes versions.

Vous devez vous rendre sur la page suivante pour disposer de la dernière version de previewgenerator, sinon voici le lien direct de la version 1.0.7 pour Nextcloud v12.

Téléchargez et installez le module :

wget https://github.com/rullzer/previewgenerator/releases/download/v1.0.7/previewgenerator.tar.gz
cd /var/www/nextcloud/apps/
tar -xf /root/previewgenerator.tar.gz
chown -R www-data:www-data previewgenerator/

Listez ensuite les applications via le CLi OCC, toujours dans le répertoire racine de votre Nextcloud : /var/www/nextcloud/

php occ app:list
Enabled:
  - admin_audit: 1.2.0
  - bruteforcesettings: 1.0.2
  - comments: 1.2.0
  - dav: 1.3.0
  - federatedfilesharing: 1.2.0
  - federation: 1.2.0
  - files: 1.7.2
  - files_external: 1.3.0
  - files_pdfviewer: 1.1.1
  - files_sharing: 1.4.0
  - files_texteditor: 2.4.1
  - files_trashbin: 1.2.0
  - files_versions: 1.5.0
  - files_videoplayer: 1.1.0
  - gallery: 17.0.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.0.0
  - nextcloud_announcements: 1.1
  - notifications: 2.0.0
  - oauth2: 1.0.5
  - password_policy: 1.2.2
  - provisioning_api: 1.2.0
  - serverinfo: 1.2.0
  - sharebymail: 1.2.0
  - survey_client: 1.0.0
  - systemtags: 1.2.0
  - theming: 1.3.0
  - twofactor_backupcodes: 1.1.1
  - updatenotification: 1.2.0
  - workflowengine: 1.2.0
Disabled:
  - activity
  - encryption
  - firstrunwizard
  - previewgenerator
  - richdocuments
  - user_external
  - user_ldap

Si vous voyez « previewgenerator », c’est correct. Il ne reste qu’à l’activer :

php occ app:enable previewgenerator

Première génération des miniatures

Voici donc la première étape pour générer toutes les miniatures. Il est possible de le faire également pour un utilisateur défini :

php occ preview:generate-all [user-id]

Loop over all files and try to generate previews for them. If `user-id` is supplied just loop over the files for that user.

Génération automatique pour les nouvelles images

Tester la commande de génération de thumbnails pour les nouveaux fichiers en utilisateur www-data :

su -c 'php /var/www/nextcloud/occ preview:pre-generate' www-data

Do the actual pregeneration. This means only for new or modified files (since the app was enabled or the last pregeneration was done).

Exemple de cron journalier en utilisateur www-data pour créer les miniatures des nouveaux fichiers : /etc/cron.d/nextcloud

0 1 * * * www-data php /var/www/nextcloud/occ preview:pre-generate

Voilà vos miniatures seront créées automatiquement dorénavant

L’article Miniatures Nextcloud – générer les thumbnails automatiquement est apparu en premier sur Mon linux.

Owncloud vous permet déjà de récupérer votre document depuis n’importe où dans le monde via un simple navigateur. Vous pouvez ainsi le télécharger, l’éditer en local et le déposer sur votre Owncloud. Mais il faut que la machine que l’on vous prête ait soit Office, soit Libreoffice ou bien OpenOffice… Ce qui n’est pas toujours le cas.

Vous en voulez donc plus… Pouvoir éditer vos documents à la volée sans quitter votre navigateur, depuis n’importe quel machine… Et bien cela est possible pour vos documents texte! L’opération n’est pas bien longue et je vous invite à voir la suite…

Vous allez devoir installer les binaires LibreOffice pour pouvoir visionner des documents .doc ou .docx. Pour les fichiers .odt vous n’en avez pas forcement besoin.

Installation du plugin Owncloud / Nextcloud

Vous devez vous rendre dans le menu application d’owncloud :

Dans Productivity vous pouvez sélectionner le module Documents et l’activer.

Vous pouvez déjà ouvrir des documents LibreOffice Writer .odt dans votre Owncloud!

Gestion des fichiers Word .doc et .docx

Pour pouvoir gérer les documents Word, vous devez installer LibreOffice. Vous n’avez pas besoin d’installer toute la suite LibreOffice qui prend pas mal de place. Mais voici le minimum, avec en prévision d’une compatibilité future pour les documents type tableur.

Dans mon cas je suis en Debian 8 Jessie avec PHP 7 installé.

On installe Java ou OpenJDK dans mon cas, avec le paquets common et les modules de documents LibreOffice qui nous intéresse :

apt-get install openjdk-7-jre-headless libreoffice-common libreoffice-writer libreoffice-calc libreoffice-draw

Dans le fichier config.php à la racine de votre répertoire Owncloud, insérez ceci :

'preview_libreoffice_path' => '/usr/bin/libreoffice',
 'preview_office_cl_parameters' => '--headless --nologo --nofirststartwizard --invisible --norestore --convert-to pdf --outdir ',

Vérifiez que tout fonctionne bien dans : Administration > Document > choisir local > appliquer

Si ca me fonctionne pas, voir si libreOffice a bien été installé correctement et que le mode headless fonctionne :

# libreoffice --headless --convert-to odt:writer8 --outdir /data/owncloud/g/files --writer /data/owncloud/g/files/Bon.docx
convert /data/owncloud/g/files/Bon.docx -> /data/owncloud/g/files/Bon.odt using writer8

Vous avez également des logs en bas de la page Administration. Vous devrez rafraichir la page au besoin.

Je vous conseille d’installer un cache pour Owncloud, qui vous sera utile pour gérer vos documents.

L’article Owncloud – inclure la gestion de documents Writer Word est apparu en premier sur Mon linux.

Je vous propose ici de remplacer votre cache Memcached par le cache Redis pour votre serveur Owncloud. Il est plus performant, afin d’avoir un peu plus de répondant! Il a aussi d’autres points intéressants, je vous laisse lire ce commentaire sur stackoverflow qui parle de Redis.

Si vous n’avez pas Memcached pour votre Serveur Owncloud et que vous partez de rien, cela est également bon pour vous.

Dans mon serveur j’utilise PHP7 pour Owncloud 8.2.2, je vous invite à lire ce billet pour la marche à suivre si cela vous intéresse.

Le remplacement de memcached par Redis se fait en un claquement de doigts, vous aller voir…

Voici ce qu’il faut installer pour commencer, si vous êtes en PHP 5.5 il y a le paquet php5-redis

apt-get install redis-sentinel php7.0-redis
phpenmod redis
/etc/init.d/apache2 restart

Vérifier l’installation :

netstat -tlpn | grep redis
tcp        0      0 127.0.0.1:26379         0.0.0.0:*               LISTEN      26203/redis-sentine
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      26156/redis-server

Si vous aviez APC ou APCu, retirez la ligne suivante dans config/config.php :

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

Et vous mettez donc le nouveau cache en fonction dans le fichier config/config.php :

'memcache.local' => '\OC\Memcache\Redis',
'redis' => array(
   'host' => 'localhost',
   'port' => 6379,
    ),

Voilà votre serveur Owncloud est configuré!

Si vous voulez plus d’information, voici la source sur le site Owncloud.

L’article Owncloud – Installer Redis pour remplacer memcached est apparu en premier sur Mon linux.

• Une vitesse d’exécution jusqu’à 2x supérieure
• Compatibilité 64 bits
• Utilisation de la mémoire vive réduit de 2/3

Pour toutes ces raisons, autant en faire profiter notre Owncloud

Vous devez être en Debian 8 Jessie minimum pour suivre ce billet? Vous aurez l’avantage de rester en Debian stable et disposer des améliorations de PHP 7. Si vous êtes sous Debian 9 stretch ou dérivé Ubuntu vous êtes déjà équipé

Guillaume Plessis de Dotdeb met à disposition des paquets PHP 7 pour Debian 8 (Jessie). Pour rappel, on est toujours en PHP 5.6 sous Debian 8 et PHP 7 ne sera ajouté que sous Debian 9. Pour les détails je vous retourne vers son blog.

PHP7 son installation via des dépôts

Ajouter les dépôts si vous faites confiance à Guillaume Plessis :

~# wget -O- https://www.dotdeb.org/dotdeb.gpg | apt-key add -

~# echo "deb http://packages.dotdeb.org jessie all" > /etc/apt/sources.list.d/dotdeb.list

~# apt-get update

Lister tous les paquets de type PHP5 afin de ne pas oublier de module :

~# dpkg -l php5* | egrep '^ii'
ii  php5            5.6.17+dfsg-0+deb8u1 all          server-side, HTML-embedded scripting language (metapackage)
ii  php5-apcu       4.0.7-1              amd64        APC User Cache for PHP 5
ii  php5-cgi        5.6.17+dfsg-0+deb8u1 amd64        server-side, HTML-embedded scripting language (CGI binary)
ii  php5-cli        5.6.17+dfsg-0+deb8u1 amd64        command-line interpreter for the php5 scripting language
ii  php5-common     5.6.17+dfsg-0+deb8u1 amd64        Common files for packages built from the php5 source
ii  php5-curl       5.6.17+dfsg-0+deb8u1 amd64        CURL module for php5
ii  php5-fpm        5.6.17+dfsg-0+deb8u1 amd64        server-side, HTML-embedded scripting language (FPM-CGI binary)
ii  php5-gd         5.6.17+dfsg-0+deb8u1 amd64        GD module for php5
ii  php5-intl       5.6.17+dfsg-0+deb8u1 amd64        internationalisation module for php5
ii  php5-json       1.3.6-1              amd64        JSON module for php5
ii  php5-mcrypt     5.6.17+dfsg-0+deb8u1 amd64        MCrypt module for php5
ii  php5-mysql      5.6.17+dfsg-0+deb8u1 amd64        MySQL module for php5
ii  php5-readline   5.6.17+dfsg-0+deb8u1 amd64        Readline module for php5
ii  php5-sqlite     5.6.17+dfsg-0+deb8u1 amd64        SQLite module for php5

Pour lister rapidement les paquets de PHP 5 à supprimer :

~# dpkg -l php5* | egrep '^ii' | while read i name v a d ; do echo -n "$name " ; done

Vérifier que tous les paquets php7.0 sont dispo avec ce dépôt Debian :

~# apt-get install php7.0 php7.0-apcu php7.0-cgi  php7.0-cli php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-mcrypt php7.0-mysql php7.0-sqlite

On supprime ensuite la liste donnée après vérification que tous ce que vous utilisiez est disponible pour php7.0 :

~# apt-get remove php5 php5-apcu php5-cgi php5-cli php5-common php5-curl php5-fpm php5-gd php5-intl php5-json php5-mcrypt php5-mysql php5-readline php5-sqlite

Installer les paquets correspondants :

~# apt-get install php7.0 php7.0-apcu php7.0-cgi  php7.0-cli php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-mcrypt php7.0-mysql php7.0-sqlite
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'php7.0-sqlite3' for regex 'php7.0-sqlite'
The following packages were automatically installed and are no longer required:
comerr-dev krb5-multidev libapr-memcache0 libblas3gf libdrm-nouveau1a libexiv2-12 libgcrypt11-dev libgd2-xpm libgnutlsxx27 libicu48 libidn11-dev libjpeg8 libkadm5clnt-mit8 libkdb5-6
libkrb5-dev liblcms1 libldap2-dev libmagickcore5 libmagickcore5-extra libmagickwand5 libmpc2 libp11-kit-dev libpango1.0-0 libpthread-stubs0 librsvg2-2 librsvg2-common librtmp0
libssh2-1-dev libssl-doc libtasn1-3-dev libtiff4 libtime-modules-perl python-central python-gnupginterface zlib1g-dev
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
php-common php-readline php7.0-common php7.0-opcache php7.0-readline
Suggested packages:
php-user-cache
The following NEW packages will be installed:
php-common php-readline php7.0 php7.0-apcu php7.0-cgi php7.0-cli php7.0-common php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-mcrypt php7.0-mysql php7.0-opcache php7.0-readline
php7.0-sqlite3
0 upgraded, 16 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.0 MB of archives.
After this operation, 44.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]

On installe ensuite le module Apache pour PHP 7 :

~# apt-get install libapache2-mod-php

Vérification de l’installation

Vérifier la version de PHP :

~# php -v
~# /etc/init.d/php7.0-fpm status
[ ok ] php-fpm7.0 is running.

S’il y a encore php5-fmp qui est mis en démarrage :

~# ls -l /etc/rc?.d/*php*
lrwxrwxrwx 1 root root 18 Mar 12 20:40 /etc/rc0.d/K01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc0.d/K01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:40 /etc/rc1.d/K01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc1.d/K01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:58 /etc/rc2.d/S01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc2.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:58 /etc/rc3.d/S01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc3.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:58 /etc/rc4.d/S01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc4.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:58 /etc/rc5.d/S01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc5.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 18 Mar 12 20:40 /etc/rc6.d/K01php5-fpm -> ../init.d/php5-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc6.d/K01php7.0-fpm -> ../init.d/php7.0-fpm

~# update-rc.d php5-fpm remove

~# ls -l /etc/rc?.d/*php*
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc0.d/K01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc1.d/K01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc2.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc3.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc4.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc5.d/S01php7.0-fpm -> ../init.d/php7.0-fpm
lrwxrwxrwx 1 root root 20 Mar 12 22:49 /etc/rc6.d/K01php7.0-fpm -> ../init.d/php7.0-fpm

Ensuite un fichier de test contenant ceci pour valider que php fonctionne bien :

<?php phpinfo(); ?>

Et en essayant Owncloud, vous pourriez avoir ceci comme message d’erreur dans le format HTML :

Memcache \OC\Memcache\APC not available for local cache Is the matching PHP module installed and enabled?

C’est du à l’utilisation de memcached si vous l’aviez activé pour accélérer votre serveur.

Après vérification APCu est bien activé, et le problème est ailleurs : changement de nom de classe et des adaptation dans le code de Owncloud 8.2.1.4 sont à faire. Vous pouvez utiliser ce workarround pour php7. Mais également vous pouvez mettre à jour Owncloud vers la 8.2.3 ou passer le cap de la v9.

Vous pouvez faire un test en désactivant le memcache en désactivant la ligne suivant dans le fichier /var/www/owncloud/config/config.php :

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

Vous retrouverez votre interface.

Dans mon cas je n’ai pas été plus loin avec memcached car il a trouvé un remplaçant depuis quelques temps…. Il ne reste plus qu’à remplacer votre memcached par redis, qui est un cache plus performant, afin de retrouver un peu de rapidité! J’en parle dans un prochain billet.

Retour rapide sur le gain de Performance de PHP7

Ces graphiques sont pour une application WordPress. Voici le temps de réponse dynamique (bleu clair) et static (bleu foncé). On peut voir une baisse du temps de réponse sur le dernier tiers. Ce n’est pas énorme comme boost mais c’est toujours ça de gagné

Sur le CPU on remarque également une diminution de la charge :

En conclusion, ce remplacement de PHP 5.6 en PHP 7 est bien bénéfique pour mon utilisation (WordPress). Mais je n’ai par contre pas de statistiques valable pour Owncloud car c’est une utilisation personnelle et donc peu de trafic pour une comparaison.

L’article Owncloud – utiliser php7 sous Debian Jessie est apparu en premier sur Mon linux.

Penser à sécuriser la partie système de son application est également important. Voici quelques points qui me semblent intéressants.

Redirection HTTPS pour Owncloud

La première chose à faire est de sécuriser l’échange des données entre le serveur et le client, ce qui se fait par HTTPS bien évidemment. Mais il faut penser à rediriger les infidèles qui utiliseraient HTTP vers la page en HTTPS. Un moyen simple de le faire est d’éditer le fichier /etc/apache2/site-available/default et d’y mettre ceci :

	DocumentRoot /var/www
	Redirect / https://votrecloud.votredomaine.net

Préférez également l’utilisation d’un certificat SSL validé par une autorité de certification valide. Par exemple startSSL, qui a été expliqué dans un article précédent.

Sécuriser les droits d’accès

Vous devez changer les droits d’accès unix à vos fichiers Owncloud afin de limiter l’impacte d’un potentiel hack de votre applicatif. Pour cela, voici un script passe partout glané sur le web (je n’ai plus la source). Veillez à utiliser le bon « path » et le bon utilisation Apache. Pour Debian, Ubuntu, etc ce sera « www-data ». Pour CentOS et ses dérivés, ce sera « httpd » :

#!/bin/bash
ocpath='/var/www/owncloud'
htuser='www-data'

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

Vous aurez peut-être un warning sur des fichiers inexistants selon votre système, lisez le pour voir si tous le reste est bon.

Configurer le vhost HTTPS Owncloud

Il faut activer certaines restrictions pour la durée de vie du certificat :

• Activer le mode headers : a2enmod headers
• Ajouter une configuration dans le vhost 443 : Header always add Strict-Transport-Security « max-age=15768000 » (dans cet exemple 6 mois)<VirtualHost *:443>
  ServerName cloud.owncloud.com
  Header always add Strict-Transport-Security « max-age=15768000 »
  </VirtualHost>

Source

Le reste viendra par la suite…

Si vous avez des indications utiles n’hésitez pas!

L’article Owncloud sécurité de son installation serveur est apparu en premier sur Mon linux.