Pensées Libres dans un Monde Binaire
Petit pense-bête, pour éviter de perdre plusieurs dizaines de minutes à retrouver la liste des valeurs possibles pour la variable ansible_os_family dans ansible, après plusieurs semaines ou mois sans pratiquer.
La liste est par là:
ansible/ansible/module_utils/facts/system/distribution.py#L511
De temps en temps, j’ai besoin de cloner l’un de mes dépôts GitHub, vers un poste de travail sur lequel je ne souhaite pas ou ne peut pas utiliser ma clef SSH pour réaliser l’opération. Dans ces cas là, je passe par la génération d’un token via Settings > Developer settings > Personal access tokens > Fined-grained tokens, auquel je ne n’assigne que l’autorisation « Content » avec « Read and Write », sur le dépôt concerné.
Avec une validité maximum d’un an, la sélection des dépôts concernés et une sélection minimale des permissions, je réduit ainsi grandement la surface d’exposition de mes dépôts. Une fois en possession du token généré, vient ensuite le moment de cloner le dépôt via git. Pour mémoire, voici la syntaxe à utiliser, par exemple, pour cloner mon dépôt yt-auto-dark:
git clone https://oauth2:<token>@github.com/vvision/yt-auto-dark.gitVoilà pour l’aide-mémoire.
Seul bémol de la solution, n’importe qui ayant accès au dépôt cloné pourra effectuer des modifications pendant toute la durée de validité du token, ou jusqu’à ce que ce dernier soit révoqué. A ne pas utiliser n’importe comment, n’importe où donc. En sacrifiant un peu de simplicité (et encore) et en fonction de l’environnement, on pourra préférer la génération d’une clef SSH spécifique à la machine, auquel on veillera bien à associer une pass phrase de qualité. On aura alors accès à tous nos dépôts, mais il faudra penser nous-même à retirer la clef des clefs autorisées lors de la décommission de la machine utilisée.
Bref, plusieurs solutions possibles en fonction des besoins et des environnements, à choisir en connaissance de cause.
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):
Pour les navigateurs:
Sur ces quelques chiffres, amis lecteurs, bonne nuit !
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é.
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