{{indexmenu_n>20}} ## Trucs à faire les soirs d'ennuis 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 ! 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. 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 ### Mise à jour des machines virtuelles De temps en temps, passer sur toutes les machines virtuelles et les mettre à jour : ``` apt update apt full-upgrade ``` 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 : * https://alice.picasoft.net:8006 pour Alice * https://bob.picasoft.net:8006 pour Bob * https://caribou.picasoft.net:8006 pour Caribou Les identifiants sont sur le [[asso:tuto:vaultwarden|vaultwarden]] (utilisateur `root`). ### Mise à jour des hyperviseurs 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](https://pve.proxmox.com/wiki/Roadmap), on voit si c'est important pour nous de mettre à jour, et si oui, on la planifie avec l'équipe technique. ### Mise à jour des services 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. Et concrètement ? Une méthode : * On prend les [[technique:graph_services|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 [[technique:docker:picasoft:dockerfiles|dépôt]] associé au service * Dans tous les cas, on construit la nouvelle image et on la pousse sur le registre ([[technique:docker:picasoft:update|voir doc de mise à jour]]) * Et on le relance ! Astuce : on peut utiliser le [[technique:adminsys:secu:services_updates|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. ### Vérifier le serveur mail Le brave serveur mail est un service délicat. De temps en temps, c'est très utile de : * [[technique:adminsys:mail:maintenance:logs|Vérifier ses logs]] * [[technique:adminsys:mail:maintenance:dmarc_reports|Vérifier les rapports DMARC]] On pourra ainsi détecter rapidement un problème de blacklist. Il n'est pas prévu de faire ça automatiquement. ### Vérifier la santé des machines Un petit tour sur le [[technique:adminsys:monitoring:metrologie:grafana|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. Même si de [[technique:adminsys:monitoring:alerting:start|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é... ### Vérifier les backups Tu veux une histoire rigolote ? Tu peux aller lire [[technique:incidents:incident-18-11-2020|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 [[technique:infrastructure:backup|expliqué ici]]. * Les backups des bases de données, des volumes, des secrets et de la configuration des machines, gérés par restic, comme [[technique:adminsys:backup:start|expliqué ici]]. 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. ### Nettoyer de l'espace disque Docker COMMENT ?! DOCKER PREND DE LA PLACE ?? Pas mal. [[technique:docker:admin:nettoyer_docker|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é... ### Vérifier les certificats TLS Docker Tout est [[technique:docker:admin:socket-certs|expliqué ici]]. Les certificats générés sont valables un an, il faut les vérifier à un moment... Un bon moyen de vérifier, c'est de regarder la date des [[technique:graph_services|graphes des services]]. Si ce n'est pas hier, alors il y a un souci, et c'est probablement un certificat expiré. ### Vérifier que la zone DNS va bien Avec l'incroyable outil Zonemaster, comme expliqué sur [[technique:adminsys:dns:check_zone|cette page]]. ### Vérifier les permissions d'accès Ç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 [[technique:adminsys:ldap:start|LDAP]] et les comptes existants. * Le [Gitlab](https://gitlab.utc.fr/picasoft/) et les membres du groupe `Picasoft`. * Le [[asso:tuto:vaultwarden|vaultwarden]] et les clés pour lesquelles sont chiffrées les identifiants. ### Renouvellement des mots de passe critiques [[asso:administratif:registre|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 [[asso:tuto:vaultwarden|vaultwarden 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. 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 ### Maintenir la documentation 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. 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. 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. ### Mater les *issues* des services Si tu es arrivé·e jusque là et que rien ne te tente, il reste toujours les *issues* abandonnées sur Gitlab ! [Toutes les issues](https://gitlab.utc.fr/groups/picasoft/projets/-/issues) ### Lancer une idée Et si on arrêtait Docker ? Et si on faisait fonctionner nos serveurs au solaire ? Et si on diffusait des semences libres de tomates ? Toute idée est bonne à prendre.