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".