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 dans douloureusement à la main.) Quoi qu'il en soit, deux ans plus tard, cela s'est reproduit (et exactement la même condition de démarrage - l'arrêt ne s'est pas arrêté alors que la machine à remonter le temps avait été "arrêtée" pendant des jours sans s'arrêter, ou sauvegarder, de sorte que la machine devait ê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 mentionnent le serveur lion, ou peut-être y a-t-il des changements de commandes 10.7 précoces et tardifs ; je ne m'en souviens certainement pas précisément. La réponse dont j'ai donné le lien dans un commentaire ci-dessus ( Comment réparer l'échec d'Open Directory (la base de données "cn=authdata" ne peut pas être ouverte, err 12) après une interruption de service ? ) semblait utile, mais le problème s'est reproduit au bout de quelques heures tout au plus - et j'ai dû exécuter ce qui, d'après les lumières de la réponse, serait des commandes 10.6 et 10.7 pour que cela fonctionne.
Ainsi, sur mon système Lion (10.7.5) exécutant Server.app 10.7.5(1.5.0), je devrais faire ce qui suit :
$ 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
Le fait de redémarrer ou non ne semble pas faire de différence. Le système fonctionnait pendant un temps relativement court, puis se détraquait à nouveau. Les utilisateurs étaient rétifs, l'administrateur système manquait de sommeil et était grincheux.
Finalement, j'ai trouvé une procédure qui, une fois de plus, a dû être quelque peu modifiée sur un site que je vais essayer de linker à nouveau, en tant que commentaire sur une réponse similaire à la procédure ci-dessus. Tel que modifié pour mon système... Après avoir effectué les réparations ci-dessus (vous pouvez sauter l'étape de chargement ci-dessus)
1) sudo pour Root
sudo -i
2) arrêter LDAP (si vous l'avez redémarré)
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
3) vidanger une copie de la base de données de l'Open Directory dans un fichier texte au format LDIF
mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif
Si vous n'effectuez pas les réparations (ou, je suppose, si elles ne fonctionnent pas), le fichier .ldif sera vide - vérifiez donc qu'il semble raisonnable, et sinon, commencez à creuser dans les sauvegardes.
4) déplacer les anciens fichiers de base de données (corrompus) (ou les supprimer).
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. Il est nécessaire.
5) recréer la base de données à partir du fichier au format LDIF
cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex
Vous verrez quelques avertissements inoffensifs pendant le slapadd. Ignorez-les.
Redémarrer LDAP
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Et à ce stade, vous pourriez tout aussi bien rebooter, aussi. Commentaire de "Ranj" sur cette page (avec des 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 jurerais pas qu'il est durci, car je pensais l'avoir fait il y a deux jours et je me suis trompé, mais il a fonctionné pendant 12 heures sans se détériorer totalement, ce qui est une amélioration par rapport à ce qu'il était il y a 2 jours et demi.
J'ai également découvert un problème ennuyeux (peut-être lié, qui sait exactement ce qui dérange la chose) concernant les 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 court de l'utilisateur) dans AltSecurityIdentities. J'ai essayé la correction automatisée par ce script. https://github.com/arekdreyer/Lion-Server/blob/master/FixAltSecurityIdentities.sh et aussi à la main comme décrit dans plusieurs sites (soit via l'interface graphique, soit en déconstruisant la ligne de commande à partir du script lié) et cela échouait à chaque fois que je voulais écrire. Une fois que j'avais fait le correctif ci-dessus pour reconstruire les bases de données, je pouvais effectivement réécrire les données incorrectes. De toute évidence, le "remède" est de créer des comptes uniquement avec Server.app (mais si vous avez ce problème, vous ne pouvez pas, jusqu'à ce que vous les corrigiez ...)
Enfin, cette joyeuse expérience me rappelle qu'il faut cracher un
slapcat -l LDAPBackup<date>.ldif
sur une base plus régulière afin de rendre le processus de récupération moins angoissant (ainsi que de mettre "ce que j'ai fait quand cette chose est arrivée" ici comme réponse au cas où cela se reproduirait - ou à quelqu'un d'autre).
Pendant ce temps, toute cette affaire a également contribué à cristalliser le sentiment que MacOS Server est parti en vrille après la 10.6, donc étant donné que la seule chose que cette machine fait vraiment est le service de fichiers, je vais probablement la remplacer par une boîte Nas4Free, ou peut-être deux dans la configuration HAST. Je suis en quelque sorte moins qu'intéressé par les délices que 10.11 apporte au désordre total qu'est Server.app (IMHO à ce stade de la semaine) et je ne peux pas commencer à dire à quel point je ne suis pas ravi que la mise à niveau vers autre chose que 10.11 soit une non-option à l'époque du "tous les logiciels viennent seulement de l'app store, et vous ne pouvez pas obtenir n'importe quelle version que vous aimez, seulement les versions de pointe".
