Linux Mint Debian Edition (LMDE) est vraiment très stable et fonctionne avec des paquets éprouvés mais pas vraiment à jour.
Si vous avez du matériel récent, il est possible qu’il ne soit pas détecté – c’est le cas du pavé tactile de mon ordinateur portable – à cause du noyau linux qui laggue un peu.
A l’heure où j’écris ces lignes, Linux Mint Debian Edition utilise le kernel 3.16 alors que le dernier en date est le 4.6.3… voyons comment on peut le mettre à jour.
Le kernel Liquorix
Liquorix vient remplacer le noyau linux de votre distribution.
C’est un noyau à jour, avec des configurations supplémentaires pour les ordinateurs de travail, le multimédia et les jeux vidéos.
Installation de Liquorix
On passe root :
sudo -i
On édite le fichier sources.list d’apt :
nano /etc/apt/sources.listCode language:PHP(php)
et on y ajoute :
# liquorix kernel
deb http://liquorix.net/debian sid mainCode language:PHP(php)
On sauvegarde le fichier, on met à jour les paquets et on installe le keyring de Liquorix :
Aujourd’hui, petite mise à jour mineure de PHP7, en utilisant les dépôts DotDeb.
Le problème : PHP-FPM désactivé par défaut
A la fin de l’installation, j’obtiens ce message d’avertissement :
Setting up php7.0-fpm (7.0.8-1~dotdeb+8.1) ...
Installing new version of config file /etc/init.d/php7.0-fpm ...
NOTICE: Not enabling PHP 7.0 FPM by default.
NOTICE: To enable PHP 7.0 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.0-fpm
NOTICE: You are seeing this message because you have apache2 package installed.
[ ok ] Restarting PHP 7.0 FastCGI Process Manager: php-fpm7.0.Code language:JavaScript(javascript)
C’est bien la première fois qu’une mise à jour de PHP désactive PHP-FPM, ce n’est pas vraiment une mise à jour mineure et sans accroc.
On réactive donc les deux modules indiqués et on relance la configuration de PHP-FPM avant de relancer Apache et PHP-FPM :
Je lance le site : page d’erreur de certificat la première fois, et page blanche ensuite !
Des modules PHP à installer séparément
Après analyse des dernières lignes du fichier log d’Apache, je me suis rendu compte que le site avait besoin des modules mbstring et xml or, cette nouvelle version ne les fournit plus : ce sont maintenant des paquets à installer à part.
Voici le message d’erreur des logs:
[26-Jun-2016 08:39:12 UTC] PHP Fatal error: Uncaught Error: Class 'DOMDocument' not found in /public_html/wp-content/plugins/ginger/front/gingerfront.core.php:171
Stack trace:
#0 /public_html/wp-includes/plugin.php(235): ginger_parse_dom('...')
On installe donc mbstring et xml avant de relancer Apache et PHP :
Cette fois-ci, c’est tout bon. Tous les services sont actifs et le site est de nouveau opérationnel.
Attention donc : c’est une mise à jour mineure que j’aurais pu faire en SSH depuis mon téléphone, sans avoir les moyens de réparer à distance. Cela remet en perspective les mises à jour “on-the-go“.
Voici les nouveaux modules qui ne sont plus inclus par défaut avec PHP : bcmath, dba, mbstring, soap, xml et zip. Ce sont donc maintenant des paquets à part entière, à installer séparément.
Pas de clé publique disponible pour vérifier l’authenticité des dépôts
Au lancement de la mise à jour des paquets du serveur, je suis tombé sur le message d’erreur suivant :
W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553Code language:PHP(php)
Visiblement, APT a perdu ses petits et ne retrouve plus la clé publique GPG d’un des mes dépôts (webmin en l’occurence).
Voici comment remédier au problème.
Solution : demander et ajouter la clé au trousseau GPG
Un peu de ménage dans APT
On commence par faire un peu de ménage dans les fichiers APT avec un petit coup de balai:
apt-get cleanCode language:JavaScript(javascript)
… avant de récréer le dossier lists/partial pour véritablement recréer le cache APT :
Les inodes perdues ! Cette semaine, j’ai eu droit à un problème particulier sur le serveur : alors que rien dans la configuration des services n’a été changé, je me suis rendu compte que WordPress ne réagissait pas comme d’habitude.
Les symptômes les plus visibles sont la lenteur de l’application, l’impossibilité de mettre à jour ou corriger un article ou encore ajouter des tags à un nouvel article.
Je tente alors un df -i pour vérifier le nombres d’inodes disponibles :
df -i
Un nœud d’index ou inode (contraction de l’anglais index et node) est une structure de données contenant des informations à propos d’un fichier stocké dans les systèmes de fichiers Linux/Unix.
À chaque fichier correspond un numéro d’inode (i-number) dans le système de fichiers dans lequel il réside, unique au périphérique sur lequel il est situé.
Descripteurs de fichiers, table des fichiers et table des inodes sous Linux
Les inodes contiennent notamment les métadonnées des systèmes de fichiers, et en particulier celles concernant les droits d’accès.
Les inodes sont créés lors de la création du système de fichiers. La quantité d’inodes (généralement déterminée lors du formatage et dépendant de la taille de la partition) indique le nombre maximum de fichiers que le système de fichiers peut contenir.
Dans notre cas, catastrophe, il ne reste quasiment plus d’inodes disponibles !
Mon NAS Synology est configuré pour se mettre automatiquement à jour, ce qui est plutôt pratique puisque cela permet d’automatiser les mise à jour de sécurité et des paquets essentiels.
Hier, une nouvelle mise à jour du DSM est arrivée : DSM 6. La mise à jour s’est visiblement bien déroulée mais quelques petites choses ont été modifiées au sein du système, dont la perte d’accès root pour rsync, ce qui est problématique pour mes sauvegardes.
Le truc qui change, c’est qu’au lieu d’utiliser root comme utilisateur, il va désormais être obligatoire d’utiliser un utilisateur qui appartient au groupe administrators. Chez moi, il y en a plusieurs mais pour des raisons de simplicité, nous utiliserons l’utilisateur admin dans ce tutoriel.
Voyons donc comment donner l’accès à rsync pour l’utilisateur admin, cela ne prend que quelques minutes.
Ajouter des utilisateurs dans le groupe des administrateurs
Nous commençons par vérifier que nous possédons bien au moins un administrateur sur le NAS. Par défaut, il devrait au minimum y avoir le compte admin mais vous pourriez l’avoir désactivé pour des raisons de sécurité (c’était mon cas avant de faire cette mise à jour).
Rendez-vous dans Synology > Control Panel > Group > Administrators > Edit members:
Ici, nous avons bien l’utilisateur admin. N’hésitez pas à y ajouter vos autres utilisateurs qui possèdent les droits d’administration.
Note: profitez-en pour faire un détour par Control Panel > User et changez le mot de passe de l’utilisateur admin pour un mot de passe plus robuste.
Après avoir joué quelques minutes avec Windows 10, j’ai ensuite installé Ubuntu Mate, qui a l’air vraiment génial.
Après l’installation, au redémarrage de la machine, je constate que la luminosité de l’écran est au maximum et qu’il m’est impossible de régler la luminosté avec les touches Fn + F5/F6.
Si vous êtes vous aussi confronté à ce problème, voici comment le résoudre.
Baisser la luminosité de l’écran
On commence par baisser la luminosité de l’écran avant de perdre la vue ou attraper une sinusite oculaire.
Rendez-vous dans Système > Préférences > Matériel > Gestionnaire d’énergie et baissez la luminosité. Je l’ai mise à 60% dans mon cas.
Ajouter le support des touches F5 et F6 pour régler la luminosité
Il nous reste maintenant à ajouter le support des touches F5 et F6 pour régler la luminosité. Cela m’a pris un peu de temps pour trouver la solution : j’ai d’abord regardé sur le net, installé des paquets, testé, rebooté…
En fait, il n’y a pas de paquets à installer. Il suffit juste d’ajouter une directive dans la configuration de démarrage de GRUB.
Mon NAS Synology vient de mettre à jour son firmware DSM et je constate en lançant ma sauvegarde rsync que la connexion rsync vers le NAS ne se fait plus : après saisie du mot de passe, on obtient une erreur “permission denied”.
Voici comment remédier à ce petit désagrément en deux minutes montre en main.
Après vérification que les identifiants (user/password) sont bien corrects, il s’avère que la solution réside dans l’utilisation de l’argument --rsync-path afin d’expliciter le chemin de l’exécutable rsync présent sur le NAS.
Solution : ajouter le chemin du binaire rsync du NAS
La solution est toute simple, il suffit de renseigner le chemin du binaire rsync qui se trouve sur le NAS Synology comme argument de notre connexion.
Sous DSM5, le chemin de rsync est /usr/syno/bin/rsync.
A partir de DSM6, le chemin de rsync est /usr/bin/rsync, qui est le chemin habituel sous linux.
Nous ajoutons donc l’argument --rsync-path à notre connexion initiale, ce qui nous donne :
Un des problèmes majeurs dans la gestion des données informatiques est la sauvegarde des données.
Idéalement, il faut pouvoir être en mesure de disposer de plusieurs copies de sauvegarde de nos données, intégres et utilisables, disponibles dans plusieurs lieux géographiquement éloignés afin de prévenir les risques.
Sur ce serveur par exemple, les sauvegardes sont envoyées sur le FTP de backup mis à disposition par OVH.
Connexion à un serveur distant en SSH, sans mot de passe
Mais il est également possible d’en envoyer une copie chez vous, directement sur votre NAS. Pour plus de sécurité (le FTP n’est pas un protocole sécurisé) il peut être très intéressant de créer un set de clés SSH pour que le script de sauvegarde (ou alors rsync) se connecte directement à votre NAS/serveur de sauvegarde en SSH.
Voyons donc comment nous pouvons créer un jeu de clés SSH sur notre serveur linux – ou n’importe quelle autre machine Unix, comme votre PC – vers un NAS Synology.
Cela nous permettra de nous identifier sur le NAS depuis le serveur, sans avoir à rentrer de mot de passe ou à le mettre en clair dans un script. C’est aussi un grain de temps de se logguer en SSH au NAS sans mot de passe !
De temps en temps, on a besoin d’intervenir sur le NAS et l’interface web d’administration du Synology n’est ni la plus intuitive, ni la plus rapide. En tout cas, sur un D212+, cela rame toujours un peu.
Aujourd’hui, je vous montre comment ouvrir une session SSH en tant que root sur votre Synology afin d’y installer des applications non officielles mais toutes aussi valables comme nano ou screen. Ce tuto prend à peine 10 minutes à réaliser.
Cela nous permettra à terme de pouvoir lancer différentes commandes et d’exploiter à fond les possibilités du NAS.
Activer SSH sur le Synology
Première étape : on active le service SSH sur le Synology :
connectez-vous au webadmin de votre Synology,
rendez-vous dans Control Panel > Applications > Terminal & SNMP,
dans l’onglet Terminal, cochez l’option Enable SSH service,
changez le port par défaut pour quelque chose de plus exotique : 44222 par exemple,
sauvegardez les options.
Retenez bien le numéro du port que vous avez défini. Il sera maintes fois utilisé par la suite.
Ouvrir une session SSH sur le NAS avec l’utilisateur root
Cette étape est cruciale et permet d’éviter de longues heures de recherche sur Internet pour comprendre pourquoi les commandes des étapes suivantes ne fonctionnent pas…
Vous devez *absolument* ouvrir une session SSH sur le NAS en tant qu’utilisateur root.
Le mot de passe de l’utilisateur root est le même que celui de l’utilisateur admin mais une session en tant qu’admin ne vous donnera pas les droits nécessaires pour installer quoi que ce soit.
Lorsque l’on jongle avec différents serveurs et plusieurs fenêtres de terminal, il n’est pas toujours évident d’identifier immédiatement sur quelle machine on se trouve.
Pour remédier à ce problème, je vous propose de changer les couleurs de l’invite de commande (prompt) de votre terminal sous linux.
Editer le fichier .bashrc
Nous allons éditer le fichier .bashrc, qui permet d’éditer les préférences utilisateurs pour tout ce qui concerne bash:
nano.bashrcCode language:CSS(css)
Ajout de styles
Et voici quelques styles sympas à ajouter pour tuner votre prompt.
C’est sur toutes les lèvres : 2015 aura vu l’arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.
Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.
HTTP/2 : une évolution du protocole HTTP
Avec HTTP/1.1, la vie des développeurs n’était pas simple. L’optimisation d’un site revenait à plusieurs techniques qui tournaient toutes autour de l’idée de minimiser le nombre de requêtes HTTP vers un serveur d’origine.
Un navigateur ne peut ouvrir qu’un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C’est ce qu’on appelle le head-of-line blocking.
HTTP/2 promet donc des gains de performance d’environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.
Plus besoin (normalement!) d’optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concaténation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d’HTTP 1.1.
Aujourd’hui, Jac m’envoie un message pour m’informer que sa redirection email ne fonctionne plus.
Je lance donc un terminal et vérifie les logs de Postfix, qui chargent des dizaines de lignes d’erreurs de ce type:
Dec 15 16:30:33 mail postfix/smtpd[5912]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102] Dec 15 16:30:34 mail postfix/smtpd[5912]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102] Dec 15 16:30:34 mail postfix/smtpd[5912]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102] Dec 15 16:30:34 mail postfix/smtpd[5908]: connect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102] Dec 15 16:30:34 mail postfix/smtpd[5908]: lost connection after AUTH from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102] Dec 15 16:30:34 mail postfix/smtpd[5908]: disconnect from static-68-236-203-102.nwrk.east.verizon.net[68.236.203.102]
Comme vous pourvez le constater, ça débite et ça impacte forcément les ressources du système. Voyons donc comment nous pouvons y mettre un terme.
Pré-requis : fail2ban
Nous allons utiliser fail2ban, un compagnon très utile pour surveiller les logs et analyser les comportements néfastes à l’aide d’expressions régulières.
