2 votos

Después de la actualización de seguridad 2019-003, OpenLDAP está dañado. ¿Cómo puedo recuperarme?

He instalado la Actualización de Seguridad 2019-003 esta mañana. La actualización salió mal, y producido en (postgres) inducida por el pánico en el host, un segundo intento tuvo éxito. Después de la actualización, slapd no se abrirá más.

He intentado restaurar /private/var/db/{krb5kdc,openldap,auth} a partir de una copia de seguridad Time Machine (a través de Cmd-R reiniciar, incluyendo convirtiendo temporalmente la SIP off) pero lo que puedo hacer, yo no puedo hacerlo funcionar de nuevo. db_recover no servirá de nada. slapd prueba produce:

bash-3.2# /usr/libexec/slapd -T test
5cdfeed8 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
5cdfeed8 bdb_db_open: database "cn=authdata": unclean shutdown detected; attempting recovery.
5cdfeed8 bdb_db_open: database "cn=authdata": recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded
bash-3.2# slaptest -v
5cdfef28 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
5cdfef28 bdb_db_open: database "cn=authdata": unclean shutdown detected; attempting recovery.
5cdfef28 bdb_db_open: database "cn=authdata": recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded

¿Cómo puedo recuperar esto desde mi Máquina del Tiempo de copia de seguridad sin restaurar completamente el servidor y la sobrescritura de todo lo demás?

Al parecer, la restauración he intentado (copia openldap través de una Máquina del Tiempo de copia de seguridad) no funciona como Postgres DB-recuperación se opone a lo que es en authdata:

bash-3.2# db_recover -cv -h authdata/
Finding last valid log LSN: file: 31 offset 174121
Recovery starting from [30][28]
db_recover: Log sequence error: page LSN 23 1709981; previous LSN 30 28
db_recover: Recovery function for LSN 30 8130 failed on forward pass
db_recover: PANIC: Invalid argument
db_recover: process-private: unable to find environment
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
bash-3.2# db_recover -cv -h openldap-data/
Finding last valid log LSN: file: 1 offset 1754044
Recovery starting from [1][28]
Recovery complete at Sat May 18 13:45:46 2019
Maximum transaction ID 80000cad Recovery checkpoint [1][1754044]

2voto

gctwnl Puntos 126

He sido capaz de reparar esto. Es posible que haya sido suerte. Lo que yo hice:

  1. Copia todos los private/var/db/openldap/authdata de todos los tiempos de la Máquina copias de seguridad en un directorio de trabajo (for i in 2019*; do ditto $i/DumbledoreRoot/private/var/db/openldap/authdata/ /tmp/$i/authdata; done). Mi volumen de arranque se llama DumbledoreRoot.
  2. Ejecutar la recuperación de errores en todos los authdata copias, para ver cuales son recuperable (for i in 2019-0*; do echo $i; db_recover -cv -h $i/authdata/; done)
  3. La mayoría estaría de informar de un error. Esto no es extraño, la Máquina del Tiempo no puede realmente una copia de seguridad de datos de copia de respaldo de una base de datos activa en su mayoría se presenta resultados incorrectos en la copia de seguridad. Me pregunto cómo restaurar de una Vez Máquina hace esto, sin embargo. Debe haber una mejor manera.
  4. Reemplace /private/var/db/authdata con lo que está en la copia de seguridad. Yo probablemente debería haber copiado openldap-data , dado lo sucedió a continuación
  5. Corrió slapd -T test e di cuenta de que todavía había algunos casos de corrupción (aunque diferentes):

Salida:

bash-3.2# /usr/libexec/slapd -T test
5cdff90d bdb_db_open: database "dc=Dumbledore,dc=local": unclean shutdown detected; attempting recovery.
5cdff90d bdb_db_open: database "dc=Dumbledore,dc=local": recovery skipped in read-only mode. Run manual recovery if errors are encountered.
5cdff90d bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
5cdff90d bdb_db_open: database "cn=authdata": unclean shutdown detected; attempting recovery.
5cdff90d bdb_db_open: database "cn=authdata": recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded

Desesperó. A continuación, en un capricho, comenzó a Abrir el Directorio del Servidor.aplicación y para mi sorpresa, empezó y mi red de cuentas de usuario, estaban de vuelta.

Por lo tanto, estoy probablemente sólo la suerte y la mejor de las respuestas pueden ayudar a futuros problemas.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X