Résoudre l'erreur

Résoudre l’erreur “/var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable”

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.


Serveur dédié : résoudre l'erreur  'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' — Missing /var/run/mysqld/mysqld.sock photo

Serveur dédié : résoudre l’erreur ‘Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)’ — Missing /var/run/mysqld/mysqld.sock

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.

Cron : résoudre l'erreur logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operator photo

Cron : résoudre l’erreur logrotate_script: 3: [: /var/run/mysqld/mysqld.pid: unexpected operator

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.

Serveur dédié : installation de MariaDB 10.3 photo

Serveur dédié : installation de MariaDB 10.3

mariadb

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.

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core photo

Serveur dédié : remplacer gzip par pigz pour profiter de la compression multi-core

Tous les matins, une sauvegarde des sites hébergés sur le serveur est effectuée.

A ce moment là, gzip tourne à plein régime et utilise pendant un certain temps le CPU – la montée en charge atteint 50%, ce qui devient limite pour la réactivité des sites Et pour cause : gzip ne fonctionne qu’en mono-core.

Il nous faut donc optimiser tout cela ! Mark Adler, l’auteur de gzip, a écrit pigz (qui se prononce pig-zee, à l’américaine) pour compresser fichiers et répertoires en utilisant tous les coeurs du processeur simultanément.

Pigz représente donc un gain de temps mais allège également la charge du processeur, sollicité moins longtemps.

Installation de pigz

Pigz est disponible sur la plupart des distributions linux, on peut donc l’installer avec un simple :

apt install pigz

L’autre avantage, c’est que si on lit le manuel, on se rend compte que les options et paramètres sont les mêmes que ceux de gzip, ce qui en fait un drop-in replacement de choix.

Remplacer gzip par pigz sur le serveur

L’occasion d’optimiser la compression des sauvegardes est trop belle : et si nous remplacions tout simplement gzip par pigz, sur l’intégralité du serveur et sans toucher à aucun de nos scripts ?

Allez, c’est parti ! On édite donc le fichier .bashrc :

nano .bashrc

et on y ajoute les deux fonctions suivantes :

###
# Matt Biscay
# https://www.skyminds.net/?p=29838
# Use pigz instead of gzip
###
function gzip(){
 pigz $@
}
export -f gzip

function gunzip(){
 unpigz $@
}
export -f gunzip

Cela nous permet de remplacer les fonctions gzip et gunzip par pigz et unpigz, respectivement.

Sauvegardez le fichier et rechargez-le pour activer les changements :

source .bashrc

Et voilà : pigz remplace désormais gzip pour toutes les opérations de compression du serveur. A nous la compression multi-core :)

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
PHP : configurer un pool PHP pour chaque site photo

PHP : configurer un pool PHP pour chaque site

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sock

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restart

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Linux : récupérer des vidéos depuis votre terminal avec MovGrab photo

Linux : récupérer des vidéos depuis votre terminal avec MovGrab

Movgrab est un outil en ligne de commande écrit en C (sans dépendances) qui permet de récupérer facilement des vidéos sur des sites comme YouTube, DailyMotion, Vimeo, Blip.tv, Liveleak, Guardian…

movgrab-download-videos-shell

Il permet de choisir les flux disponibles sur les pages vidéo, supporte les proxies, peut reprendre des téléchargements… c’est une application très utile.

Liste des sites supportés par movgrab

Movgrab fonctionne avec:

[one_half]

  • YouTube
  • Metacafe
  • Dailymotion
  • Vimeo
  • Break.com
  • eHow
  • 5min.com
  • vbox7
  • blip.tv
  • Ted
  • MyVideo
  • ClipShack
  • MyTopClip
  • RedBalcony
  • Mobando
  • Yale University
  • Princeton University
  • Reuters
  • LiveLeak
  • Academic Earth
  • Photobucket
  • VideoEmo
  • VideosFacebook

[/one_half]

[one_half_last]

  • Aljazeera
  • Mefeedia
  • IViewTube
  • Washington Post
  • CBS News
  • Euro News
  • MetaTube
  • MotionFeeds
  • Escapist
  • Guardian
  • RedOrbit
  • Sciive
  • Izlese
  • uctv.tv
  • royalsociety.tv
  • British Academy
  • Kitp
  • Dotsub
  • Astronomy.com
  • Teachertube.com
  • Discovery
  • Bloomberg.com

[/one_half_last]

Lire la suite

Subliminal : résoudre l'erreur

Subliminal : résoudre l’erreur “AttributeError: list object has no attribute lower”

Dernièrement, le script python que j’ai écrit pour télécharger les sous-titres automatiquement avec Subliminal a renvoyé le message d’erreur suivant :

AttributeError: 'list' object has no attribute 'lower'

Il se trouve que l’attribut lower ne peut-être appliqué qu’à des variables (type string) et non pour des objets (type array).

Nous allons donc éditer le code source de subliminal pour corriger le problème.

Ajout de nouvelles directives à subtitle.py

1. On se connecte au Synology en SSH:

ssh admin@SYNOLOGY

2. On passe root:

sudo -i

3. On recherche le fichier subtitle.py :

find / -type f -name "subtitle.py"

Résultat, 3 fichiers trouvés sur le NAS:

/usr/lib/python2.7/site-packages/subliminal/subtitle.py
/volume1/@appstore/VideoStation/subtitle_plugins/syno_subscene/subtitle.py
/volume1/@appstore/subliminal/env/lib/python2.7/site-packages/subliminal/subtitle.py

4. Le fichier qui nous intéresse se trouve sous /usr/lib donc nous l’éditons:

nano /usr/lib/python2.7/site-packages/subliminal/subtitle.py

5. Faites une recherche avec le terme lower (avec Ctrl+W sous nano). Vous trouver cette ligne:

    # format
    if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       matches.add('format')

Nous allons commenter ces lignes et ajouter des conditions pour que lower ne soit appliqué qu’aux chaînes (type string):

    # format
    #if video.format and 'format' in guess and guess['format'].lower() == video.format.lower():
       #matches.add('format')
    if video.format and 'format' in guess:
       guess_format = guess['format'] if isinstance(guess['format'], list) else [guess['format']]
       if any(gf.lower() == video.format.lower() for gf in guess_format):
            matches.add('format')
Attention à bien respecter le nombre d’espaces pour l’indentation : il s’agit d’un script python donc très tatillon à ce sujet !

6. Sauvegardez le fichier.

7. Relancez la recherche automatique des sous-titres : plus d’erreurs relatives à l’attribut lower :)

Enjoy!

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Lire la suite

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 2

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu

A la maison, je galère un peu avec les taux de transfert des fichiers entre ma machine fixe (The Reaper) et le NAS Synology.

Lors des transferts via le navigateur, la vitesse arrive à peu près à 2MB/s, ce qui, excusez-moi du peu, sonne comme une douce plaisanterie.

Pour pallier ce problème, nous allons donc “mapper” un des répertoires du NAS directement dans un répertoire local de ma machine.

Comme cette dernière tourne sous Ubuntu, il suffira dans Nautilus de copier des fichiers ou dossiers dans ce répertoire pour que tout soit uploadé directement dans le NAS. Un gain de temps en perspective !

Activation de NFS sur le NAS

Sur le NAS, nous allons avoir besoin du protocole NFS (Network File System).

Rendez vous dans Control Panel > File Sharing > File Services > cochez la case pour activer le service NFS et appliquez les changements:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo

Ensuite, cliquez sur l’icône qui se trouve juste au dessus, Shared folders :

  1. créez un nouveau dossier partagé. Je vais prendre NetBackup comme exemple pour ce tutoriel.
  2. sélectionnez le dossier > cliquez sur Edit > sélectionnez l’onglet NFS permissions.
  3. cliquez sur Create pour ajouter une nouvelle politique de droits NFS sur ce dossier.

Voici les droits à accorder:

NAS Synology : mapper un répertoire du NAS sur un répertoire local sous Ubuntu photo 1

Configuration :

Hostname/IP : on indique l’IP de la machine locale. Sur mon réseau local, 192.168.0.10 est l’adresse de ma machine fixe.

Privileges: Read/Write pour lecture et écriture.

Squash : Map root to admin. Cela permet de monter automatiquement le répertoire au démarrage de la machine.

Je laisse coché toutes les autres options, les transferts asynchrones ne me dérangent pas.

Lire la suite

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown photo

Serveur dédié : mise à jour du kernel OVH pour combler les failles Spectre et Meltdown

Au début du mois de février, l’université de Graz et Google Project Zero ont annoncé avoir découvert deux failles de sécurité importantes s’appuyant sur les mécanismes de fonctionnement interne des processeurs.

Trois vulnérabilités permettant d’accéder à de la mémoire privilégiée ont été publiées, qui ont pour point commun d’exploiter les mécanismes d’exécution spéculative et les timings des caches mémoires.

Meltdown

La première faille, Meltdown (CVE-2017-5754), permet de bypasser les mécanismes d’isolation mémoire entre mémoire classique (utilisée par les applications) et mémoire kernel (utilisée par le noyau du système d’exploitation, et protégée normalement par des mécanismes hardware dans le CPU).

Meltdown est une attaque side channel permanent;qui s’attaque à une faille de certains processeurs OOO (Out Of Order, la plupart des processeurs performants modernes depuis le Pentium Pro) qui, dans leur mécanismes d’exécution spéculatifs, peuvent non seulement lire des données mémoires protégées mais aussi exécuter des instructions sur ces données mémoires.

Concrètement, avec Meltdown, il est possible de lire tout type de mémoire à partir d’un process malicieux, y compris côté serveur de bypasser toutes les protections de type VM/Hyperviseur/Docker. Meltdown touche spécifiquement les architectures d’Intel et ARM.

Spectre

En parallèle à Meltdown, une autre faille a été dévoilée baptisée Spectre. permanent;Pour Spectre, la situation est plus compliquée. Il s’agit toujours d’une variation sur le même thème, à savoir tenter d’exploiter les mécanismes d’exécution spéculative des processeurs. T

ous les processeurs modernes sont concernés a différents niveau et l’on retrouve, y compris chez un même constructeur, des différences d’une architecture à l’autre en fonction des mécanismes précis de fonctionnement de chaque génération.

Le papier décrit deux attaques distinctes. La première, connue sous le nom de CVE-2017-5753 (bounds check bypass) permet à un processus d’accéder, dans certains conditions un peu plus complexes, à la mémoire d’un autre processus.

Contrairement à Meltdown dont l’exploitation est triviale, il faut ici connaître les spécificités du programme que l’on attaque pour réussir à l’exploiter.

Le groupe Google Project Zero a montré que cette attaque était exploitable aussi bien sur les CPU Intel, AMD (FX et APU), et ARM (un Cortex A57 à été testé). Si tous les processeurs sont exploitables, c’est que tous les modèles OOO modernes reposent, dans les grandes lignes, sur l’algorithme de Tomasulo, du nom de l’ingénieur qui l’a développé en 1967 chez IBM.

Virtuellement, tous les systèmes (du serveur au smartphone) sont vulnérables à cette attaque pour laquelle des PoC existent même en Javascript (pour bypasser les barrières des VM qui isolent le code Javascript de vos différents onglets), ce qui la rend assez grave.

Des méthodes de mitigations, aussi bien au niveau des compilateurs, des navigateurs, et des systèmes d’exploitations sont en cours de développement et des patchs sont attendus rapidement pour limiter le problème.

Vous pouvez retrouver les détails techniques des failles Spectre et Meltdown chez OVH.

Mon machine est-elle touchée par ces failles?

Il vous suffit de tester votre processeur avec le script Spectre & Meltdown Checker:

curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
chmod +x spectre-meltdown-checker.sh
sh ./spectre-meltdown-checker.sh

Résultat avant la mise à jour du kernel:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 46 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

Mise à jour du kernel OVH

Sur la Kimsufi, c’est le kernel OVH 4.9.87 qui intégre tous les correctifs Meltdown et Spectre, ainsi que la mise à jour du microcode pour les puces Intel.

Il suffit de suivre le tutoriel pour mettre à jour le noyau OVH.

Après mise à jour du noyau et redémarrage du serveur, les failles semblent maintenant comblées:

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

Voilà, mettez vos noyaux à jour, c’est important.

Backup Manager : résoudre l'erreur

Backup Manager : résoudre l’erreur “tar: file changed as we read it” lors de la création de la sauvegarde

Cela fait quelques jours que Backup Manager, qui me sert à sauvegarder automatiquement les fichiers et bases de données du site sur le serveur de sauvegarde, renvoie une erreur lors de la création d’un de mes fichiers de sauvegarde, alors que tout se passait sans encombres jusqu’alors.

C’est gênant dans le sens où on ne sait pas vraiment ce qui a empêché la bonne création du fichier et on ne peut vraiment être certain de l’intégrité du fichier de sauvegarde, ce qui est critique.

Voici le message d’erreur reçu par email à la fin de la sauvegarde :

Unable to create "/home/archives/mail.skyminds.net-home.20180208.master.tar.gz", check /tmp/bm-tarball.log.TZ2VAU
1 error occurred during the tarball generation.

Et voici le contenu du fichier log en question :

tar: /wp-content/ file changed as we read it

Étapes du débogage

Le moins que l’on puisse dire, c’est que tar ne nous donne pas vraiment d’indications sur la cause du problème. Un fichier qui change lors de la lecture, d’accord mais lequel ? De plus, il indique un répertoire et non un fichier précis.

Dans le fichier de configuration de Backup Manager, il est possible de choisir plusieurs formats de fichier pour compresser les fichiers de sauvegarde. J’utilise .tar.gz puisque tous mes machines tournent sous Unix mais là, j’ai changé la configuration pour utiliser le format zip.

On relance le script de sauvegarde : zip est beaucoup plus loquace dans ses messages d’erreur !

Voici ce qu’il nous indique :

zip warning: Not all files were readable
  files/entries read:  55621 (1.3G bytes)  skipped:  96 (414K bytes)

Très bien. Il ne nous reste plus qu’à trouver quels sont ces fichiers qui n’ont pas les droits de lecture.

A la racine du site, on lance donc une recherche pour trouver tous les fichiers et dossiers qui n’auraient pas les droits basiques de lecture (read) :

find . ! -perm -o=r

Résultat :

./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B0089KSLUY
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---CustomerReviews_B004LS7G3G
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00B2OI0FU
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B00JGYYQ24
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B006H4R9LG
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B005BHE48Q
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---internal-metadatas---B00H2O1YOI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---CustomerReviews_B00MVQLMPI
./wp-content/plugins/amazonsimpleadmin/cache/zend_cache---B017EOYW9Y

Il s’agit donc de fichiers de cache de produits Amazon, qui sont absolument inutiles pour les sauvegardes: nous allons donc exclure ce répertoire de cache de nos fichiers de backup.

Suppression des répertoires de cache avant compression des archives

Dans la configuration de Backup Manager, ajoutez le chemin des répertoires de cache de quasiment tous les plugins WordPress :

export BM_TARBALL_BLACKLIST="/home/public_html/wp-content/plugins/*/cache/* /home/public_html/wp-content/*cache*"

Sauvegardez le fichier et relancez votre script de backup.

Méthode plus radicale : éditer le script

Si la méthode précédente ne porte pas ses fruits, en voici une autre. Il suffit de modifier la valeur du chmod dans ces deux fichiers :

/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/File.php
/wp-content/plugins/amazonsimpleadmin/lib/AsaZend/Cache/Backend/Static.php

Cherchez le chmod 600 :

'cache_file_umask' => 0600,

et remplacez-le par un chmod 644:

'cache_file_umask' => 0644,

Tada, plus d’erreur et des fichiers de sauvegarde propres, sans fichiers de cache inutiles !

Je suis assez content d’avoir trouvé une solution à ce problème assez récurrent.

Le fait d’avoir momentanément modifié le type d’archive à créer a bien aidé à isoler la cause du problème.