dnsmasq y la persistencia de las IPs

A veces pasa. Te obsesionas con un problema determinado, algo nimio pero capaz de perturbar tu sueño por el mero hecho de estar ahí, de existir. Pasa el tiempo y no das con la solución y, finalmente, cansado de la situación, desistes. Pues bien, lo que suele pasar es que en un plazo de tiempo no superior a las dos semanas, la solución te busca y, claro está, te encuentra. ¡Maldito Murphy!

La última solución que me buscó y me encontró, tiene que ver con dnsmasq, el servidor de DNS y DHCP que tengo funcionando en raspas, el ordenador más importante de mi casa, ese que entra en una cajetilla de tabaco. Con la limitada capacidad de raspas no hay nada mejor que un servicio ligero y muy ágil que apenas entorpece. Mi problema, decía, tenía que ver con la asignación de direcciones IP y, básicamente consistía en que tenía todo el rango separado según el tipo de solicitante (móviles, tabletas, ordenadores personales, ordenadores de trabajo, lavadoras, tostadoras, etcétera…) y en unos pocos casos, ignoraba mis instrucciones y asignaba una IP diferente, aunque reconociese al dispositivo.

Concretamente me tenía frito que mi movil, nexus no tuviese la dirección IP 20 asignada con mimo y cariño sino la 131. Tras realizar todo tipo de ajustes en la configuración del servicio, cambios en el direccionamiento IP y un largo etcétera de pruebas, todas infructuosas, claudiqué y admití mi derrota a manos de un ordenador que se llama igual que el esqueleto de las sardinas. De eso hace un par de semanas.

Hoy sólo quería saber dónde podía encontrar una lista de los dispositivos que tienen asignada una dirección IP en dnsmasq.

Una búsqueda rápida y el primer resultado, una respuesta de una lista de email, sólo dice que la tiene en el fichero que contiene los préstamos de IPs, en /var/lib/misc/dnsmasq.leases. Y es cierto, contiene esa lista, un poco más grande de lo que esperaba. De hecho, estaba a punto de cerrar el fichero cuando un dato llamó mi atención: algunos de los equipos listados sólo habían estado conectados unas horas, mucho tiempo atrás. Mirando con más detenimiento, observé que, además, esos equipos tenían direcciones IP que deberían estar asignadas a otros, como el nexus. Y todos ellos tenían un bonito cero al principio de la línea. En este punto, sólo quería llorar.

Lo que acababa de ver era una demostración del concepto de persistencia. Al principio, cuando estaba aprendiendo a usar dnsmasq le asigné a los equipos con una IP determinada un tiempo de arrendamiento muy alto, infinito concretamente. Luego decidí cambiar el direccionamiento y, aunque cambié en la mayor parte de los casos la etiqueta infinite por 12h, no limpié la base de datos y esas IPs seguían reservadas hasta el infinito y más allá. Por eso, por mucho que intentase asignarle la 20 al nexus el servidor seguía dándole una muy superior y alejada de mis sueños de orden y categorización, puesto que ya primera ya estaba asignada por siempre jamás.

Bastó una prueba para que quisiese darle cabezazos a la pared. Detuve el servicio, borré las entradas viejas del fichero /var/lib/misc/dnsmasq.leases y volví a levantar el servicio. A continuación solicité una nueva IP desde el móvil y… dnsmasq le asignó la número 20.

Por supuesto, ya le había cambiado el tiempo de asignación en la configuración para que nunca más tuviese otra IP.

¿La moraleja de esta historia? Que nunca barres toda la mierda de debajo de las alfombras. Siempre queda algo que, además, apesta.

 

[Tutorial] Cómo crear backups cifrados e incrementales en Debian y derivados con Déjà Dup

Deja DupYa he comentado en algún podcast que por lo general, siempre suelo instalar mis máquinas Debian (escritorio) con LVM cifrando la raíz, /home y la swap (una buena “feature” de Debian, si cifras vía dm-crypt tu /home, por seguridad te obliga desde el instalador a cifrar la swap por los datos que se podrían extraer almacenados en RAM).

Como además de mis equipos portátiles también tengo cifrados los de escritorio, según mi criterio, no tendría mucha lógica guardar las copias de seguridad sin esa capa de cifrado y ahí es donde entra en escena Déjà Dup (el nombrecito se las trae, lo sé ;D).

También es importante comentar que tras más años de los que recuerdo usando KDE, llevo unos meses con GNOME (modo clásico y “flashback según equipos, menos recursos que un Shell “puro”) y XFCE ya que la integración con (en adelante) Deja Dup es muy buena (este tuto lo estoy escribiendo desde Debian Testing y GNOME 3.8.4).

Cuando hablo de mejor integración, me refiero a poder hacer click con el botón del ratón y ver un menú contextual (más abajo veréis las capturas) con el texto: “restaurar los ficheros que faltan” y es pinchar el disco, y ver restaurado el fichero o directorio sin problemas. También los indicadores de progreso de la copia de seguridad, o el aviso emergente caso de haber programado una tarea, del inicio de la copia.

En el título pongo Debian y derivados, ya que es válida para otras distros como Ubuntu o Mint, pero está empaquetado en muchas más con algún ligero cambio. Por ejemplo, en Ubuntu se pueden lanzar backups contra Amazon s3 o Ubuntu One, pero las funcionalidades son similares. Para el cifrado utiliza GPG (GNU Privacy Guard) todo un clásico, mediante un sistema de cifrado simétrico. También trabaja con herramientas tan conocidas como Rsync, etc. Os recomiendo ver info más detallada de cómo funciona.

Así que ya sabéis, sólo un aptitude install deja-dup y empezar con esos backups. Os pongo unas cuantas capturas de pantalla para que podáis ver en modo gráfico lo que os he ido comentando. Sencillo, seguro y efectivo, concepto KISS a tope.

Seleccionando la opción de cifrado e introduciendo la frase de paso.

Aquí podéis configurar opciones de la copia de seguridad.

Un ejemplo con la frecuencia de las copias de seguridad.

La opción que os comentaba de restauración y el menú contextual.

Seleccionando el fichero a restaurar.

Confirmación y ubicación (coge la ruta de forma automática).

Progreso de la restauración.

Y confirmación de que todo ha salido ok.

Un vistazo después a los ficheros .gpg.

Eso es todo, espero que lo encontréis útil y no dejéis de hacer vuestros backups.

 

Debian Sources List Generator. Interesante servicio online

Una duda muy común en los que empiezan es “¿Qué repos incluyo en mi sources.list?. Bien, ya hemos hablado en alguna ocasión del tema y hoy os quería recomendar una herramienta vía web que os puede solventar muchas dudas respecto al tema.

Se trata de “Debian Sources List Generator“, ahí además de los repositorios habituales, podéis escoger otros (tanto free como privativos) de Google, Skype, Wine, multimedia, etc. Hablando de los “principales”, yo suelo usar (en este caso Sid / “unstable”);

deb http://ftp.debian.org/debian sid main contrib non-free
deb-src http://ftp.debian.org/debian sid main contrib non-free

O en su defecto de Finlandia, que van muy rápido;

deb http://ftp.fi.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.fi.debian.org/debian/ testing main contrib non-free

Aquí una captura de pantalla

Sources List

Y no olvidéis que si estáis bajo Debian “Sid” no hay que meter “Security”. Saludos !

 

a vueltas con LDAP – txn_checkpoint failed: Invalid argument (22)

Esta mañana me he encontrado con que el servidor LDAP no funcionaba. Tras un vistazo rápido al log del sistema (/var/log/syslog) me he encontrado con este mensaje, ideal para despertar a dormidos. He puesto en negrita la parte más importante del informe de fallo, IMHO.

Del servidor de LDAP, slapd, hay poco malo que decir. Funciona rápido y bien, sobre equipos con pocos recursos y no lo canibaliza en exceso, cosa de agradecer. Pero sí se puede pensar que es muy propenso a fallos en cuanto se actualiza algo, lo más mínimo, que toque tangencialmente el servidor. En ese momento, deja un montón de literatura en los ficheros de registro y se detiene.

Tras dos minutos de búsqueda (otras caídas súbitas del servicio me han enseñado a buscar bien y rápido), apareció la respuesta. Todo pasaba por reparar la base de datos del servidor, que ha quedado inconsistente. Más claro, en comandos:

¡Listo! Como si no hubiese pasado nada.

 

cierra news.debian.net

A casi le sonará, como sucede con la mayoría de servicios alojados en debian.net, pero el servicio de noticias relacionadas con la comunidad cierra. En un escueto mensaje publicado ayer, anunciaban que el servicio cierra tras diecinueve meses de actividad y que pasará a ser una página estática.

Personalmente pienso que es una pena, que la información que daba este servicio, aunque distanciada en el tiempo, era de calidad y, sobre todo de primera mano, desde dentro del proyecto Debian. Sólo hay que recordar el seguimiento que hicieron del lanzamiento de squeeze, durante varios días y aportando datos de la liberación.

Lamentablemente me estoy acostumbrando a ver cómo los servicios lanzados desde debian.net duran unos meses y pasan a ser webs estáticas. Supongo, aunque no me gusta, que ya nacen con el estigma de ser minoritarios y con un determinado tiempo de actividad.

 

[short] preguntando a debian

Logo Debian Hackers Short

La gente de Debian sigue añadiendo servicios a su ya extensa lista y esta vez sorprenden (al menos a mí) con una web donde dejar y responder preguntas. En Debian Q&A uno puede preguntar sobre cualquier tema relacionado con la distribución, ya sea acerca cual es el mejor reproductor de sonido, lo primero que se hace nada más instalar un sistema o algo más productivo, como una lista de hardware compatible.

También se pueden votar las respuestas, tanto afirmativa como negativamente y, algo que cada vez me gusta más, no es necesario crear un usuario (otro más) para hacer uso del servicio porque cuentan con la colección de proveedores de identidad más grande que he visto hasta la fecha.

Un servicio, otro más, que supongo vendrá a rellenar el hueco dejado por las listas de correo de la comunidad y los LUG’s de los noventa, donde uno podía encontrar (y apabullar a preguntas) a su gurú de turno. Yo, por lo pronto, ya ando dando consejos gratis. 🙂

 

Recuperación de slapd (Program version 4.8 doesn’t match environment version 4.7)

Utilizo slapd para dar un servicio de directorio, la clásica agenda de contactos con email, teléfono y demás. Hace algunos años, cansado de tener que pasar de una a otra herramienta de gestión de contactos, según cambiaba de programa de correo (de mutt a pine; de pine a evolution; de evolution a thunderbird), decidí quedarme en el punto intermedio de todos ellos y, tras investigar un poco, éste resultó ser OpenLDAP.

Crear una estructura de directorio es sencillo (forat, cúrrate un howto ;)) y muy útil. Como, además, el servicio lastra muy poco el equipo donde está alojado, puede funcionar en máquinas no muy potentes, como es mi caso. A cambio, dispondremos de una agenda de contactos rápida, accesible desde la mayoría de clientes de correo (incluso Outlook Express) y fácil de gestionar y mantener. En mi caso era así, hasta hoy.

Hay ciertos servicios que, una vez los pones a funcionar, dejas de pensar en ellos y únicamente los utilizas, los conviertes en rutina. Por eso, cuando fallan (porque nada es infalible), la sensación de estupor es grande y no sabes por dónde empezar la batalla.

Hace dos días, slapd decidió no arrancar más tras una actualización del equipo. El error que aparecía en syslog era bastante feo, llegando a mencionar el sacrosanto backup, toda una osadía, en mi opinión.

Tras bucear un rato por internet (aquí y aquí) entendí que las bases de datos que utiliza slapd tenían el formato Berkeley DB version 4.7 y, desde la última actualización, debían tener el formato Berkeley DB version 4.8. Para pasar de un formato a otro hacen falta un par de paquetes, uno por cada versión de la base de datos con que vamos a trabajar. Se instalan:

El directorio de las bases de datos está definido en el fichero de configuración de slapd (/etc/ldap/slapd.conf) pero, por defecto es /var/lib/ldap/midominio.net. Todas las modificaciones se harán sobre ese directorio y es conveniente, como siempre, hacer una copia de seguridad de los ficheros que vamos a tocar porque esta solución salió al tercer intento.

Lo primero es eliminar toda referencia a la versión 4.7 en los ficheros:

Y, una vez hecho esto, falta por restaurar la base de datos con la nueva versión del entorno, algo así como la nueva versión del gestor.

Como los ficheros que se han tocado no pertenecen al programa que los va a usar, retoco permisos y propietario:

Y, al reiniciar de nuevo slapd, funciona sin más problemas.