Tu es membre de l’équipe technique de Picasoft, et tu t’ennuies ? Tu as super envie de faire quelque chose, mais surtout pas quelque chose d’excitant ?

Tu as envie de vérifications de routines, d’opérations de maintenance et autres joyeusetés ?

Cette page est faite pour toi !

Note:

Plus sérieusement, il y a des vérifications/mises à jour à faire de temps en temps, elles sont listées ici. Comme il n’y a pas de responsable technique, elles sont effectuées selon le temps et la bonne volonté de chacun·e.

Important:

Vraiment sérieusement, il faut quand même que ce soit fait de temps en temps. Ne pas hésiter à pinger l’équipe technique pour le rappeler, même si tu n’as pas le temps. :-D

De temps en temps, passer sur toutes les machines virtuelles et les mettre à jour :

apt update
apt full-upgrade

Attention:

Si les mises à jour installent un nouveau noyau, on redémarre la VM pour en profiter. Il vaut mieux faire ces mises à jour dans la nuit, avec un sweat à capuche et dans le noir complet, afin d’optimiser ses chances de réussite. Prévoir un backup et prévenir l’équipe technique pour éviter la panique.

Pour redémarrer les VM, on peut se servir de l’interface graphique de Proxmox :

Les identifiants sont sur le pass (utilisateur root).

Important:

Si ça foire, c’est chaud, parce qu’on parle des machines physiques, qui ont les vraies données sur les vrais disques dur.

On réserve cette opération à la sortie d’une mise à jour majeure ou de sécurité importante de Proxmox.

Pour ce faire, on consulte régulièrement le changelog de Proxmox, on voit si c’est important pour nous de mettre à jour, et si oui, on la planifie avec l’équipe technique.

Une petite comparaison de ce qui tourne en production avec les nouvelles versions des logiciels. En général, on regarde souvent les services publics (Mattermost, Etherpad, Wekan).

Les services internes (LDAP, serveur mail…) sont souvent oubliés. Pourtant, c’est important de reconstruire les images régulièrement, même si le logiciel en tant que tel n’a pas été mis à jour. En effet, on profite des dernières mises à jour des images de base (par exemple Debian), et donc des mises à jour de sécurité des paquets qui n’ont rien à voir avec le service.

Question:

Et concrètement ?

Une méthode :

  • On prend les graphes des services pour savoir ce qui tourne
  • On choisit un service à mettre à jour
  • Si une nouvelle version est sortie, on met à jour les fichiers sur le dépôt associé au service
  • Dans tous les cas, on construit la nouvelle image et on la pousse sur le registre (voir doc de mise à jour)
  • Et on le relance !

Note:

Astuce : on peut utiliser le bot des mises à jour qui poste des messages sur Mattermost à chaque nouvelle release d’un service. Sur Mattermost, on tapera :

in:team-technique from:maj_bot

dans la recherche pour trouver les plus récents messages de ce bot.

Le brave serveur mail est un service délicat. De temps en temps, c’est très utile de :

On pourra ainsi détecter rapidement un problème de blacklist. Il n’est pas prévu de faire ça automatiquement.

Un petit tour sur le Grafana de Picasoft donne accès à tout plein de graphes. Les plus intéressants en ce qui nous concerne sont :

  • Les métriques système des VM et des hyperviseurs
  • Les métriques Proxmox
  • Les métriques réseau

On pourra ainsi vérifier que les disques n’explosent pas, que le CPU n’est pas en train de ployer sous 15.000 pads, etc.

Note:

Même si de l'alerting est mis en place, c’est une bonne idée d’aller voir manuellement de temps en temps. Si ça se trouve, l’alerting est cassé…

Question:

Tu veux une histoire rigolote ?

Tu peux aller lire cet incident, où des données de production ont failli être perdues définitivement à cause de backups défaillants depuis un mois, sans qu’on s’en rende compte.

Les backups, c’est franchement vital pour l’infrastructure. Il existe deux types de backups :

  • Les backups de machines virtuelles, gérés par Proxmox, comme expliqué ici.
  • Les backups des bases de données, gérés par un script ad-hoc, comme expliqué ici.

Note:

Et bientôt, les backups des volumes Docker…

Dans les deux cas, on peut vérifier que tout fonctionne bien en allant inspecter les dossiers où se trouvent les backups, en regardant leur heure, leur taille, etc. Ça évitera les mauvaises surprises.

Question:

COMMENT ?! DOCKER PREND DE LA PLACE ??

Pas mal. Cette page de wiki explique comment nettoyer les ressources qui ne sont pas utilisées. À utiliser prudemment tout de même sur les machines de production ; bien vérifier que tout ce qui doit être allumé est allumé…

Tout est expliqué ici. Les certificats générés sont valables un an, il faut les vérifier à un moment…

Note:

Un bon moyen de vérifier, c’est de regarder la date des graphes des services. Si ce n’est pas hier, alors il y a un souci, et c’est probablement un certificat expiré.

Avec l’incroyable outil Zonemaster, comme expliqué sur cette page.

Ça c’est la partie pas super rigolote, on va vérifier qu’on a pas des vieux accès qui traînent. Parce que faut pas rigoler non plus, l’accès aux machines donne accès à des données personnelles (messages Mattermost, pads, etc), et sont autant de risques de sécurité.

On regardera donc de temps en temps :

  • Le LDAP et les comptes existants.
  • Le Gitlab et les membres du groupe Picasoft.
  • Le pass et les clés pour lesquelles sont chiffrées les identifiants.

Le règlement intérieur prévoit que l’on change tous nos identifiants critiques chaque semestre. Concrètement, ce sont les mots de passe root des machines, les mots de passes d’administration des services…

Ils se trouvent tous dans le pass de Picasoft.

L’idée est de déterminer les mots de passe critiques, les changer (passwd, fichier de conf…), puis les mettre à jour dans le pass.

Important:

On est d’accord, c’est sans doute le truc le moins sexy de cette page, mais un mot de passe root compromis, par exemple d’Alice ou Bob, c’est littéralement toute l’infra de compromise. Donc, si on a la flemme, au moins les mots de passe root. :-P

Globalement, à chaque changement sur l’infrastructure où tu es le/la seul·e à être au courant, il est préférable de mettre à jour le wiki. L’idée du wiki est essentiellement : si toute l’équipe technique passe sous un bus demain, n’importe qui peut reprendre l’infrastructure en lisant bien le wiki. C’est un peu exagéré mais c’est l’idée.

Important:

Même si ça n’a pas toujours été le cas par le passé, il est donc une bonne pratique de ne rien déployer en production si cela n’a pas été correctement documenté sur le Wiki.

Note:

Documenter des trucs d’adminsys, ça paraît pas super sexy, mais ça permet de vérifier qu’on a compris en tentant d’expliquer aux autres, de généraliser un cas particulier, etc. C’est utile pour tout le monde!

Dans une association à fort turn-over comme Picasoft, la documentation technique est essentielle. En fait, elle est même vitale. Déployer et maintenir des services sur une infrastructure comme celle de Picasoft ne peut pas se faire sans documentation lorsque l’on arrive dans l’association.

Si tu es arrivé·e jusque là et que rien ne te tente, il reste toujours les issues abandonnées sur Gitlab !

Question:

Et si on arrêtait Docker ?

Question:

Et si on faisait fonctionner nos serveurs au solaire ?

Question:

Et si on diffusait des semences libres de tomates ?

Toute idée est bonne à prendre.

  • technique/tips/todo_adminsys.txt
  • de ppom