- Re2o - federez.net

Fwd: Intégration des clés publiques OpenSSH dans un arbre LDAP

par Alexandre IOOSS

On 6/12/21 6:36 PM, Alexandre IOOSS wrote: > Vous en avez assez de copier manuellement votre clé SSH publique ? > Ce mail résume la discussion entre des membres actifs pour utiliser un > LDAP comme solution de stockage des clés SSH publiques des comptes > administrateurs. > > Problème : Le schéma LDAP par défaut sous Debian ne permet pas de > stocker une clé publique SSH. > Solution 1 : utiliser un certificat x509 que l'on stocke dans l'entrée > "userCertificate;binary" de l'utilisateur. Cela ne permet pas d'utiliser > des clés SSH ed25519 et nécessite quelques commandes OpenSSL côté client > pour générer la clé. On a en plus la gestion des expirations des clés. > Solution 2 : abuser d'un champ dans le LDAP et placer les clés publiques > en format classique. > > Problème : Configurer OpenSSH pour qu'il utilise ces clés publiques. > Solution 1 : Utiliser l'option "AuthorizedKeysCommand" pour qu'OpenSSH > lance un script pour interroger le LDAP. Cela ajoute de la latence au > SSH, et ne semble pas très robuste. > Solution 2 : Utiliser l'option "AuthorizedKeysFile" et synchroniser > toutes les clés publiques dans > `/var/cache/ssh/authorized_keys/NOM_UTILISATEUR`. Il faut les bonnes > permissions sur ces fichiers, ce qui peut mener à une calvitie > prématurée lors de la mise en place. > > Les secondes solutions marchent et ont été déployés sur une machine > virtuelle pour un test au Crans. > > Pour Aurore : vous pouvez peut-être abuser du champs "description" dans > le profil sur re2o et l'exporter vers votre LDAP (solution temporaire). > > Merci à esum et Jeltz d'avoir passé du temps à réfléchir sur cette > problématique. > > ======================================================================= > > Mise en place : > > 1. Éditer `/etc/ssh/sshd_config` et changer : > > ``` > AuthorizedKeysFile .ssh/authorized_keys /var/cache/ssh/authorized_keys/%u > ``` > > 2. Placer un script qui va aller chercher les clés publiques dans le > LDAP et les écrire dans /var/cache/ssh/authorized_keys/UTILISATEUR. Il > est de bon goût de placer un fichier vide si l'utilisateur n'a pas de clé. > > 3. Placer un timer systemd ou un cron qui va régulièrement appeler ce > script en root. On peut réduire ses capabilities, mais il a besoin de > changer les propriétaires des fichiers placés, sinon openssh refusera > d'utiliser ces fichiers de clés publiques. > > Le script en question est en cours de test côté Crans, on l'enverra > probablement en réponse à ce mail quand il marchera bien. > > Bonne soirée, > > > _______________________________________________ > Tech.aurore mailing list -- tech.aurore(a)lists.crans.org > To unsubscribe send an email to tech.aurore-leave(a)lists.crans.org > Ça intéresse sûrement aussi l'équipe de re2o. -- Alexandre

3 années, 6 mois

1
0
0 0

Re2o 2.9

par Jean-Romain

Bonjour à tous et à toutes, Après presque 1 an de développement et 600 commits (pas un de plus, pas un de moins), les contributeurs de Re2o sont heureux de vous annoncer la sortie de la version 2.9. Cette version se focalise sur l’amélioration de l’auto-rézotage, des fonctionnalités d’historique et de journaux, et de l’interface de manière générale. Le changelog complet est disponible ici <https://gitlab.federez.net/re2o/re2o/-/blob/master/CHANGELOG.md> et un résumé en est fait ci-dessous. Améliorations notables !488 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/488> : Utilisation de + dans la recherche pour combiner des mot-clés (par exemple "Joe+Dalton") ; !495 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/495> : Ajout d’un comportement optionnel autorisant les utilisateurs à récupérer la chambre d’un autre utilisateur si ce dernier n’est plus actif ; !496 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/496> : Ajout d’une option permettant aux utilisateurs de choisir leur mot de passe à la création du compte. Il est nécessaire de confirmer séparément leur adresse email ; !504 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/504> : Ajout d’un réglage pour changer la longueur minimum d’un mot de passe ; !507 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/507> : Nouveau formulaire pour éditer les groupes de droits qui devrait rendre tout le monde plus heureux ; !512 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/512> : Ajout de la possibilité de commenter un ticket ; !513 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/513> : Historique des adresses IP et MAC (onglet Statistiques > Historique machine) qui fonctionne également pour les interfaces supprimées. Les historiques pré-existants à la mise-à-jour sont pris en compte ; !516 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/516> : Événements détaillés dans la vue de l’historique (par exemple, montre "re2o-2.8(a)federez.net -> re2o-2.9(a)federez.net") ; !519 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/519> : Ajoute la possibilité de filtrer les événements de log (par exemple pour montrer toutes les cotisations ajoutées par un administrateur) ; !569 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/569> : Réfaction de la barre de navigation afin de rendre la navigation entre les menus plus simple ; !569 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/569> : Ajout d’une option permettant d’installer des thèmes personnalisés (cf ce projet <https://gitlab.federez.net/re2o/re2o/-/merge_requests/589> pour des thèmes dédiés à Re2o) ; !578 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/578> : Migrations squashées afin de simplifier le processus d’installation de Re2o ; !582 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/582> : Amélioration de l’autocomplétion dans les champs de formulaire (chargement progressif plus rapide et comportement plus instinctif) ; !589 <https://gitlab.federez.net/re2o/re2o/-/merge_requests/589> : Déplacement du code lié à la gestion du LDAP dans une application optionnelle séparée ; Correction de nombreux bugs. Vous pouvez accéder à la liste de tous les correctifs ici <https://gitlab.federez.net/re2o/re2o/-/issues?scope=all&state=all&milestone…>. Précautions pour migrer Avant toute chose Avant de migrer pensez à effectuer une sauvegarde de votre base de données. Pour les serveurs RADIUS Il faut utiliser les backports dans Debian buster pour utiliser Python3. echo "deb http://deb.debian.org/debian buster-backports main contrib" >> /etc/apt/sources.list Puis installer les nouveaux packages requis : apt update apt install -t buster-backports freeradius cat apt_requirements_radius.txt | xargs sudo apt -y install Utilisation de Django Autocomplete Light Il faut installer les nouveaux packages requis et lancer collectstatic sudo pip3 install -r pip_requirements.txt python3 manage.py collectstatic Gestion du LDAP optionnelle Il faut ajouter l’application ldap_sync dans les réglages locaux (re2o/settings_local.py) pour continuer à utiliser la synchronisation LDAP. Dernières étapes Pensez à migrer vos modèles, compiler les traductions et recharger Apache. python3 manage.py migrate python3 manage.py compilemessages sudo service apache2 reload Suite du projet Nous recherchons toujours de nouveaux contributeurs, n’hésitez pas à vous manifester ! La version 3.0 est déjà dans les tuyaux et promet d’apporter de nombreux changements. Conclusion Nous espérons que vous serez aussi enthousiasmé que nous le sommes par cette nouvelle version de Re2o. Si c’est le cas, ou si vous avez la moindre question ou remarque, n’hésitez pas à visiter la page Gitlab du projet <https://gitlab.federez.net/re2o/re2o>, à venir discuter avec nous sur le chan irc (irc.rezosup.org sur le canal #re2o), la conversation Telegram <https://t.me/joinchat/Gv_Hw1Mu9L7pu-VIzN9L9Q>, ou sur la mailing list re2o(a)federez.net <mailto:re2o@federez.net>. Sincèrement vôtre, Jean-Romain Garnier, mainteneur de Re2o

3 années, 11 mois

1
0
0 0

Release 2.8 de Re2o

par Gabriel Detraz

Salut à tous, Nous sommes heureux de vous annoncer la version 2.8 de re2o. Le point principal de la release 2.8 est son support et sa compatibilité avec django 1.11 et debian buster. La liste complète des nouvelles fonctionnalités apportés par la release 2.8 est la suivante : - Ajoute un paginateur sur les résultats de recherche lorsqu’ils sont nombreux #474 - Permet de créer des cotisations inférieures au mois #454 - Ajout de la possibilité d’ajuster le ttl par enregistrement #453 - Ajout de mentions légales, exigence comnpay #460 - Possibilité d’avoir des switchs sur plusieurs subnet (objets IpTypes différents) : correction et adaptation de topologie, emplacement des serveurs radius, etc pertinents en fonction du subnet #459 - Application permettant la gestion multi opérateurs des prises ethernet filaire #451 - Adaptation du reçu d’adhésion en fonction du mandat sous lequel il a été délivré #444 - Commande CLI pour archiver en masse #448 - Les factures de 0 euros sont automatiquement acceptées #450 - Permet la désactivation des raccourcis JS #441 - Ajout de réglages permettant la fournitures d’informations supplémentaires dans les réponses radius pour permettre la captures des macs, en particulier pour le matériel juniper #436 - Ajout de messages expliquant les raisons d’un refus d’accès si la permission requise n’existe pas #432 - Application de gestion des tickets #427 - Optimisation des requètes (mise en cache etc) #425 - Permet de créer des profiles de ports rattachés géographiquement à une résidence #424 - Augmentation de la taille du texte pour les rappels #422 - Renomage de variable dans machines pour éviter les confusions : type->name, type->machine_type etc #413 - Crée un état full archive, dans lequel toutes les données sont supprimées sauf les données légales (nom, prénom et coordonnées) #414 - Crée la possibilité de gérer plusieurs résidences séparées, avec l’objet dormitory #412 - Reprise de l’interface admin #417 Les bugs corrigés sont les suivants : - Correction du problème sur les filtres avancés de recherche #475 - Correction de bugs sur le javascript du menu vente #478 - Problèmes divers de traduction, de date et de langue #471, #466, #465, #409 - Suppression de code mort #467, #446 - Correction du problème des achats simultanées de cotisations de durées différente #454 - Corrige le problème de radius et tls 1.3 #464 - Correction de bug sur le formulaire de domain #463 - Correction du problème d’affichage sous ios #452 - Correction de l’affichage du statut d’adhésion sur les groupes #223 - Correction et adaptation de la bonne extension pour un domain #443 - Correction du bug can_view_all #442 - Correction du crash en cas d’absence de GTU #440 - Les comptes désactivés peuvent se loguer #434 - La validation de « force » ne crash pas en cas d’absence de chambre #435 - Correction du bug de plantage si le montant voulu est exactement le montant minimal autorisé #421 - Correction de bug sur le hashage md5 et crypt #420 #419 Il est possible que des points mineurs aient été oubliés dans la liste. Nous vous remercions par avance de remplir le questionnaire suivant, orienté end user, que nous avons préparé pour orienter la suite du développement et la direction que pourra prendre le projet : https://limesurvey.crans.org/index.php/167739?lang=fr <https://limesurvey.crans.org/index.php/167739?lang=fr> Bien cordialement, — Chirac

4 années, 12 mois

1
0
0 0

Proposition de réunion de dev

par Hugo LEVY-FALK

Hello Re2o ! Chibrac a proposé une réunion de dev pour re2o. Si vous voulez être de la partie donnez vos disponibilités ici : https://planner.rezometz.org/w3ThBsTrfPLzMI7i . Pour l'ordre du jour : https://etherpad.rezometz.org/p/odj_re2o La bise, klafyvel

5 années, 7 mois

2
2
0 0

L'équipe de Re2o cherche des volontaires !

par Hugo LEVY-FALK

Hello FedeRez ! L'équipe de Re2o cherche de nouvelles têtes pour venir épauler les devs actuels qui se font vieux *kof kof*. Pour rappel, Re2o est un système de gestion de réseau à destination des associations étudiantes développé par des membres de FedeRez. Le projet se veut aussi indépendant que possible de l'architecture du réseau. À l'heure actuelle, Re2o est utilisé dans cinqassociations : FedeRez, le Cr@ns, le Rézoléo, le Rézo Rennes et le Rézo Metz. C'est donc une occasion rêvée si vous souhaitez vous investir dans un projet utile au plus grand monde ! Si vous êtes intéressé, ou par simple curiosité, vous pouvez rejoindre le chan Telegram de Re2o ici : https://t.me/joinchat/Gv_Hw1Mu9L7pu-VIzN9L9Q. Si vous préférez IRC, on se donne rendez-vous sur le chan #re2o de irc.rezosup.org. :) Klafyvel, pour les devs Re2o P.S. : On fait une réunion de dev bientôt, c'est le bon moment de venir s'investir, ou de nous faire part de vos besoins !

5 années, 8 mois

1
0
0 0

Re2O 2.7 + Réunion de dev

par Gabriel Detraz

Salut à tous, Re2o 2.7 a été release, il est actuellement en phase de test intensif. La version 2.7 apporte pleins de fonctionnalités supplémentaires (provision automatique des switchs par ex) et de réglages possibles dans le menu préférences. On avance à présent sur la version 2.8. Au menu, pas de gros changement niveau fonctionnalités. En revanche, l’idée est de rationaliser les ajouts nombreux de fonctionnalités qui ont eu lieu dans 2.6 et 2.7. A titre d’exemple, il est proposé de spliter l’app preferences, et de créer dans chacune des application un sous dossier préférences. Idem pour api. Ces 2 appli empèchent actuellement la modularisation complète et l’ajout de nouvelles apps sans dépendance du coeurs (impression par exemple). Aussi je pense qu’une petite réu pour parler de tout cela serait nécessaire. Voici un framadate : https://framadate.org/PzirKUP6dwIQYVYO Cordialement, — Chirac

5 années, 11 mois

1
0
0 0

Proposition de guide du contributeur et nouveautés dans Re2o

par Hugo Levy-Falk

Bonsoir à toutes et à tous, Dernièrement il y a eu des conflits au sein de l'équipe de développement (et je suis le premier a avoir cédé à la tentation d'élever le ton). Or il me semble que certains de ces conflits auraient peut-être pu être évités si nous avions un document définissant clairement comment nous souhaitons contribuer. D'autre part l'organisation des branches du dépôt git telle qu'elle était jusque là semble avoir fait son temps. C'est pourquoi je propose dans le document en pièce jointe un nouveau mode de fonctionnement, inspiré d'un lien donné par Lhark. Pour que la situation actuelle ne s'empire pas nous avons dors et déjà procédé à la création d'une branche `dev` suffisamment proche de master mais qui permet d'intégrer les modifications du crans (cf le document pour plus de précisions sur le fonctionnement). Cette solution peut être temporaire ou plus définitive, le document n'étant qu'une proposition. Il ne faut surtout pas hésiter à le critiquer et à proposer des modifications. Pour finir sur une note plus joyeuse, je profite de ce mail pour signaler la sortie de Re2o 2.6 qui intègre de nouvelles fonctionnalités et corrections de bug. Ainsi on trouve de nouveaux éléments de design, l'API annoncée par MoaMoaK, un script d'installation proprifiéet un paiement en ligne fonctionnel. Il devrait être maintenant beaucoup plus facile d'intégrer des méthodes de paiement personnalisées, si vous avez des besoins particuliers, rapprochez-vous de l'équipe de développement. Hugo 'Klafyvel' Levy-Falk Pour l'équipe Re2o

6 années, 4 mois

1
0
0 0

Merge des modifications de Crans

par Gabriel Detraz

Bonjour à tous; Comme vous avez pu le voir, un certain nombre de MR sont en attente. Elles concernent des fonctionnalités essentielles à la mise en prod de re2o au CRANS. La mise en prod au CRANS est programmée le 4 aout prochain. Elle ne pourra se faire à un autre moment; on profite en effet de l’été pour faire l’opération. En raison de l’urgence de la chose; ces MR seront mergées le 4 aout; en l’état, sous réserve qu’elles marchent et n’introduisent pas d’erreurs, ce à quoi je veillerai personnellement. En attendant, le code est disponible sur le gitlab, si vous avez des modification à faire (et pas à faire faire par d’autres) c’est le moment. Très cordialement, — Gabriel

6 années, 5 mois

1
0
0 0

Nouvelle API et gros changements pour le client API

par Maël Kervella

Salut, salut, Ceci est un long mail pour parler un peu de la nouvelle API qui va prochainement arriver dans Re2o et des changements qui viennent avec. Je vous préviens il y a plein d'infos et de détails donc je vous conseille de vous posez avant de lire ce mail. Bonne lecture ! Commencons par parler de l'API côté server Re2o. Tout d'abord pour ceux qui ne passent pas leur vie sur #re2o (askip, ça existe mais je suis pas sûr), je vais décrire où en est actuellement la situation et les problèmes liés à l'API actuelle: 1) Actuellement,*les endpoints de l'API ont été fait un peu l'arrache* aux moments et aux endroits où on en avait besoin. Par exemple les premiers endpoints commencent par "/machines/rest/..." parce que les premières données nécessaires étaient des infos dans l'app "machines" puis des endpoints en "/users/rest/..." sont apparus parce qu'on utilisait des infos dans l'app "users". Bref vous l'aurez compris, les endpoints ne sont pas a des endroits logiques et un peu difficile à trouver donc à utiliser (et puis c'est pas parce qu'on avait écrit rest dans l'url que l'API était REST ...) 2) *Les infos exposées sont celles dont on avait besoin uniquement et dans un format qui nous arrangeait* donc autant dire que c'est pas vraiment utilisable pour autre chose. Ce qui fait que si quelqu'un voudrait dev un script utilisant les infos de Re2o via l'api, bah il faut commencer par ajouter les endpoints dans Re2o ce qui est sacrément décourageant. 3) On utilise django-rest-framework pour gérer l'api, sérialiser les infos, ... (c'est probablement le package le plus courant pour gérer une api avec Django). Sauf que *les quelques endpoints utilisent vraiment les trucs les plus basiques et assez salement* parce que ça suffisait et que personne n'avait fait l'effort d'apprendre comment fonctionnait django-rest-framework (qui a une courbe d'apprentissage assez violente il faut le dire). Bref autant dire que le peu d'api qui existait n'était pas vraiment utilisable. Je me suis donc lancé dans le projet de refaire l'api et je vous annonce donc qu'il va bientôt avoir une nouvelle app "api" dans re2o qui exposera tous les modèles de Re2o de façon REST, systèmatique et uniforme (ex : des urls en "/api/<model>/<id>" ou encore des opérations basés sur les méthodes HTTP "GET", "POST", ...). Pour plus de détails, je vous invite a aller voir la documentation à partir de https://gitlab.federez.net/federez/re2o/wikis/API/Raw-Usage (puis vous balader dans la section API du wiki pour plus d'infos). Et oui on a commencé à écrire de la doc ;). Pour les détails de l'implémentation, la MR est encore en phase de review : https://gitlab.federez.net/federez/re2o/merge_requests/172 <https://gitlab.federez.net/federez/re2o/merge_requests/172> Pour ceux qui craignent de voir leur prod cassée à cause d'un changement d'API, sachez qu'on essaye de le faire le plus en douceur possible: 1) on ajoute les endpoints dans Re2o (ça c'est la MR et ce que j'ai décrit au-dessus) SANS supprimer les anciens endpoints. 2) Pendant que les gens pull Re2o avec la nouvelle API, on dev les script utilisant la nouvelle API 3) Les gens pullent ces scripts utilisant la nouvelle API (génération de DNS, DHCP, ...) 4) Quand on a la confirmation que plus personne utilise l'ancienne API (il y a suffisament peu d'instance en prod pour qu'on puisse se permettre de faire comme ça), on vire l'ancienne API. Passons maintenant au second sujet, un peu plus récent: le client API. En effet qui dit "nouvelle API" dit "re2o-tools doit utiliser cette API" et donc dit aussi "refaire pas mal de choses dans re2o-tools" qui commencait à présenter plusieurs soucis. Selon moi, il y a en particulier: 1) *Tous les services sont dans le même projet*, ce qui veut dire que si tu veux ajouter un service qui n'est utilisé que dans ton asso, bah tu te retrouves à l'ajouter partout (dans ton dns, dans ton dhcp, chez les autres assos, ...) ce qui a aussi pour conséquence que tu te retrouves avec des dépendances qui ne font pas de sens. Par exemple actuellement il faut python3-mongodb pour faire tourner re2o-tools (parce qu'un des services l'utilise) et honnêtement c'est un peu dommage quand tu veux juste générer des fichiers de zone DNS. 2) *Le manager est devenu trop complexe*. C'est un truc qui marche bien mais son code est assez violent pour un projet dont le but c'est de récupérer quelques infos depuis l'API et de faire trois actions basiques avec ces infos. Une des idées primaire de ce manager était justement de pouvoir gérer plusieurs services en même temps (lequels regen, forcer la regen de certains, ...) mais bon soyons hônnetes, en pratique tout le monde n'utilise qu'un seul service à la fois. Personne ne fait tourner en prod un DNS, un DHCP, un server mail et un contrôleur de bornes Wi-Fi sur la même machine ... En quand bien même quelqu'un voudrait le faire, ce serait plus simple et plus propre d'avoir plusieurs fois re2o-tools dans des dossiers séparés. En termes de perf, c'est pareil et tu évites de mélanger les fichiers et les conf tout en t'assurant que si la génération d'un service plante, ça ne plante pas les autres. Bref, virez-moi ce manager overkill. 3) *Le code est parfois dégueulasse*. Faut dire ce qui est, le code marche mais c'est loin d'être le plus beau. Je parles d'expérience puisque je vais prendre un example que j'ai écrit. Dans le code pour générer les fichiers de DNS, il y a une partie pour générer les fichiers de reverse que j'ai écrite. Bon si on oublie le fait que j'ai appris plein de trucs en python depuis (notament à moins réinventer la roue), je reste impressioné de voir que l'algo que j'ai pondu marche nickel mais je dois bien être le seul puisqu'à chaque fois il me faut 5-10 minutes pour recomprendre les 30 lignes de codes en question. Donc ça s'appelle un code moche et pas maintenanable quand seul l'auteur le comprend (et pas sans efforts en plus). Bref une nouvelle API était l'occasion de revoir en profondeur tous ces problèmes. Et j'ai donc commencer à faire un POC de ce que ça pouvait donner. Bien que le résultat ne soit pas terminé, ça marche assez bien. Les résultats sont dispo à https://gitlab.federez.net/re2o. By the way vous verrez que cette URL mène à un nouveau groupe que j'ai commencé sur le gitlab de FedeRez dédié à Re2o (d'où le nom du groupe ^^) parce que je ne trouvais pas normal que je soit "owner" du groupe FedeRez (dans lequel est Re2o actuellement) sous prétexte que je dev Re2o. Bon rassurez vous, si je voulais faire une connerie je l'aurais déjà faite mais bon sur le principe, je trouve pas ça super. Alors autant profiter de faire des projets from scratch pour commencer ce nouveau groupe. (j'avais prévenu qu'il y avait plein de nouveauté dans ce mail). Pour ce qui est du nouveau fonctionnement des services j'ai écrit un bout de doc là (https://gitlab.federez.net/federez/re2o/wikis/API/API-Client) (désolé pour la piètre qualité du schéma). Le principe est d'abord d'avoir un client API qui facilite grandement l'utilisation de l'API (gestion de l'authentification, des URLs, du formats des réponses, ...). Bref simplifier tout ça. Et surtout proposer un truc que tout le monde peut utiliser de façon indépendante des autre projets. C'est de là qu'est venue l'idée d'utiliser une "API en couche". L'idée est d'avoir une couche facile à utiliser (= le client API dont on parle) mais qui cache plein de choses (et donc ne permet pas une utilisation ultra pécise) et si nécessaire, il est toujours possible "d'enlever une couche" et d'utiliser directement la lib requests de python ou encore l'API REST avec un autre language que python mais à vous de réimplémenter les trucs compliqués. Sur le groupe Re2o, il y a un projet "Re2o API client" qui est donc ce client API en question. Ce code là est quasi complet, il y a sans doute des ajustements à faire mais dans l'ensemble il ne bougera pas trop je pense. Les autres projets sont justement les POC pour remplacer re2o-tools (DHCP, DNS et ML pour l'instant) en utilisant le client API comme submodule git (à terme avoir un package python serait encore mieux mais chaque chose en son temps). Tout d'abord, vous verrez qu'ils sont dans des projets séparés, ce qui était (toujours selon moi) un problème de re2o-tools. Vous verrez que les codes de ces projets sont bien plus simples que ceux de re2o-tools (mais pas commenté, oui je sais). Bien qu'il n'y ait pas encore tout le sucre qui consiste à vérifier les fichiers générés sont corrects, la base du script fonctionne et génère les fichiers. Ils pourraient presque être déjà utilisés en prod. \o/ En résumé, (parce qu'il faut bien un résumé à la fin de ce roman) les nouveautés sont : 1) Une nouvelle API RESTful qui permet d'accéder à l'ensemble des données de Re2o 2) Un nouveau client API qui a pour but de simplifier grandement l'utilisation de la nouvelle API et faire en sorte de ne pas se prendre la tête pour dev un nouveau service 3) Un nouveau groupe dédié à Re2o sur le gitlab (je suis encore le seul membre mais il est publique est je propose d'y transférer les gens si l'idée de ce groupe convient à tout le monde) 4) Je sais pas faire des infos concises et des mails courts (mais ça c'est pas nouveau) ;) N'hésitez pas à me faire part de vos avis si ces changements sont bien ou pas. Perso je suis assez content de la tournure que ça prend et je trouve la base plus saine mais bon j'ai pas un avis très neutre. Et enfin pour ceux qui ont lus jusque là, sachez que la version 2.7 se rapproche à grand pas et ne devrait plus trop tarder à être annoncée. Voilà merci de votre attention, Bon baisers de Russie d'Allemagne Maël "MoaMoaK" Kervella

6 années, 6 mois

1
0
0 0

Petite réu pour de grand projets

par Maël Kervella

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

6 années, 7 mois

1
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Re2o