Re: [bofhers] Recuperar base de datos de Openldap
- From: Juan Luis Aranda <dasmandr@xxxxxxxxx>
- To: bofhers@xxxxxxxxxxxxx
- Date: Wed, 8 Jan 2014 23:51:16 +0100
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.
Other related posts:
