En passant

De retour chez OVH

Article du samedi soir qui devrait rester court, simplement pour informer qu’Unicoda est de retour chez OVH depuis quelques heures. Cette fois, le serveur s’éloigne de moi de plusieurs centaines de kilomètres, alors qu’il était longtemps à moins de 15 kilomètres de mon domicile. Bref, retour en France, après un court passage chez Hetzner à Falkenstein en Allemagne. Tout a l’air de bien fonctionner. Vérification demain matin que le processus de sauvegarde quotidien s’est exécuté comme prévu et avec succès.

Au passage, j’en ai profité pour ajouter une sauvegarde distante supplémentaire. Le site est donc à présent sauvegardé vers deux services de stockage différents: Backblaze B2 (déjà évoqué ici) et désormais également dans le Cloud IBM. Je suivrai les sauvegardes vers ce nouveau dépôt dans les prochains jours afin de valider définitivement son bon fonctionnement.

J’ai profité de cette nouvelle migration pour jeter un œil du côté des logs Apache, pour la journée du 19 mars, en utilisant GoAccess, découvert pour l’occasion, et qui permet d’avoir quelques données agrégées directement accessible dans le terminal. Je note au passage l’option --ignore-crawlers permettant de filtrer les robots et autres bots. Difficile par contre de se faire une idée précise du nombre de lecteurs quotidiens, mais le flux RSS semble être appelé régulièrement: tant mieux !

C’est vraiment un point que je souhaite améliorer, à savoir la surveillance du serveur, en termes d’utilisation de ressources et d’analyse du trafic. Loin de moi l’idée de mettre en place du Google Analytics, mais quelque chose basé sur l’analyse des logs Apache devrait suffire et permettre, par exemple sur une durée d’un mois, de distinguer le trafic « réel », du trafic des bots, crawlers et autres spammers automatisés, et de savoir comment se comporte le serveur.

Pour finir, quelques données en vrac concernant les proportions de chaque système d’exploitation et les navigateurs pour cette journée du 19 mars. Pour les systèmes d’exploitation, je note environ (arrondi à la valeur inférieure):

  • 36% Windows
  • 25% GNU/Linux
  • 18% Android
  • 11% Macintosh
  • 1% iOS

Pour les navigateurs:

  • 37% Chrome
  • 26% Firefox
  • 19% Safari
  • 2% MSIE

Sur ces quelques chiffres, amis lecteurs, bonne nuit !

Suppression sécurisée

Ayant résilié la location d’une machine virtuelle chez OVH le mois dernier, j’ai procédé à un petit nettoyage des données avant de rendre la machine. La suppression sécurisée s’effectue avec shred, combiné avec find pour effacer plus simplement une arborescence de fichiers (shred ne traite que des fichiers, pas les dossiers).

sudo find /path/to/dir -type f -exec shred -zu {} +;

On supprime ensuite le répertoire avec un traditionnel rm -rf et le tour est joué.

Déterminer la version d’Apache

Suite à l’annonce récente de multiples vulnérabilités dans Apache server (CERTFR-2020-AVI-490), je souhaitais vérifier la version d’Apache installée. Vu que j’essaye à chaque fois un --version sans succès, voici pour référence, les deux commandes possibles (2e non testée).

 apachectl -v

Ou encore :

httpd -v

acme.sh en mode test

Petite note, pour mettre en avant l’option test de acme.sh, qui permet d’envoyer toutes les requêtes d’obtention d’un certificat Let’s Encrypt vers les serveurs de test, et non vers ceux de production. Incontournable lorsque l’on teste l’exécution de scripts de déploiement automatique et que l’on se retrouve à demander plusieurs fois un certificat wildcard dans la même journée, pour un même domaine, et que l’on atteint de ce fait les limites en nombre de création/renouvellement du service.

--test

Une autre solution, si l’on se contente de relancer le script de déploiement plusieurs fois, après avoir corrigé les étapes en erreur et sans reprendre le déploiement sur une machine vierge, consiste à vérifier l’absence des fichiers de certificats avant de faire une nouvelle demande de certificat.

Source: Acme.sh supports ACME v2 wildcard now

[Note de service] Migration

Unicoda migre vers un nouveau serveur. En théorie, le changement devrait être transparent pour les lecteurs, le script de réinstallation s’étant exécuté sans erreur et puisque j’écris depuis la nouvelle instance. Cette nouvelle instance deviendra progressivement accessible avec la propagation de la nouvelle version de la zone DNS.

Si vous lisez ce texte, vous accédez donc bien à la nouvelle instance !