Category

Web/Tech

Category

Tous les tutoriels et articles de barbus orientés technique.

Suite à une mauvaise manipulation, j’ai malencontreusement écrasé ma version de pip installée par APT en faisant un pip install pip. Après cela, toute commande lancée par pip donne cette erreur:

Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in <module>
    from pip import main
ImportError: cannot import name main

Pas glop! Si cela vous arrive un jour, voici comment retrouver la version pip initiale, installée par votre gestionnaire de paquet APT.

On marque python2.7 comme binaire Python par défault en le sélectionnant dans cette liste (si besoin):

update-alternatives --config python

On désinstalle pip, dans APT et dans PIP :

python -m pip uninstall pip
apt purge --autoremove python-pip

On réinstalle pip avec APT:

apt install python-pip

Et on vérifie la version de pip :

pip --version

qui nous donne:

pip 9.0.1 from /usr/lib/python2.7/dist-packages (python 2.7)

Et voilà, nous venons de retrouver une version de pip utilisable sur notre système.

Note : ne pas tenter de mettre à jour pip manuellement, il vaut mieux laisser le gestionnaire de paquet gérer les mises à jour de ce paquet lorsque cela est nécessaire, au fil des mises à jour.

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:

upstream sent too big header while reading response header from upstream

Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.

Il ne reste plus ensuite qu’à relancer le serveur NginX:

service nginx restart

Hop, problème réglé.

J’ai récemment écrit un petit script bash qui me permet de sauvegarder rapidement toutes les bases de données d’un serveur. Le script est lancé par une tâche cron automatiquement, tous les jours.

Si l’on passe l’utilisateur et le mot de passe SQL dans la requête, avec mysql ou mysqldump, vous obtiendrez très certainement le message d’avertissement suivant:

Warning: Using a password on the command line interface can be insecure.

Et pour cause : cela veut dire que n’importe qui ayant accès au serveur pourra voir, dans les logs ou avec un simple ps, vos informations de connexion à vos bases de données. Ce n’est pas ce qui se fait de mieux en matière de sécurité !

Une solution est de passer en argument un fichier qui contiendra vos données de connexion à la base de données.

Donc, au lieu d’écrire :

mysqldump -u $USER -p$PASSWORD --databases $db > $BACKUP_PATH/$date-$db.sql

Il vaut mieux écrire:

mysqldump --defaults-extra-file=/etc/mysql/mysql-backup-script.cnf --databases $db > $BACKUP_PATH/$date-$db.sql

Note: L’argument --defaults-extra-file doit venir en premier, sinon il ne sera pas interprété.

Le fichier /etc/mysql/mysql-backup-script.cnf contient les identifiants de votre utilisateur SQL qui aura les droits sur chacune des bases de données à sauvegarder. Voici à quoi il ressemble:

[client]
user = 'backup'
password = 'GIGANTIC_SECURE_PASSWORD'

Par sécurité, on restreint les droits d’accès au fichier pour qu’il ne soit pas lisible par tout le monde:

chmod 400 /etc/mysql/mysql-backup-script.cnf

Il ne vous reste qu’à créer votre cron avec votre nouvelle commande, sans montrer les identifiants SQL en clair.

Si vous possédez votre propre serveur email, géré avec Postfix, vous pouvez parfois obtenir l’avertissement suivant, lorsque vous utilisez un certificat SSL/TLS :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.166.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

La solution est très simple, il suffit d’éditer le fichier main.cf de Postfix :

nano /etc/postfix/main.cf

Et on y ajoute:

smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs

Sauvegardez le fichier puis relancez Postfix :

service postfix restart

Envoyez un mail depuis le serveur, vous devriez maintenant obtenir le graal :

postfix/smtp[7243]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1a]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Et voilà, authentifié en TLS pour l’envoi de mail avec Postfix.

Les directives « HttpOnly » et « Secure »

A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives « HttpOnly » et « Secure ».

Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.

Edition de php.ini

On édite donc notre fichier php.ini:

nano /etc/php/7.2/fpm/php.ini

Et on modifie ces valeurs :

session.cookie_httponly 1
session.cookie_secure 1
session.use_only_cookies 1

Enregistrez le fichier et relancez PHP:

service php7.2-fpm restart

Testez votre site de nouveau : les cookies de session contiennent maintenant les deux nouvelles directives :

set-cookie: PHPSESSID=7d5h81tfiuna3p2p00o1v7b13q; path=/; secure; HttpOnly

Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site. Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.

Résoudre l'erreur "/var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" photo

Lors d’une mise à jour APT, il arrive qu’un installeur vous demande s’il faut écraser ou non un des fichiers de configuration existant. C’est le cas notamment de certaines versions de PHP qui requièrent une mise à jour du fichier php.ini

Si vous êtes derrière votre terminal, pas de problème. Si par contre, vous ne prêtez pas attention à votre terminal, pensant que tout s’est mis à jour, ou si votre connexion SSH est rompue lors de l’installation, vous risquez d’avoir dpkg en vrac, avec une installation de paquet qui restera ‘en cours ».

Concrètement, vous obtiendrez un de ces messages:

debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
dpkg: error processing package XXXXX:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 XXXXX:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Mais pas de panique, il est très simple de résoudre le problème en quelques commandes.

Commencez par vérifiez quel est le processus responsable du fichier en question:

fuser -v /var/cache/debconf/config.dat

Résultat :

USER        PID ACCESS COMMAND
/var/cache/debconf/config.dat:
root       8756 F.... frontend

Il ne nous reste plus qu’à tuer proprement le processus:

kill 8756

Il ne vous reste plus qu’à relancer vos commandes apt habituelles, tout est redevenu opérationnel.


Après mise à jour du serveur SQL, il est possible d’obtenir cette erreur au redémarrage physique (boot) du serveur :

error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' — Missing /var/run/mysqld/mysqld.sock

Il se trouve que systemd lance bien le service mysql qui est donc démarré mais ne semble pas pouvoir être en mesure de créer son fichier sock. Il va donc falloir l’aider:

On crée un nouveau fichier pour systemd:

nano /etc/tmpfiles.d/mysql.conf

et on y ajoute ce code qui va permettre de chmoder et chowner le répertoire /var/run/mysqld pour l’utilisateur mysql:

# systemd tmpfile settings for mysql
# See tmpfiles.d(5) for details

d /var/run/mysqld 0755 mysql mysql -

Cela règle le problème définivement.

Depuis que j’ai déplacé les bases de données SQL sur une autre partition, logrotate semble avoir quelques soucis avec l’archivage des logs de MariaDB. Voici le message d’erreur complet :

/etc/cron.daily/logrotate: logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operator

C’est en fait un problème de regex connu et la solution est très simple.

1. On édite le fichier /etc/logrotate.d/mysql-server:

nano /etc/logrotate.d/mysql-server

2. on recherche la ligne avec la regex de grep:

if [ -f `my_print_defaults --mysqld | grep -oP "pid-file=\K[^$]+"` ]; then

3. on ajoute m1 aux arguments de grep, ce qui nous donne:

if [ -f `my_print_defaults --mysqld | grep -oPm1 "pid-file=\K[^$]+"` ]; then

Sauvegardez le fichier. Vous ne recevrez plus de message d’erreur lors du lancement de la tâche cron et les fichiers logs de MySQL/MariaDB seront bien archivés.

Debian Stretch possède MariaDB 10.1 mais au vu des améliorations récentes de MariaDB, il est intéressant de passer à la version 10.3 pour des raisons de performance.

Ajout du nouveau dépôt

On installe les dépendances et on ajoute le dépôt de MariaDB 10.3 à notre fichier de configuration apt, ainsi que la clé du dépôt:

apt install software-properties-common dirmngr
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.3/debian stretch main'

Mise à jour de MariaDB

Une fois que la clé du dépôt est ajoutée au trousseau, on installe la nouvelle mouture de MariaDB:

apt update
apt install mariadb-server

Notez que vous pouvez choisir la version de MariaDB à installer très facilement depuis le site officiel.

Et voilà, serveur de base de données mis à jour.

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes. Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

MariaDB : changer le répertoire des bases de données sous Debian photo

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home. Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = false

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

MacOS dispose de Time Machine, l’utilitaire qui permet de sauvegarder et restaurer le système d’exploitation de votre Mac, ainsi que tous vos fichiers et documents.

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 11

Time Machine nécessite normalement un disque dur dédié à toutes vos sauvegardes. Un énième disque dur de sauvegarde… sauf si vous avez un NAS Synology – il est en effet possible d’utiliser une partie de votre Synology pour accueillir les sauvegardes de Time Machine alors autant l’utiliser !

Ajout du support de Time Machine dans le DSM du Synology

Nous avons besoin de configurer DSM pour qu’il puisse converser correctement avec Time Machine : il nous faut créer un utilisateur dédié avec des droits propres, un répertoire de destination et un quota pour ne pas que l’espace du NAS ne soit complètement phagocyté.

Ajout d’un répertoire partagé

Dans l’interface d’administration DSM, rendez-vous dans Panneau de Configuration > Dossier partagé et cliquez sur le bouton Créer un dossier partagé :

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo

Vous pouvez maintenant éditer les paramètres du dossier partagé :

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 1

Sur l’écran suivant, vous pouvez choisir de chiffrer les sauvegardes de Time Machine. Pour un usage purement personnel, j’opte pour la rapidité, sans chiffrement.

Cliquez sur Appliquer pour sauvegarder les changements.

Création d’un utilisateur Time Machine

Nous créons un utilisateur qui sera dédié à la sauvegarde Time Machine, avec des droits spéciaux.

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 2

On entre le nouveau mot de passe pour notre utilisateur que nous appellons TimeMachineUser:

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 3

Au niveau des groupes utilisateurs, il fera parti du groupe des utilisateurs par défaut (users) :

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 4

On donne à notre utilisateur les droits de lecture et écriture sur le dossier partagé TimeMachine:

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 5

Je vous recommande de définir un quota votre utilisateur Time Machine, afin d’éviter que les sauvegardes ne saturent complètement le NAS :

Utiliser un NAS Synology comme disque Time Machine sous MacOS photo 6

Cliquez sur Appliquer pour sauvegarder les changements.

Depuis la mise à jour de MacOSX Mojave, il est devenu impossible de lancer Meld, l’application multi-plateforme dont je me sers pour comparer plusieurs versions de fichiers afin de visualiser les différences dans du texte ou code.

Débloquer le démarrage de Meld sous MacOSX Mojave photo

L’application se lance mais ne présente pas la fenêtre habituelle qui permet de sélectionner les options de comparaison. Le menu apparait bien en haut de l’écran mais reste inutilisable.

On peut débloquer la situation très facilement – ouvrez une fenêtre de terminal et lancez les commandes suivantes:

cd ${HOME}
rm ./.local/share/meld -rf 
rm ./Library/Preferences/org.gnome.meld.plist -f
rm "./Library/Saved Application State/org.gnome.meld.savedState/" -rf 

Ces commandes permettent de supprimer le fichier de préférence GNOME de l’application et de réinitialiser l’état de l’application.

Une fois que vous avez exécuté ces commandes, relancez Meld – il me semble plus lent qu’avant à démarrer mais il est tout à fait fonctionnel ensuite, ce qui est l’essentiel.

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :