Coucou :)
J'ai pas encore rédigé le CR de la réunion d'hier pour ceux que ça
intéresse, ça va venir sous peu.
En attendant, on y a soulever la question de comment écrire les
docstrings et surtout quelle syntaxe adopter, mais sans avoir vraiment
de réponse. C'est pourquoi je viens vous demander votre avis.
Pour info en python, une docstring c'est un commentaire en début de
fonction, de classe ou de module qui sert à décrire son utilité, ses
paramètres, ses valeurs de retours, ... Et il existe des outils (comme
"sphinx" qui est probablement ce qu'on va utiliser) pour générer de la
doc à partir de ces docstrings pour peu qu'on respecte une certaine
syntaxe (à peu près tout ce qu'on trouve comme doc python vient de ce
genre d'outil).
Il existe plusieurs syntaxes possibles et courament utilisées. Un
exemple de ce que ça peut donner: https://stackoverflow.com/a/24385103
Actuellement on a une partie des docstrings qui sont au format "reST",
une partie au format "Google" et une (grosse) partie qui n'a pas de
syntaxe particulière.
L'objectif est d'homogénéiser tout ça en adoptant une syntaxe précise,
ce qui permettra aussi de générer de la doc automatiquement.
Les infos sont les mêmes d'une syntaxe à l'autre juste présentées
différement, ce qui veut dire que tous les outils supportent toutes les
syntaxes courantes et on peut faire la même chose quelque soit la
syntaxe utilisée. Au final le choix se résume surtout à une préférence
de style et de présentation du code.
Pour faire part de votre préference, c'est là:
https://planner.rezometz.org/9Tce2dKWXw6Hpj4t
Merchi ^^
Maël 'MoaMoaK' Kervella
Ploc à tous,
Pour gérer dnssec avec re2o, on a fait des tests avec 5-1, globalement re2o marche avec knot ou bind pour gérer des zones dns.
En ce qui concerne DNSEC, il apparait que utiliser knot est beaucoup plus simple, je vous explique pourquoi. Evidemment peut-être que des éléments plus subtils m’ont échappé.
Avec bind, il faut générer les clefs avec une commande pour chaque zone, puis ensuite lancer une commande sur le fichier de zone à chaque fois qu’on le modifie pour le signer, cf https://www.skyminds.net/serveur-dedie-mettre-en-place-dnssec-pour-securise… <https://www.skyminds.net/serveur-dedie-mettre-en-place-dnssec-pour-securise…> . Du coup il est nécessaire d’avoir un bout de re2o-tools qui s’occupe de lancer la commande à chaque fois qu’on regen la zone.
Avec knot, c’est beaucoup plus simple, cf https://www.swordarmor.fr/gestion-automatique-de-dnssec-avec-knot.html <https://www.swordarmor.fr/gestion-automatique-de-dnssec-avec-knot.html> . Il suffit d’ajouter dnssec-signing: on et dnssec-policy: default dans la zone, knot s’occupe alors de générer la clef. Il reste juste à récup la DNSKEY et la publier chez gandi/ovh/whatever.
A mon avis, knot simplifie grandement le process et ne nécessite pas d’avoir un script re2o (ou autres) pour resigner la zone à chaque fois. Qu’en pensez-vous ?
—
Chirac
Salut à tous,
Pour ceux qui n’étaient pas là, voici ce qui s’est dit (de mémoire, les présents corrigeront) vendredi.
Présents : Chirac, Charlie, Grizzly et Esum
A noter que la réunion n’a pas durée très longtemps à cause du départ de Charlie :
Point sur ce qui a été fait niveau infra :
- mise en place de re2o-server, vm avec un serveur web apache de dev et bdd sur thot (postgresl)
- mise en place de re2o-ldap, contenant le ldap de re2o
- mise en place de re2o-services, contenant les services dhcp, dns notamment.
- import de la bdd actuel avec un script d’import bien avancé, permettant de faire des tests ( presque tout passe, sauf les serveurs disposant de la même mac sur plusieurs VLAN : https://gitlab.crans.org/nounous/scripts/blob/master/re2o/import_crans.py <https://gitlab.crans.org/nounous/scripts/blob/master/re2o/import_crans.py> )
Ces vm sont sur adh/adm.
Charlie suggère de rajouter l’embryon de parefeu sur services, de créer des vlans dédiés en dehors de adm avec des id élevés ( > 30 ? ); enfin de tester sur ces vlan un mini réseau, avec également la vm re2o-services qui servirait de routeur. Tout le monde semble d’accord là dessus.
Ce qui a été fait niveau dev :
- factorisation du système de gestion des acl
- portages de scripts divers mais essentiels ( chsh, chgpass, unifi-ap-sync, dernière connexion) via des commandes django et des appels aux forms et aux validations des models
- enregistrement de l’emplacement des switchs et génération de la map de la topologie du réseau
- affichage pretty des switchs (equivalent de swicths2 pretty)
- fonction de ménage cableur
- possibilité d’éditer la liste des shells sans passer par le /admin
- model borne wifi spécifique
Ces taches ont une criticité diverse. Sur le reste, il faut avancer dans le code, on fait grosso modo la liste des chantiers. En critique/prioritaire, il y a :
- firewall, à partir de l’embyron présent dans re2o (nftable ? )
- generation de la conf des switchs, code modulaire permettant de générer de la conf pour d’autre modèles que des hp. Voir une solution existante ?
- adherent : gestion de la creation des homes, à inclure dans re2o-tools
Enfin, on a débattu un peu sur la sécurité. Dans re2o, il n’y a qu’un seul login/mdp pour tout.
Avantages :
- plus simple pour les users à comprendre et à retenir comme système
- permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de son compte crans en entier à un « ami »
Inconvénient :
- le mdp est le même partout, cela peut poser un problème de sécu en particulier pour les admin.
On identifie les fonctions sensibles : il s’agit de l’accès web re2o, et des accès serveurs (sudo en particulier).
L’autre problème concerne la phase transitoire, il va falloir gérer les mdp legacy des machines, mais il « suffira » de tweaker un peu auth.py au moins temporairement pour ça.
Plusieurs solutions possibles :
Avoir un second compte; on est tous d’accord pour dire que les gens ne s’y tiendront pas, cette solution semble trop pénible.
Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou l’accès mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme actuellement au CRANS.
On peut forcer l’authentification par clef ssh pour les admin, comme ça si un mot de passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne résout pas le problème de l’accès re2o-web qui serait toujours le même mot de passe.
On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet de couvrir à peu près tout. Le débat reste ouvert.
Voilà à peu près ce qu’on a dit,
Cordialement,
—
Chirac
Plop,
C’était un peu le bordel dans les auteurs des commits, j’ai donc uniformisé.
Sauf pour lhark et Dalahro que j’ai pas sous la main, est-ce que cela vous va ?
cf
root@dodecagon:/var/www/re2o# git shortlog --summary --numbered
624 Gabriel Detraz
177 Maël Kervella
110 Hugo LEVY-FALK
55 Dalahro
55 lhark
47 root
17 guimoz
8 Yoann Pietri
7 Matthieu Michelet
6 Simon Brélivet
5 Éloi Alain
4 David Sinquin
4 Pierre Cadart
3 Laouen Fernet
2 Thibault de BOUTRAY
1 B
1 Daniel STAN
1 Guimoz
1 Hugo Hervieux
1 Lemesle
1 Nymous
—
Chirac
Salut à tous,
Comme annoncé, a eu lieu hier soir la réunion de dev re2o, qui a été un peu longue (1h30) mais très productive.
Vous en trouverez le compte rendu ci joint.
/!\ Important : le chan irc officiel #re2o est migré sur rezosup.
Le gitlab officiel/repo du projet est migré sur le gitlab de FedeRez.
Un gitlab runner est déjà en place pour la CI sur le gitlab de FedeRez.
Les règles de push/review et de développement sont modifiées.
Le système de suivi du projet se base officiellement sur les issues du gitlab.
Voilou,
Cordialement,
—
Chirac
Salut à tous,
Je vous propose une réunion sur appear.in <http://appear.in/> d’ici les prochaines semaines. https://framadate.org/ve5pvC3eqilCtPLR <https://framadate.org/ve5pvC3eqilCtPLR>
Le but est de fixer un certain nombre de choses sur le développement qui nécessitent que les contributeurs s’entendent, en vrac, la langue de dev, la langue et le format de la doc, la gestion des droits, etc etc
Egalement sur le dev : ce qui relève du développement du coeur et ce qui relève des modules externes développés pour les besoins de tel ou tel.
J’ai mis la date des nocturnes, Mael (MoaMoak) suggère qu’on fasse ce point aux nocturnes où beaucoup seront.
La réunion est évidemment ouverte à tous,
Cordialement,
—
Gabriel
Bonsoir à tous,
La version 2.4 apporte les nouveautés suivantes :
- Utilisation de formulaires de recherche js client side pour les listes d'objets longues
- Passage à la pep8 sur les fichiers python serveur side
- Support ipv6 (partiel, pour les machines)
- Support des ouvertures de ports
Toutes les issues sur :
https://gitlab.rezometz.org/rezo/re2o/issues <https://gitlab.rezometz.org/rezo/re2o/issues>
Cordialement,
—
Gabriel
Salut à tous,
La version 1.3 ajoute un certain nombre de fonctionnalités :
- Les reglages sont centralisés dans une application « préférences ». On y retrouve les réglages de l’association, adresse, SIRET etc (nécessaires pour les factures). Les services de la page d’accueil aussi s’y trouvent.
- La liste des vlans est prise en charge dans un menu de machines
- La liste des types de nas est ajoutée. En lien avec auth.py rénové, elle permet de configurer les types de nas, l’autocapture mac address (activée ou désactivée), le type de machine par default du nas (pour l’ajout d’adresse mac, il est nécessaire de connaitre le type de machine que le nas gère (ex : machine wifi, machine filaire) pour lui affecter le bon type et la bonne ip.
- Auth.py : il est maintenant rénové, et importe directement les models re2o. Ceux-ci ont été corrigés pour être importables aussi en python2.7. En effet, freeradius3 dans debian est packagé avec le backend python en 2.7. Cette nouveauté a permis d’ajouter facilement la prise en charge de l’autocapture des macs, de la gestion fine du type d’authentification, et de gérer de manière uniforme entre une authentification 802.1X ou mac-address, en filaire ou en wifi.
Cordialement,
—
Chirac
