Distribution EOLE » Modules » EOLE AD DC

root@dck:~# cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=26.04
DISTRIB_CODENAME=resolute
DISTRIB_DESCRIPTION="Ubuntu 26.04 LTS" 

root@dck:~# samba-tool domain level show
Domain and forest function level for domain 'DC=domk,DC=ac-test,DC=fr'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2

Nous pouvons ajouter une vérification au tout début du reconfigure afin de s’assurer que personne n’ai modifié la valeur dans /etc/eole/config.eol à une version plus ancienne que celle actuellement en place.

Il me semble possible de gérer côté dictionnaire et fonction (eosfunc) en ce qui concerne le choix de la version.

Je vois deux pistes possibles :
- permettre de choisir, une fois pour toute, la version ;
- toujours permettre de monter de version (dans la limite de ce qui est supporté par Samba).

Dans le premier cas, il est possible d’utiliser une variable en auto-freeze mais cachée par défaut (donc, pas d’enregistrement tant que d’administrateur ne fait pas le choix de la renseigner).

Dans les deux cas, il faut pouvoir lister les versions cibles possibles pour s’assurer de ne pas proposer une version antérieure à la version courante.

La construction de cette liste nécessite, a priori, l’interrogation de la configuration Samba (testparm -sl --parameter-name="ad dc functional level" 2>/dev/null) et l’interrogation de l’annuaire comme décrit dans le scénario. Ce genre d’interrogation n’est peut-être pas idéale dans eosfunc. Il faut que l’annuaire soit démarré, ce qui n’est pas forcément le cas lors de l’utilisation de l’application de configuration du module par exemple.
On peut peut-être renseigner un fichier avec les informations lors du reconfigure et disposer d’une valeur par défaut avant que ce fichier ne soit disponible (liée à l’état d’installation qu’on maîtrise ?).

La question de la cohérence entre version de l’annuaire et des fonctionnalités n’est pas évidente. On a bien une version 88 pour le Schema (version par défaut pour Windows 2019 et 2022) alors que les fonctionnalités rapportées sont celles de 2008R2 dans la configuration.

Peut-être les deux devraient-elles être traitées à part ?

Je pense qu'il faut aller au plus simple : coder en dur les versions de schéma possibles (pas d'interrogation eosfunc).

Il faut juste prévoir que l'utilisateur ne peut pas revenir en arrière. Une fois qu'une version AD a été choisi le choix d'une version inférieure ne doit pas être possible. OU ALORS c'est lors du "reconfigure" qu'un message peut être affiché pour indiquer un problème avec les valeurs de version samba et que la valeur précédente a été prise en compte.

Klaas TJEBBES a écrit :

Je pense qu'il faut aller au plus simple : coder en dur les versions de schéma possibles (pas d'interrogation eosfunc).

La difficulté est d’exclure les versions inférieures. Il semble nécessaire de récupérer la version courante pour faire le tri.

Il faut juste prévoir que l'utilisateur ne peut pas revenir en arrière. Une fois qu'une version AD a été choisi le choix d'une version inférieure ne doit pas être possible. OU ALORS c'est lors du "reconfigure" qu'un message peut être affiché pour indiquer un problème avec les valeurs de version samba et que la valeur précédente a été prise en compte.

Ça semble problématique de permettre la saisie de valeurs non fonctionnelles dans l’application de configuration, d’où l’idée de pouvoir mettre en place une contrainte dans le dictionnaire et de recourir à une fonction spécifique pour construire une liste des valeurs possibles excluant les versions inférieures.