Journal Sortie imminente de Red Hat Directory Services

Posté par  .
Étiquettes : aucune
0
26
mai
2005
Red Hat s'apprête à rendre public les sources de Netscape Directory Services qu'il avait acheté à AOL l'année dernière. Cela aura lieu le 1er juin au Red Hat Summit 2005 à la Nouvelle Orléans.

Pour rappel, Directory Services est un des annuaires qui a évolué des sources de feu iPlanet, à l'instar de l'annuaire SunONE. iPlanet est toujours un annuaire assez utilisé dans les très grosses structures car il est capable de tenir des bases d'utilisateurs de grandes tailles (on rapporte des utilisations de plus de 100000 utilisateurs), et dispose de fonctionnalités assez sympa, comme l'intégration complète d'une PKI dans l'annuaire, une gestion des réplications en mode dit "multi-master", et de bonnes performances quelque soit la quantité d'objets stockés, etc.

La grande interrogation est de savoir les fonctionnalités qu'aura cet annuaire comparé à la concurrence propriétaire (je pense surtout aux fonctionnalités de meta-annuaire qu'ont Novell eDirectory et SunONE).

Dans tous les cas, les mois prochains risquent d'être intéressants (et je suis surtout curieux de voir comment Novell va réagir si Directory Services est à la hauteur de eDirectory... Peut-être la voie vers une libéralisation de eDirectory ?)

Plus d'info:
http://www.microsoft-watch.com/article2/0,1995,1819925,00.asp(...)
  • # samba ?

    Posté par  . Évalué à 2.

    et vis a vis de samba, ca marchera tel quel ou il faut que samba s'adapte ?

    Imbolcus
    A vot' service
    • [^] # Re: samba ?

      Posté par  . Évalué à 2.

      Vu que samba repose sur du LDAP pur (comprendre qu'il n'y a pas d'intéractions avec des objets cachés de l'annuaire comme sur les domaines AD), je mets ma main à couper que ca marchera quasiment out-of-the-box (à la limite quite à faire une extension de schéma, qui, soit dit en passant, est aussi nécessaire pour OpenLDAP).
      J'avais réussi à faire un truc similaire avec PAM/pam_ldap, nss_ldap et eDirectory, sans trop faire couler de sueur, et je sais que c'est dors et déjà possible sur des serveurs iPlanet.
  • # OpenLDAP -> Netscape -> iPlanet -> RedHat

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

    j'ai travaillé sur iPlanet et sur Netscape Directory Service. Mais j'ai toujours cru que le moteur sous-jacent à toute la façade graphico-web rajoutée par ces firmes, c'était OpenLDAP.

    Me trompais-je ? D'après la licence de openldap, normalement oui, mais je me souviens bien que les serveurs s'appelaient slapd et slurpd et qu'ils acceptaient les mêmes options en ligne de commande.

    En tout cas, c'est un chouette outil : le front-end est très efficace et tout est possible en ligne de commande néanmoins (donc tout est scriptable simplement). C'est pourquoi iPlanet Directory Server a été si couronné de succès, d'ailleurs, outre ses perfs (qui sont aussi très similaires à OpenLDAP, j'avais lu dans un magazine).
    • [^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat

      Posté par  . Évalué à 1.

      > outre ses perfs (qui sont aussi très similaires à OpenLDAP, j'

      Non qui explosent les perfs d'openldap.
      • [^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat

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

        >Non qui explosent les perfs d'openldap.

        Tout dépend comment tu le fais ça ....

        J'ai vu un serveur OpenLDAP esclave (en lecture seul) avec une base en RAM disk et je peut t'assurer que ca va très vite, surement beaucoup plus vite que Netscape.

        De plus les requêtes LDAP sont tellement light que par rapport à un service ( un serveur de fichier, un smtp... ) qui est devant cela est négligeable dans les performances.

        Ce n'est pas la ( à mon avis) qu'il faut comparer les LDAP car dans 95% des cas cela n'est pas important mais bien sur les features par exemple :
        - Réplications
        - Console d'admin
        - Gestion d'ACLs
        - Souplesse


        A ce propopos est ce que iPlanet/Red Hat) permet d'avoir des backend script ou sql ?
        • [^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat

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

          iPlanet utilisait un backend proprio (qui est donc libre maintenant) à ce dont je me souviens et pas de SQL là-dedans.

          Dans la doc, ils disaient que le backend avait été optimisé pour les perfs avec LDAP ce qui veut dire :
          - des accès rapides en lecture (et moins en écriture)
          - une structure optimisée pour les petits objets textuels
          • [^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat

            Posté par  . Évalué à 2.

            Pouf, pouf :
            - iPlanet (devenu Red hat Directory Server) utilise le même backend que OpenLDAP (disons plutôt le backend recommandé pour OpenLDAP) : Berkeley DB
            - iPlanet et OpenLDAP ont un ancêtre commun qui le premier serveur LDAP standalone, de l'université du Michigan. D'où des éléments qui sont restés communs.
            - Les performances sont EXTREMEMENT variables en fonction de l'usage et de la configuration du serveur. J'aurais tendance à dire que les possibilités d'OpenLDAP, en tant que produit Open Source, offre plus de possibilités, mais que c'est un peu plus difficile à maîtriser.
    • [^] # Re: OpenLDAP -> Netscape -> iPlanet -> RedHat

      Posté par  . Évalué à 1.

      Nop, c'est clairement du code différent. OpenLDAP date du milieu d'année 1998 alors que iPlanet Directory Server en était déjà à la version 3 ou 4 à cette époque. Par contre il est très probable que OpenLDAP ait repris la même ligne de commande (un peu comme Postfix et Exim assurent une compatibilité Sendmail).

      Sur un nombre d'objets raisonnable, OpenLDAP est certainement imbattable au niveau performance. Là où la différence se fait sentir, c'est sur de grandes quantité de données et quand on a besoin d'autres choses que de la performance ;)

      Il y a des infos intéressantes sur le pourquoi du comment du rachat de Directory Services par Red Hat sur le blog de Chris Blizzard (dev de chez Red Hat et membre de la Mozilla Foundation):
      http://www.0xdeadbeef.com/html/2005/01/(...)

Suivre le flux des commentaires

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