Pour l'instant il y a deux serveurs DNS possible pour Samba 4 et je ne pense pas que DNSmasq soit à l'ordre du jour, […]
Je pense qu'on y pense mais pour l'instant rien n'est fait.
Je comprends que ça n'a pas dû être simple de combiner tout ça. Je ne sais si Dnsmasq reste à l'étude en tout cas ce que j'aime dans ce programme c'est l'extrême simplicité de son interface. Il supporte aussi DBUS mais c'est peut-être un point philosophique sujet à discussion, je le reconnais. Par contre, c'est sans doute la partie “mise à jour du DNS par les postes de travail” qui pourrait causer un peu plus de brainstorming. En tout cas, l'explication de Samba 4 me confirme en quoi un contrôleur de domaine Microsoft est un truc assez complexe et compliqué.
Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?,
En fait, non, pas tout à fait. La question était plutôt de reporter le développement autour de LDAP dans OpenLDAP, comme pour Kerberos. Mais au vu de l'explication je pense comprendre que le couplage LDAP réalisé par Microsoft devrait peut-être rester un cas à part. Un développement particulier de LDAP, adapté à ce cas précis était donc nécessaire. Je pige.
Afin que ça fonctionne il faut que l'instance Openldap soit "privatisé" pour Samba sinon il peut se passer de drôles de choses si quelqu'un fait des modifications directement via LDAP en by-passant les modules spécifiques AD.
Effectivement, ça, c'est le genre de cas qui interpelle. D'où l'explication sur la partie transactionnelle à ce niveau je suppose. [Et, entre parenthèses, je suppose aussi que la non-atomicité des opérations sur l'annuaire est sans doute (je prends des précautions, là) une des raisons pour lesquelles Active Directory pourrait se mettre à dérailler.]
[reprise des fonctionnalités de Kerberos dans MIT] Mais la question c'est quel est exactement le besoin ?
Simplement pour savoir si le produit Kerberos MIT allait aussi profiter du développement de l'équipe Samba, tant par la pertinence technique (vu que c'est loin d'être le cas pour OpenLDAP) que pour le bénéfice de Kerberos. C'était juste une question de curiosité. La question qui me vient est alors qu'est-ce qui a empêché l'ajout des fonctionnalités nécessaires à Kerberos MIT pour son couplage avec Samba?
Maintenant, le niveau de complexité de Samba 4 n'a-t'il pas des répercussions sur son applicabilité, c-à-d quant aux raisons qui feront qu'on adopte soit Samba 3 soit Samba 4? Je suppose qu'il existe des circonstances où il vaut mieux adopter Samba 3 que la version 4, exact? Par exemple, dans le cas d'une [petite] entreprise n'ayant pas encore de contrôleur de domaine (ni de messagerie Exchange), il est sans doute plus pratique d'adopter Samba 3, est-ce un raisonnement correct? Est-ce que Samba 4 est plutôt destiné aux entreprises possédant déjà une empreinte Windows importante dans les fonctionnalités des contrôleurs de domaine et qui souhaitent s'en libérer progressivement?
Il me paraît en tout cas évident que l'équipe Samba n'a pas réinventé la roue mais a produit un travail considérable en tenant compte de ce qui existait déjà et n'était plus à faire. Si j'ai bien compris, tout ce qui a été fait devait être fait de cette manière (Lapalisse était un de mes ancêtres lointains ;-), par exemple la particularisation de LDAP. Les apports à Kerberos par Samba bénéficieront aux produits Kerberos existants et tout ceci est une bonne chose. L'ironie de l'histoire est qu'il aura fallu le développement de Samba par une équipe indépendante pour commencer à comprendre comment Windows fonctionne dans ses entrailles!
[^] # Re: Samba 4, DNS et LDAP
Posté par FantastIX . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 2.
Je comprends que ça n'a pas dû être simple de combiner tout ça. Je ne sais si Dnsmasq reste à l'étude en tout cas ce que j'aime dans ce programme c'est l'extrême simplicité de son interface. Il supporte aussi DBUS mais c'est peut-être un point philosophique sujet à discussion, je le reconnais. Par contre, c'est sans doute la partie “mise à jour du DNS par les postes de travail” qui pourrait causer un peu plus de brainstorming. En tout cas, l'explication de Samba 4 me confirme en quoi un contrôleur de domaine Microsoft est un truc assez complexe et compliqué.
En fait, non, pas tout à fait. La question était plutôt de reporter le développement autour de LDAP dans OpenLDAP, comme pour Kerberos. Mais au vu de l'explication je pense comprendre que le couplage LDAP réalisé par Microsoft devrait peut-être rester un cas à part. Un développement particulier de LDAP, adapté à ce cas précis était donc nécessaire. Je pige.
Effectivement, ça, c'est le genre de cas qui interpelle. D'où l'explication sur la partie transactionnelle à ce niveau je suppose. [Et, entre parenthèses, je suppose aussi que la non-atomicité des opérations sur l'annuaire est sans doute (je prends des précautions, là) une des raisons pour lesquelles Active Directory pourrait se mettre à dérailler.]
Simplement pour savoir si le produit Kerberos MIT allait aussi profiter du développement de l'équipe Samba, tant par la pertinence technique (vu que c'est loin d'être le cas pour OpenLDAP) que pour le bénéfice de Kerberos. C'était juste une question de curiosité. La question qui me vient est alors qu'est-ce qui a empêché l'ajout des fonctionnalités nécessaires à Kerberos MIT pour son couplage avec Samba?
Maintenant, le niveau de complexité de Samba 4 n'a-t'il pas des répercussions sur son applicabilité, c-à-d quant aux raisons qui feront qu'on adopte soit Samba 3 soit Samba 4? Je suppose qu'il existe des circonstances où il vaut mieux adopter Samba 3 que la version 4, exact? Par exemple, dans le cas d'une [petite] entreprise n'ayant pas encore de contrôleur de domaine (ni de messagerie Exchange), il est sans doute plus pratique d'adopter Samba 3, est-ce un raisonnement correct? Est-ce que Samba 4 est plutôt destiné aux entreprises possédant déjà une empreinte Windows importante dans les fonctionnalités des contrôleurs de domaine et qui souhaitent s'en libérer progressivement?
Il me paraît en tout cas évident que l'équipe Samba n'a pas réinventé la roue mais a produit un travail considérable en tenant compte de ce qui existait déjà et n'était plus à faire. Si j'ai bien compris, tout ce qui a été fait devait être fait de cette manière (Lapalisse était un de mes ancêtres lointains ;-), par exemple la particularisation de LDAP. Les apports à Kerberos par Samba bénéficieront aux produits Kerberos existants et tout ceci est une bonne chose. L'ironie de l'histoire est qu'il aura fallu le développement de Samba par une équipe indépendante pour commencer à comprendre comment Windows fonctionne dans ses entrailles!