Distribution EOLE » Modules » Amon » eole-radius

Pour résumer ce qui peut justifier le besoin d'une refonte globale de eole-freeradius : le serveur ne contrôle pas ce que les clients lui envoient.
De ce fait, l’intégration de freeradius pourrait privilégier la facilité d’adaptation au cas par cas plutôt qu'une configuration cherchant à être exhaustive mais qui se révèlera sans doute limitante.

La complexité majeure rencontrée lors de la tentative d’avoir une configuration complètement intégrée et templatisée est la multiplicité des modules pouvant être chargés par le serveur freeradius et leur inter-dépendance. Le choix d’activer ou désactiver un module, par exemple, doit prendre en compte les interactions avec d’autres modules.

On trouve tout de même quelques modules qui sont gérables indépendamment comme le module files (celui qui gère l’injection de variables dans les requêtes par exemple). Quoique, pour ce cas particulier, la modélisation de la configuration et la transcription en variables creole n’est pas forcément évidente (on retomble facilement sur un besoin de listes de listes).

Il y a également des modules dont la configuration dépend directement de l’infrastructure EOLE (configuration de l’annuaire par exemple) qui bénéfiecierait d’une configuration creole.

Liée à ce dernier exemple, la dernière difficulté rencontrée est l’intégration conjointe avec d’autres services dont freeradius partage les dépendances fonctionnelles. L’absence d’une intégration indépendante de winbind fait pour l’instant défaut et la cohabitation avec des services comme le proxy n’est pas évidente. À noter que pour avoir un service winbind fonctionnel, il faudrait une jonction au domaine.

Attention à genconfig en mode zéphir. La liste des modèles devrait être disponible.