Lion Server LDAP disparu après le redémarrage - Erreur -14006

Semblable à Le démon slapd ne peut pas démarrer mais en dépit d'être accepté, la réponse n'a pas vraiment fonctionné pour le demandeur.

Arrêtez Lion Server 10.7.5 (sur un mini-serveur 2011) aujourd'hui après que Time Machine se soit mis à fond et n'a pas réussi à sauvegarder pendant plusieurs heures en prétendant qu'il "s'arrêtait". (probablement sans rapport avec le problème, juste le pourquoi de le redémarrer.)

Arrêtez accroché - après 15 minutes environ, je l'ai éteint.

Quand il est revenu, il y avait une boule rouge à la droite de la boîte du nom d'utilisateur avec un nastygram indiquant que les comptes réseau n'étaient pas disponibles. Connecté à l'administrateur local - lorsque vous essayez d'accéder à LDAP à partir du gestionnaire de groupe de travail " Le noeud .LDAPv3 / 127.0.0.1 n'a pas pu être ouvert car une erreur inattendue de type -14006 s'est produite "est la réponse utile et amicale.

Alertes serveur indique que les certificats auto-signés ont expiré. Offres à réparer / recréer. Ne semble pas aider. Redémarrez après cela - ne semble toujours pas aider. Vraisemblablement, le problème est survenu au premier redémarrage après leur expiration; Cela ne semble toutefois pas être vrai, compte tenu des dates d'expiration. Le serveur a redémarré plusieurs fois et LDAPv3 a été heureux jusqu’à aujourd’hui.

Ce sujet à AFP548 (D'abord, j'ai entendu parler de ce forum) semble lié, mais son application peut être difficile étant donné que mes certificats d'auto-signature sont expirés et non supprimés.

Il faudra tard dans la nuit pour remettre mon serveur de fichiers en forme avant que d'autres personnes n'arrivent et ne l'utilisent. Au moins, j'ai les fichiers, mais nous serions reconnaissants d'avoir une meilleure idée que celle fournie par les sujets liés.

Au moment où LDAP et Open Directory s'en mêlent, je regarde toujours vers Kerberos.

Roulez avec kadmin et ktutil et voyez si Kerberos fonctionne correctement. Regardez bien pour obtenir vos certificats A-OK. Vérifiez que le DNS et le DNS inversé donnent des réponses valides.

Copiez la base de données LDAP, supprimez-la et recommencez pour voir si cela pose problème. Si slapd est actif, essayez quelques recherches avec ldapsearch.

Je trouve que je ne me souviens pas exactement de ce que j'ai fait lorsque j'ai posé cette question à l'origine - je pense que j'ai peut-être fini par recréer la base de données (comme douloureusement à la main.) Quoi qu'il en soit, deux ans plus tard, c'est à nouveau arrivé (et exactement le même condition de démarrage - l’arrêt n’a pas été arrêté lorsque la machine temporelle s'était "arrêtée" pendant des jours sans arrêt ni sauvegarde, de sorte que la machine a dû être mise hors tension.)

Les suggestions dans la nature semblent être réparties entre les commandes 10.6 et 10.7, même lorsqu'elles parlent d'un serveur lion, ou peut-être qu'il y a des modifications de commandes précoces et tardives 10.7; Je ne me souviens certainement pas avec précision. La réponse que j'ai liée à un commentaire ci-dessus ( Comment réparer Open Directory qui échoue (la base de données "cn = authdata" ne peut pas être ouverte, erreur 12) après le blocage ) semble utile, mais le problème se reproduit au plus tard en quelques heures - et j’ai dû exécuter ce que les témoins de la réponse indiqueraient à la fois comme étant des commandes 10.6 et 10.7 pour que cela fonctionne.

Donc, sur mon système Lion (10.7.5) exécutant Server.app 10.7.5 (1.5.0), je devrais faire:

$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
$ sudo db_recover -h /var/db/openldap/authdata/ # Mac OS X 10.7
$ sudo db_recover -h /var/db/openldap/openldap-data/ # Mac OS X 10.6 (this one too, even on 10.7)
$ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Redémarrer ou non semblait faire peu de différence. Cela fonctionnerait pendant un temps relativement court, puis à nouveau. Les utilisateurs étaient agités, l'administrateur système était privé de sommeil et grincheux.

Finalement, j'ai trouvé une procédure qui, une fois encore, a dû être légèrement modifiée sur un site sur lequel je vais essayer de créer un lien, en tant que commentaire sur une réponse similaire au processus ci-dessus. Comme modifié pour mon système ... Après avoir effectué les réparations ci-dessus (vous pouvez ignorer l'étape de chargement ci-dessus)

1) sudo à la racine

sudo -i

2) arrêter LDAP (si vous l'avez redémarré)

launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

3) dump une copie de la base de données Open Directory dans un fichier texte au format LDIF

mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif

Si vous ne faites pas les réparations (ou je suppose, si elles ne fonctionnent pas), le fichier .ldif sera vide - vérifiez donc que cela semble raisonnable, sinon, commencez à creuser dans les sauvegardes.

4) déplacez les anciens fichiers (corrompus) de la base de données (ou supprimez-les).

cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/

assurez-vous de ne pas déplacer, renommer ou supprimer le fichier nommé DB_CONFIG. C’est nécessaire.

5) recréer la base de données à partir du fichier de format LDIF

cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex

Vous verrez des avertissements inoffensifs pendant slapadd. Ignore les.

Redémarrer LDAP

launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Et à ce stade, vous pouvez aussi bien redémarrer. Commentaire de "Ranj" sur cette page (avec les commandes "service" qui ne fonctionnent pas pour moi) http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/

Je ne jurerai pas que ça a guéri, parce que je pensais l'avoir fait guérir il y a deux jours et je me suis trompé, mais ça a duré 12 heures sans foutre en l'air, ce qui est une amélioration par rapport à ça depuis 2-1 / 2 il y a quelques jours.

J'ai également réagi à un problème gênant (probablement lié, qui sait exactement ce qui le contrarie) lié aux comptes créés avec le gestionnaire de groupe de travail plutôt qu'avec server.app - ils ont une entrée incorrecte (untitled_1 plutôt que le nom abrégé de l'utilisateur) dans AltSecurityIdentities. J'ai essayé le correctif comme automatisé par ce script https://github.com/arekdreyer/Lion-Server/blob/master/FixAltSecurityIdentities.sh et également à la main, comme décrit sur plusieurs sites (soit via une interface graphique, soit en décomposant la ligne de commande à partir du script lié) et il échouerait à chaque fois que j'écrirais. Une fois le correctif ci-dessus résolu pour reconstruire les bases de données, je pouvais réécrire les données incorrectes. Évidemment, le "remède" consiste à créer des comptes uniquement avec Server.app (mais si vous rencontrez ce problème, vous ne pourrez pas le faire avant d'avoir résolu le problème ...)

Enfin, cette joyeuse expérience me rappelle de cracher une

slapcat -l LDAPBackup<date>.ldif

sur une base plus régulière pour rendre le processus de récupération moins pénible (ainsi que pour mettre "ce que j'ai fait quand cette chose s'est produite" ici comme une réponse au cas où cela se reproduirait - ou à quelqu'un d'autre.)

Pendant ce temps, toute cette activité a également contribué à cristalliser le sentiment que MacOS Server avait été malmené dans un panier à main après 10h06. Étant donné que la seule chose que cette machine fait vraiment est le service de fichiers, je vais probablement le remplacer par une boîte Nas4Free. , ou peut-être deux cases en configuration HAST. Je ne suis pas du tout intéressé par les plaisirs que 10.11 apporte au désordre total qu'est Server.app (à mon humble avis, cette semaine) et je ne peux pas commencer à dire à quel point je suis ravi de ne pas passer à la version 10.11, mais la non-option à l'époque de "tous les logiciels ne proviennent que de l'App Store, et vous ne pouvez obtenir aucune version de votre choix, uniquement les versions les plus récentes".