Neutrinet issueshttps://gitlab.domainepublic.net/groups/Neutrinet/-/issues2021-10-03T08:26:47Zhttps://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".https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/15Playbook Keycloak2022-01-29T15:07:50ZHgOPlaybook KeycloakPlaybook pour installer un keycloak en HA
La configuration du SSO fera l'objet d'un NeutritonPlaybook pour installer un keycloak en HA
La configuration du SSO fera l'objet d'un Neutritonhttps://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/14Rôle relay smtp2021-05-04T17:12:02ZHgORôle relay smtpRôle permettant à une machine d'envoyer des mails via un serveur SMTP distant
Par exemple, en installant un `postfix` configuré en MTA (mail transfert agent)Rôle permettant à une machine d'envoyer des mails via un serveur SMTP distant
Par exemple, en installant un `postfix` configuré en MTA (mail transfert agent)https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/9Create an Ansible playbook to install Discourse2021-01-17T20:17:56ZHgOCreate an Ansible playbook to install DiscourseWe want to manage the Discourse install with Ansible.
We should be able to configure Discourse with :
- list of plugins
- upgrades channel (stable, tests-passed, ...)
- smtp parameters
- database parameters (local or remote?)
Discourse...We want to manage the Discourse install with Ansible.
We should be able to configure Discourse with :
- list of plugins
- upgrades channel (stable, tests-passed, ...)
- smtp parameters
- database parameters (local or remote?)
Discourse should be behind a reverse proxy such as Nginx, that way we can display maintenance pages.
Because Discourse upgrades are managed through the admin panel, there is no need to support this for now.https://gitlab.domainepublic.net/Neutrinet/infra-ansible/-/issues/8Fine-grained users and SSH keys management2021-01-16T18:52:58ZHgOFine-grained users and SSH keys managementWe want to be able to create users on certain hosts or groups.
We should be able to define the user's groups (e.g. if the user is part of sudoers), the user's status (present / absent), and of course their SSH public keys.
In the Ansib...We want to be able to create users on certain hosts or groups.
We should be able to define the user's groups (e.g. if the user is part of sudoers), the user's status (present / absent), and of course their SSH public keys.
In the Ansible structure, the user's SSH keys are stored inside a repository. This repository also contains a `main.yml` config file with the list of groups and the user's status.HgOHgOhttps://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/39Depreciation of yunocube scripts2020-12-12T17:00:33ZHgODepreciation of yunocube scriptsApparently, La Brique Internet will change the way they build the images. Instead of [a script that builds a Yunohost image](https://github.com/labriqueinternet/build.labriqueinter.net), they will provide their own image : https://github...Apparently, La Brique Internet will change the way they build the images. Instead of [a script that builds a Yunohost image](https://github.com/labriqueinternet/build.labriqueinter.net), they will provide their own image : https://github.com/YunoHost/arm-images
I'm not sure what's the status of this project, or when would the yunocube scripts become obsolete...
But I think we should have a look on this as this could affect our own script.
According to these [PR comments](https://github.com/labriqueinternet/build.labriqueinter.net/pull/70#issuecomment-623019265), we could get more information this Monday.https://gitlab.domainepublic.net/Neutrinet/neutrinet_ynh/-/issues/24Generate dummy VPN certificate for testing2022-01-14T21:34:01ZHgOGenerate dummy VPN certificate for testingThe Yunohost CI cannot run the renew script, as the openvpn client is not installed in the test environment.
The script is reading credentials from `/etc/openvpn/keys/credentials`, and the public certificate from `/etc/openvpn/keys/use...The Yunohost CI cannot run the renew script, as the openvpn client is not installed in the test environment.
The script is reading credentials from `/etc/openvpn/keys/credentials`, and the public certificate from `/etc/openvpn/keys/user.crt`. Then, it is calling the renew_cert python script \[1\], which will just check the expiration date of the certificate. It will do complex stuff only when the certificate must be renewed.https://gitlab.domainepublic.net/Neutrinet/ketupa/compose/-/issues/1Openvpn cipher2020-11-23T11:26:56ZTharyrokOpenvpn cipher```
cipher CHACHA20-POLY1305 AES-256-GCM AES-128-GCM
auth SHA256 SHA384 SHA512
tls-version-min 1.3
tls-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
``````
cipher CHACHA20-POLY1305 AES-256-GCM AES-128-GCM
auth SHA256 SHA384 SHA512
tls-version-min 1.3
tls-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
```https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/38Add -v flag in help2020-06-21T15:57:55ZHgOAdd -v flag in helpThe -v flag exists but is missing in help messageThe -v flag exists but is missing in help messagehttps://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/37Installation aborted when directory contains spaces2020-06-21T15:53:26ZHgOInstallation aborted when directory contains spacesWe are getting an error on line 355: pushd have too many arguments
And indeed, there are some quotes missing for the directory name...We are getting an error on line 355: pushd have too many arguments
And indeed, there are some quotes missing for the directory name...https://gitlab.domainepublic.net/Neutrinet/neutrinet_cube_install/-/issues/36if domain.nohost.me exists already2020-06-07T13:39:43ZThierry Fenasseif domain.nohost.me exists alreadyDuring a complete reinstallation of an exsiting domain.nohost.me cube, thi script said that the domain exists (and off course it does) and ask to chose another.
```
[INFO] Vous avez choisi un sous-domaine gratuit. Vérification de sa dis...During a complete reinstallation of an exsiting domain.nohost.me cube, thi script said that the domain exists (and off course it does) and ask to chose another.
```
[INFO] Vous avez choisi un sous-domaine gratuit. Vérification de sa disponibilité...
[WARN] DOMAIN.nohost.me n'est pas disponible. Veuillez choisir un autre nom de domaine
[INFO] Vous pouvez soit utiliser votre propre nom de domaine, soit utiliser gratuitement un sous-domaine provenant de l'un de ces noms de domaine :
```
Actually, I decided to provide a « fake name » and when the hypercube file was created I have edited the file to replace de domain name.https://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/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/29Check if the VPN credentials and certificates are mandatory2020-02-11T19:20:58ZHgOCheck if the VPN credentials and certificates are mandatoryThe idea is to see if one can enter dummy credentials and empty certs. At the moment, we don't know if the install would fail or not.
If the install succeed anyways, we could make this part optional with a flag (although I'm not sure th...The idea is to see if one can enter dummy credentials and empty certs. At the moment, we don't know if the install would fail or not.
If the install succeed anyways, we could make this part optional with a flag (although I'm not sure this would be useful for our use cases).