Dans mon flux #semaine 7

Dans mon flux #semaine 7

Au programme de cette semaine :

En général

  • Instagram expliqué au enfant : Une avocat réécrit les conditions d’utilisations utilisateur d’instagram afin qu’elles soient lisibles par des enfant de 8 ans.
  • Partager la culture n’est pas un crime : Je rajouterai même que copier n’est pas voler.
  • Directive droit d’auteur : récapitulatif sur le contenu de cette directive européenne très décriée.
  • La ligue des égouts : Pour citer son auteur « quand les égouts de twitter débordent ». Il nous partage sont vécu face au harcèlement en faisant une analogie avec la ligue du lol.
  • Article 13 : Quand la France oublie les valeurs même de sa république et jouent le jeu des lobbys.

Technique

Jeux Vidéo

  • World of Warcraft 14 ans ! (en) : Parce que je suis tombé dans l’univers warcraft quand j’étais petit, et parce que cela fait 14 ans qu’il partage ma vie je ne pouvais pas passé à côté.

C’est tout pour cette semaine 🙂

Nextcloud 13 vers 14

Nextcloud 13 vers 14

Lors de la mise à jour vers la version 14 de mon nextcloud j’ai fait face à deux erreurs bloquantes. Voici comment j’y est remédié.

504 Gateway Time-out

Dès les préparatifs de la mise à jour je suis tombé sur ce bel écran.

Il s’agit du serveur nginx qui coupe délibérément la connexion. En effet comme il ne reçoit plus de données depuis la page de mise à jour, celle-ci étant en attente du téléchargement de l’archive de nextcloud, il coupe simple les ponts au bout de quelques secondes. Cela est bloquant car le processus de mise à jour ne détecte pas que l’archive est téléchargée et par conséquent reste bloqué sur l’étape du téléchargement. Pour y remédier il suffit d’ajouter la directive proxy_read_timeout dans le fichier
proxy_params afin d’augmenter le temps d’attente de nginx. La mise à jour terminé j’ai désactivé cette directive par mesure de sécurité.

sudo nano /etc/nginx/proxy_params
[...]
proxy_read_timeout 6000s;
[...]
sudo systemctl restart nginx

Après le redémarrage de nginx j’ai pu passer aux étapes suivantes.

Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes

Cette erreur est apparue lors de la deuxième phase de la mise à jour.

Pour rétablir la mise à jour j’ai joué avec ma base mariadb. Apparemment c’est une erreur connue chez mariadb : https://www.youtube.com/watch?v=vPNU3fONY7c

sudo mysql -u root -p
MariaDB [(none)]> use nextcloud;
MariaDB [nextcloud]> set global innodb_large_prefix=on;
MariaDB [nextcloud]> set global innodb_file_format=Barracuda;

Validation des changement auprès de nextcloud.

 sudo -u www-data php occ maintenance:repair

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
 - Repair MySQL collation
     - Change row format for oc_addressbooks ...
     - Change collation for oc_addressbooks ...
     - Change row format for oc_authtoken ...
     - Change collation for oc_authtoken ...
     - Change row format for oc_calendarobjects ...
     - Change collation for oc_calendarobjects ...
     - Change row format for oc_calendars ...
     - Change collation for oc_calendars ...
     - Change row format for oc_calendarsubscriptions ...
     - Change collation for oc_calendarsubscriptions ...
     - Change row format for oc_dav_shares ...
     - Change collation for oc_dav_shares ...
     - Change row format for oc_migrations ...
     - Change collation for oc_migrations ...
     - Change row format for oc_mimetypes ...
     - Change collation for oc_mimetypes ...
     - Change row format for oc_systemtag_group ...
     - Change collation for oc_systemtag_group ...
     - Change row format for oc_trusted_servers ...
     - Change collation for oc_trusted_servers ...
 - Repair mime types
     - Fixed comicbook mime types
 - Clean tags and favorites
     - 0 tags of deleted users have been removed.
     - 0 tags for delete files have been removed.
     - 0 tag entries for deleted tags have been removed.
     - 0 tags with no entries have been removed.
 - Repair invalid shares
 - Remove shares of a users root folder
 - Move .step file of updater to backup location
     - .step file exists
     - .step file moved to .step-previous-update
 - Fix potential broken mount points
     - No mounts updated
 - Repair invalid paths in file cache
 - Add log rotate job
 - Clear frontend caches
     - Image cache cleared
     - SCSS cache cleared
     - JS cache cleared
 - Add preview background cleanup job
 - Queue a one-time job to cleanup old backups of the updater
 - Repair pending cron jobs
     - Repaired 1 pending cron job(s).
 - Fix component of birthday calendars
     - 2 birthday calendars updated.
 - Fix broken values of calendar objects
    0 [>---------------------------]
 - Registering building of calendar search index as background job
     - Repair step already executed
 - Remove activity entries of private events
     - Removed 0 activity entries
 - Fix the share type of guest shares when migrating from ownCloud
 - Copy the share password into the dedicated column
 - Migrate binary status into separate boolean fields
 - Update OAuth token expiration times

Retour sur la mise à jour, cela fonctionne !

Ma migration vers Nextcloud 15 n’attend plus que moi.

En route vers PHP 7.2 au volant de ma Stretch

En route vers PHP 7.2 au volant de ma Stretch

Ce matin en parcourant mes flux RSS depuis mon instance Nextcloud, j’ai reçu une jolie notification m’invitant à passer en version 14. Après une lecture rapide du changelog afin d’identifier les différents changements, je décide de réaliser la mise à jour. Quelle ne fut pas ma surprise lorsque je vis ces messages :


-Vous utilisez actuellement PHP 5.6.36-0+deb8u1. Mettez à jour votre version de PHP afin de tirer avantage des améliorations liées à la performance et la sécurité fournies par le PHP Group dès que votre distribution le supportera.
-Vous utiliser actuellement PHP 5.6. La version majeure actuelle de Nextcloud est la dernière qui est supportée sous PHP 5.6. Il est recommandé de mettre à niveau PHP vers la version 7.0+ pour pouvoir passer à Nextcloud 14.

Interloqué je vérifie la version de php installée :


 sudo apt-cache policy php
php:
  Installed: 1:7.0+49
  Candidate: 1:7.0+49
  Version table:
 *** 1:7.0+49 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

Même si je ne dispose pas de la dernière version en date, j’ai bien php7 installé sur mon serveur. La question est pourquoi nextcloud détecte php 5.6 ? J’ai fini par trouver la réponse en consultant le Vhost de nginx.

upstream php-handler {
            server 127.0.0.1:9000;
            #server unix:/var/run/php/php5-fpm.sock;
}

Jusque là rien d’anormal, le moteur php écoute sur le port 9000 du pc local. Je décide donc de faire un tour dans la configuration de php-fpm, je m’aperçois qu’il est configuré pour écouter sur .sock et non un port réseau. Et que dans le dossier /etc j’ai un dossier php5 qui traîne.

sudo nano /etc/php/7.0/fpm/pool.d/www.conf
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
;   'ip.add.re.ss:port'    - to listen on a TCP socket to a specific IPv4 address on
;                            a specific port;
;   '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 address on
;                            a specific port;
;   'port'                 - to listen on a TCP socket to all addresses
;                            (IPv6 and IPv4-mapped) on a specific port;
;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
listen = /run/php/php7.0-fpm.sock

De plus j’ai toujours php 5.6 qui tourne sur le serveur.

 sudo systemctl status php*
● php5-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php5-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-02-12 10:20:04 CET; 10s ago
  Process: 15111 ExecStartPre=/usr/lib/php5/php5-fpm-checkconf (code=exited, status=0/SUCCESS)
 Main PID: 15118 (php5-fpm)
   Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/sec"
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/php5-fpm.service
           ├─15118 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
           ├─15121 php-fpm: pool www
           └─15122 php-fpm: pool www

Feb 12 10:20:03 durotan systemd[1]: Starting The PHP FastCGI Process Manager...
Feb 12 10:20:04 durotan php5-fpm[15118]: [12-Feb-2019 10:20:04] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynami
Feb 12 10:20:04 durotan systemd[1]: Started The PHP FastCGI Process Manager.

● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-02-07 10:40:19 CET; 4 days ago
     Docs: man:php-fpm7.0(8)
 Main PID: 10010 (php-fpm7.0)
   Status: "Processes active: 0, idle: 4, Requests: 18523, slow: 0, Traffic: 0.1req/sec"
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/php7.0-fpm.service
           ├─10010 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
           ├─10012 php-fpm: pool www
           ├─13024 php-fpm: pool www
           ├─14453 php-fpm: pool www
           └─15125 php-fpm: pool openmediavault-webgui

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

● phpsessionclean.timer - Clean PHP session files every 30 mins
   Loaded: loaded (/lib/systemd/system/phpsessionclean.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Wed 2018-11-28 06:40:16 CET; 2 months 15 days ago

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

En y réfléchissant je me souviens avoir conservé php 5.6 nécessaire au fonctionnent de mon instance openmediavault (OMV3). De plus à cette époque j’ai déménagé deux fois en l’espace de cinq mois (et pas des petits déménagements), je n’ai pas vraiment eu le temps de finaliser dans les détails cette migration. Mais aujourd’hui les choses sont différentes, mon serveur est bien installé chez moi et la version d’OMV que j’utilise ne nécessite plus PHP5. Néanmoins je n’échappe pas à l’adage qui veut que les cordonniers sont toujours les plus mal chaussés. Il est temps de passer à l’action !

D’abords je modifie mon Vhost nginx pour qu’il utilise php7.

 sudo nano /etc/nginx/sites-available/nextcloud

upstream php-handler {
    #server 127.0.0.1:9000;
    server unix:/var/run/php/php7.0-fpm.sock;
}
sudo systemctl restart nginx

Ensuite je désactive le vieux php.

sudo systemctl disable php5-fpm
Synchronizing state of php5-fpm.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable php5-fpm
insserv: warning: current start runlevel(s) (empty) of script `php5-fpm' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `php5-fpm' overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script `php5-fpm' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `php5-fpm' overrides LSB defaults (0 1 6).

sudo systemctl stop php5-fpm

De retour sur Nextcloud les deux messages précédents ont disparus mais la version de Php que j’utilise n’est plus supporté depuis le premier Janvier 2019. Il me faut donc migré vers une version encore maintenue. Problème j’utilise les paquets fournis par Debian qui sont gelés en version 7 et les versions encore maintenues de php sont introuvables sur le dépôt backport. A force de chercher je suis tombé sur ce site https://deb.sury.org/ qui s’avère être le dépôt et site personnel du développeur en charge du paquet php pour Debian. Ce qui est selon moi un gage de sérieux. Je décide d’utiliser son dépôt en attendant une mise à jour officielle de Debian ( lors de la migration vers Buster) en suivant les instructions.

sudo apt -y install apt-transport-https lsb-release ca-certificates
sudo curl -ssL -o /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
sudo sh -c 'echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt update
sudo apt upgrade

Une fois la mise à niveau effectuée ne pas oublier de modifier le Vhost de nginx pour qu’il pointe vers php 7.2 et non php7.0, puis redémarrer nginx.

sudo nano /etc/nginx/sites-available/nextcloud
upstream php-handler {
    #server 127.0.0.1:9000;
    server unix:/var/run/php/php7.2-fpm.sock;
}
susod systemctl restart nginx

Avec cette version de php je suis tranquille jusqu’en 2020. Je peux maintenant mettre mon nextcloud à jour vers la version 14 et même la version 15 sortie au mois de décembre 2018.

En conclusion

Cet incident met à mal le système Debian en ce qui me concerne. J’ai toujours utilisé Debian pour mes serveurs. Debian a toujours privilégié la stabilité de son système sans pour autant sacrifier la sécurité, à tel point qu’une équipe de développeur lui est entièrement consacrée. C’est la première fois que suis obligé d’utiliser, sur mes serveurs, un dépôt tier afin de maintenir un paquet à jour. Lorsqu’on regarde les différentes versions de php entre la stable, testing et sid il y a un fossé.

https://packages.debian.org/stretch/php

  • Stable est bloquée en version 7
  • Testing et sid proposent un version en 7.3

Entre deux rien, on passe d’une version quasi obsolète à une version ultra récente; en gros on passe du rien au tout sans transitions (comme dirai l’autre). De plus pour une version stable il n’y a pas eu pléthore de mise à jour de sécurité : https://security-tracker.debian.org/tracker/source-package/php7.0, la dernière datant de décembre 2018 juste avant la fin du support par l’équipe de PHP. Depuis cette date plus rien, silence radio. Laisser une version obsolète sans autre procédure pour corriger cela, pour moi il s’agit d’une négligence pure et simple de la part de l’équipe Debian ou une très grande prétention de croire que ses paquets sont si parfaits qu’il n’y a plus besoin de les mettre à jour. En 20 ans de Linux c’est la première que je suis déçu. Alors non je ne compte pas changer mon écosystème du jour au lendemain mais si cela venait à se reproduire je serai plus enclin à réfléchir à une nouvelle distribution pour mes serveurs.

Dans mon flux #semaine6

Dans mon flux #semaine6

Je me lance dans une série d’écrits que je voulais faire depuis très longtemps. Partager hebdomadairement les lectures RSS notables traitant de mes différents centres d’intérêts. Chaque vendredi, je publie ces lectures de la semaine écoulée, en général il s’agit de 5 à 10 liens accompagnés d’une courte description.

  1. PHP 5.6 est mort : Un petit point sur les versions maintenus de php7
  2. Youtube va lutter contre les conspis : Youtube en marre de servir de relais à toutes les conspirations de la terre.
  3. Hacker le grand débat : Une réflexion intéressante sur la façon d’être dépossédé d’une initiative citoyenne.
  4. Migrer vers un nouveau disque SSD : Parce que cela peut toujours servir !
  5. Lutter contre le pistage : Un petit avant/après le RGPD avec quelle notion d’hygiène numérique.

C’est tout pour cette semaine, à la prochaine !