Problèmes de création d'Open Directory Replica sur OS X Server 5.1

Notez que bien que j'aie obtenu la même erreur, je suis sous MacOS 10.12.6 et Server 5.3.1.

J'ai documenté ce que j'ai fait, étape par étape. Je ne sais pas exactement laquelle de ces étapes a fait la différence, mais j'espère que cela pourra aider quelqu'un.

Dans mon cas, j'ai un serveur sur la côte ouest et un autre sur la côte est qui utilisent un VPN site à site et deux sous-réseaux IP /24 différents. La communication est donc possible mais la réplication a manifestement échoué. Avant de commencer, je recommande d'avoir les mêmes numéros de version/build de MacOS ainsi que la même version de server.app.

1. Faites sauter la DO des deux côtés. J'ai utilisé $ sudo slapconfig -destroyldapserver . Assurez-vous d'avoir d'abord une sauvegarde de vos données.

2. Faites en sorte que le DNS fonctionne parfaitement. Pour cela, il a fallu passer par le processus de "modification du nom d'hôte" de Server.app et (dans mon cas) utiliser un FQDN. Lorsque vous modifiez le nom d'hôte et qu'il vous est demandé de choisir si le serveur fonctionne en réseau local uniquement, réseau local + VPN ou Internet, sélectionnez les options réseau local + VPN ou Internet. Cela permet au serveur de créer des zones DNS qui ne sont pas ".local", ce qui, à mon avis, est l'un des principaux problèmes qui empêchent la réplication de fonctionner, parce que .local est pour Bonjour et je pense que cela perturbe les choses.

   J'ai donc changé le nom de l'ordinateur en "Company X Vancouver Server" et le nom d'hôte en vanserv.clientcompany.com. J'ai redémarré le serveur, vérifié les choses avec $ changeip -checkhostname et vérifié que les DNS en avant et en arrière fonctionnent avec l'outil "host", en recherchant à la fois l'IP et le nom d'hôte, et en s'assurant qu'ils sont résolus dans les deux sens. Configurez le serveur pour qu'il utilise d'abord 127.0.0.1 pour le DNS, puis son autre IP (192.168.10.10), puis le routeur local de saut suivant, puis le DNS public. Redémarrez.

   J'ai fait exactement la même chose sur le serveur de la côte est, en l'appelant "Company X Toronto Server", et en lui donnant le nom d'hôte "torserv.clientcompany.com".

   Je me suis assuré qu'il y avait des entrées sur les deux serveurs pour l'autre serveur. Donc vanserv a vanserv.clientcompany.com (192.168.10.10) et torserv.clientcompany.com (192.168.20.10). J'ai vérifié les recherches DNS avant et arrière pour l'autre serveur sur les deux. Et l'envoi d'un ping à torserv depuis vanserv résout et renvoie des paquets, et vice-versa.

   J'ai configuré les deux serveurs pour qu'ils "effectuent des recherches pour certains clients seulement" - et j'ai configuré cela sur le serveur lui-même, uniquement. Ainsi, les recherches DNS pour le domaine de l'entreprise, clientcompany.com, n'aboutissent pas sur le serveur et n'aboutissent pas, par exemple si un membre du personnel du bureau visite le site Web de l'entreprise.

3. Créez le DO primaire, mais laissez-le vide. Redémarrez. Joignez la réplique à celle-ci en utilisant le FQDN - dans ce cas, la DO a été créée sur vanserv et j'ai joint torserv à celle-ci en tant que réplique. J'ai utilisé le FQDN vanserv.clientcompany.com au lieu de l'adresse IP. Le succès est au rendez-vous !

4. Remplissez le DO avec des données, assurez-vous qu'il se réplique avec succès. C'est le cas !

5. Ajouter les locales (facultatif) - J'ai défini 192.168.20.0 comme Toronto et configuré ce serveur à torserv.clientcompany.com, et Vancouver comme 192.168.10.0/24 et configuré ce serveur à vanserv.clientcompany.com.

Je soupçonne donc que le "problème de réseau" ainsi que les erreurs "version différente de MacOS" que j'obtenais dans l'interface graphique de server.app n'étaient en fait qu'un manque de bonne communication dû à une configuration du DNS que server.app n'appréciait pas.

Oui - cela a fonctionné pour moi sur Sierra avec un tout nouveau répertoire. https://support.apple.com/en-us/HT204880