Il existe une version mineure LTS 3.28.66 supportée jusque juin 2023. Plus de version LTS après cela!

L’OS utilisé passant à Ubuntu 22.04, il faut déjà trouver un intermédiaire pour faire fonctionner la version actuelle et la mettre à jour. La version installée ne supporte uniquement que PHP 7.0.

Le but à atteindre étant d’utiliser la dernière version de l’application 6.1.8 et sa version PHP supportée 8.0.

Phases de migration LimeSurvey

1. Migrer en dernière version LTS 3.28.66 (support PHP 7.4 max)
2. Mise à jour de PHP 7.0 vers 7.4
3. Migrer vers 5.6.31 (supports PHP 7.2.5 to 8.0.x)
4. Migrer vers 6.1.8 (requires PHP 7.4.x or newer)
5. Mise à jour de PHP 7.4 vers 8.0

Pré-requis

1. On va devoir utiliser une sandbox docker ayant différentes versions de PHP pour faire la migration de l’application du à l’incompatibilité entre les version PHP de l’app et la nouvelle machine
2. On va ajouter un dépôt pour gérer les versions de PHP qui ne sont pas dans le dépôt ubuntu https://ppa.launchpadcontent.net/ondrej/php/ubuntu/ jammy main

Pour utiliser docker sous Windows, je vous réfère à mon article sur Docker Desktop.

Export/Import base de donnée LimeSurvey actuel

Export :

cd /var/www
sudo tar -czf /home/b/lime-prod.tgz limesurvey
sudo mysqldump --defaults-file=/etc/mysql/debian.cnf limesurveydb | gzip --to-stdout > /home/b/lime-prod.sql.gz

import :

scp new-srv:lime-prod.* ./
zcat lime-prod.sql.gz | sudo mysql lime
cd /data/www
sudo tar -xf /home/b/lime-prod.tgz
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Migrer LimeSurvey en dernière version LTS

Sur la sandbox docker, ajouter le support de PHP 7.0 et 7.4 via un dépôt supplémentaire.

La version Version 3.15 ne supportant pas php 7.4, il faut passer par le 7.0 pour mettre à jour vers la 3.28.66 et puis essayer de passer php en 7.4

Situation fonctionnelle

• Ajout du dépôt

sudo add-apt-repository ppa:ondrej/php

• ajout des paquets

sudo apt update
sudo apt install php7.0 php7.0-curl php7.0-mysql php7.0-mbstring php7.0-zip php7.0-gd php7.0-ldap php7.0-simplexml
sudo apt install php7.4 php7.4-curl  php7.4-mysql  php7.4-mbstring  php7.4-zip  php7.4-gd  php7.4-ldap  php7.4-simplexml

• Switch du PHP par défaut :

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
* 0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php) in manual mode

• Vérifier : php -v
• Activer dans apache la version à utiliser, ici 7.0 d’abord:

sudo a2dismod php8.1
sudo a2enmod php7.0
sudo systemctl restart apache2

• Importer les fichiers tgz + db

zcat limesurvey.sql.gz | mysql lime
cd /data/www
tar -xf lime-prod.tgz

• changer les accès db dans application/config/config.php

Pour le debug limesurvey :
application/config/config.php
‘debug’=>2,

Migration de LimeSurvey 3.15.3 vers 3.28.66

Notes de migration anciennes version

cd
wget https://download.limesurvey.org/latest-3.x-LTS/limesurvey3.28.66+230719.zip
cur_version=3.15.3
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey3.28.66+230719.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

Upgrade DB en console :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime_stag; with prefix :lime_ from 355 to 366
Database has been successfully upgraded to version 366

Après connexion à l’interface admin, pas de message pour upgrade la DB. Et vérifier si erreur template.

==> Etat OK, customisation logo, templates formulaire également.

Switch de PHP 7.0 vers PHP 7.4

Pour les versions suivantes, la version minimum est PHP 7.2.5 et il faut donc abandonné PHP7.0. Allons directement en 7.4 qui est censé être supporté par la version 3.28.66….

sudo update-alternatives --config php
There are 3 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
* 1            /usr/bin/php7.0   70        manual mode
  2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/php7.4 to provide /usr/bin/php (php) in manual mode
Time: 0h:00m:03s
php -v
sudo a2dismod php7.0
sudo a2enmod php7.4
sudo systemctl restart apache2

==> Etat OK également!

Migrer LimeSurvey vers 5.6.31

Cette version 5.6.31 supporte PHP 7.2.5 à 8.0.x.

cd
wget https://download.limesurvey.org/latest-5.x/limesurvey5.6.31+230718.zip
cur_version=3.28.66
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey5.6.31+230718.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 366 de la base de données pour rappel.

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 366 to 497
Database has been successfully upgraded to version 497
Time: 0h:00m:18s

Si erreur pour faire l’update entre 418 et 497, voir si bien en php 7.4 et recommencer depuis la 3.28.66. Un oubli arrive vite…

Migrer LimeSurvey vers 6.1.8

Cette version 6.1.8 de Limesurvey nécessite PHP 7.4.x ou plus.

Upgrade 5.6.31 vers 6.1.8

Attention l’interface est très différente, à voir l’impacte sur les utilisateurs de l’application !

cd
wget https://download.limesurvey.org/latest-master/limesurvey6.1.8+230717.zip
cur_version=5.6.31
sudo mysqldump lime | gzip --to-stdout > lime-${cur_version}.sql.gz
cd /data/www
sudo mv limesurvey limesurvey-$cur_version
sudo unzip /home/b/limesurvey6.1.8+230717.zip
sudo cp limesurvey-$cur_version/application/config/config.php limesurvey-$cur_version/application/config/security.php limesurvey/application/config/
sudo cp -ar limesurvey-$cur_version/upload limesurvey/
sudo chown -R www-data limesurvey/tmp limesurvey/upload limesurvey/application/config

On est à la version 497 de la base de données

Update en console possible :

sudo -u www-data php limesurvey/application/commands/console.php updatedb
Update mysql:host=localhost;port=3306;dbname=lime; with prefix :lime_ from 497 to 607
Database has been successfully upgraded to version 607
Time: 0h:00m:04s

Switch de PHP 7.4 vers PHP 8.0

Pour les versions suivantes de LimeSurvey, la version minimum est PHP 7.4.x. Pas d’infos officielles sur la version maximal, mais un information sur le forum :

8.1 and 8.2 are not supported, yet.
The maximum PHP version currently supported by LimeSurvey 5 is 8.0.x.

Il faut donc tester… Résultat des tests :

• PHP 7.4 est OK
• PHP 8.0 est OK
• PHP 8.1 ne semble pas supporté!!!
• PHP 8.2 non testé

Il faut donc utiliser PHP 8.0.

Installer :

sudo apt install php8.0 php8.0-curl  php8.0-mysql  php8.0-mbstring  php8.0-zip  php8.0-gd  php8.0-ldap  php8.0-simplexml
sudo a2dismod php7.4
sudo a2enmod php8.0
sudo systemctl restart apache2

sudo update-alternatives --config php
There are 4 choices for the alternative php (providing /usr/bin/php).

  Selection    Path             Priority   Status
------------------------------------------------------------
  0            /usr/bin/php8.1   81        auto mode
  1            /usr/bin/php7.0   70        manual mode
* 2            /usr/bin/php7.4   74        manual mode
  3            /usr/bin/php8.0   80        manual mode
  4            /usr/bin/php8.1   81        manual mode

Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/php8.0 to provide /usr/bin/php (php) in manual mode
php -v

Conclusion

La tâche n’était pas simple sans avoir une manipulation officielle d’un changement de version application + PHP. Il faut donc faire quelques raté pour en arriver à cette manipulation. Espérant aider le plus grand nombre!

L’article LimeSurvey migration 3.15 vers 6.1.8 est apparu en premier sur Mon linux.

Installation de certbot

Dans ce cas-ci, il sera installé sur le serveur Apache directement. Suivez d’abord les instructions d’installation selon votre système.

Sous Debian 9, faites directement ceci :

apt-get install certbot python-certbot-apache

Validation d’un seul domaine via let’s encrypt

Pour valider un seul domaine pour un certificat, il faut déjà avoir créé la configuration du site en HTTP. Certbot se chargera de demander le certificat à let’s encrypt et de créer une configuration de site identique en HTTPS, vous n’aurez rien à faire côté Apache. Vous aurez la possibilité de choisir de rediriger les utilisateurs depuis http vers https.

Exécutez ceci et suivez les instructions :

certbot --apache

Pour prendre en compte la modification, rechargez Apache :

service apache2 reload

Par la suite, un renouvellement de certificat pourra se faire via :

certbot renew

Un certificat let’s encrypt n’est valide que 3 mois. Il faut donc le renouveler tous les 3 mois. Heureusement un cron permet de le faire automatiquement, vérifiez que celui-ci est bien présent /etc/cron.d/certbot :

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Validation d’un certificat multi-domaine

Afin de valider un certificat multi-domaine, il faut spécifier ces domaines via des arguments de certbot. Bien évidemment pour le renouvellement il n’y aura rien de spécial à faire, cela suit la même procédure qu’un domaine seul.

Il faut exécuter manuellement:

certbot-auto --apache -d domaineprincipal.tld -d www.domaineprincipal.tld -d ...

Le premier domaine sera utilisé comme domaine principal, tous les autres seront utilisés comme domaines secondaires, appelé « SAN Certificates« . Cela signifie « Subject Alternative Name ».

Notre certificat multi-domaine a été installé directement dans la configuration Apache par Certbot, il suffit d’un reload de la configuration Apache.

L’article Créer un certificat multi-domaine let’s encrypt avec Apache est apparu en premier sur Mon linux.

Vous pouvez installer le contrôleur sur un serveur linux, windows ou macOS. C’est du java avec une base de données MongoDB. Il tourne très bien sur un serveur qui héberge aussi mon nextcloud, deluge, samba, etc. Mais mon « souci » est qu’il fonctionne sur un port alternatif et je voudrais le rendre disponible sur le port HTTPS où tourne déjà mon Apache avec nextcloud, un proxy pour deluge-web, let’s encrypt, etc.

L’accès à la gestion des clients et AP du contrôleur se fait via une page web principalement. Il existe aussi une application android. Il faut bien comprendre que sans contrôleur, on ne sait pas manager les AP. Donc ces AP ne disposent pas d’une page web d’administration comme les autres AP du marché grand public ou semi-pro.

L’application Android permet toutefois de faire un mode disvovery et faire une simple installation AP pour un seul réseau. Mais pour ce qui est de diffuser 2 SSID simultanés, de passer par un portail captif, etc. Il vous faut un contrôleur.

Pour lier un AP au contrôleur Unifi à distance, cela se fait soit via Unifi-discover sur pc (il faut être sur le même réseau ethernet layer2) ou via une app android Unifi. Les méthodes sont décrites sur la guideline d’Ubiquiti.

Je vous livre ma configuration d’Apache pour se connecter en HTTPS pour sécuriser l’accès à distance au contrôleur Unifi. Et ce sera avec une URL plus classe que http://unify.domain.com:8080/inform

Installer le paquet Unifi nécessaire

Vous pouvez récupérer le paquet le plus récent du software Unifi. Un paquet deb est dispo pour ceux qui sont sous Debian ou Ubuntu.

dpkg -i /disk/upload/unifi_sysvinit_all.deb
unifi depends on mongodb-server (>= 2.4.10) | mongodb-10gen (>= 2.4.14) | mongodb-org-server (>= 2.6.0); however:
Package mongodb-server is not installed.
Package mongodb-10gen is not installed.
Package mongodb-org-server is not installed.
unifi depends on openjdk-7-jre-headless | java8-runtime-headless; however:
Package openjdk-7-jre-headless is not installed.
Package java8-runtime-headless is not installed.
apt-get -f install

L’accès se fait via : https://localhost:8443
Attention que le premier réseau utilisable dans l’AP est en mode untagged

L’url pour joindre un second contrôleur : controller inform URL http://unify.domain.com:8080/inform

Mettre un proxy revers apache pour du WSS sur /wss et du http à la racine :

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/unify.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/unify.domain.com/privkey.pem

# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /wss wss://127.0.0.1:8443/wss retry=0
ProxyPassReverse /wss wss://127.0.0.1:8443/wss
ProxyPass / https://127.0.0.1:8443/ retry=0
ProxyPassReverse / https://127.0.0.1:8443/
ProxyPreserveHost On

L’accès au contrôleur Unifi se fait maintenant via https://unify.domain.com

L’article Configurer son contrôleur Ubiquiti UniFi dans son proxy Apache est apparu en premier sur Mon linux.

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.

Après l’installation, j’ai eu le joli message disant de faire la mise à jour de la base de données et puis le souci est survenu… L’installation reste bloquée sur ce message :

Je vous évite les détails, mais ce problème peut être réglé rapidement.

Vérifiez le fichier config/config.php. Il doit y avoir le numéro de version qui est le 8.1.3 et la maintenance à false en théorie. Dans mon cas j’avais :

  'version' => '8.0.3.0',
  'maintenance' => true,

J’ai donc mis maintenance à « false ».

Ensuite j’ai fais la mise à jour via la commande PHP exécutée dans Bash :

su -c 'php occ upgrade' www-data

Et le site s’est correctement mis à jour, j’ai de nouveau accès à owncloud

ownCloud or one of the apps require upgrade - only a limited number of commands are available
Turned on maintenance mode
Checked database schema update
Checked database schema update for apps
Updated database
Updating <updater> ...
Updated <updater> to 0.6
Updating <files> ...
Updated <files> to 1.1.10
Updating <activity> ...
Updated <activity> to 2.0.2
Updating <files_sharing> ...
Updated <files_sharing> to 0.6.2
Updating <files_trashbin> ...
Updated <files_trashbin> to 0.6.3
Updating <files_versions> ...
Updated <files_versions> to 1.0.6
Update successful
Turned off maintenance mode

Vous pouvez activer le mode debug dans le fichier conf/conf.php de Owncloud via les options suivantes (source) :

"log_type" => "owncloud",
"logfile" => "owncloud.log",
"loglevel" => "3",
"logdateformat" => "F d, Y H:i:s",

Si cela vous a dépanné un merci ne coute rien

L’article Owncloud problème de mise à jour vers la version 8.1.3 est apparu en premier sur Mon linux.