• D'avoir votre instance à vous
• D'ajuster sa taille en fonction de sa fréquentation
  
• De pouvoir la modérer comme bon vous semble
• De ne pas avoir à vous soucier de l'état du serveur qui la fait tourner
• De profiter de la dernière version stable disponible
  

Original post of dada.Votez pour ce billet sur Planet Libre.

Pour la 33ème semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Désinstaller des applications système d'Android
• Devops et SRE, De quoi s'agit-il ?
• Des développeurs dévoilent les choses les moins éthiques qu'ils ont codées
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• Firefox, est-il vraiment respectueux de notre vie privée (vidéo) ?
• Dotclear 2.14
• Github : quel impact sur les étudiants ?
• Nest : Le framework Node.js qu'il nous fallait
• Git comme système de snapshots simple pour sauver le sysadmin
• LineageOS

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

% sudo certbot --authenticator webroot --installer apache --webroot -w /usr/share/drupal7 -d www.ezvan.fr

 - The following errors were reported by the server:

   Domain: www.ezvan.fr
   Type:   unauthorized
   Detail: Invalid response from
   http://www.ezvan.fr/.well-known/acme-challenge/UWXvHv0ueIHLLooJIcIfdD2OiuNipVF5TuSc0dXnXd0:
   "
   
   403 Forbidden
   
   Forbidden"

 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/www.ezvan.fr/fullchain.pem. Your cert will
   expire on 2018-11-16. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again with the
   "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot renew"

Original post of Paul Ezvan.Votez pour ce billet sur Planet Libre.

J’appelle problème bloquant, un problème m’empêchant d’utiliser un outil. Cela ne signifie pas obligatoirement “l’outil ne fonctionne pas” mais plus globalement “l’outil n’est pas utilisable pour moi en l’état“. C’est le cas ici, je teste Mint XFCE et j’ai un démarrage en 46 secondes. Le démarrage fonctionne mais le temps de démarrage est bloquant pour moi, hors de question de rester sur une distrib qui met autant de temps à démarrer. Je suis en dual-boot, Xubuntu démarre en 7s.

Identifier

Il est nécessaire de connaître deux commandes pour identifier les lenteurs au démarrage des systèmes d’exploitation utilisant systemd : systemd-analyze et systemd-analyze blame. Vous en croiserez parfois une troisième permettant de présenter les résultats de manière graphique : systemd-analyze plot (à utiliser ainsi systemd-analyze plot > boot.svg). Un man systemd-analyze vous renseignera sur la fonction de chacune.

Voici le résultat de systemd-analyze sur ma Mint XFCE. Le noyau Linux (kernel) met donc 35s au démarrage et l’espace utilisateur (userspace) 11s. C’est ce résultat que je désigne par “démarrage” dans cet article et pour être précis tiré du man : “the time spent in the kernel before userspace has been reached, the time spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system userspace took to initialize”. On vient d’identifier deux problèmes, lenteur au niveau kernel et lenteur au niveau userspace.

Startup finished in 35.072s (kernel) + 11.461s (userspace) = 46.533sgraphical.target reached after 1.380s in userspace

Un systemd-analyze blame affiche le temps d’initialisation de chaque service et donne le résultat suivant (tronqué aux 5 premiers résultats). On identifie de suite la raison de la lenteur au démarrage de l’userspace : ntp.service. Ce service met 10s à s’initialiser à lui tout seul.

10.153s ntp.service408ms dev-nvme0n1p3.device292ms NetworkManager.service252ms systemd-cryptsetup@cryptswap1.service245ms systemd-resolved.service

Je vous invite à tester en live ces commandes sur votre pc. L’immense majorité des services systemd démarrent en moins d’une seconde si vous avez un SSD. Évidemment certains services sont lourds/longs à démarrer : virtualisation, bases de données… Je simplifie mais tout service qui démarre en plus de 2-3 secondes mérite votre attention : Est-il nécessaire ? À quoi sert-il ? Pourquoi ce délai ?

Diagnostiquer

On commence à mettre les mains dedans : Qu’est-ce qui provoque ce délai et est-ce qu’une action change ce délai ? Commençons par le service ntp.

La bonne manière de procéder : 1/ Favoriser des tests aux résultats visibles et compréhensibles, ça oriente et confirme nos soupçons. On doit être sûr que c’est notre action qui a changé quelque chose, pouvoir constater un changement, comprendre ce qu’on a fait et ce qui s’est passé 2/ Effectuer des tests qui impactent le moins possible le système d’exploitation afin de pouvoir revenir en arrière (rollback) et reproduire la situation d’origine 3/ Pour rechercher et isoler la cause d’un problème, on va du grossier au précis. Plutôt que faire 100 tests sur des choses précises (plus long et difficile), il vaut mieux faire un test général pour savoir dans quelle direction poursuivre (disque, kernel, réseau, etc.) 4/ Créer des tests de sorte que problème/résultat soient reproductibles ainsi on teste et valide facilement/rapidement une action

Ici nous allons donc simplement désactiver le service ntp sudo systemctl disable ntp.service (pour rollback : sudo systemctl enable ntp.service), redémarrer sudo reboot puis afficher de nouveau le résultat systemd-analyze blame. Il est évident mais ça confirme qu’il n’y a pas d’effets indésirables dans l’immédiat : L’userspace démarre en moins de 2 secondes. On gagne près de 10s à chaque démarrage.

Repassons sur notre lenteur kernel. Lorsqu’on arrive sur Grub, on choisit Advanced options for Linux Mint 19 Xfce puis Linux Mint 19 XFCE (recovery mode) et on regarde ce qui se passe. Dans mon cas c’est simple, ça reste longtemps sur un message : Scanning for btrfs file systems. On va orienter nos recherches de ce côté-là.

Réparer

Le service ntp permet de fournir l’heure exacte au système d’exploitation, on ne peut pas se contenter de le laisser désactivé mais on peut probablement lui trouver un remplaçant. Je vous recommande chaudement chrony, vous pouvez aussi passer à systemd-timesyncd. Chrony est méconnu pourtant c’est la nouvelle référence, il est déjà utilisé de base sur les systèmes Fedora, CentOS, Red Hat. Sa configuration par défaut est sécurisée, correcte, il n’écoute qu’en local et n’agit qu’en client NTP. Il faut donc juste l’installer : sudo apt install chrony. On redémarre sudo reboot puis on affiche de nouveau le résultat systemd-analyze blame : La lenteur constatée niveau userspace a disparu, on a définitivement gagné 10s à chaque démarrage, le service chrony s’initialise en 54ms. On aurait pu creuser le problème du service NTP, ça aurait pris sûrement beaucoup plus de temps. Nous avons là une solution simple, rapide, satisfaisante.

En effectuant quelques recherches sur la lenteur niveau kernel, on apprend qu’il y a des problèmes avec le noyau 4.15.0-20. On vérifie notre noyau (uname -r), pas le même. Le plus évident lorsqu’on a un problème avec un noyau, c’est d’en tester un autre.

On se rend sur http://kernel.ubuntu.com/~kernel-ppa/mainline/ puis on cherche la dernière branche. Le plus simple étant de cliquer sur Last modified, actuellement le noyau le plus récent est le 4.18. Je n’aime pas prendre la dernière version, je lui préfère une version antérieure (par exemple la 4.17.12) : 1/ Les bugs commencent à être connus et identifiés, on peut retrouver leurs traces 2/ Trop récent, peu fiable.

On télécharge, on installe, on redémarre, on vérifie le noyau et systemd-analyze.

wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-headers-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-headers-4.17.12-041712_4.17.12-041712.201808030231_all.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-image-unsigned-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.12/linux-modules-4.17.12-041712-generic_4.17.12-041712.201808030231_amd64.debsudo dpkg -i linux*4.17.12*.debsudo rebootuname -rsystemd-analyze

Pas de bol, pas mieux ! On a encore un démarrage kernel de plus de 30 secondes. À noter que sur Grub, on peut toujours choisir de booter sur l’ancien noyau. On va faire des recherches sur Scanning for btrfs file systems, je précise que je n’utilise pas btrfs sur mon pc.

Le premier lien est la solution qui a marché pour moi.

sudo blkid # On affiche les identifiants (UUID) des périphériques bloc (systèmes de fichiers)sudo cat /etc/initramfs-tools/conf.d/resume # On compare les UUID de la commande blkid avec le contenu du fichier resume, dans mon cas aucune correspondance. L'UUID ne correspond à aucun périphérique bloc, c'est incohérentsudo cp /etc/initramfs-tools/conf.d/resume ~/resume.bak # On fait une sauvegarde du fichier pour pouvoir rollbacksudo nano /etc/initramfs-tools/conf.d/resume # Remplacer RESUME=UUID=xxx par RESUME=nonesudo update-initramfs -u

Je pense qu’une bonne explication est ici. Je recommande également ces liens connexes : 1, 2, 3, 4. Pour résumer il y a des problèmes si vous chiffrez votre /home notamment autour de la swap. Dans la release notes de Mint 19 XFCE, Known issues : There is an issue with home directory encryption that causes swap to be misconfigured during installation. To correct this…”

Conclusion

Au début de l’aventure.

Startup finished in 35.072s (kernel) + 11.461s (userspace) = 46.533sgraphical.target reached after 1.380s in userspace

Après la résolution du problème dans l’userspace (ntp.service).

Startup finished in 35.071s (kernel) + 1.371s (userspace) = 36.442sgraphical.target reached after 1.363s in userspace

À la fin de l’aventure (après la résolution du problème niveau kernel).

Startup finished in 3.786s (kernel) + 1.380s (userspace) = 5.167sgraphical.target reached after 1.373s in userspace

Je démarre à présent en moins de 6s, 40s gagnées à chaque démarrage, un confort indéniable. Soulignons le fait qu’une version LTS (Long Term Support) n’est pas exempte de soucis/bugs, que le démarrage est aussi concerné par des problèmes/optimisations.

J’ai essayé de vous fournir une méthodologie et quelques bases pour vous débrouiller avec des lenteurs au démarrage, l’article Danse avec les reboots est un bon complément. Les commentaires sont ouverts, je réponds aux questions.

Tcho !

Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Pour lutter contre le spam dans les commentaires du blog, j’ai opté pour la simplicité dès le début parce que l’audience est restreinte, que je ne veux pas compliquer la vie des lecteurs avec des systèmes de captchas (de plus en plus illisibles d’ailleurs) et que je veux préserver l’accès au blog sans JavaScript pour les durs, les vrais, les tatoués ;-)

Ma naïve défense est basée sur un pot de miel : un champ caché dans le formulaire de saisie de commentaire, invisible pour l’humain normalement constitué, qui ne peut donc être rempli que par un bot qui analyse les pages HTML. Ces commentaires sont jetés directement par mon gestionnaire de commentaires Stacosys. Pendant longtemps, ce fut une défense suffisante ; de rares fois un facheux postait un commentaire pour me vanter un site de vente de pilules : je refusais le commentaire et voilà.

Mais depuis quelques temps, je reçois des rafales de spams : soit les robots sont plus efficaces et analysent aussi la CSS de la page, soit quelqu’un a embauché une armée de zombies pour poster manuellement sur tous les sites à moins de 100 visiteurs / jour. J’ai donc mis en place une 2ème ligne de défense. Quand j’étiquète spam le commentaire, Stacosys écrit une ligne de log avec l’adresse IP du spammeur, et fail2ban ajoute une règle iptables pour le bannir. La méthode n’est pas révolutionnaire, ça a demandé quelques lignes de code dans Stacosys ; ce qui est plus intéressant, c’est sa mise en oeuvre dans une architecture Docker avec un reverse proxy.

Nginx joue le rôle de reverse proxy, il balance les requêtes du blog vers Hugo et le post du formulaire vers Stacosys. Pour ne pas perdre l’adresse IP réelle du visiteur, on la propage jusqu’à Stacosys dans l’attribut HTTP X-Forwarded-For.

On a une configuration NginX de ce genre :

location /newcomment {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://stacosys:8100/newcomment;
}

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_pass http://nginx-blog;
}

Stacosys est un container Docker donc l’application (PID 1) écrit ses logs dans la sortie standard (STDOUT) ; c’est le comportement par défaut. Mais, afin d’ajouter des règles iptables, le container fail2ban a besoin de lire ces logs. On va donc exporter les logs de stacosys vers le container logger en rajoutant une section logging dans le fichier docker-compose qui décrit le lancement du service stacosys :

logging:
  driver: syslog
  options:
    syslog-address: "tcp://127.0.0.1:514"
    tag: "stacosys"

et le container logger, qui n’est rien d’autre qu’un serveur syslog, écrit ses logs dans un volume Docker :

logger:
    image: bobrik/syslog-ng
volumes:
    - syslog:/var/log/syslog-ng
ports:
    - "514:514"

Le volume de données syslog est partagé avec le container fail2ban qui peut ainsi lire les logs de stacosys, appliquer ses règles de filtrage et définir dynamiquement des règles iptables pour bannir les vilains.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.