Re: [bofhers] Recuperar base de datos de Openldap
- From: Alberto cmoft <albertocmoft@xxxxxxxxx>
- To: bofhers@xxxxxxxxxxxxx
- Date: Thu, 9 Jan 2014 10:21:14 +0100
Buenos días.
Por partes:
El 8 de enero de 2014, 23:51, Juan Luis Aranda <dasmandr@xxxxxxxxx>escribió:
>
> Antes de nada, seguro que tenéis backup de las entradas de LDAP [1]. A que
> sí :)
>
>
Sí, claro. De mayo. (Aquí le tienen alergía a los backups, pero eso es otra
historia :-/) Existe la posibilidad de que tengamos alguno más moderno,
pero no tengo demasiada esperanza
> Si está cacheado "bien", aunque el servidor esté en el otro barrio,
> debería funcionar. A mí me funciona :)
>
Entonces supongo que estará cacheado mal. Deja conectar cuando el servidor
no responde (porque no hay red, está parado, etc), pero si el server
responde diciendo que no encuentra el user, no deja entrar.
> > 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.
>
Sí, estuve probando con una copia y las cosas de db4.7-util, sin suerte.
Voy a volver a intentarlo con lo que ha puesto Feina.
> A no ser que sea problema de permisos. Y por la pinta que tiene no me
> extrañaría.
>
Los permisos de /var/lib/ldap :
root@server:/var/lib# ls -l ldap
total 11664
-rw-r----- 1 openldap openldap 4096 2014-01-08 21:49 alock
-rw------- 1 openldap openldap 24576 2014-01-08 21:49 __db.001
-rw------- 1 openldap openldap 319488 2014-01-09 09:46 __db.002
-rw------- 1 openldap openldap 2629632 2014-01-09 09:46 __db.003
-rw------- 1 openldap openldap 98304 2014-01-08 23:40 __db.004
-rw------- 1 openldap openldap 1179648 2014-01-09 09:46 __db.005
-rw------- 1 openldap openldap 32768 2014-01-08 23:40 __db.006
-rw-r----- 1 openldap openldap 96 2013-06-21 11:08 DB_CONFIG
-rw------- 1 openldap openldap 8192 2013-12-27 12:26 dn2id.bdb
-rw------- 1 openldap openldap 32768 2013-12-27 12:26 id2entry.bdb
-rw-r----- 1 openldap openldap 10485760 2014-01-08 22:19 log.0000000001
-rw-r----- 1 openldap openldap 45056 2013-12-11 18:38 objectClass.bdb
> [1] Si no tienes backup no hay problema, seguro que tienes tiempo libre
> para picarte de nuevo los usuarios }:)
>
Creo que la respuesta de $BOSS en ese caso sería algo como "Pues a la porra
con el ldap, usuarios locales"
> P.S: ¿dc=example,dc=org? ¡Boh, que cutrez!, ni para cambiar los nombres de
> los jautús.
>
dc=example,dc=org es cortersía del Buscar y Reemplazar de gedit :-P (y no,
no lo estoy haciendo sobre el original, sino sobre la copia que tengo en mi
pc, por aquello de no guardar sin querer)
El 9 de enero de 2014, 8:45, Feina Centdos <feina102@xxxxxxxxx> escribió:
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?
>
No, la linea siguiente es justo la de sldap starting:
Jan 8 21:24:28 minsky slapd[10870]: @(#) $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:24:28 minsky slapd[10871]: hdb_db_open: database
"dc=gsi,dc=dit,dc=upm,dc=es": unclean shutdown detected; attempting
recovery.
Jan 8 21:24:28 minsky slapd[10871]: slapd starting
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".
>
Sin hacer nada, tal cual tenía los archivos dice que --->
http://pastebin.com/9d7Emazf
>
> Saludos.
>
>
>
Voy a probar con el db_recover y os cuento, gracias a los dos :-)
Other related posts:
