Description
Re2o est l'outils de gestion du réseau utilisé au Crans.
Il est développé par plusieurs associations de Federez, le dépôt principal est ici. Les serveurs crans pull depuis un dépot sur notre gitlab, qui à vocation à être uniquement un miroir et à ne pas servir au dev. On est pas branché directement sur le dépôt federez pour ne pas être dépendant d'eux, et pour des raisons de sécurité (les dépots sont auto pullé régulièrement).
Qu'est ce que c'est ?
C'est une application Django, qui gère toute la BDD. On peut découper le système en plusieurs partie:
la bdd postgres, sur thot
- Le serveur re2o, qui tourne via apache
- Un serveur ldap, dont les infos sont exporté par django grâce à django-ldapdb
des services clients, qui se connecte via une API rest pour récupérer les infos pertinentes, cf re2o-services
Comment ça marche
On trouve des infos générique sur le wiki re2o.
Une doc sphinx est disponnible pour l'instant sur le site du rezo-metz : ici
TODO : Vérifier qu'elle est à jour, et mettre en place une doc crans.
TODO : Faire une doc fonctionnelle.
Guidelines
On ne touche pas à l'instance de prod sur le serveur re2o ! Il y a un ensemble de 4 serveur pour les tests et le dev.
Comment contribuer ?
Se référer au phabricator, rubrique re2o : https://phabricator.crans.org/tag/crans_technique/
Quand il s'agit de frontend web
Se référer aux guidelines générales du projet. Les consignes de base : respecter un minimum la pep8, documenter dans une docstring ce que font vos fonctions/classes/etc (en utilisant la syntaxe sphinx)
Quand il s'agit de scripts
3 cas se présentent :
Ces scripts sont portables upstream pour re2o (ex chsh.py...) et font des écritures ldap ou des actions ponctuelles
Dans ce cas, il est préférable de les transformer en commande manage.py. Se référer à la doc django idoine. N'oubliez pas dans ce cas de ne rien laisser de trop crans related.
On les écrit dans le dépôt re2o.
Ces scripts sont trop cranso-cranseux
On les écrit alors dans /usr/scripts/re2o. On importe l'environnement re2o comme par exemple au début de ce script : https://gitlab.crans.org/nounous/re2o/blob/master/freeradius_utils/auth.py
Il s'agit de la régénération régulière d'un service (dhcp, dns...)
A ce moment là, on l'intègre dans les re2o-services avec un dépot à part qui utilise l'api client et est régénéré régulièrement par cron quand il le faut.
Détails Cranseux
Même si on essaye de faire le plus agnostique et indépendant des spécificités du Crans, y a quelques fois des problèmes spécifiques.
Mot de passe
Dans l'ancienne base, on avait plusieurs type de mot de passe, dont les formats peuvent être parmi:
{SSHA}mVL66OPbX3/3x2cBMxcqZvD/GTjurZDt
{crypt}$1$LJgKu7e6$eNGbVZvS7HpwBuFHIsfuA1
{crypt}KkF/pf0w8TlCE
{SMD5}p5AZuAUEG3cWOQUj3cS101fgsh0=Tout ces formats de hash sont pourris, il faut lancer une migration. Le problème, c'est qu'il faut prévenir les gens longtemps à l'avance, et faire l'opération tranquillement. Une option est de faire une transition smooth, où à chaque fois qu'un user se log, on en profite pour upgrade son algo de chiffrement.
Lors de la migration, on a fait en sorte de migrer tous les formats, et il a donc fallu que re2o supporte tous les formats. L'un des problèmes est que nos mot de passe sont de la forme hash(sel+pass), alors que django par défault fait du hash(pass+sel}. Il a donc fallu recoder des hasher dajngo pour supporter nos formats. Cf re2o/re2o/login.py pour les hasher. Dans la base django, les mot de passe doivent être de la forme :
{SSHA}$mVL66OPbX3/3x2cBMxcqZvD/GTjurZDt
{crypt}$1$LJgKu7e6$eNGbVZvS7HpwBuFHIsfuA1
{crypt}$KkF/pf0w8TlCE
{SMD5}$p5AZuAUEG3cWOQUj3cS101fgsh0=On a donc rajouté un $ à l'import quand c'était nécéssaire. Maintenant, il faut refaire l'opération inverser pour export vers la base ldap, donc retiré le $ en trop quand il le faut, pour ça en se base sur la longueur du hash pour redétecter le cas du {crypt}$KkF/pf0w8TlCE, cf ldap_sync dans re2o/users/models.py