Journal Un nouvel outil pour synchroniser Postgres et LDAP

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
15
21
juil.
2017

Salut les moules,

Comme je sais qu'il y a quelques DBA parmi nous, je passe la nouvelle: j'ai travaillé depuis un mois sur un outils pour créer les rôles dans Postgres à partir d'un annuaire LDAP: ldap2pg.

Pour la petite histoire, contrairement à PAM, PostgreSQL a besoin que les rôles soient créés dans l'instance avant de demander à LDAP d'authentifier l'utilisateur. Dis autrement, LDAP ne sert qu'à récupérer le mot de passe, c'est toujours PostgreSQL qui stocke les rôles, leurs options (SUPERUSER, LOGIN, etc.) et l'héritage de rôles entre eux.

Il y a un projet pg-ldap-sync qui existait déjà. Pourquoi avoir réinventé la roue ? D'abord un soucis pratique: c'est en ruby, et on installe rarement ruby sur un serveur PostgreSQL ou alors c'est pas la bonne version, très peu de dépendances sont disponibles en paquets rpm/deb. Ensuite, pg-ldap-sync est assez simple: une recherche LDAP pour les utilisateurs et une pour les groupes. L'idée de définir ça dans un fichier YAML propre est très chouette.

Tous les utilisateurs ont les mêmes options: pas moyen de créer des SUPERUSER sans que tout le monde le soit. Je voulais gérer dans un seul fichier YAML la définitions des rôles d'une instance. Sinon il faut faire des blacklists pour ne pas dropper ce qu'on crée par ailleurs.

En outre, je voulais aussi accorder ou révoquer les ACLs des rôles. Là ça commence à être assez avancé: je veux gérer qui a les accès DDL ou pas, les accès DML ou pas. Et sans que l'outil écrive les requêtes à ma place.

Au final, en un mois de dév je trouve ldap2pg assez complet et pas mal documenté! Et vous comment gérez-vous les rôles de vos instances PostgreSQL ?

  • # pg-ldap-sync

    Posté par  . Évalué à 2. Dernière modification le 21/07/17 à 19:51.

    J’ai utilisé cet outil il y a un petit moment, je confirme, il est un peu trop simpliste. Ça dépanne.

    Par contre pour Ruby bon… je ne vois pas bien ce que ça change par rapport à Python. RVM est bien pratique pour installer la version qui va bien et les gems peuvent s’installer dans le $HOME d’un utilisateur.

    Avec Python ça m’est arrivé une paire de fois de faire la même chose, et même de compiler. Alors après je viens de découvrir pyenv.

    • [^] # Re: pg-ldap-sync

      Posté par  (site Web personnel) . Évalué à 3.

      Pour ldap2pg, j'ai pris soin d'être très compatible. Peu de dépendances : psycopg2, python-ldap et pyyaml. Les versions de CentOS 7 sont testées sur CircleCI. D'ailleurs, ldap2pg est installé via yum dans les tests fonctionnels :-)

      Je suis d'accord, ça peut très bien se passer avec ruby aussi hein :-) J'ai eut des mauvais souvenirs avec wheezy, où ruby semblait mal intégré à Debian, un peu comme python à l'époque des versions 2.4 et autour. C'est vraiment à partir de python 2.5 et distutils que ça a bougé.

      Merci pour ton retour !

  • # python et yaml...

    Posté par  . Évalué à 5.

    Je ne sais pas sur quelle version de libyaml le module PyYaml est basé, mais mon expérience avec cette lib a été navrante.
    Des crash (dans yaml_string_write_handler), une doc bof, et des performances de merde dues à trop d'accès systèmes, notamment une chiée de malloc de très petite taille (0 ou 1 octets dans de nombreux cas)…

    Je ne sais pas si les crash que j'ai subi (et corrigés avec patch, mais peut-être pas sur le bon repo, remarque) ont été corrigés, mais les problèmes architecturaux ne l'ont très probablement pas été. Ca ne serait pas en soi hyper difficile d'améliorer les perfs du bousin hein, il faudrait juste allouer un buffer pour les strings au lieu de faire autant appel au système pour recopier des chaînes de caractère. Une amélioration encore plus efficace serait de travailler sur des pointeurs constants au lieu de, justement, recopier inutilement des chaînes de caractère… Non, je ne contribuerai pas, j'ai déjà donné.

    Je n'ai pas vraiment d'autre lib à recommander, celles que j'avais cherchées en remplacement ne m'avaient pas trop séduit, j'y retrouvais soit le même genre de problèmes (de qualité de code, à la lecture sans tester, j'avais perdu assez de temps comme ça avec une lib de merde) soit des choix qui me gênaient (lancement d'exception dans une lib externe, ça veut dire qu'il faut lier en statique pour ne pas risquer d'avoir de problèmes d'ABI.
    J'ai bien sûr tenté d'écrire mon propre outil, mais la doc du format sur laquelle j'étais tombé était assez bordélique, et, somme toute, m'a surtout fait comprendre que yaml est une usine à gaz si on essaie de supporter la totalité du bouzin. Pour l'histoire, je suis reparti sur ce bon vieil INI-style.

    En conclusion, je dirais que si quelqu'un a besoin ou souhaite utiliser du yaml, il vaut mieux faire comme avec le C++: ne supporter qu'un jeu des fonctionnalités, et faire un outil qui se tienne à ce jeu.

    Ceci mis à part, je garde ton outil en mémoire, ça peut être utile ce genre de trucs.

    • [^] # Re: python et yaml...

      Posté par  (site Web personnel) . Évalué à 3.

      Salut freem, merci pour ton commentaire, très utile!

      Heureusement, ldap2pg ne fait que de la lecture de YAML pour la configuration. À mon sens, c'est le cas le plus général pour du YAML. Si les perfs comptent, autent passer par du JSON directement ? Il semble que la qualité et les performances des parsers JSON soient bien meilleures.

      As-tu essayé TOML ? https://github.com/toml-lang/toml C'est une sorte de INI amélioré et minimal. J'ai l'impression que ça souffre moins de certains problèmes de YAML. Et puis au moins, c'est clairement orienté configuration. TOML est moins répandu alors que PyYAML est dans les dépôts standards de pas mal de distro. Faut attendre un peu encore.

      Peux-être qu'une libyaml en C, stable, avec des passerelles vers les langages de scripts fera son apparition. Un peu comme ce qui est arrivé à SASS avec http://sass-lang.com/libsass . On a beau dire, le C a de beaux jours devant lui ^

      Ceci mis à part, je garde ton outil en mémoire, ça peut être utile ce genre de trucs.

      Merci pour le compliment, j'espère qu'il te sera utile :-)

      • [^] # Re: python et yaml...

        Posté par  . Évalué à 2.

        Si les perfs comptent, autent passer par du JSON directement ?

        Bof. On colle du JSon et de l'XML partout de nos jours, mais soyons sérieux: c'est illisible et lourd. Dans pas mal de cas, c'est totalement inutile (pour tout ce qui est config, déjà).
        Yaml est lourd, certes, mais au moins c'est lisible. Si seulement il existait une lib efficace, je plébisciterais volontiers… malheureusement, si c'est le cas, j'ai pas trouvé.

        As-tu essayé TOML ? https://github.com/toml-lang/toml C'est une sorte de INI amélioré et minimal.

        Nope, mais pas besoin, écrire une routine qui lit un fichier et repère 2-3 caractères est largement à ma portée :)

        On a beau dire, le C a de beaux jours devant lui ^

        Ce qui est à la fois malheureux et une excellente chose.
        C'est malheureux parce que le C utilisé est trop souvent du C old-school, qui utilise des #define quand des const ou des fonctions inline seraient au moins aussi efficace sans pour autant rendre le code horrible à lire et débuguer.
        C'est une excellente chose aussi, parce que malgré les inconvénients du C (pas de RAII, pas de prog. générique, typage faible, etc), il a une ABI relativement stable et tous les langages savent s'interfacer avec. "Accessoirement", c'est un langage standardisé, avec plusieurs implémentations standard, chose rare, très rare, et très importante à mes yeux. Bien que je préfère C++ ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.