Re: [bofhers] Recuperar base de datos de Openldap
- From: Feina Centdos <feina102@xxxxxxxxx>
- To: bofhers@xxxxxxxxxxxxx
- Date: Thu, 9 Jan 2014 08:45:41 +0100
El 8 de enero de 2014, 23:51, Juan Luis Aranda <dasmandr@xxxxxxxxx>escribió:
>
> El 08/01/2014 22:03, "Alberto cmoft" <albertocmoft@xxxxxxxxx> escribió:
>
> > Vale, perdón por la poca claridad, intento aclarar algo:
> >
> > Salvo para hacer el slapcat, el servicio está corriendo, sí. Por otro
> lado:
> >
> > - El phpmyadmin, aunque conecta, dice que "dc=example,dc=org \n This
> base entry does not exist"
> >
>
> Antes de nada, seguro que tenéis backup de las entradas de LDAP [1]. A que
> sí :)
>
> > - Usando ldapsearch, me dice que no such object:
> > root@server:/var/lib# ldapsearch -h 127.0.0.1 -D
> cn=admin,dc=example,dc=org -W -b "dc=example,dc=org" -s sub
> "(objectclass=*)"
> > Enter LDAP Password:
> > # extended LDIF
> > #
> > # LDAPv3
> > # base <dc=example,dc=org> with scope subtree
> > # filter: (objectclass=*)
> > # requesting: ALL
> > #
> >
> > # search result
> > search: 2
> > result: 32 No such object
> >
> > # numResponses: 1
> >
> > - El propio server (y todos los demás cacharros del laboratorio) estaban
> configurados para autenticar contra el ldap. Además de no autenticar,
> haciendo "finger usuario" dice que no existe el usuario. En principio,
> están puestos para que si el ldap no responde tengan el usuario cacheado, y
> aún así permitan conectar, pero en este caso no dejan autenticar (gdm de
> hecho se queda ligeramente colgado, pero creo que ese es otro tema)
> >
>
> Si está cacheado "bien", aunque el servidor esté en el otro barrio,
> debería funcionar. A mí me funciona :)
>
> > El slapcat -n 0 devuelve esto --> http://pastebin.com/tjhZWpWG
> > El salpcat -n 1 no devuelve nada (Y me refiero a literalmente nada, un
> string vacio)
> >
>
> cn=config parece estar bien por lo que puedo ver
>
> > Por otro lado, en el /var/log/syslog tengo cosas como:
> > Jan 8 21:49:36 server kernel: [11642.120014] parport0: FIFO is stuck
> > Jan 8 21:49:36 server kernel: [11642.160013] parport0: BUSY timeout (1)
> in compat_write_block_pio
> > Jan 8 21:49:41 server slapd[14808]: @(#) $OpenLDAP: slapd 2.4.21 (Aug
> 10 2010 17:08:36) $#012#011buildd@yellow
> :/build/buildd/openldap-2.4.21/debian/build/servers/slapd
> > Jan 8 21:49:41 server slapd[14809]: slapd starting
> > Jan 8 21:49:46 server kernel: [11652.160020] DMA write timed out
> > Jan 8 21:50:01 server CRON[14814]: pam_ldap: could not open secret file
> /etc/ldap.secret (No such file or directory)
> > Jan 8 21:50:01 server CRON[14815]: pam_ldap: could not open secret file
> /etc/ldap.secret (No such file or directory)
> > Jan 8 21:50:01 server CRON[14814]: pam_ldap: ldap_search_s No such
> object
> > Jan 8 21:50:01 server CRON[14815]: pam_ldap: ldap_search_s No such
> object
> >
> > Y un poco antes, entre la versión de OpenLDAP y el "slapd starting":
> > Jan 8 21:24:28 server slapd[10871]: hdb_db_open: database
> "dc=example,dc=org": unclean shutdown detected; attempting recovery.
> >
>
> La base de datos de entradas está malamente, parece. Creo recordar que hay
> alguna utilidad para intentar repararla. Son los archivos en /var/lib/ldap.
>
> A ver si mañana tengo un rato para buscar esa utilidad. De todas formas
> son, creo, bases de datos Berkeley DB.
>
> A no ser que sea problema de permisos. Y por la pinta que tiene no me
> extrañaría.
>
> > Estoy suponiendo que los errores de DMA no tienen que ver con eso, y que
> son cosa del cups, pero de los demás no lo tengo nada claro.
> >
>
> Ni idea.
>
> > Salu2 y gracias por la paciencia :-)
>
> A mandar.
>
> [1] Si no tienes backup no hay problema, seguro que tienes tiempo libre
> para picarte de nuevo los usuarios }:)
>
> P.S: ¿dc=example,dc=org? ¡Boh, que cutrez!, ni para cambiar los nombres de
> los jautús.
>
Buenos días, una preguntilla:
Después de la línea
"Jan 8 21:24:28 server slapd[10871]: hdb_db_open: database
"dc=example,dc=org": unclean shutdown detected; attempting recovery."
hay algún resultado del attempting recovery?
Sino puedes intentar http://www.grotan.com/ldap/restore.txt (antes parar
openldap y copia de seguridad de todos los ficheros de /var/lib/ldap)
Después de aplicar los procedimientos (básicamente el db_recover) del link
comprueba los permisos de los ficheros (si los has hecho como root y los ha
creado de nuevo, el servicio de ldap no arrancará ya que el owner ha de ser
el del usuario con el que se ejecuta el servicio).
Intenta arrancar slapd desde el terminal slapd -u <usuario_servicio_ldap>
-d <debug_level> y a ver que "escupe".
Saludos.
Other related posts:
