Neutrinet issueshttps://gitlab.domainepublic.net/groups/Neutrinet/-/issues2020-02-16T14:35:50Zhttps://gitlab.domainepublic.net/Neutrinet/vpn/ISP-ng/-/issues/17Ability to change user password2020-02-16T14:35:50ZTharyrokAbility to change user password*Created by: wannes-ds*
*Created by: wannes-ds*
0.1 Releasehttps://gitlab.domainepublic.net/Neutrinet/vpn/ISP-ng/-/issues/13Self-host static files.2020-02-16T14:36:21ZTharyrokSelf-host static files.*Created by: Psycojoker*
It's not the first time that I've had this request.
*Created by: Psycojoker*
It's not the first time that I've had this request.
0.1 Releasehttps://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/33Make the hotspot install optional2020-05-09T16:00:31ZHgOMake the hotspot install optionalWhen [the PR on Github is merged](https://github.com/labriqueinternet/build.labriqueinter.net/pull/69), the hotspot install will be optional in the hypercube script.
The install could be disabled with the following setting in the hyper...When [the PR on Github is merged](https://github.com/labriqueinternet/build.labriqueinter.net/pull/69), the hotspot install will be optional in the hypercube script.
The install could be disabled with the following setting in the hypercube file:
```json
"hotspot": {
"enabled": false,
...
}
```Install Party 17/05/2020sohkasohkahttps://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/30Explain where to register a VPN account or renew certificates2020-05-09T13:37:56ZHgOExplain where to register a VPN account or renew certificatesCurrently, the documentation doesn't explain where one could register a VPN account or renew their certificatesCurrently, the documentation doesn't explain where one could register a VPN account or renew their certificatesInstall Party 17/05/2020https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/34Yunohost app list migration2020-05-16T13:02:27ZHgOYunohost app list migrationAlex from Yunohost told us (@ilja and I) that the release of Yunohost 3.8 would make some breaking changes on how the package lists are managed. In short, it won't be possible to manage a custom app list from the web interface or from th...Alex from Yunohost told us (@ilja and I) that the release of Yunohost 3.8 would make some breaking changes on how the package lists are managed. In short, it won't be possible to manage a custom app list from the web interface or from the cli. The custom app lists that are currently installed on cubes will be removed.
Here is what Alex told us:
> 1. The thing is that there's a big refactoring to the app list management in 3.8 ... Mostly to integrate app categories (which required a change in the way we fetch app list) and because I got fed up of the underlying code that was a total mess.
>
> 2. Also the "multiple app catalog" seemed like a big YAGNI after complaining so many times about it ended up removing it because nobody seemed to use it. It's still available but requires to manually add a line in a .yml file in /etc/yunohost/.
>
> 3. Yunohost is also more and more discouraging user to install "bad quality" apps (c.f. the level key in the json app catalog). In particular anything below level 4 is considered bad quality. I think that's already the case in 3.7 ?
>
>
> Anyway, as said a lot of things would be simplified (well, requires a bit of work but I can help) if :
> - neutrinet_ynh goes into the "official" app catalog
> - but that also means that neutrinet will be tested on the app CI, and it should be level 4 to be easily installable in the app list (otherwise users gotta ask to see 'all apps and not just decent quality' ones)
> - we can run some tests about the package on our dev ci to see what level it goes up to
> - but I can already say that our package_linter.py will block level 4 currently. There are some errors that are easy to fix. Warnings won't block level 4 but ideally they should still be taken care of as much as possible ...
> - it would help if the main branch you work on is "master" (or an alias can be created to stable, idk)
> - once everything is done, you're still independant in the management of the app (nothing to push on apps.json), the only thing that changes is that the CI may warn you about failing tests
>
> (hopefully this makes some sense)
## Questions
It followed some questions from our part.
### What exactly do you mean with the "multiple app catalog"?
The "Custom applications list"
Because of the breaking changes required by 3.8 to have app categories, the format of the apps.json changes.
And because it was assumed that nobody was using custom app list anymore (e.g. La Brique was doing so in the past but not anymore) the 3.8 will agressively resets the app list to just keep Yunohost's default app list ... Now that I think about it and that I found somebody using that system, I could try to implement some compatibility mode for older app lists format but meh...
### We started using a [dev list for testing purpose](https://apps.neutrinet.be/unstable.json). What is the workflow for testing within the official app list?
The usual practice is to tell people to install or upgrade using the testing branch. C.f. an example here for nextcloud : https://github.com/YunoHost-apps/nextcloud_ynh#developers-infos (notice the /tree/testing at the end). Looking at the code in the core, same thing should also work for non-github repo (even though the url goes nowhevere, it's just a quick-and-dirty parsing)
### As you know, we are using a Gitlab repo, with a mirror to Github. Could we keep working on Gitlab, or is Github required to work with the list?
No worries, any git[whatever] is okay as long as repo can be cloned. There already are a couple of apps hosted on framagit or other forges in the list 😉 . You're free to choose to put the gitlab url or github url in the list.
### We were thinking about using the CI tool provided by Ynh, so that's good :) Do we need to write tests somehow? How is it working?
I'll start a test on the dev CI to see how that looks. (Btw you can probably ask Maniack for an access too, just need an SSH key, c.f. https://yunohost.org/#/packaging_apps_ci )
I think by default it magically finds some dummy default values to use ... But usually project set up a "check_process" file in the repo. The syntax is a bit funky but for example you can look at : https://github.com/YunoHost-Apps/anarchism_ynh/blob/testing/check_process (or any other app that has this file). I see that neutrinet_ynh only ask for a domain + path so maybe not even needed ? Full doc is here : https://github.com/YunoHost/package_check#syntax-of-check_process
### For when is planned the 3.8? In other words, how much time do we have?
There are many fixes to do, at least another testing iteration to validate everything, so would say a good 2~3 weeks.
### Is it still possible to add a custom app list?
Adding a custom list now would look like:
```shell
echo "- id: neutrinet
url: https://.../neutrinet_ynh_list" >> /etc/yunohost/apps_catalog.yml
```
(assuming the actual json is at https://.../neutrinet_ynh_list/v2/apps/json)
Then `yunohost tools update --apps` to refresh the app catalogs cache.
If you wish to build and maintain your own app list, you can have a look at: https://github.com/YunoHost/apps/
Basically you "just" need a cron job that calls rebuild.sh, itself calling list_builder.py
Maybe just a few things to tweak for everything to be smooth on your side
### What will happen with the instances that already have the applist?
The applists will be gone completely, which means you'll have to figure out a way to get the applist back (or better, the new applist in).
The big question is how to properly handle the upgrade so that everything stays consistent... We could also just have some ad-hoc piece of code in Yunohost that says "if there's the neutrinet list, replace it with the new neutrinet list"
### Is it possible to just change our applist to the newer format?
Note that you need to keep serving both the old version and the new version (it's what we already do as you can notice in https://app.yunohost.org/ ... apps.json is the current version (pre-3.8) and default/v2/apps,json is the new version (post 3.8)
In fact you could generate the new version easily by adding a top-level "apps:" key and an empty "categories:" key ... which is easier on the short-term. But on the long-term it might be worth to setup a real list_builder.py + cron job if we do improvements or other migrations in the future...
Also there's in fact a yunohost app to setup the app list system (yup, appception) : https://github.com/YunoHost-Apps/app_ynh_core but I recently yolo-commited without testing, but that can be used as partial doc :/
## Concerns
The question is whether it's easier/better for us to move to the official app list, or still keep our own.
We formulated some concerns to Alex:
- On not allowing custom app-lists:
Although we understand not wanting people to think badly of ynh based on some bad apps that aren't even really part of the project, and we even think that's a valid concern! But this is also a step towards centralization and we dislike that on principle alone... Ynh is already too depended on central services (github, but also things like ip.yunohost.org...), removing the possibility for custom applists just adds to that I think. But that's maybe not relevant here...
- On timing and on the breaking change itself:
There are ynh instances out there with this app list, these should not break. For us this wouldn't be too much of a problem, there aren't big changes planned for the app (we recently did a whole rewrite, but things should be more stable now)
- On the removal of custom app lists already installed:
We COULD add the list back from the app, but if people upgrade ynh before they can upgrade the app then that's a problem...
- On the CI tool:
The app needs an installed and working VPN, so the CI tool might fail (which doesn't mean the app is uninstallable)
## Decision
We asked on [Mattermost](https://chat.neutrinet.be/neutrinet/pl/wmcr9m5u77gixno8inoyg7fi6y) what should we do. The current consensus is (but this could still change ofc):
> The saner approach would be to move to the Yunohost app list. Maintaining a whole list for only one app is quite overkill... Later, if we feel like it, we could upgrade our old list to make it compliant with the new app list system and move back in our own app list.Install Party 21/06/2019https://gitlab.domainepublic.net/Neutrinet/accounting/-/issues/4Faire en sorte que accounting se déploie automagiquement avec un pipeline2023-12-02T10:56:47ZHgOFaire en sorte que accounting se déploie automagiquement avec un pipelineHgOHgOhttps://gitlab.domainepublic.net/Neutrinet/accounting/-/issues/3Affichage des mouvements en json2023-08-30T16:57:16ZHgOAffichage des mouvements en jsonEst-ce que ce serait possible d'avoir un endpoint qui affiche les mouvements au format json?
Comme ça on pourrait afficher des beaux graphes sur le site web, si un jour on a le temps de le faire :p
Par exemple, quelque chose comme ça:
...Est-ce que ce serait possible d'avoir un endpoint qui affiche les mouvements au format json?
Comme ça on pourrait afficher des beaux graphes sur le site web, si un jour on a le temps de le faire :p
Par exemple, quelque chose comme ça:
```
> curl "https://accounting.neutrinet.be/movements?year=2023&format=json"
[
{"number": 1, "date": "2023/01/01", "amount": 4.0, "type": "donation"},
...
]
```https://gitlab.domainepublic.net/Neutrinet/matrix-alertbot/-/issues/10Permettre plusieurs comptes matrix2024-01-22T10:29:26ZHgOPermettre plusieurs comptes matrixPermettre au bot de se connecter à des comptes matrix de secours, donc sur des serveurs différents, pour éviter d'être coincé parce que le serveur matrix est en panne.
En règle générale, il y aura un compte principal, et si le serveur e...Permettre au bot de se connecter à des comptes matrix de secours, donc sur des serveurs différents, pour éviter d'être coincé parce que le serveur matrix est en panne.
En règle générale, il y aura un compte principal, et si le serveur est down, le bot envoie les alertes sur le second serveur, et ainsi de suite.HgOHgOhttps://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/matrix-alertbot/-/issues/7Tester le module main2022-10-26T17:04:31ZHgOTester le module mainC'est assez critique parce que c'est là que ce fait le login notamment et la gestion des exceptions, notamment.C'est assez critique parce que c'est là que ce fait le login notamment et la gestion des exceptions, notamment.https://gitlab.domainepublic.net/Neutrinet/matrix-alertbot/-/issues/6Documenter les fonctions2022-10-29T16:13:50ZHgODocumenter les fonctionsLa plupart des fonctions ne sont pas documentées, ou alors ce sont juste des copiés/collés d'autres fonctions...
Peut-être voir du côté de `sphinx` pour automatiser un peu tout ça ?La plupart des fonctions ne sont pas documentées, ou alors ce sont juste des copiés/collés d'autres fonctions...
Peut-être voir du côté de `sphinx` pour automatiser un peu tout ça ?https://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
- Alertmanager