Salut,
On se disait qu'il serait temps de faire un point sur l'avancement de re2o via appear.in ou un truc dans le genre. Histoire de parler de ce qui a été fait, ce qui a été commencé mais pas fini, et ce qui devrait être fait ;)
Ofc tout le monde peut venir à cette réu: les détails sont pas encore fixés (à venir ce week-end) mais je pense qu'il y aura :
* point sur les nouveautés depuis la dernière réu (journées ou Nocturnes FedeRez je sais plus)
* façon de dev en général (issues, mr, communication,...). Est-ce que les gens sont contents, voudrait changer des choses ?
* nouvelle api: que gérer et par qui ?
* la traduction: comment qu'on fait ça
* les tests: un poc existe ?
* la doc: 100% de couverture en docstring mais de la dire que c'est une vraie doc...
* d'autres gros chantiers en cours ?
Et bien sûr hésitez pas à dire si vous avez des truc à ajouter, une idée révolutionnaire dont vous voulez parler, une feature marrante à ajouter ;)
Le but étant d'etre productif si vous pouviez parler (par mail ou irc) de votre idée avant la réu, histoire qu'on aie des commentaires pertinent à y faire, ce serait mieux.
Prévoir un minimum de 2h est pas deconnant je pense donc pour que tout le monde soit dispo, petit sondage comme d'hab (et il y a plein de choix) : https://planner.rezometz.org/plopidum
MoaMoaK
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
