Salut, Je suis pas très fan de perl, mais j'en ai fait pas mal au boulot, au besoin .. Si y a le choix, c'est clairement pas le langage que je préfère. J'utilise dolibarr personnelement, sans être un expert, je peux bidouiller du python ou du Ruby aussi, et je suis pas mauvais en PHP, même si on s'en passe. Cordialement, Kevin Lemonnier On Mon, Sep 09, 2013 at 05:35:28PM +0200, Étienne Loks wrote:

Salut Simon,

On 09/09/2013 16:54, Simon Boche wrote:

...

Le SI va nous permettre de gérer les adhérents ainsi que les différents services. Il est donc important de bien le concevoir dès le début pour éviter toute migration future.

Nous pouvons reprendre le SI de FDN (http://edgard.fdn.fr/developpements/fdnlibs/index.shtml, qui ne semble pas répondre) ou bien nous baser sur les travaux de Rhizome (http://orga.rhizome-fai.net/projects/si-dolibarr/).

Pour ce que j'ai pratiqué du SI de FDN et à moins qu'il y ait des gros afficionados de Perl dans nos rangs, je ne suis pas très motivé par cette solution.

...

Je ne connais pas la solution de FDN mais en ce qui concerne Rhizome, ils se basent sur dolibarr (un outils de compta). Je pense ne pas me tromper en disant que nos trésoriers sont partis sur un autre logiciel de comptabilité. Mais il est peut être encore temps de changer ?

Nous pouvons aussi repartir de "zéro" mais cela implique une charge de travail supplémentaire qui peut ne pas être négligeable.

Je ne suis pas sûr que l'on ait dans nos rangs assez de ressources pour pondre *et maintenir* un nouveau SI (typiquement je suis à même de pondre du code mais je suis très nul pour le maintenir). Mais il faudrait p-e évaluer nos ressources de personnes à même de coder.

Pour ma part (par ordre dégressif de plaisir), dans le cadre de Grifon, je peux coder en Python, bidouiller du Ruby voire du PHP.

...

En ce qui concerne cette solution, je verrais bien un serveur LDAP pour gérer les adhérents ainsi que toutes les informations nécessaires pour la gestion de leurs services. L'avantage de cette solution c'est la centralisation en un seul endroit de toutes les informations concernant un adhérent, avec en plus des solutions existantes et éprouvées pour la mise en place d'un serveur de secours, l'interconnexion avec d'autres services (genre ssh ou bien les mails), l'authentification sécurisée (en passant par Kerberos)... De plus, je dispose déjà d'une biblio assez importante sur cette solution (et au passage je vais très certainement la déployer sur mon propre serveur).

J'ai l'impression que la solution de Rhizome fonctionne déjà plus ou moins avec du ldap (http://orga.rhizome-fai.net/issues/194).

Librement,

-- Étienne Loks

_______________________________________________ Grifon mailing list Grifon@grifon.fr http://lists.grifon.fr/mailman/listinfo/grifon

Bonsoir, Le lundi 09 septembre 2013 à 17:58 +0200, Emmanuel Thierry a écrit :

Le 9 sept. 2013 à 16:54, Simon Boche a écrit :

...

En ce qui concerne cette solution, je verrais bien un serveur LDAP pour gérer les adhérents ainsi que toutes les informations nécessaires pour la gestion de leurs services.

Aïe, à chaque fois que je lis LDAP, ya « usine à gaz » qui s'affiche dans ma tête. J'ai ré-étudié récemment la problématique d'authentification/autorisation, et j'avoue toujours avoir du mal à m'enlever cette idée de la tête… même si je ne vois pas de solution aussi « complète » à côté.

...

L'avantage de cette solution c'est la centralisation en un seul endroit de toutes les informations concernant un adhérent,

Ça sa doit coller à pas mal d'autres solutions d'authentification que LDAP.

...

avec en plus des solutions existantes et éprouvées pour la mise en place d'un serveur de secours, l'interconnexion avec d'autres services (genre ssh ou bien les mails), l'authentification sécurisée (en passant par Kerberos)...

Rhaaa, Kerberos… Là, je vois la centrale atomique à gaz !(!)

...

De plus, je dispose déjà d'une biblio assez importante sur cette solution (et au passage je vais très certainement la déployer sur mon propre serveur).

Bon, je comprends que si tu connais, tu aimes bien.

Attention avec le LDAP, c'est beaucoup moins hackable que du SQL. Et ça n'a d'avantage que sur les bases avec beaucoup de lookups, ce que vous n'aurez pas à Griffon.

C'est clair que pour les perfs, on s'en fou un peu.

Le SQL te permettra plus facilement des schémas custom, des requêtes custom, etc. Le LDAP te contraint en terme d'accès et d'utilisation des données.

Oui, mais il y a toujours des avantages et des désavantages à la souplesse versus un truc bien défini/rodé.

Moi-même je fonctionne avec un LDAP et je regrette d'avoir choisi ça...

Ah ouai ? T'as des exemples concrets de problèmes ? Perso, après avoir vraiment bien regardé comment différents protocoles pouvaient interagir ensemble, je n'arrive pas à trouver une solution « globale » satisfaisante. En fait, je suis parti de ce dont on aura besoin en tant qu'opérateur pour l'authentification, afin de voir quel protocole/logiciel répond à nos besoins : * Pour se connecter aux machines en local (pour les interventions physiques), je suppose que PAM peut se brancher à un paquet de trucs, donc pas trop de problèmes. Prévoir un fallback en cas de problème réseau, quand même… * Pour l'authentification SSH, là c'est un peu plus galère : on peut utiliser PAM aussi, mais si on veut faire autre chose que du mot de passe, genre de clés asymétriques, il faut utiliser autre chose, à ma connaissance. Là, LDAP est moyen branlé pour (même si les attributs existent en non-standard à priori), RADIUS aussi, mais avec un OpenSSH récent on peut lancer un hook pour lui sortir de l'équivalent à authorized_keys, qu'on peut chopper d'où on veut (c-à-d même d'un fichier qu'on pourrait synchro « à la main » sur les machines, si on voulait faire « simple »). * Pour de la collecte, on aura sûrement à mettre en place un serveur RADIUS ; c'est ce que parlent les équipements réseau. FreeRADIUS est pas mal, et peut parler SQL derrière, ou LDAP, mais ça a l'air moins bien intégré. * Pour faire de l'accounting (OK, c'est pas lié directement à l'authentification), bah, ya que RADIUS, je ne crois pas que LDAP fasse vraiment. * Pour l'authentification DHCP(v6), car ça serait pas mal de préparer un peu le futur, et qu'on aura peut-être des méthodes d'accès autre que du PPP-like (i.e. basé sur RADIUS seulement), où un serveur DHCP sera utilisé, genre sur du Wifi, il faut pouvoir brancher le serveur DHCP sur une « base ». Il y a un plugin LDAP à l'ISC DHCP, et un patch non-officiel pour du SQL, mais rien pour RADIUS. Pour l'IPv6, si on ne veut pas que les gens le configurent à la main, c'est _obligé_ d'avoir du DHCPv6. Et sur du PPP ; c'est vraiment un peu galère à mettre en place (i.e. j'ai encore réellement essayé, mais vu les discussions, ça a pas l'air d'être de la tarte). Et bien sûr, faire marcher tout ça ensemble veut dire qu'on sera à peu près obligé de stocker les mots de passe en clair… (je vous laisse vous moquer des « grands » qui le font, mais c'est réellement impossible avec le spaghetti de protocoles à supporter). C'est un autre truc limitant de LDAP : ça n'est qu'une base, et les infos dedans sont « en clair », même si ça peut bien sûr être un mdp hashé. Et bien sûr, si on veut faire moderne avec du SCRAM (RFC 5802) pour les mdp (j'ai pas compris comment LDAP pouvait supporter ça avec SASL et comment ils interagissent, vu que ça a l'air théoriquement supporté…) ou des courbes elliptiques (ECDSA/ECDH) pour les clés asymétriques, ça sera avec des patchs plus ou moins expérimentaux, voire qu'il faudra qu'on écrive… Le plus chiant, et qui sera encore un autre « limiteur », c'est de voir par quel protocole on va _modifier_ la base ; car autant lire les infos avec un traducteur LDAP/RADIUS/DHCP, ça se fait, autant les écrire… Bref, si quelqu'un a une idée pour tout ça… C'est pour ça que le SQL ça me tente pas mal comme (plus petit ?…) dénominateur commun. Mais ça se discute, vu la gueule du module SQL de LDAP (il m'a fait un peu peur). -- benjamin

Le 10 septembre 2013 01:39, Benjamin Cama <benoar@dolka.fr> a écrit :

Bonsoir,

Le lundi 09 septembre 2013 à 17:58 +0200, Emmanuel Thierry a écrit :

...

Le 9 sept. 2013 à 16:54, Simon Boche a écrit :

...

En ce qui concerne cette solution, je verrais bien un serveur LDAP pour gérer les adhérents ainsi que toutes les informations nécessaires pour la gestion de leurs services.

Aïe, à chaque fois que je lis LDAP, ya « usine à gaz » qui s'affiche dans ma tête. J'ai ré-étudié récemment la problématique d'authentification/autorisation, et j'avoue toujours avoir du mal à m'enlever cette idée de la tête… même si je ne vois pas de solution aussi « complète » à côté.

C'est vrai que c'est un peu difficile à mettre en place (surtout maintenant, puisque la configuration du serveur LDAP passe par... LDAP !) mais je dirai que le plus difficile (et peut être le moins documenté) concerne la création d'un arbre cohérent et facilement extensible.

...

...

L'avantage de cette solution c'est la centralisation en un seul endroit de toutes les informations concernant un adhérent,

Ça sa doit coller à pas mal d'autres solutions d'authentification que LDAP.

Par exemple, Kerberos ne permets pas de stocker des attributs pour d'autres applis. Il faut donc coupler cela à une base de données. En fait, LDAP ne fait que remplacer la base de données (avec en plus des choses concernant l'authentification de base mais c'est pareil dans un SGBD). Quand je parle de LDAP, je parle simplement de la partie base de données. L'authentification interne pour LDAP, c'est autre chose.

...

...

avec en plus des solutions existantes et éprouvées pour la mise en place d'un serveur de secours, l'interconnexion avec d'autres services (genre ssh ou bien les mails), l'authentification sécurisée (en passant par Kerberos)...

Rhaaa, Kerberos… Là, je vois la centrale atomique à gaz !(!)

Roh, tout de suite ;-) C'était juste un exemple, mais on peut tout à fait se passer de Kerberos.

...

...

De plus, je dispose déjà d'une biblio assez importante sur cette solution (et au passage je vais très certainement la déployer sur mon propre serveur).

Bon, je comprends que si tu connais, tu aimes bien.

Disons qu'en ce qui concerne LDAP, je trouve cette solution plus élégante que bien d'autres que j'ai pu étudier avec le gros avantage d'être interrogeable par pleins d'applications différentes.

...

Attention avec le LDAP, c'est beaucoup moins hackable que du SQL. Et ça n'a d'avantage que sur les bases avec beaucoup de lookups, ce que vous n'aurez pas à Griffon.

C'est clair que pour les perfs, on s'en fou un peu.

Tout à fait d'accord. Ce n'est pas pour de meilleures perfs que je proposais cette solution (disons que c'est un effet de bord intéressant).

...

Le SQL te permettra plus facilement des schémas custom, des requêtes custom, etc. Le LDAP te contraint en terme d'accès et d'utilisation des données.

Oui, mais il y a toujours des avantages et des désavantages à la souplesse versus un truc bien défini/rodé.

Tout à fait ! LDAP est fait pour stocker un annuaire, il existe pleins de schémas différents (et il est possible d'en rajouter). SQL, c'est beaucoup plus généraliste. Alors certes, c'est plus souple, mais cela peut poser pleins d'autres soucis. ET pour certaines choses, je pense que LDAP est plus souple. Par exemple, rajouter des attributs a posteriori. en SQL, la solution naïve consiste à modifier la table pour ajouter des colonnes. En LDAP, c'est pas un soucis.

...

Moi-même je fonctionne avec un LDAP et je regrette d'avoir choisi ça...

Ah ouai ? T'as des exemples concrets de problèmes ?

Je serai aussi très intéressé. La seule critique que j'ai entendu de personnes ayant mis en place LDAP concernait la relative difficulté de la mise en oeuvre.

Perso, après avoir vraiment bien regardé comment différents protocoles pouvaient interagir ensemble, je n'arrive pas à trouver une solution « globale » satisfaisante. En fait, je suis parti de ce dont on aura besoin en tant qu'opérateur pour l'authentification, afin de voir quel protocole/logiciel répond à nos besoins :

* Pour se connecter aux machines en local (pour les interventions physiques), je suppose que PAM peut se brancher à un paquet de trucs, donc pas trop de problèmes. Prévoir un fallback en cas de problème réseau, quand même…

Yep, c'est pas un point bloquant. LDAP peut tout à fait jouer ce role. Pour le fallback, j'ai entendu parler de sssd, mais je n'ai pas encore regardé.

* Pour l'authentification SSH, là c'est un peu plus galère : on peut utiliser PAM aussi, mais si on veut faire autre chose que du mot de passe, genre de clés asymétriques, il faut utiliser autre chose, à ma connaissance. Là, LDAP est moyen branlé pour (même si les attributs existent en non-standard à priori), RADIUS aussi, mais avec un OpenSSH récent on peut lancer un hook pour lui sortir de l'équivalent à authorized_keys, qu'on peut chopper d'où on veut (c-à-d même d'un fichier qu'on pourrait synchro « à la main » sur les machines, si on voulait faire « simple »).

Hum, cela fait quand même depuis le début du millénaire que des gens utilisent LDAP pour stocker les clés. Il y avait même un patch qui était maintenu pour que openssh puisse interroger un serveur LDAP (patch qui n'est plus nécessaire maintenant, comme tu le disais).

* Pour de la collecte, on aura sûrement à mettre en place un serveur RADIUS ; c'est ce que parlent les équipements réseau. FreeRADIUS est pas mal, et peut parler SQL derrière, ou LDAP, mais ça a l'air moins bien intégré.

Je viens de lire la doc rapidement de FreeRADIUS et en effet, il semble que la méthode par défaut pour stocker les infos soit d'utiliser une base SQL. Mais le module pour LDAP semble plutôt bien fonctionner. Bon, par contre, le choix binaire PAP / CHAP pour l'authentification...

* Pour faire de l'accounting (OK, c'est pas lié directement à l'authentification), bah, ya que RADIUS, je ne crois pas que LDAP fasse vraiment.

L'accounting va être fait du coté de RADIUS mais ensuite nous pouvons stocker ce genre d'information dans LDAP.

* Pour l'authentification DHCP(v6), car ça serait pas mal de préparer un peu le futur, et qu'on aura peut-être des méthodes d'accès autre que du PPP-like (i.e. basé sur RADIUS seulement), où un serveur DHCP sera utilisé, genre sur du Wifi, il faut pouvoir brancher le serveur DHCP sur une « base ». Il y a un plugin LDAP à l'ISC DHCP, et un patch non-officiel pour du SQL, mais rien pour RADIUS. Pour l'IPv6, si on ne veut pas que les gens le configurent à la main, c'est _obligé_ d'avoir du DHCPv6. Et sur du PPP ; c'est vraiment un peu galère à mettre en place (i.e. j'ai encore réellement essayé, mais vu les discussions, ça a pas l'air d'être de la tarte).

Peu importe que DHCP ne parle pas RADIUS. Le principal, c'est qu'il puisse parler soit LDAP, soit SQL.

Et bien sûr, faire marcher tout ça ensemble veut dire qu'on sera à peu près obligé de stocker les mots de passe en clair… (je vous laisse vous moquer des « grands » qui le font, mais c'est réellement impossible avec le spaghetti de protocoles à supporter). C'est un autre truc limitant de LDAP : ça n'est qu'une base, et les infos dedans sont « en clair », même si ça peut bien sûr être un mdp hashé. Et bien sûr, si on veut faire moderne avec du SCRAM (RFC 5802) pour les mdp (j'ai pas compris comment LDAP pouvait supporter ça avec SASL et comment ils interagissent, vu que ça a l'air théoriquement supporté…) ou des courbes elliptiques (ECDSA/ECDH) pour les clés asymétriques, ça sera avec des patchs plus ou moins expérimentaux, voire qu'il faudra qu'on écrive…

Idem dans SQL. Il y a une différence entre les protocoles d'authentification (genre Kerberos, RADIUS, Diameter...) et les protocoles d'interrogation de base de données (SQL, LDAP....). Mais on peut tout à fait stocker des certificats X.509 dans LDAP.

Le plus chiant, et qui sera encore un autre « limiteur », c'est de voir par quel protocole on va _modifier_ la base ; car autant lire les infos avec un traducteur LDAP/RADIUS/DHCP, ça se fait, autant les écrire…

Si on prends du SQL, SQL. Sinon LDAP. Si on commence à attaquer avec des langages différents la même base de données, cela va commencer à être dangereux (ou si nous avons des infos éclatées entre les différents services utilisant différentes méthodes de stockages des infos).

Bref, si quelqu'un a une idée pour tout ça… C'est pour ça que le SQL ça me tente pas mal comme (plus petit ?…) dénominateur commun. Mais ça se discute, vu la gueule du module SQL de LDAP (il m'a fait un peu peur).

Je ne vois pas en quoi c'est le plus petit dénominateur commun. Tout ce que tu citais au dessus peut utiliser LDAP. Après, un bon point pour SQL et qu'il est beaucoup mieux connu que LDAP. Librement, -- Simon Boche

Le 10 sept. 2013 à 11:24, Emmanuel Thierry a écrit :

Le 10 sept. 2013 à 11:16, Simon Boche a écrit :

...

...

Moi-même je fonctionne avec un LDAP et je regrette d'avoir choisi ça...

Ah ouai ? T'as des exemples concrets de problèmes ?

Je serai aussi très intéressé. La seule critique que j'ai entendu de personnes ayant mis en place LDAP concernait la relative difficulté de la mise en oeuvre.

Concrètement le problème c'était pour centraliser sur un même compte utilisateur: * les adresses mail * les credentials (admin, pas admin) * l'identité * l'authentification * etc Le tout en considérant qu'un utilisateur pouvait être dans plusieurs entités et devait pouvoir changer son mot de passe pour toutes les entités dans lesquels il était (donc avoir des comptes qui ne sont que des alias vers un autre compte).

Ça a donné un truc immonde et ingérable (enfin bon j'ai cherché aussi...).

Ah oui, et bien sûr en utilisant les données dans Postfix, Dovecot &cie ! ;) Manu

Le 2013-09-09 17:58, Emmanuel Thierry a écrit :

Bonjour,

Le 9 sept. 2013 à 16:54, Simon Boche a écrit :

...

En ce qui concerne cette solution, je verrais bien un serveur LDAP pour gérer les adhérents ainsi que toutes les informations nécessaires pour la gestion de leurs services. L'avantage de cette solution c'est la centralisation en un seul endroit de toutes les informations concernant un adhérent, avec en plus des solutions existantes et éprouvées pour la mise en place d'un serveur de secours, l'interconnexion avec d'autres services (genre ssh ou bien les mails), l'authentification sécurisée (en passant par Kerberos)... De plus, je dispose déjà d'une biblio assez importante sur cette solution (et au passage je vais très certainement la déployer sur mon propre serveur).

Attention avec le LDAP, c'est beaucoup moins hackable que du SQL. Et ça n'a d'avantage que sur les bases avec beaucoup de lookups, ce que vous n'aurez pas à Griffon. Le SQL te permettra plus facilement des schémas custom, des requêtes custom, etc. Le LDAP te contraint en terme d'accès et d'utilisation des données. Moi-même je fonctionne avec un LDAP et je regrette d'avoir choisi ça...

Salut, Je partage pas mal le point de vue de Manu sur ce coup: SQL est 100x plus flexible, ne serait ce que pour avoir/coder des interfaces de gestion au dessus (listing des entrées, rajout..). Toute application qui sait utiliser LDAP sait utiliser SQL. VHFFS, le panel de tuxfamily et de toile-libre c'est par exemple du 100% SQL (avec des exports possibles vers LDAP). Et pour avoir vu les deux en prod, la replication pgsql et meme mysql est bien plus fiable que la replication LDAP. -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org

Comme j'ai un peu de mal à vous suivre dans la réflexion autour du SI (ça parle de LDAP, de dolibarr, de MySQL, du SI de FDN ou Aquilenet... ) j'ai un peu mis à plat le sujet. Selon moi, les besoins que nous avons ou allons avoir et auquel un SI devra (peut-être) répondre : - gérer la base adhérents - tenir une comptabilité rigoureuse - générer des factures, des reçus, des prélèvements? etc. - communiquer au public ou en interne - permettre une authentification sur les services (e-mails, etc.) - être interopérable avec les solutions qui nous permettrons de fournir différents accès (Marque blanche ? Wifi ? Fibre ? Notre propre porte ADSL ? etc.) - mesurer la consommation - vérifier le fonctionnement de nos équipements de production - etc. (et bien d'autres choses ! ) Pour ma part, un SI, ça se décompose déjà en 2 parties qu'il faut à tout prix éviter de mélanger ! Pour organiser tout ça dans ma tête j'ai fait un petit schéma en partant de bonnes pratiques existantes pour qu'on se comprenne bien. Je pense qu'il vaut mieux fragmenter les systèmes un script ou un job (de type de ce qu'on peut produire avec TOS ou autre cochonnerie du genre) car : ça prend 2 fois plus de temps d'installation (on utilise 2 systèmes différents), mais 2 fois moins de temps a intégrer (moins de code a pondre) et 2 fois moins de temps à maintenir (on peut mettre a jour les différentes briques avec moins de tracas de patchs, plugins etc. ). On migre une brique d'une solution A à une solution B plus facilement. Par exemple, le jour où on en a marre de gnucash, on passe à un autre soft et on refait le script qui fait l'interconnexion ou alors, on refait rien du tout car les "briques" à côté nous génèreront des .QIF... Bref, plus on a un gros système monolithique, plus il est difficile à entretenir et moins il risque de coller aux utilisations que chaque personne veut en faire. Donc, je ne pense pas que ça soit une bonne idée de faire une espèce de base (SQL ou autre) et de forcer les différents trucs qu'on veut installer à s'y plier. Déjà on risque de se limiter en choix (car untel sera pas connecté au SGBD que l'on a choisi ... ), ensuite on est pas à l’abri d'avoir à modifier constamment la BD commune parce que le soft A à mis son schéma à jour et ça va pas trop bien dans le sens du B qui n'a pas bougé depuis... -- Gaël (gfa)