Trovo che non ricordo esattamente cosa ho fatto quando ho fatto questa domanda originariamente - Penso che potrei aver finito per ricreare il database (come dolorosamente a mano.) Comunque, due anni dopo è successo di nuovo (e esattamente la stessa condizione di partenza - l'arresto non si è arrestato quando la macchina del tempo si è "arrestata" per giorni senza fermarsi, o il backup, quindi la macchina doveva essere spenta.)
I suggerimenti in natura sembrano essere suddivisi tra i comandi 10.6 e 10.7 anche quando dicono server leone, o forse ci sono modifiche di comando in anticipo e in ritardo di 10,7; Certamente non ricordo precisamente. La risposta a cui ho collegato in un commento sopra ( Come risolvere la mancanza di Open Directory (il database" cn = authdata "non può essere aperto, err 12) dopo l'hang ) sembrava utile, ma il problema si ripresentava in poche ore al massimo - e in realtà dovevo eseguire quello che per le luci della risposta sarebbero stati entrambi i comandi 10.6 e 10.7, anche per funzionare.
Quindi, sul mio sistema Lion (10.7.5) che esegue Server.app 10.7.5 (1.5.0), dovrei fare:
$ 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
Il riavvio o meno sembrava fare poca differenza. Funzionerebbe per un tempo relativamente breve, poi cazzerebbe di nuovo. Gli utenti erano irrequieti, il sysadmin era privato del sonno e scontroso.
Alla fine ho trovato una procedura che ancora una volta doveva essere in qualche modo modificata su un sito che proverò a collegare di nuovo, come un commento su una risposta simile al processo di cui sopra. Come modificato per il mio sistema ... Dopo aver eseguito le riparazioni di cui sopra (puoi saltare il passaggio di caricamento sopra)
1) sudo per root
sudo -i
2) shutdown LDAP (se lo avvii di nuovo)
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
3) scaricare una copia del database Open Directory in un file di testo in formato LDIF
mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif
Se non fai le riparazioni (o suppongo, se non funzionano) il file .ldif sarà vuoto - quindi controlla che sia ragionevole, e in caso contrario, inizia a scavare nei backup.
4) sposta i vecchi (corrotti) file di database (o rimuovili).
cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/
assicurati di non spostare, rinominare o eliminare il file denominato DB_CONFIG. È necessario.
5) ricrea il database dal file di formato LDIF
cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex
Vedrai alcuni avvertimenti innocui durante slapadd. Ignorali.
Riavvia LDAP
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
E a questo punto potresti anche riavviarti. Commento di "Ranj" in questa pagina (con comandi "di servizio" che non funzionano per me) link
Non giuro che è guarito, perché pensavo di averlo guarito due giorni fa e ho sbagliato, ma è eseguito per 12 ore senza rovinare totalmente, il che è un miglioramento su dove è stato dal 2 1/2 giorni fa.
Ho anche twittato su un problema fastidioso (possibilmente correlato, che sa esattamente cosa sconvolge) relativo agli account creati con workgroup manager piuttosto che con server.app - hanno una voce errata (untitled_1 piuttosto che il nome utente) in AltSecurityIdentities. Ho provato la correzione come automatizzata da questo script link e anche a mano come descritto in diversi siti (tramite GUI o decostruendo la riga di comando dallo script collegato) e fallirebbe ogni volta che andavo a scrivere. Una volta eseguita la suddetta correzione per ricostruire i database, potevo effettivamente riscrivere i dati errati. Evidentemente la "cura" è creare account solo con Server.app (ma se hai questo problema, non puoi, fino a dopo averli risolti ...)
Infine, mi viene in mente questa gioiosa esperienza di sputare un
slapcat -l LDAPBackup<date>.ldif
su base più regolare per rendere il processo di recupero meno agonizzante (oltre a mettere effettivamente "ciò che ho fatto quando è accaduta questa cosa" qui come un astore nel caso in cui accada di nuovo - o a qualcun altro.)
Nel frattempo, tutta questa faccenda ha anche contribuito a cristallizzare la sensazione che MacOS Server sia andato a segno in un handbasket dopo il 10.6, quindi dato che l'unica cosa che questa macchina fa veramente è il servizio file, probabilmente andrò a sostituirlo con una scatola Nas4Free o forse due in configurazione HAST. Sono in qualche modo meno interessato a ciò che delizia 10.11 porta al caos totale che è Server.app (IMHO a questo punto in questa settimana) e non posso iniziare a dire quanto sono entusiasta che l'aggiornamento a qualsiasi cosa tranne 10.11 sia un non-option nei giorni in cui "tutto il software proviene solo dall'app store e non è possibile ottenere alcuna versione che ti piace, solo quelle con margini sanguinanti."