Python : résoudre l'erreur "ImportError: cannot import name main"

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.

NginX : résoudre "upstream sent too big header while reading response header from upstream"

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é.

MySQL : résoudre le message "Warning: Using a password on the command line interface can be insecure."

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.

Pin It on Pinterest

Spelling error report

The following text will be sent to our editors: