Mot-clé - linux

Fil des billets

samedi 28 octobre 2017

Volumio over-the-air update, no SSH anymore?

What a surprise when I upgraded Volumio to the latest version (noteworthily to patch against the KRACK attack) and discovered that the SSH access was not activated anymore after a reboot!

It seems that the security-conscious Volumio team has decided to desactivate the SSH access by default, which makes sense. Although, it seems that the dev mode is activated by default (?) at http://ip.to.volumio/dev and permits the reactivation of SSH? Beware in an insecure context, Volumio was clearly built for a home-usage with low security constraints, one willing to go further will have no difficulties in increasing the level of security around Volumio (for example some filtering through a reverse proxy would certainly do a lot of good).

It is however quite easy to re-activate the SSH server: just create a "ssh" file in the /boot folder of Volumio. And reboot!

Tomato by Shibby n'est peut-être pas mort ? Mas vive LEDE malgré tout !

Si j'en crois Wikipedia, l'histoire du micrologiciel Tomato remonte au vénérable Linksys WRT54G et au projet HyperWRT qui avait été développé pour ce routeur. HyperWRT a été supporté par les bénévoles de 2004 à 2008 et en 2008 un fork aura lieu et mènera à Tomato qui sera développé jusqu'en version 1.28. Et là, nouvel abandon, et nouveaux forks, celui de Shibby (un développeur polonais) acquiert une certaine renommée. En 2017, deux vulnérabilités majeures sont publiées :

  • l'une concerne le logiciel dnsmasq (un petit serveur DNS/DHCP) : elle est publiée le 2 octobre 2017 sous le numéro CVE-2017-14491. Brièvement, une faille est détectée qui permet l'exécution de code distant sur une machine propulsant dnsmasq
  • la seconde est KRACK, la découverte par un chercheur belge d'une faille dans le protocole WPA2

Deux très bonnes raisons de mise à jour !

Tous les utilisateurs de firmware de routeurs & points d'accès se sont alors tournés vers les fournisseurs de ceux-ci, et les utilisateurs de Tomato by Shibby ont attendu avec impatience la sortie d'une nouvelle version. Malheureusement, deux semaines après ces annonces, aucun signe de vie et le site qui hébergeait les données de Tomato by Shibby n'est plus accessible au moment où j'écris ces lignes.

Edition au 30 octobre, 8h19 : Shibby m'a répondu - ce n'est qu'un problème temporaire de réseau chez le fournisseur de VPS qui héberge son site internet. Il répond également sur la mise à jour KRACK de la façon suivante : Tomato is using NAS daemon for WPA2 security. The problem is that sources for this daemon are closed by Broadcom. So we have to wait when Asus or Netgear etc will fix it and then try to move newer binaries to Tomato. But that means (probably) only newest routers will have fix for KRACK. I dont think that Asus etc will release fixed firmwares for Mipsel..

Il y a de nombreuses distributions basées sur Tomato by Shibby et d'autres forks de Tomato (cf. la page de Wikipedia sur Tomato, cependant si celle-ci est un jour, aucun des forks n'a été mis à jour post-annonce de KRACK ce qui n'augure rien de bon). Le code source étant disponible, de bonnes âmes expertes sauront peut-être faire renaître la tomate de ses cendres.

Pas de panique, il semble que LEDE soit une bonne alternative à Tomato dans la plupart des cas. Supporté par une communauté qui semble un peu plus large (Tomato by Shibby est (était), ne semble-t-il, soutenu que par un seul homme), LEDE est un fork d'OpenWRT. La dernière version 17.01.4 est très stable, très pratique et a été patchée pour KRACK !

Il est délicat de comparer LEDE et Tomato : là où Tomato se borne (bornait ?) à propulser routeurs et autres périphériques réseau, LEDE (Linux Embedded Development Environment) veut aller plus loin et propose une véritable micro-distribution avec gestion de paquets (avec l'utilitaire opkg). L'interface graphique LuCI de LEDE est très agréable, elle comporte moins de fonctionnalités que Tomato et il est probable qu'il faille recourir plus fréquemment à la ligne de commande de LEDE pour les paramétrages complexes possibles dans Tomato (par ex. la QoS, la gestion avancée des VLAN etc...). Mais dans les situations simples, LEDE peut-être un remplacement immédiat à Tomato. Pour les cas complexes, la migration est à évaluer, surtout si personne ne reprend le flambeau de Shibby !

Pour découvrir LEDE, c'est ici.

Comment LEDE a sauvé mes "vieux" points d'accès Wifi

J'avais acheté il y a peut-être 2-3 ans des petits points d'accès Wifi d'une marque chinoise. Lors de la divulgation de KRACK, je vérifiais le site du fabricant mais je constatais qu'aucune mise à jour n'était publiée pour ces appareils.

Je me tournais alors vers LEDE, le fork open source d'OpenWRT. En quelques minutes, j'identifiais le matériel dans la liste des matériels supportés, je téléchargeais la version 17.01.4 publiée le 18 octobre avec les corrections nécessaires pour KRACK.

L'installation de LEDE sur les points d'accès fut très facile :

  1. réinitialiser les points d'accès à l'aide du bouton RESET
  2. se connecter à l'interface du constructeur chinois, et se rendre dans la section "Firmware upgrade"
  3. téléverser le fichier de micrologiciel de LEDE
  4. ... patienter pendant le processus et le redémarrage
  5. se connecter sur http://192.168.1.1 pour trouver LuCI, l'interface graphique de LEDE

Deux enseignements :

  • si vous ne connaissez pas LEDE, c'est une très belle distribution pour les routeurs/points d'accès et autres petits périphériques du genre ; une bien pratique suite à OpenWRT
  • le llbre est une bonne solution à l'obsolescence et peut apporter une pérennité d'usage de matériels délaissés par les fabricants

dimanche 22 octobre 2017

Gitlab, fail of yarn when migrating to 10.0.x

For once, the Gitlab upgrade process from 9.5.8 to 10.0.x was not totally smooth on my end. I encountered the following error:

error "webpack#ajv" not installed
error "webpack#ajv-keywords" not installed
error Found 2 errors.
Error: You have unmet dependencies. (`yarn check` command failed)

And installing ajv manually did the trick:

sudo -u git -H yarn add ajv@^4.0.0

In case this helps someone out there!

lundi 16 octobre 2017

error: error switching euid to 33 and egid to -1: Invalid argument

I recently encountered the following error (after an upgrade from Debian Jessie to Debian Stretch):

/etc/cron.daily/logrotate:
error: error switching euid to 33 and egid to -1: Invalid argument
run-parts: /etc/cron.daily/logrotate exited with return code 1

It was not so easy to find the cause in the long list of possible offenders in /etc/logrotate.d/ ! In the end, it turned out that the faulty line was:

su www-data

in one of the logrotate configuration files. Indeed, no group was given in addition to the user account, hence the gid set to -1 which is blatanly an incorrect value.

The correct and expected syntax was:

su www-data www-data

dimanche 17 septembre 2017

PG::NotNullViolation error on id column in PostgreSQL

Faced with this error:

PG::NotNullViolation: ERROR:  null value in column "id" violates not-null constraint

it took me some time to realize that my id column was not a serial but a plain integer...

To fix this, just execute:

ALTER TABLE my_table DROP COLUMN id;
ALTER TABLE my_table ADD COLUMN id SERIAL PRIMARY KEY;

samedi 3 juin 2017

Nombre de déclenchements d'un appareil Canon sous Linux avec gphoto2

Si vous êtes l'heureux possesseur d'un appareil photo reflex Canon (et peut-être d'autres marques, je n'ai pas pu tester), vous vous demandez peut-être comment accéder au compteur de déclenchements par exemple pour mesurer le degré d'usure de votre matériel (http://www.olegkikin.com/shutterlife/).

gphoto2 sera votre complice pour cela. Il faut d'abord l'installer avec votre gestionnaire de paquet préféré (ici apt) :

apt install gphoto2

Après avoir branché l'appareil photo en USB sur le PC, on exécute la commande suivante :

gphoto2 --auto-detect

qui doit retourner le type d'appareil photo connecté et reconnu :

Model                          Port                                            
----------------------------------------------------------
Canon EOS 700D                 usb:001,007

Accédons maintenant à l'info souhaitée :

gphoto2 --get-config /main/status/shuttercounter

et voilà :

Label: Shutter Counter                                                         
Type: TEXT
Current: 14611

Get shutter counter for Canon cameras on Linux

It can be useful to know the shutter counter for your Canon reflex camera, for example to compare with the data available here: http://www.olegkikin.com/shutterlife/.

Wait no more, it is easy to access the shutter counter with gphoto2 on Linux.

Let's start with the installation of gphoto2 (replace apt with your favorite package manager):

apt install gphoto2

Then plug the camera to the computer with an USB cable and then:

gphoto2 --auto-detect

It should show something like this:

Model                          Port                                            
----------------------------------------------------------
Canon EOS 700D                 usb:001,007
/// 


Then

gphoto2 --get-config /main/status/shuttercounter


and this is it:

Label: Shutter Counter Type: TEXT Current: 14611 ///

dimanche 19 février 2017

Réduire l'empreinte mémoire de GitLab en contrôlant le nombre de processus Sidekiq

Par défaut, GitLab démarre 25 processus Sidekiq pour gérer les travaux de tâche de fond de GitLab. Si ce nombre est justifié sur une instance à fort traffic, il y a fort à parier qu'un bien plus petit nombre de processus suffit pour gérer une instance de GitLab de petit volume.

Le nombre de processus Sidekiq se règle aisément dans le fichier /path/to/gitlab/config/sidekiq_queues.yml par ajout de la ligne suivante :

:concurrency: 2

où l'on remplacera "2" par le nombre de processus souhaités. 2 semble suffisant pour ma petite installation GitLab personnelle et ses quelques utilisateurs et dizaines de projets.

Voilà de quoi optimiser l'empreinte mémoire et processeur de GitLab !

Adjust number of Sidekiq processes for GitLab

By default, GitLab starts 25 processes of Sidekiq. If this certainly makes sense on systems with high load, this could be overkill for simple instances of GitLab with only a handful of users and active projects. To reduce memory usage, it is possible to reduce the number of concurrent processes for Sidekiq by adding the following line to the /path/to/gitlab/config/sidekiq_queues.yml file:

:concurrency: 2

Install NodeJS v7.x on Debian Jessie

It is rather easy to deploy NodeJS v7.0 on Debian Jessie. First, it is necessary to add the deb repository for nodejs in /etc/apt/sources.list.d/nodesource.list:

deb https://deb.nodesource.com/node_7.x jessie main
deb-src https://deb.nodesource.com/node_7.x jessie main

Then, let's add a package preference in /etc/apt/preferences.d/node:

Package: nodejs
Pin: release o=Node Source
Pin-Priority: 1200

or

Package: *
Pin: release o=Node Source
Pin-Priority: 1200

I am rather reluctant to use the second option (with the wildcard) as it would imply that the nodesource.com deb repository could replace any package. Without the wildcard, there is a risk to see some dependences not deployed as expected... at the time of writing, it seems that limiting the priority to "nodejs" is sufficient ti have version 7.5.0 installed.

Enjoy!

mercredi 15 février 2017

Installer john (theripper) avec support de multiples coeurs sous Debian Stretch

Par défaut sous Debian Stretch, john (theripper), ami de l'adminsys testeur de la solidité des mots de passe, fonctionne en utilisant un seul coeur/processeur.

Il est nécessaire de recompiler john pour faire usage de multiples processeurs. Pas de panique, cela se fait très aisément.

Il faut d'abord install gcc et make pour permettre la compilation :

apt install gcc make

Ensuite, on télécharge la dernière version de john sur le site d'Openwall :

wget http://www.openwall.com/john/j/john-1.8.0.tar.xz

On décompresse l'archive :

tar xvf john-1.8.0.tar.xz

(si tar ne reconnaît pas tar.xz, c'est qu'il faut installer le paquet xz-utils)

On rentre dans le dossier source de john

cd john-1.8.0/src/

et on modifie le fichier Makefile pour décommenter les lignes OMPFLAGS. Ainsi :

#OMPFLAGS = -fopenmp
#OMPFLAGS = -fopenmp -msse2

devient

OMPFLAGS = -fopenmp
OMPFLAGS = -fopenmp -msse2

On lance alors la compilation par la commande

make linux-x86-64-avx

(attention, la cible peut être différente selon votre processeur et votre système... make vous proposera tous les choix possible si vous l'appelez sans paramètre)

Une fois la compilation terminée, vous pouvez lancer john :

cd ../run/
./john --test

et modifier lors de l'exécution le nombre de coeurs à utiliser si vous le souhaitez :

OMP_NUM_THREADS=1 ./john --test

dimanche 30 octobre 2016

Rotated backups for RethinkDB

Very simple bash script to rotate the backups (dumps) of RethinkDB:

#!/bin/bash
# DAILY BACKUPS
# Delete daily backups DAYS_TO_KEEP days old or more
# Config
BACKUP_DIR=/var/backups/rethinkdb/
DAYS_TO_KEEP=7
# Actions
find $BACKUP_DIR -maxdepth 1 -mtime +$DAYS_TO_KEEP -name "rethinkdb_dump_*" -exec rm -rf '{}' ';'
cd $BACKUP_DIR
rethinkdb dump

This assumes rethinkdb python utilities have been installed with:

pip install rethinkdb

dimanche 23 octobre 2016

dd to split file

dd is one these magical GNU tools for which you can always find new usage! I recently discovered that dd could be used to split files:

dd if=~/input_file bs=1M skip=50 count=1000 iflag=skip_bytes,count_bytes of=~/output_file status=none

in details and with no surprise:

  • if for the input file
  • of for the output file
  • bs for the block size
  • skip to indicate the starting point in the input file
  • count to indicate the length of the file to copy
  • status=none is optional, it is used to make dd quiet
  • iflag is important as it gives important parameters to dd in this case:
    • skip_bytes forces dd to understand the skip parameter in bytes (and not blocks)
    • count_bytes forces dd to understand the count parameter in bytes (and not blocks)

Always useful!

samedi 22 octobre 2016

Init script for Rails app served by Unicorn with RVM

Here is an init script for a Rails app served by Unicorn with RVM.

#!/bin/bash
### BEGIN INIT INFO
# Provides:          APP_NAME, with Unicorn serving
# Required-Start:    $all
# Required-Stop:     $network $local_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start APP_NAME unicorn at boot
# Description:       Enable APP_NAME at boot time.
### END INIT INFO

set -u
set -e

# Change these to match your app:
APP_NAME="APP_NAME"
APP_ROOT="/path/to/app"
PID="/path/to/app/tmp/pids/unicorn.pid"
ENV="production"
RVM="2.3.0@gemset"
USER="user"

UNICORN_OPTS="-D -E $ENV -c $APP_ROOT/config/unicorn.rb"

SET_PATH="cd $APP_ROOT; rvm use $RVM > /dev/null;"
CMD="$SET_PATH unicorn $UNICORN_OPTS"

old_pid="$PID.oldbin"

cd $APP_ROOT || exit 1

sig () {
	test -s "$PID" && kill -$1 `cat $PID`
}

oldsig () {
	test -s $old_pid && kill -$1 `cat $old_pid`
}

start () {
        echo "Starting $APP_NAME unicorn..."
        sig 0 && echo -e >&2 "\e[31mAlready running" && exit 0
        su - $USER -c "$CMD" > /dev/null
        echo -e "$APP_NAME has \e[32mstarted\e[0m, PID is `cat $PID`"
}

stop () {
        echo "Stopping $APP_NAME unicorn (signal QUIT)..."
        sig QUIT && echo -e "$APP_NAME has \e[32mstopped" && exit 0
        echo >&2 "Not running"
}

case ${1-help} in
start)
	start
	;;
stop)
	stop
	;;
force-stop)
	echo "Force stopping $APP_NAME unicorn (signal TERM)..."
	sig TERM && echo "$APP_NAME has stopped" &&exit 0
	echo -e >&2 "\e[31mNot running"
	;;
reload)
	echo "Reloading $APP_NAME unicorn (signal USR2)..."
	sig USR2 && echo -e "$APP_NAME has \e[32mreloaded" && exit 0
	echo -e >&2 "\e[31mCouldn't reload\e[0m, starting instead"
	start
	;;
status)
	sig 0 && echo -e "$APP_NAME \e[32mrunning\e[0m with PID `cat $PID`" && exit 0
	echo -e "$APP_NAME is \e[31mnot running!"
	;;
*)
 	echo >&2 "Usage: $0 <start|stop|reload|status|force-stop>"
 	exit 0
 	;;
esac

mercredi 19 octobre 2016

Grafana & InfluxDB en HTTPS avec Let's Encrypt

Grafana et InfluxDB forment une jolie paire quand il s'agit de stocker et d'analyser des flux de données. J'ai donc voulu en sécuriser l'accès pour mes utilisateurs en permettant une connexion en HTTPS grâce aux certificats de Let's Encrypt.

Méthodologie

Pour Grafana comme InfluxDB, je n'ai pas réussi à faire accepter un dossier .well-known aux serveurs web empaquetés avec chacun des outils. J'ai donc fait intervenir le reverse proxy placé devant Grafana et InfluxDB.

Sommairement:

  1. toute requête de la forme http://url.de.grafana/.well-known/... ou http://url.de.influxdb/.well-known/... est renvoyée vers un hôte virtuel d'un serveur Apache
  2. toute autre requête est envoyée comme il se doit au serveur Grafana ou au serveur InfluxDB

Ainsi, quand Let's Encrypt effectue le test de possession du domaine, il trouve aux adresses http://url.de.grafana/.well-known/... ou http://url.de.influxdb/.well-known/... le fichier qu'il recherche et accepte alors la génération des certificats.

En pratique

La pratique dépend du reverse proxy. Dans mon cas, le reverse proxy est Pound. Dès lors on ajoute à la configuration de Pound le paragraphe suivant (avant les autres pour capturer la requête avant envoi vers un autre service) :

        Service
                HeadRequire "Host: .*(url.de.influxdb).*"
                URL "/.well-known/acme-challenge/.*"
                BackEnd
                        Address 1.2.3.4
                        Port    8000
                End
        End

avec 1.2.3.4 un serveur (par exemple Apache) qui répond sur le port 8000 en retournant le contenu de /var/www/pour-letsencrypt.

Il suffit alors d'appeler

certbot certonly --renew-by-default -a webroot --webroot-path /var/www/pour-letsencrypt/ -d url.de.influxdb

pour générer le certificat valide que l'on pourra ensuite utiliser pour protéger l'accès à InfluxDB ou Grafana !

lundi 17 octobre 2016

Gitlab, empty repository mystery, when a workhorse comes to help a unicorn!

Gitlab is a wonderful piece of open source software, incredibly pleasant to use to manage development projects. My own instance, installed from source, is updated version after version. Today, I was faced with a weird issue:

  1. all downloads of archive (whatever the format .tar.gz, .zip, .tar.bz2) of the files of the projets were failing, more precisely only empty (0 byte) archives were returned
  2. when cloning with git clone http://urlofgitlab/group/repo.git, I consistently obtained warning: You appear to have cloned an empty repository.
  3. interestingly, cloning the same repository with git clone git@urlofgitlab:group/repo.git worked seamlessly.

After some research, it appeared my Gitlab instance was not using Gitlab-workhorse at all. The magic unicorn was the only one serving the content of the instance without any help from the local workhorse :-)

Some context

It appears that Gitlab-workhorse was developed and added to Gitlab 8 to circumvent some limitations of Unicorn when serving large files (some history here)... and since then big files would not be served anymore by Unicorn.

As a consequence, if the requests are not treated by Gitlab-workhorse, then the git clone over HTTP and download of large archive files would not complete.

How did it happen?

My instance is regularly updated from version to version and pre-dates Gitlab 8. Before Gitlab 8, it was normal to have my reverse proxy/load balancer (Pound) point directly to the Unicorn server. When upgrading to Gitlab 8, I should have changed the setting of the reverse proxy/load balancer to point to Gitlab-workhorse instead of Unicorn. And then it was necessary to properly set Gitlab-workhorse to rely on Unicorn.

How fix it?

Well, 3 steps.

Step 1: fix the link between Gitlab-workhorse and Unicorn Gitlab-workhorse expects to connect to Unicorn through a Unix socket. It is therefore necessary to make sure that Unicorn is set up accordingly in /home/git/gitlab/config/unicorn.rb, with this line active:

listen "/home/git/gitlab/tmp/sockets/gitlab.socket", :backlog => 1024

Step 2: make sure that Gitlab-workhorse is well set to connect to this socket. This can be done by tweaking the parameters in /etc/default/gitlab, with inspiration from /home/git/gitlab/lib/support/init.d/gitlab.default.example.

Step 3: make sure that the reverse proxy correctly points to workhorse. As a default, Gitlab-workhorse uses a socket. In my case, I had to make it use a TCP connection/port so that the reverse proxy could use it. Again, based on the settings found in /home/git/gitlab/lib/support/init.d/gitlab.default.example, I tweaked the /etc/default/gitlab file to read:

gitlab_workhorse_options="-listenUmask 0 -listenNetwork tcp -listenAddr a.b.c.d:8181 -authBackend http://127.0.0.1:8080 -authSocket $socket_path/gitlab.socket -documentRoot $app_root/public"

Last, with the reverse proxy pointing to a.b.c.d:8181 everything worked very fine.

I am relieved to know that my Unicorn is now so efficiently supported by the Workhorse!

dimanche 2 octobre 2016

Tapoter pour cliquer sur Debian Stretch

Tapoter pour cliquer, "tap-to-click" en anglais, une fonctionnalité bien utile non activée par défaut sur Debian Stretch au moment d'écrire ces lignes semble-t-il.

Le comportement s'active facilement :

Sur Debian Stretch

Pour l'activer, il suffit de modifier le fichier '/usr/share/X11/xorg.conf.d/60-libinput.conf' afin d'ajouter l'option suivante à la section "InputClass" :

      Option "Tapping" "on"

Asus UX360C et Linux Debian Stretch

Bonjour,

Voilà un petit article bloc-note pour commenter le support du PC portable Asus Zenbook UX360C sous Linux Debian Stretch: la situation est assez simple, tout fonctionne parfaitement avec cet UX360.

L'installation se fait sans surprise avec l'installateur Debian netboot placé sur une clé USB.

  • L'écran tactile fonctionne
  • La carte son est reconnue sans problème et les boutons physique de volume sur le côté sont reconnus par défaut
  • Carte Wifi parfaitement fonctionnelle (en installation le firmware iwlwifi)
  • ... tout fonctionne bien

Voilà ce que retourne lspci :

00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated Graphics (rev 07)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 08)
00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Device 9d13 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d46 (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)

et lsusb :

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0a2b Intel Corp. 
Bus 001 Device 003: ID 0bda:57f4 Realtek Semiconductor Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Une super machine avec un écran brillant toutefois (tactile oblige).

jeudi 22 septembre 2016

Phpmyadmin et open_basedir sur Debian Sid

Stupéfaction hier quand, sur Debian Sid, phpmyadmin cessa de fonctionner... Sans doute une mise à jour récente avait-elle cassé le subtile équilibre propice à phpmyadmin.

L'examen de logs (dans /var/logs/apache2/error.log) montre que :

[Tue Sep 20 07:17:39.550343 2016] [:error] [pid 4509] [client ::1:57788]
PHP Fatal error:  require_once(): Failed opening required
'/usr/share/php/php-gettext/gettext.inc' (include_path='.') in
/usr/share/phpmyadmin/libraries/common.inc.php on line 77
[Tue Sep 20 07:17:40.162663 2016] [:error] [pid 4505] [client ::1:57790]
PHP Warning:  require_once(): open_basedir restriction in effect.
File(/usr/share/php/php-php-gettext/gettext.inc) is not within the
allowed path(s):
(/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/)

La seconde ligne (Warning PHP) est assez explicite sur l'erreur. Il semble donc nécessaire d'ajouter le chemin vers /usr/share/php/php-gettext/ dans l'instruction open_basedir.

Pour ce faire, ouvrir le fichier de configuration de l'hôte phpmyadmin en écriture :

nano /etc/apache2/conf-available/phpmyadmin.conf

et repérer la ligne "open_basedir" qui doit ressembler à

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/

Il faut alors la transformer par un ajout judicieux en :

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/:/usr/share/php/php-gettext/

Et, après un redémarrage d'Apache, tout fonctionne à nouveau.

- page 1 de 7