Me parece que no recuerdo exactamente lo que hice cuando originalmente hice esta pregunta - creo que pude haber terminado recreando la base de datos (como dolorosamente a mano.) De todos modos, dos años después sucedió de nuevo (y exactamente la misma condición de inicio - el apagado no se apagó cuando la máquina del tiempo había estado "parando" durante días sin parar, o haciendo una copia de seguridad, por lo que la máquina tuvo que ser apagada).
Las sugerencias en la naturaleza parecen estar divididas entre los comandos 10.6 y 10.7 incluso cuando dicen servidor de leones, o tal vez hay cambios de comandos 10.7 tempranos y tardíos; ciertamente no recuerdo con precisión. La respuesta que he enlazado en un comentario anterior ( Cómo arreglar el fallo de Open Directory (la base de datos "cn=authdata" no se puede abrir, err 12) después de un cuelgue ) parecía útil, pero el problema se repitió en unas pocas horas como máximo - y de hecho tuve que ejecutar lo que según las luces de la respuesta serían ambos comandos 10.6 y 10.7 para que incluso eso funcionara.
Así, en mi sistema Lion (10.7.5) ejecutando Server.app 10.7.5(1.5.0), tendría que hacer:
$ 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
Reiniciar o no parecía hacer poca diferencia. Funcionaba durante un tiempo relativamente corto y luego volvía a fallar. Los usuarios estaban intranquilos, el administrador del sistema estaba privado de sueño y malhumorado.
Finalmente encontré un procedimiento que una vez más tuvo que ser algo modificado en un sitio que intentaré enlazar de nuevo, como comentario a una respuesta similar al proceso anterior. Como modificado para mi sistema...Después de hacer las reparaciones anteriores (se puede omitir el paso de carga anterior)
1) sudo a Root
sudo -i
2) cerrar el LDAP (si lo has iniciado de nuevo)
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
3) volcar una copia de la base de datos del Open Directory en un archivo de texto con formato LDIF
mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif
Si no haces las reparaciones (o supongo que si no funcionan) el archivo .ldif estará vacío - así que comprueba que parece razonable, y si no, empieza a indagar en las copias de seguridad.
4) mover los viejos archivos de la base de datos (corruptos) fuera del camino (o eliminarlos).
cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/
asegúrese de no mover, renombrar o borrar el archivo llamado DB_CONFIG. Es necesario.
5) volver a crear la base de datos a partir del archivo en formato LDIF
cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex
Verás algunas advertencias inofensivas durante el slapadd. Ignórelas.
Reiniciar LDAP
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Y llegados a este punto también podrías reiniciar. Comentario de "Ranj" en esta página (con comandos de "servicio" que no me funcionan) http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
No voy a jurar que está curado, porque creía que lo tenía curado hace dos días y me equivoqué, pero ha funcionado durante 12 horas sin fastidiar del todo, lo cual es una mejora respecto a donde estaba desde hace 2 días y medio.
También me di cuenta de un problema molesto (posiblemente relacionado, quién sabe exactamente qué es lo que molesta) relacionado con las cuentas creadas con el gestor de grupos de trabajo en lugar de con server.app - tienen una entrada incorrecta (untitled_1 en lugar del nombre corto del usuario) en AltSecurityIdentities. Intenté el arreglo automatizado por este script https://github.com/arekdreyer/Lion-Server/blob/master/FixAltSecurityIdentities.sh y también a mano como se describe en varios sitios (ya sea a través de la GUI o deconstruyendo la línea de comandos desde el enlace script) y fallaba cada vez que iba a escribir. Una vez que hice el arreglo anterior para reconstruir las bases de datos, pude volver a escribir los datos incorrectos. Evidentemente la "cura" es crear cuentas sólo con Server.app (pero si tienes este problema, no puedes, hasta después de arreglarlas...)
Finalmente, esta alegre experiencia me recuerda que debo escupir un
slapcat -l LDAPBackup<date>.ldif
de forma más regular para que el proceso de recuperación sea menos agonizante (además de poner aquí "lo que hice cuando pasó esto" como respuesta en caso de que vuelva a pasar o a otra persona).
Mientras tanto, todo este asunto también ha ayudado a cristalizar la sensación de que MacOS Server se fue al diablo después de 10.6, así que dado que la única cosa que esta máquina realmente hace es el servicio de archivos, probablemente voy a reemplazarlo con una caja Nas4Free, o tal vez dos cajas en la configuración HAST. Estoy de alguna manera menos que interesado en lo que las delicias 10.11 trae a la absoluta confusión que es Server.app (IMHO en este punto en esta semana) y no puedo empezar a decir lo emocionado que estoy no que la actualización a cualquier cosa, pero 10.11 es una no-opción en los días de "todo el software viene sólo de la tienda de aplicaciones, y no se puede obtener cualquier versión que te gusta, sólo el sangrado de borde".
