Re: [bofhers] Recuperar base de datos de Openldap
- From: f5inet <f5inet@xxxxxxxxx>
- To: bofhers <bofhers@xxxxxxxxxxxxx>
- Date: Fri, 10 Jan 2014 11:56:12 +0100
Correcto Jose Carlos, ese es el modo 'oficioso' de implementar una politica
de backups. Mientras tanto, para evitarte sufrimientos, entre los pasos 1 y
2, todo buen bofh que se precie habra desviado de circulacion cualquier
ordenador de jefe de departamento, previo pretexto de instalar uno mejor
(esta estrategia funciona mejor con el ordenador de HiperBOSS) y te quedas
el antiguo para 'limpiarle los datos sensibles'. tras 3 meses, nadie se
acordara de el, y tendras un fastuoso CoreQuad, i3 o similar donde instalar
BackupPC y configurarlo en un rinconcito alejado de miradas indiscretas.
Cuando suceda la debacle, alarmate y echa horas extras a cholon (ojo,
siempre que puedas cobrarlas luego, sino, es tonteria) y recupera los
backups de backupPC. entonces puedes volver a pedir la solucion de backup
para no tener downtime.
junto con la estrategia de 'actualizar el ordenador del jefe', funciona muy
bien la estrategia de 'cambiar el ordenador antiguo del jefe de caja ATX a
una mas churretosa'. los Lusers, cuando se enteran que el jefe (que cambio
de ordenador hace 6 meses y ahora ha vuelto a cambiar a uno mas gordo)
vengan a pedirte que se lo instales a ellos (vamos, heredar el antiguo),
solo se fijan en 'la cascara', si cambias los interiores y les metes
incluso uno INFERIOR al que ellos tienen, haras la bofheada completa...
El 10 de enero de 2014, 11:41, José Carlos Cuevas
<reset.reboot@xxxxxxxxx>escribió:
> Cmoft, por norma general el tema de backups funciona así:
>
> 0) Hablas de implantar una política de backups.
> 1) «No necesitamos backups, necesitamos el espacio para otras cosas y esto
> no es barato, bla, bla bla»
> 2) Sucede el gran desastre, se pierden meses o años de trabajo.
> 3) Sudas la gota gorda recuperando todo lo posible.
> 4) «¿Y esto cómo ha sucedido?» «¿Por qué no teníamos backups»
> 5) Implementas una política de backups y arriba se obsesionan con ello.
> 6) Tras un tiempo nadie se acordará de Santa Bárbara hasta que truene.
> Pero ya conseguiste unos backups lógicos.
>
> Un saludo,
>
>
> El 10 de enero de 2014, 11:34, <jmpdbluelite@xxxxxxxxx> escribió:
>
> Mejor Mayo conocido que bueno por conocer. #FridayJokes
>>
>> Enviado desde mi dispositivo android.
>>
>>
>> -----Original Message-----
>> From: "Eduardo G. Aguilar Grandes" <yacopi88@xxxxxxxxx>
>> To: bofhers <bofhers@xxxxxxxxxxxxx>
>> Sent: vie, 10 ene 2014 11:32
>> Subject: Re: [bofhers] Recuperar base de datos de Openldap
>>
>> "De Mayo"
>> Luego se me quejan porque les casco el del día anterior.
>>
>> Suerte chacho!
>>
>>
>> El 10 de enero de 2014, 11:29, Alberto cmoft
>> <albertocmoft@xxxxxxxxx>escribió:
>>
>>> Bueno, por si a alguien le quedaba alguna duda:
>>>
>>> Al final he pillado el backup de mayo y voy a intentar recuperar los
>>> users nuevos como pueda.
>>>
>>> Gracias por la ayuda :-)
>>>
>>>
>>> El 9 de enero de 2014, 10:36, Alberto cmoft
>>> <albertocmoft@xxxxxxxxx>escribió:
>>>
>>>
>>>>
>>>>
>>>> El 9 de enero de 2014, 10:30, Feina Centdos <feina102@xxxxxxxxx>escribió:
>>>>
>>>> Más preguntas:
>>>>>
>>>>> Entiendo que las pruebas las haces con una copia en otra máquina:
>>>>> utilizas exactamente la misma configuración /etc/openldap/* a parte de los
>>>>> ficheros de datos de /var/lib/ldap? (lo del dc=example,dc=org me ha
>>>>> descolocado :()
>>>>>
>>>>>
>>>> Las pruebas ahora mismo las estoy haciendo en el propio server, previa
>>>> copia de /var/lib/ldap a /var/lib/ldap-old. Lo próximo que voy a intentar
>>>> es poner un ldap en mi maquina, pero no sé hasta que punto podré poner una
>>>> versión exactamente igual a la que tenemos en el server.
>>>>
>>>> El dc=example,dc=org lo pongo por aquello de anonimizar el nombre del
>>>> sitio donde estoy (que los que me conocéis sabéis donde es, pero esta lista
>>>> es pública y tampoco es plan). En todos los sitios donde aparece, ponía la
>>>> base que utilizamos.
>>>>
>>>>
>>>>
>>>>> Saludos
>>>>>
>>>>>
>>>>> El 9 de enero de 2014, 10:21, Alberto cmoft
>>>>> <albertocmoft@xxxxxxxxx>escribió:
>>>>>
>>>>> 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 :-)
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>>
>>
>> Saludos,
>>
>> Eduardo G. Aguilar Grandes
>>
>
>
Other related posts:
