Creo que no recuerdo exactamente lo que hice cuando formulé esta pregunta originalmente. Creo que terminé recreando la base de datos (como dolorosamente a mano). De todos modos, dos años después sucedió nuevamente (y exactamente la misma condición de inicio: el apagado no se detuvo cuando la máquina del tiempo estuvo "deteniéndose" durante días sin detenerse, o retrocediendo, por lo que la máquina tuvo que apagarse.)
Las sugerencias en la naturaleza parecen estar divididas entre los comandos 10.6 y 10.7 incluso cuando dicen servidor leon, o tal vez hay cambios tempranos y tardíos en el comando 10.7; Ciertamente no recuerdo con precisión. La respuesta a la que me he vinculado en un comentario anterior ( Cómo reparar el Open Directory con errores (la base de datos" cn = authdata "no se puede abrir, error 12) después de colgar ) pareció útil, pero el problema se repitió en unas pocas horas como máximo - y en realidad tuve que ejecutar lo que para las luces de la respuesta serían los comandos 10.6 y 10.7 para que incluso eso funcione.
Entonces, 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 parece hacer poca diferencia. Funcionaría por un tiempo relativamente corto, y luego volvería a cagarse. Los usuarios estaban inquietos, el administrador del sistema estaba privado de sueño y gruñón.
Finalmente, encontré un procedimiento que una vez más tuvo que ser modificado un poco en un sitio al que intentaré vincular nuevamente, como comentario sobre una respuesta similar al proceso anterior. Modificado para mi sistema ... Después de realizar las reparaciones anteriores (puede omitir el paso de carga anterior)
1) sudo a root
sudo -i
2) apagar LDAP (si lo volviste a iniciar)
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
3) volcar una copia de la base de datos de Open Directory en un archivo de texto de formato LDIF
mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif
Si no hace las reparaciones (o supongo que, si no funcionan), el archivo .ldif estará vacío, así que verifique que parezca razonable y, si no, comience a buscar copias de seguridad.
4) Mueva los archivos de base de datos antiguos (corruptos) fuera del camino (o elimínelos).
cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/
asegúrese de no mover, renombrar o eliminar el archivo llamado DB_CONFIG. Es necesario.
5) vuelva a crear la base de datos a partir del archivo de formato LDIF
cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex
Verás algunas advertencias inofensivas durante slapadd. Ignorarlos.
Reiniciar LDAP
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Y en este punto, puede que también reinicies. Comentario por "Ranj" en esta página (con comandos de "servicio" que no funcionan para mí) enlace
No juraré que se ha curado, porque pensé que lo había hecho hace dos días y estaba equivocado, pero duró 12 horas sin arruinarlo por completo, lo cual es una mejora en el estado en que se encuentra desde 2 Hace 1/2 días.
También me preocupé por un problema molesto (posiblemente relacionado, que sabe exactamente qué es lo que le molesta) relacionado con las cuentas creadas con el administrador 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. Probé la solución como automatizado por este script enlace y también a mano como se describe en varios sitios (ya sea a través de GUI o mediante la deconstrucción de la línea de comandos desde el script vinculado) y fallaría cada vez que escribiera. Una vez que había hecho la corrección anterior para reconstruir las bases de datos, podía reescribir los datos incorrectos. Evidentemente, el "remedio" es crear cuentas solo con Server.app (pero si tiene este problema, no puede hacerlo hasta después de corregirlos ...)
Finalmente, esta experiencia alegre me recuerda a escupir un
slapcat -l LDAPBackup<date>.ldif
de forma más regular para que el proceso de recuperación sea menos agonizante (así como para poner "lo que hice cuando sucedió esto" aquí como una respuesta en caso de que vuelva a suceder, o para otra persona).
Mientras tanto, todo este negocio también ha ayudado a cristalizar la sensación de que el Servidor MacOS se fue al diablo en una bolsa de mano después de las 10.6, por lo que dado que lo único que realmente hace esta máquina es el servicio de archivos, probablemente voy a sustitúyalo por un cuadro Nas4Free, o tal vez por dos cuadros en la configuración HAST. De alguna manera, estoy menos que interesado en lo que deleita el 10.11 que trae al desastre total que es Server.app (IMHO en este momento en esta semana) y no puedo comenzar a decir lo emocionado que estoy de que actualizar a otra cosa que no sea el 10.11 es un no está disponible en los días en que "todo el software viene solo de la tienda de aplicaciones, y no puede obtener ninguna versión que le guste, solo las que están a la vanguardia".