owncloud, actualizaciones y certificados

He actualizado owncloud, mi nube particular, de la versión 8.0.4 a la 8.1.11 y tengo la impresión de haber actualizado a Windows 10. Quizá es que, con miles de actualizaciones de debian a mis espaldas que me han malacostumbrado a que sean silenciosas e indoloras, quizá es que ninguna actualización es sencilla o quizá es que tienen varios puntos que mejorar.

En cualquier caso, tras terminar la actualización tenía tres errores en la consola de administración, varias apps que no funcionaban y un problema, que el cliente de escritorio de linux (los tres, en realidad) no conectaba. Éste último fue fácil de solucionar, actualizando el cliente a la versión 2.0, que además soporta múltiples cuentas sin hacer cosas raras.

error no internet connection

De los errores, el más extraño era uno que decía que owncloud no tenía conexión a internet y que era necesaria para un funcionamiento adecuado. Lo extraño es que ese servidor está en algún lugar de Bélgica y yo, obviamente, no cojo el coche cada vez que quiero conectarme. Además, este error en concreto parecía deberse a un fichero de configuración viejo, según el solucionador de problemas de actualización, que no existía.

Leyendo a más gente con el mismo problema (y conexión a sus servidores remotos), me encontré con una persona que atinaba con la solución, diciendo que en un hilo de github alguien decía algo de un certificado. Y así es. El error se debe a que owncloud no reconoce a https://owncloud.org como entidad certificadora hasta que no tiene ese fichero y lo asocia con una desconexión de la red. La pregunta es porqué no se asegura el proceso de actualización que ese fichero existe antes de validar nada más. Así que, para solucionar el error más absurdo de owncloud, sólo tuve que descargar el código y copiar el fichero /config/ca-bundle.crt en mi instalación de owncloud. Nada más. Y, a partir de ese momento, las apps que no funcionaban y el propio entorno de gestión de apps, comenzaron a funcionar correctamente.

A lo tonto he estado pegándome con la actualización de marras unas cuantas horas para tenerlo todo bien configurado. Y luego damos (doy) por sentado que las actualizaciones tienen que ser sencillas, rápidas e indoloras. A ver si aprendo.

 

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.