infra-ansible issueshttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues2023-09-25T08:12:45Zhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/211Backup de la config pfsense2023-09-25T08:12:45ZHgOBackup de la config pfsenseDe ce que je vois, il y a plusieurs possibilités pour backuper la config des pfsense :
- Le service [AutoBackupconfig](https://docs.netgate.com/pfsense/en/latest/backup/autoconfigbackup.html) permet de backuper facilement la config sur ...De ce que je vois, il y a plusieurs possibilités pour backuper la config des pfsense :
- Le service [AutoBackupconfig](https://docs.netgate.com/pfsense/en/latest/backup/autoconfigbackup.html) permet de backuper facilement la config sur les serveurs de Netgate, en les chiffrant avec AES.
- Récupérer la config via curl ou wget : https://www.provya.com/blog/pfsense-making-automatic-backups-with-a-script/
- Envoyer la config sur un serveur distant en SSH : https://docs.netgate.com/pfsense/en/latest/backup/remote-backup.html
Le risque de la première méthode, c'est d'avoir les serveurs de NetGate qui tombent en panne le jour où on a besoin des backups… Mais ce n'est pas très grave car on a encore les backups Proxmox.
Pour moi, si on met en place deux méthodes (AutoBakcupConfig + envoi de la config sur storage-01), c'est parfait. Mais on peut aussi se contenter d'AutoBackupConfig dans un premier temps.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/202Ajout d'un webhook pour Accounting2023-01-24T17:50:33ZHgOAjout d'un webhook pour AccountingComme suggéré dans !239 ...
Un peu comme on a fait avec le site web de la brique internet, on aurait un webhook qui serait déclenché à chaque merge dans le master.Comme suggéré dans !239 ...
Un peu comme on a fait avec le site web de la brique internet, on aurait un webhook qui serait déclenché à chaque merge dans le master.HgOHgOhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/195Idempotence du port série2022-11-23T20:37:42ZHgOIdempotence du port sérieLa configuration du port série n'est pas idempotente pour les serveurs HP: à chaque exécution du playbook, on lui attribue d'abord le port série 0, puis juste après on le met à 1.
Le problème vient du fait qu'on a la condition `ansible_...La configuration du port série n'est pas idempotente pour les serveurs HP: à chaque exécution du playbook, on lui attribue d'abord le port série 0, puis juste après on le met à 1.
Le problème vient du fait qu'on a la condition `ansible_virtualization_type == "kvm"` pour le port série 0 et qui est aussi valide pour les serveurs HP.
Je me demande également ce qu'il en est pour les VMs qui ne sont pas dans le cluster patata?
Ce serait peut-être plus simple d'avoir une variable pour le port série, qui serait vide par défaut, à 0 pour tous les serveurs présents à LouiseDC, et à 1 pour les 2 serveurs HP?https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/192Installation du vmagent2022-11-03T08:30:06ZHgOInstallation du vmagentA priori cela remplacerait telegraf.
https://victoriametrics.com/blog/proxmox-monitoring-with-dbaas/
À voir s'il faudra installer vmauth également : https://docs.victoriametrics.com/vmauth.htmlA priori cela remplacerait telegraf.
https://victoriametrics.com/blog/proxmox-monitoring-with-dbaas/
À voir s'il faudra installer vmauth également : https://docs.victoriametrics.com/vmauth.htmlhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/185Inclure les playbooks Proxmox et Routinator dans le playbook principal2023-07-17T09:14:11ZHgOInclure les playbooks Proxmox et Routinator dans le playbook principalJ'ai remarqué qu'il manquait les playbooks de Proxmox et Routinator dans le playbook principal. Comme on les utilise peu, il faudrait vérifier si tout est ok avant de les rajouter.J'ai remarqué qu'il manquait les playbooks de Proxmox et Routinator dans le playbook principal. Comme on les utilise peu, il faudrait vérifier si tout est ok avant de les rajouter.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/175Playbook Peering Manager2022-09-03T09:26:04ZHgOPlaybook Peering ManagerComme le nom l'indique, [Peering Manager](https://peering-manager.net/) permet notamment d'automatiser la gestion des demandes de peerings.
L'idée ce serait de l'utiliser en mode inventaire, pour avoir une bonne vue des peerings accepté...Comme le nom l'indique, [Peering Manager](https://peering-manager.net/) permet notamment d'automatiser la gestion des demandes de peerings.
L'idée ce serait de l'utiliser en mode inventaire, pour avoir une bonne vue des peerings acceptés, refusés (avec les raisons du refus), etc.
L'outil peut se coupler à [NetBox](#174) pour s'auto-provisionner, et réciproquement et vice et versa.
Il faut voir comment utiliser l’API dans Ansible pour provisionner les configurations BGP.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/174Playbook Netbox2022-09-03T09:26:05ZHgOPlaybook Netbox[NetBox](https://docs.netbox.dev/en/stable/) est un outil d'inventaire réseau, il pourra servir comme inventaire pour Ansible.
Il existe aussi [un plugin](https://github.com/netdevopsbr/netbox-proxbox) permettant de raccorder Proxmox à...[NetBox](https://docs.netbox.dev/en/stable/) est un outil d'inventaire réseau, il pourra servir comme inventaire pour Ansible.
Il existe aussi [un plugin](https://github.com/netdevopsbr/netbox-proxbox) permettant de raccorder Proxmox à Netbox.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/172À propos de l'url des alertes2022-10-23T15:48:11ZHgOÀ propos de l'url des alertesLorsqu'on reçoit une alerte, dans Matrix par exemple, le lien correspondant à cette alerte est celui par défaut de victoriametrics-alert, càd `http://storage-01.ovh.neutri.net:8880/api/v1/<group id>/<alert id>/status`.
Donc pour que ce ...Lorsqu'on reçoit une alerte, dans Matrix par exemple, le lien correspondant à cette alerte est celui par défaut de victoriametrics-alert, càd `http://storage-01.ovh.neutri.net:8880/api/v1/<group id>/<alert id>/status`.
Donc pour que ce soit plus joli, il faudrait rajouter le paramètre `-external.url` et peut-être aussi jouer avec `-external.alert.source` si ça ne marche pas (voir aussi https://github.com/VictoriaMetrics/VictoriaMetrics/issues/517). Il faudra faire en sorte que HAProxy pointe d'une manière ou d'une autre vers le service victoriametrics-alert, qui écoute sur localhost:8880.
Cela dit, l'url correctement configurée donne accès à un json, donc je ne sais pas si c'est très intéressant :
![image](/uploads/47e6b61bf114b42e1c129330e9ba92db/image.png)https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/165Alertes lorsqu'un des clusters Ceph est cassé2022-10-23T15:48:12ZHgOAlertes lorsqu'un des clusters Ceph est cassé- [ ] Avoir une alerte pour le cluster Ceph S3
- [ ] Avoir une alerte pour le cluster Ceph des Proxmox- [ ] Avoir une alerte pour le cluster Ceph S3
- [ ] Avoir une alerte pour le cluster Ceph des Proxmoxhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/152Version tracker2022-04-20T18:05:59ZHgOVersion trackerhttps://release-monitoring.org/
Il faudrait pouvoir être notifié quand une nouvelle version d'un des outils qu'on utilise est publiée:
- Mattermost
- Matterbridge
- Hedgedoc
- Matrix GO NEB ? pas vraiment de version
- Dokuwiki
- Grav
- ...https://release-monitoring.org/
Il faudrait pouvoir être notifié quand une nouvelle version d'un des outils qu'on utilise est publiée:
- Mattermost
- Matterbridge
- Hedgedoc
- Matrix GO NEB ? pas vraiment de version
- Dokuwiki
- Grav
- Nextcloud
- Prometheus
- Alertmanagerhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/150Envoi des alertes par SMS2022-10-23T15:48:12ZHgOEnvoi des alertes par SMShttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/148Migration de la VM vpn vers buster2023-04-07T20:47:28ZHgOMigration de la VM vpn vers busterOn ne pourra pas aller jusque bullseye parce que ISPng ne le supporterait pas.
Dans bullseye, le serveur openvpn est en v2.5, et l'API de management change dans cette version (ISP-ng ne supporte openvpn que jusqu'à la version 2.4.x). Il...On ne pourra pas aller jusque bullseye parce que ISPng ne le supporterait pas.
Dans bullseye, le serveur openvpn est en v2.5, et l'API de management change dans cette version (ISP-ng ne supporte openvpn que jusqu'à la version 2.4.x). Il faudrait donc adapter ISP-ng en conséquence... sauf qu'on n'a pas tout le code source, à l'époque certains changements ont été fait en local.
Bref, si un jour on veut passer en bullseye, il faudra réécrire ISP-ng ou retrouver les morceaux de code perdus.HgOHgOhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/146Playbook Loki2022-01-29T15:03:32ZHgOPlaybook Lokihttps://grafana.com/oss/loki/
Pour monitorer les logshttps://grafana.com/oss/loki/
Pour monitorer les logshttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/143Supprimer les anciennes versions de Hedgedoc2022-01-25T22:49:20ZHgOSupprimer les anciennes versions de HedgedocComme on télécharge chaque version depuis Github, celles-ci vont s'accumuler sur le serveur.
Il faudrait garder quelque chose comme les 5 dernières versions (voir aussi ce qu'on a fait pour Mattermost)Comme on télécharge chaque version depuis Github, celles-ci vont s'accumuler sur le serveur.
Il faudrait garder quelque chose comme les 5 dernières versions (voir aussi ce qu'on a fait pour Mattermost)https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/92Simplifier la config systemd de hedgedoc2021-10-03T08:26:47ZHgOSimplifier la config systemd de hedgedocVoir la discussion dans !100Voir la discussion dans !100https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/75Logguer la dernière exécution d'un playbook sur les serveurs2022-10-24T00:00:00ZHgOLogguer la dernière exécution d'un playbook sur les serveursAvoir un moyen de savoir facilement quand a été lancé un playbook pour la dernière fois.
Cela peut être les logs du playbook ou simplement la date de dernière exécution.
Idéalement, permettre d'en extraire une metrics pour le monitoring.Avoir un moyen de savoir facilement quand a été lancé un playbook pour la dernière fois.
Cela peut être les logs du playbook ou simplement la date de dernière exécution.
Idéalement, permettre d'en extraire une metrics pour le monitoring.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/74Documenter nos conventions2022-10-24T00:00:00ZHgODocumenter nos conventions- [ ] Vaults
- [ ] Variables (dict vs prefix, recopier les defaults dans l'inventaire)
- [ ] autres ?- [ ] Vaults
- [ ] Variables (dict vs prefix, recopier les defaults dans l'inventaire)
- [ ] autres ?https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/71Pages d'erreur custom2021-08-22T21:05:27ZHgOPages d'erreur customAvoir deux pages d'erreur légèrement différentes :
- [ ] Caddy
- [x] HAProxyAvoir deux pages d'erreur légèrement différentes :
- [ ] Caddy
- [x] HAProxyhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/39Documentation pour molecule2022-10-23T23:59:59ZHgODocumentation pour moleculeHgOHgOhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/24Séparation entre rôles systèmes et rôles applicatifs2022-10-24T00:00:00ZHgOSéparation entre rôles systèmes et rôles applicatifsCommentaire de @Tharyrok :
> Je trouve que le rôle nexcloud fait beaucoup trop de chose. Pour moi, il serait plus intéressant de séparer l'installation de brique système (postgresql, redis, ...) dans des role séparée. Je me demande s'il ...Commentaire de @Tharyrok :
> Je trouve que le rôle nexcloud fait beaucoup trop de chose. Pour moi, il serait plus intéressant de séparer l'installation de brique système (postgresql, redis, ...) dans des role séparée. Je me demande s'il n’est pas judicieux de soit préfixer les rôles soit le mettre dans 2 dossiers différant pour distinguer les rôles "système" et les rôles "application". Pour moi, un rôle "système" est autonome et un rôle "application" inclus les rôles "système".