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 )

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.

- 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