On part du principe que les nounou font attention et savent ce qu'elle font.
C'est plus pratique comme ça pour migrer des services d'une machine à l'autre
sans avoir à rééditer les certificats à chaque fois.
On peut générer/ajouter des clefs privées via gest_crans_lc. Elles sont forcément chiffré avec une
passphrase. Pour les machines crans, elle est dans /etc/crans/secrets. Pour les autres machines
elle n'est pas connue du crans et demandée à l'utilisateur lorsqu'il y a besoin de la clef privée
pour des opérations.
Du coup, on peut générer des csr automatiquement dans gest_crans_lc, ça m'a l'air bien pratique,
ça évite d'oublier des subjectAltName par exemple quand on renouvel le certificat comme les
nom du certificat sont également dans ldap.
On peut aussi, juste avec une requête ldap voir quels sont les certificats qui vont bientôt
expirer (&(objectClass=x509Cert)(end<int(time.time())+delai)).
Je pense particulièrement à chambre qui est unique sauf pour ???? et EXT
On en a besoin pour détecter, quand on affecte quelqu'un a une chambre, que
la chambre est déjà occupée
Pour historique il faudrait faire quelque chose pour que soi, parent,
cableur ne puissent que ajouter de nouvelles lignes, mais en attendant, il peuvent
"en théorie" le modifier.
Pour rappel, les machineMulticast n'ont pas d'existance pour la base ldap
et sont juste pratiques pour générer le dns de la zone TV sans avoir de cas
particulier dans gen_conf/bind.py
En effet, en effectue ensuite un nombre important de fois l'opération i in nonfree.
Avec des liste l'opération est en O(n) alors qu'elle est en O(1) avec des set
D'une façon général, on s'assure que tous les locks concernant un cransLdapObject
sont bien mis avec l'identifiant de lock cransLdapObject.lockId.
Avant d'entrer dans le context manager du cransLdapObject, on fait bien attention
d'intercepter les exceptions pouvant être levée pour libérer les locks potentiellement
déjà posés avant de propager l'exception.
Si on essayer d'appeler une methode d'enregistrement (.save() .delete() .create()) sans
utiliser un context manager, on affiche un warning sur stderr.
À terme ça serait bien de n'utiliser que des context manager pour être sûr qu'on ne
laisse pas de lock traîner dans la base de donnée.
Il faut bien sûr faire attention de bien ajouter les lock avec l'identifiant cransLdapObject.lockId
puisqu'on se base là dessus pour les libérer.
Si on a utiliser une context manager, en en sortant, on rend le cransLdapObject read only
(de façon douce en modifiant le cransLdapObject.mode et de façon force en changeant les methodes
save create delete pour lever l'exception EnvironmentError("Hors du context, impossible de faire des écritures"))
