Jouons avec les multiplexeurs de terminaux sous Debian

Aujourd’hui nous parlerons de screen, byobu, tmux et tmate, quatre outils en ligne de commande permettant de rendre un terminal persistant dans un processus.

GNU Screen

« Il permet à un utilisateur d’accéder à de multiples sessions de terminal à l’intérieur d’une simple fenêtre de terminal, ou d’une session distante typiquement lancée par SSH » (Wikipedia). Il s’installe avec apt-get install screen.

Créer une nouvelle session : screen ou screen -S exemple. La session remplace le terminal courant par un terminal virtuel vivant dans un processus. Utiliser Ctrl+d tuera la session. La commande screen -d ou Ctrl+a d détachera la session et vous ramènera sur votre terminal initial, sans fermer la session. Le terminal virtuel continue sa vie dans un processus. Les sessions sont isolées par utilisateur système.
Lister les sessions : screen -ls.
Se connecter à une session : screen -r ou screen -r exemple.
Détacher une session de l’extérieur : screen -d, Ctrl+a d ou screen -d exemple.
Rejoindre une session attachée : screen -x ou screen -x exemple. Cela permet de visualiser de plusieurs endroits le contenu d’un unique terminal.

Il n’est pas possible d’imbriquer des sessions, bien qu’on puisse les lister depuis n’importe quel terminal et en créer (ce qui a pour effet de changer de session sans détacher la première). En revanche, on peut ajouter des terminaux virtuels (onglets) au sein d’une même session avec Ctrl+a c et les lister à leur tour avec Ctrl+a ".

Il existe de nombreux autres raccourcis clavier que l’on retrouve dans cette documentation permettant notamment de jouer avec le fenêtrage des terminaux (split vertical ou horizontal).

Les avantages de screen

  • S’utilise aussi bien en utilisant la session par défaut qu’avec de multiples sessions nommées.
  • Permet de lancer des opérations longues telles que du transcodage vidéo, des transferts de données ou des scripts interactifs sans se soucier d’attendre le retour ou de risquer un « Broken pipe »
  • Permet de partager un même terminal avec quelqu’un à distance
  • Permet se construire très rapidement des écrans de monitoring, en splittant le terminal en grille et en lançant des commandes telles que htop (uptime, load average, consommation en ram), watch -n1 df -h (calcul de l’espace disque en temps réel), iftop (trafic réseau), etc.

Les inconvénients

Peu user-friendly, de fonctionne que par raccourcis claviers à mémoriser. Le risque de mélanger les raccourcis et de faire ctrl+d par habitude est un problème.

tmux

« Tmux a pour but d’être une alternative stable et moderne à GNU Screen, il possède d’ailleurs la majorité des fonctions de GNU Screen, mais contrairement à celui-ci il est distribué sous licence BSD et fait partie de la base système d’OpenBSD » (Wikipedia). Il s’installe avec apt-get install tmux.

Créer une nouvelle session : tmux ou tmux new -s exemple. La session remplace le terminal courant par un terminal virtuel vivant dans un processus. Utiliser Ctrl+d tuera la session. La commande tmux detach ou Ctrl+b d détachera la session en cours et vous ramènera sur votre terminal initial, sans fermer la session. Le terminal virtuel continue sa vie dans un processus. Les sessions sont isolées par utilisateur système.
Lister les sessions : tmux ls.
Se connecter à une session : tmux a ou tmux a -t exemple. tmux permet de rejoindre les sessions via cette même commande, détachées ou non. C’est l’équivalent screen -r et screen -x.
Détacher une session de l’extérieur et s’y connecter : tmux a -d ou tmux a -d -t exemple.

Comme avec Screen, on peut ajouter des terminaux virtuels (onglets) au sein d’une même session avec Ctrl+b c et les lister à leur tour avec Ctrl+b w.

Il existe de nombreux autres raccourcis clavier que l’on retrouve dans cette documentation permettant notamment de jouer avec le fenêtrage des terminaux (split vertical ou horizontal), renommage des sessions ou onglets, défilement etc.

Les avantages de tmux sur Screen

À première vue, les deux outils se ressemblent énormément. Il existe quelques petites différences qui font pencher la balance en faveur de tmux :

  • la portabilité du code le rend présent sur plus de systèmes d’exploitation
  • meilleure gestion de l’entrelacement de sessions (avec des alertes, etc)
  • il affiche une barre de statut en bas du terminal avec quelques infos, ce qui permet aussi de savoir qu’on est en train d’utiliser tmux
  • il offre plus de possibilités pour être scripté, telles que le partage de sessions entre utilisateurs
  • globalement plus de petites options de configuration le jour où on souhaite personnaliser une session

Les inconvénients

Potentiellement toujours ce même risque d’utiliser ctrl+d par réflexe et toujours autant de commandes à retenir.

tmate

tmate est un fork de tmux. Il apporte la possibilité de partager un terminal en lecture seule, ainsi que la possibilité de partager à quelqu’un d’autre une commande SSH reconnectant directement dans une session.

Il n’est pas présent dans les dépôts de Debian et doit donc être installé via un dépôt externe. Le serveur utilise des fonctionnalités spécifiques du noyau Linux et n’est donc pas multiplateforme, alors que le client est disponible sous Mac et BSD.

Byobu

Byobu est initialement une couche d’amélioration à GNU Screen écrit pour Ubuntu. Aujourd’hui il utilise tmux par défaut pour proposer un ensemble de fonctionnalités user-friendly, ce qui signifie que tmux est installé comme dépendance. Le tout s’installe avec apt-get install byobu. Byobu est même préinstallé sur les instances Cloud d’Ubuntu par Canonical.

On lance le contexte Byobu via la commande byobu. La session remplace le terminal courant par un terminal virtuel vivant dans un processus. Une interface graphique en mode texte apparait dans le terminal, proposant comme tmux une barre listant les onglets mais en y ajoutant des indicateurs du système d’exploitation.
Byobu - écran d'accueil

Ces indicateurs sont configurables dans l’aide de Byobu, que l’on obtient en appuyant sur F1 ou F9. Byobu ne semble pas prévu pour lancer plusieurs sessions en parallèle, comme le permettent screen et tmux. À la place, Byobu permet d’être lancé au démarrage via sa fenêtre d’aide. Lorsque cette option est activée, byobu est exécuté à chaque connexion SSH. Mieux, Ctrl+d ou exit ne font plus sortir du contexte Byobu, ils ferment les onglets virtuels, ce qui est très pratique. Lorsqu’il ne reste qu’un onglet à fermer, la connexion SSH se referme automatiquement.
Byobu - Aide (F1 ou F9)

Les commandes basiques

Créer un nouvel onglet : F2.
Aller à l’onglet précédent : F3.
Aller à l’onglet suivant : F4.
Se détacher de la session : F6.
Rafraichir les indicateurs : F5 (automatique).
Renommer l’onglet : F8.
Entrer en mode historique : F7.

Il existe d’autres commandes, notamment pour diviser un onglet en plusieurs écrans, que je ne peux pas tester sous Mac OSX car ces raccourcis claviers sont déjà utilisés par le système.

Utilisation du mode historique

Le mode historique permet de naviguer dans les anciennes sorties en utilisant des commandes similaires à vi :

  • h ou flèche gauche – reculer le curseur d’un caractère
  • l ou flèche droite – avancer le curseur d’un caractère
  • j ou flèche bas – descendre le curseur d’un ligne
  • k ou flèche haut – monter le curseur d’une ligne
  • 0 – aller au début de la ligne
  • $ – aller à la fin de la ligne
  • G – aller à la ligne indiquée (par défaut va en fin de tampon)
  • / – recherche en avant
  • ? – recherche en arrière
  • n – Passe à la prochaine correspondance, en avant ou en arrière

Les avantages de Byobu sur tmux

Par où commencer ?! L’utilisation des touches Fonction est une réelle avancée, les actions sont simples à retenir, toutes au même endroit. En mode de démarrage automatique, plus de risque de détruire la session accidentellement. Les indicateurs de la santé du système restent toujours visibles, et le parcours de l’historique à la vi est un réel plus !

Les inconvénients

Il n’y a plus vraiment d’inconvénient avec Byobu, tout est à la fois simple, intuitif et puissant. Byobu ne semble pas pensé pour être scripté ni multi-utilisateurs mais bien pour être une surcouche graphique à un outil qui peut l’être. Byobu partage les sécurités anti-sessions-imbriquées de tmux : puisque l’unique session Byobu est une session tmux, il peut devenir délicat d’utiliser tmux.

Conclusion

Byobu est le grand vainqueur de ce match. Il existe de nombreux cas pratiques où ce logiciel vous sauvera la mise : lorsqu’il ne le fera pas, le confort d’utilisation qu’il procure reste une raison valable de l’installer sur tout serveur nécessitant un minimum de maintenance.

Empêcher crontab de remplir /var/mail/utilisateur et de saturer l’espace disque

En ouvrant le fichier /var/mail/utilisateur, on peut découvrir l’origine des emails en lisant qui en est l’expéditeur et quel est le sujet.

  • Crontab envoie un email système pour chaque tâche planifiée, avec le contenu de la sortie standard. On peut désactiver les mails ligne par ligne en ajoutant >/dev/null 2>&1 à la toute fin d’une ligne
  • Pour désactiver l’envoi de mails de l’ensemble des tâches planifiées, il faut ajouter MAILTO="" tout en haut du crontab -e
  • Hélas il existe d’autres crons lancé depuis d’autres endroits du système et qui ne sont pas dans crontab -e. On trouve en root le fichier /etc/crontab (un fichier cron chargé de lancer les scripts dans /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.monthly/ et /etc/cron.weekly/) ainsi que tous les fichiers dans /etc/cron.d/ dont /etc/cron.d/awstats qui écrit toutes les 10min. La conf MAILTO="" y est à répéter si besoin.

Mysql restart ne fonctionne pas

Bon un petit article sur un cas bien particulier et pas simple à résoudre.

Le contexte vous avez un serveur avec des crons, on va dire beaucoup de crons ou des crons exécutés souvent ainsi qu’une partition racine / assez petite par exemple 10Go, et bien au bout d’un moment cette partition se remplie de manière importante soit dû à un remplissage de votre dossier /tmp comme vu dans un article précédent où nous expliquons comment déplacer le /tmp, soit dû au fonctionnement du service cron comme vu dans un autre article sur le remplissage de /var/mail/utilisateur.

La rencontre du problème :

Et un beau matin, vous n’arrivez plus à vous connecter sur votre PhpMyAdmin ou encore vos applications web sont toutes en rades avec des erreurs comme « Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock' ».

La solution en mode rapide :

Du coup on monte sur le serveur en ssh en root et un df -lh plus tard on s’aperçoit que la partition est pleine, ce qui explique le souci, il ne reste donc plus qu’à utiliser l’un des 2 articles cités ci-dessus pour répondre au problème (en priorité celui sur les mails moins compliqués et plus rapide pour récupérer de la place). Fin… ou pas.

Comment ça s’est passé pour nous ? :

Oui mais forcément si j’écris cet article c’est bien que ce n’est pas ce que nous avons fait. Non en tant que développeur nous on aime bien comprendre les choses et lire des logs avec des messages d’erreurs ça aide souvent à comprendre les choses. Donc on monte sur le serveur en ssh en root et on va faire un tour dans /var/log, on regarde un peu ce qui concerne mysql et on voit des choses comme des .gz au détour d’une extraction on se dit que c’est l’extraction qui a généré un dossier mysql ou pour une raison abstraite l’envie nous prend de supprimer le dossier mysql.
A ce moment là mysql est toujours en rade (car nous n’avons pas encore fait de df -lh et nous ne connaissons pas encore la raison du plantage de mysql) et nous avons fait un rm -rf de /var/log/mysql/ (Oui il y a des fois on prend des risques). Ensuite on fait notre df -lh et oui dans les logs on a vu quelque chose comme « no space left » et là on s’aperçoit que c’est l’espace disque qui manque, on vide les mails dans le fichier /var/mail/utilisateur et on se dit que dans une seconde ça sera ok donc on fait un /etc/init.d/mysql restart et là failed, on insiste et on redémarre la VM et là mysql failed encore.
Impossible on a fait de la place etc. On va voir les logs ? Bonne idée. C’est où déjà ? Dans le dossier /var/log/mysql/. Non tu te trompes ça n’existe pas ce dossier (et oui on a une mémoire de poisson rouge parfois). Et s’en suit une longue recherche sur notre ami Google.
On tombe sur un article de stack overflow. On tente le mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock et devinez quoi ça fonctionne mysql ce relance, on est tout content, on fait même un /etc/init.d/mysql restart et encore une fois c’est ok parfait.

Oui mais … :

Oui mais voilà on est au courant que nous n’avons pas relancer mysql dans les règles de l’art et pire que ça on sait qu’on prochain redémarrage de la VM, mysql n’arrivera pas à se lancer donc on veut comprendre. Et comme la loi de Murphy nous l’apprend et bien la vm a redémarré le lendemain pour une raison quelconque sur laquelle nous n’avions pas la main et forcément re-belotte mysql en rade. Il faut qu’on trouve pourquoi et après de longues recherches aussi stupide et intrépide que possible la réponse était simplement dans le fichier de conf qui précise le répertoire des logs d’erreurs mysql et oui dans le fichier /etc/mysql/my.cnf il y a une ligne qui loggue les erreurs : log_error = /var/log/mysql/error.log et ce fichier my.cnf n’est pas appelé lorsque l’on lance la commande mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock, c’est pourquoi elle fonctionne alors que la commande /etc/init.d/mysql restart utilise notre fameux fichier my.cnf c’est pourquoi elle ne fonctionnait pas à cause de la non existence du dossier /var/log/mysql/. Vous vous doutez bien que derrière on fait en root un mkdir /var/log/mysql puis on kill le process précédemment lancé en récupérant le process id via ps aux | grep mysql puis kill -9 ProcessID et enfin un /etc/init.d/mysql restart et là bonheur tout refonctionne comme au bon vieux temps.

Enjoy 😉

Source : http://serverfault.com/questions/782725/cant-start-mysql-service

Aïe ma partition /tmp est trop petite, comment déplacer le répertoire /tmp sous debian sur une autre partition ?

Si vous vous retrouvez dans le cas où votre partition /tmp est trop petite, par exemple avec un cron qui demande beaucoup de place dans /tmp et oui cela peut arriver, il existe une astuce pour déplacer votre répertoire /tmp sur une autre partition où vous aurez plus d’espace disque. Je vais faire ici un résumé du forum suivant : https://debian-facile.org/viewtopic.php?pid=43446#p43446, si vous souhaitez plus de détails sur le sujet de nombreuses notions sont abordées sur ce forum.

Dans notre cas d’exemple, nous avons un disque séparé en plusieurs partitions : la partition racine / de 10Go contenant notre fameux dossier /tmp et une partition pour /home de 145Go.

Le problème est survenue de manière silencieuse au départ, un cron qui grossit en terme d’actions à réaliser comme des rsync et donc qui grossit en terme d’espace temporaire nécessaire tant que la partition / avait assez de place pas de soucis le disque se remplissait (pas entièrement) de fichiers temporaires et une fois le cron fini les fichiers était « réellement » supprimé.

Ce point est important, il existe plusieurs commandes pour évaluer la place prises sur une partition « df » qui vous retourne l’espace occupé ainsi que l’espace total et par une soustraction magnifique cette commande arrive à vous retournez l’espace libre (c’est incroyable ;)) et une seconde commande « du » (et son dérivé « ncdu » basé sur le même comportement que « du ») qui elle vous retourne l’espace occupé par le dossier passer en paramètre. Et bien ces 2 commandes n’ont pas le même comportement, la commande « df » tient compte des fichiers supprimés mais encore présent sur le disque car ouvert par un processus, ce n’est pas le cas pour « du » (et son dérivé « ncdu ») qui lui ne considère plus les fichiers supprimés même s’ils sont encore ouvert par un processus. Et là nous avons un souci car on peut passer beaucoup de temps à regarder quel dossier est en surpoids avec « du » sans jamais trouver la réponse.

Ce point expliqué passons au vif du sujet, comme vous l’imaginez le problème n’est réellement apparu que lorsque le cron a saturé la partition racine est a donc fait « planté » le serveur.

A partir de là et après de multiples enquêtes à base de lsof | grep deleted pour récupérer la liste des fichiers effacés encore ouvert par un processus puis un ls -alh /proc/Processus_ID/fd/ pour voir où le ou les fichiers en question étaient stockés, je me suis aperçu que le dossier fautif était toujours /tmp.

Ce faisant j’ai fait des recherches et suis tombé sur ce forum traitant de debian, et voici comment j’ai déplacé le dossier temporaire du serveur debian.

J’ai utilisé la méthode dite « commune » dans le post ci-dessus (mais pas toutes les étapes, par exemple je ne suis pas passé en mode failsafe et oui serveur de prod oblige on évite les redémarrages). Je me suis donc mis en root puis assuré qu’aucun processus n’avait besoin de /tmp avec ps aux | grep tmp, s’il y en a il faut « killé » les processus avec kill -9 ProcessusId. Ensuite j’ai créer mon nouveau répertoire qui allait accueillir le contenu de /tmp (pas sur la partition racine on est d’accord sinon ça ne sert à rien) mkdir /home/MonCheminVersLeNouveauRepertoireTmp (ce dossier peut être préfixé par un point pour le caché ex : /home/MonCheminVersLeNouveauRepertoireTmpCaché/.tmp). On lui met les bons droits pour en faire un répertoire temporaire en bonne et dû forme chmod -R 1777 /home/MonCheminVersLeNouveauRepertoireTmp (Pour plus de détails sur le 1 de 1777 voire le forum). Jusque là tout va bien nous n’avons pas modifié le comportement de notre debian mais là nous allons voir le changement dans pas longtemps.
Avec toutes les précautions et le stress qu’il faut j’ai lancé un rm -rf /tmp, à cet instant il n’y a plus grand chose qui fonctionne (par exemple passenger pour les rubyistes) même la simple complétion des chemins lorsque l’on fait « tab » affiche une erreur très inquiétante, donc très rapidement je lance ln -s /home/MonCheminVersLeNouveauRepertoireTmp /tmp. A ce moment là la complétion avec « tab » refonctionne ouf c’est réparé et bien pas tout a fait encore une fois passenger lui ne se relance pas automatiquement notament son module pour apache2 donc faire un petit /etc/init.d/apache2 restart n’est pas de trop et je pense que d’autres programmes doivent être dans le même cas à vous de voir.

Et voilà, essayer de mettre des gros fichiers dans /tmp et un df -lh, plus tard vous verrez que ce n’est plus la partition / qui se remplie mais bien la partition /home.

Enjoy 😉

Introduction à fail2ban

« fail2ban lit les logs de divers services (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source. » (source : doc.ubuntu-fr.org)

Par défaut, fail2ban applique un blocage de 10min après 6 tentatives en 10min.

Pour configurer ses « prisons », il faut éditer le fichier /etc/fail2ban/jail.conf.

Exemple :

  • ignoreip : les IP 127.0.0.1 et 8.8.8.8 sont ignorées pour tous les ports
  • fintime : fail2ban remonte 1 heure dans les logs
  • bantime : les ips sont bloquées 24 heures
  • enabled : pour activer/désactiver une prison
  • port : le/les port(s) correspondant(s) à la prison. Il faut penser à mettre les numéros de ports s’ils ont été modifiés. Par exemple, si on passe ssh sur le port 2212, il faut mettre 2212 à la place de ssh.
  • filter : le filtre à appliquer. La liste des filtres est dans /etc/fail2ban/filter.d. Il est possible d’en créer soi-même.
  • logpath : le chemin du fichier de log à analyser
  • maxretry : le nombre maximum de tentatives par une IP dans le laps de temps findtime

Il est également possible d’envoyer un mail dès qu’une adresse IP est bannie. Pour cela, il faut ajouter les lignes suivantes :

  • destemail définit le destinataire du mail
  • action définit l’action à effectuer lors d’un blocage. action = %(action_)s est l’action par défaut, elle se contente de bloquer l’IP. action = %(action_mw) envoie un mail à chaque bannissement. action = %(action_mwl) envoie un mail avec les logs.

Une fois la configuration modifiée, il faut la recharger :

Pour voir le nombre de prisons lancées :

Et pour surveiller le fonctionnement d’une prison :

Les filtres qui me paraissent importants à mettre en place sont les suivants :

  • ssh
  • apache-phpmyadmin
  • apache-noscript
  • anti-w00tw00t

Sources :

Let’s Encrypt et Apache

Let’s Encrypt est une autorité de certification lancée en décembre 2015 qui fournit des certificats gratuits. Il a l’avantage de fournir un processus qui permet d’automatiser l’installation du certificat.

Grafikart a créé un tutoriel vidéo pour la mise en place d’un certificat SSL sur Apache, ce tutoriel est très bien pour la mise en place de Let’s Encrypt et des certificats mais le script de renouvellement n’a pas fonctionné dans notre configuration sous debian 8 + apache2 : Mettre en place un serveur Web : Apache, Let’s Encrypt

Résumé de l’installation de Let’s Encrypt et mise en place des certificats

Pour plus d’infos (installation de dépendances, …) n’hésitez pas à consulter l’article de Grafikart.

On installe Let’s Encrypt avec les droits administrateur :

Voilà pour l’installation de Let’s Encrypt. L’outil se chargera par la suite d’installer les dépendances lors de son utilisation.

À noter que la version 2.7.9 de Python est requise (c’est la version présente dans Debian 8).

Passons à la mise en place des certificats. Deux solutions :

  1. Soit vous souhaitez mettre en https tous les noms de domaines configurés avec un virtual host
  2. Soit vous préférez mettre en https que certains noms de domaines pointant sur votre serveur

Pour le cas 1, utilisez la commande suivante :

Pour le cas 2, utilisez la commande suivante :

En remplaçant bien sûr mondomaine.fr et www.mondomaine.fr par votre nom de domaine.

Le script va vous demander des infos :

. Enter email address (used for urgent renewal and security notices) (Enter ‘c’ to cancel): il faut rentrer l’adresse mail sur laquelle vous souhaitez être prévenu de l’expiration du certificat

Please read the Terms of Service at : répondre A pour Agree

Would you be willing to share your email address with the Electronic Frontier Foundation… : Yes ou No (à vous de voir si vous voulez partager votre adresse mail sur leur liste de diffusion) 

Please choose whether HTTPS access is required or optional.
——————————————————————————-
1: Easy – Allow both HTTP and HTTPS access to these sites
2: Secure – Make all requests redirect to secure HTTPS access

Option 1 : vous acceptez de pouvoir accéder à votre nom de domaine à la fois en HTTP ou HTTPS
Option 2 : votre nom de domaine est automatiquement redirigé vers le HTTPS même si vous cherchez à y accéder en HTTP

Si tout s’est bien passé, un nouveau virtual host a été créé dans sites-available avec votredomaine-le-ssl.conf.

Renouvellement automatique du certificat ssl

Un certificat généré par Let’s Encrypt est valide pendant 90 jours. Il faut donc le renouveler tous les 3 mois. Il existe pour cela des scripts qu’on peut ajouter à nos tâches cron.

Pour le renouvellement ça se complique un peu, Let’s Encrypt permet de le faire très bien via la commande :

mais l’objectif n’est pas de renouveler le certificat tous les jours via un cron mais bien de le renouveler lorsque la date d’expiration est inférieure à 45 jours par exemple. Le script proposé par Grafikart disponible sur GitHub, et écrit par Erika Heidi n’est pas compatible avec notre installation debian 8 + apache2 + letsencrypt. Dans notre cas, nous avons dû apporter une petite modification. Voici notre script disponible ici. Pour l’utiliser il faut se mettre avec les droits administrateurs puis le télécharger comme suit :

Le rendre exécutable :

Et enfin le lancer via :

Où domaine.fr correspond à votre nom de domaine. Attention, si vous avez un certificat pour mondomaine.com et un pour www.mondomaine.com, pensez à lancer 2 fois la commande : une fois avec en argument mondomaine.com et une fois en argument www.mondomaine.com. Il est important de mettre le chemin complet vers le script pour le lancer depuis crontab.

Ce script vérifie, pour le nom de domaine passer en paramètres, le délai avant expiration. Si celui-ci est inférieur à 45 jours, il renouvelle le certificat. Dans le cas contraire, il ne fait rien.

Maintenant, libre à vous de mettre en tâches cron, sur la fréquence que vous souhaitez, le lancement de ce script.

Petite astuce : Si on lance via le terminal la commande de let’s encrypt pour le renouvellement de certificat comme ceci :

cela crée un fichier certbot.log dans le répertoire courant. Jusque là pas de souci, mais si par mégarde vous lancez cette commande dans le dossier /etc/apache2/sites-available et que vous essayez de relancer le commande :

Vous obtiendrez une erreur bizarre car cette commande lit le contenu du dossier /etc/apache2/sites-available et rencontrera le fichier certbot.log que la commande n’arrivera pas à parser correctement. Il suffit dans ce cas de déplacer le certbot.log ou de le supprimer et tout rentrera dans l’ordre.

Source :

Auteurs : Matthieu et Julien