A veces necesitamos una extensión Mercurial de forma puntual y no queremos tenerla activada por defecto en nuestra configuración. Por ejemplo, porque se trata de una extensión de uso delicado o experimental.

Podemos invocar Mercurial desde la línea de comandos de la siguiente manera:

$ hg --config extensions.histedit= histedit

Aquí estamos activando la extensión histedit para modificar changesets en fase secreta o borrador.

Te puede interesar conocer extensiones Mercurial comunes o cómo activar o desactivar una extensión de forma permanente.

Si lo que quieres es desactivar puntualmente una extensión activada en la configuración por defecto, puedes indicarlo con un ! (signo de admiración). Por ejemplo:

$ hg --config extensions.mq=! COMANDO

Durante esta invocación de Mercurial, la extensión Mercurial Queues estará desactivada. Por ejemplo:

$ hg qseries --config extensions.mq=!
hg: unknown command 'qseries'
'qseries' is provided by the following extension:

    mq            manage a stack of patches

(use 'hg help extensions' for information on enabling extensions)

Podemos usar el mismo principio para modificar cualquier opción configurada en los ficheros INI de Mercurial.

En Que tus "futures" de larga duración no impidan que tu programa Python termine explico cómo conseguir que un programa Python termine, aunque tenga Futures pendientes de ejecución. Más te vale que tengas buenos motivos para ello y que entiendas los riesgos, pero conocer esta técnica es útil cuando la necesitas.

El código propuesto no funciona bajo Python 3.7, a punto de salir, por su uso del nuevo PEP 562 para acelerar la importación del módulo concurrent.futures. Tendremos que importar concurrent.futures.thread y concurrent.futures.process de forma explícita.

Es decir, en Python 3.6 hacíamos algo así:

import concurrent.futures
import atexit
atexit.unregister(concurrent.futures.thread._python_exit)
atexit.unregister(concurrent.futures.process._python_exit)

En el nuevo Python 3.7 tendremos que hacer lo siguiente:

import concurrent.futures.thread
import concurrent.futures.process
import atexit
atexit.unregister(concurrent.futures.thread._python_exit)
atexit.unregister(concurrent.futures.process._python_exit)

Problema solucionado. De momento.

Ahora que tengo todas las piezas DNSSEC en su lugar (dominios protegidos por DNSSEC y clientes que verifican DNSSEC), queda explicar cómo lo estoy utilizando.

Conviene leer el contexto primero.

Teniendo DNSSEC, tenemos una base de datos masivamente distribuída y masivamente cacheada. Podemos atender millones de dispositivos de forma segura sin apenas carga en nuestros servidores DNS. Algunos ejemplos de uso:

• DNS-based Authentication of Named Entities (DANE), para decir adiós a la infraestructura de certificados X.509 actuales.
• DNS Certification Authority Authorization para limitar las entidades de certificación X.509 que tienen permiso para emitir certificados para nuestro dominio. Por ejemplo, no tiene sentido que la oficina postal de Hong Kong o Google puedan emitir certificados para nuestra organización.
• Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints permite distribuir esa información de forma segura si se utiliza DNSSEC.

En mi caso, estoy utilizando esta tecnología para controlar y actualizar una miriada de dispositivos IoT y sistemas empotrados que tengo distribuídos por todo el mundo. El DNS me permite hacerlo de una forma escalable y redundante (gracias al cacheo de la red mundial de servidores DNS) y DNSSEC me permite hacerlo de una forma segura.

Leer más…

Si seguimos los pasos indicados en Activar verificación de DNSSEC en "dnsmasq", tendremos un servicio dnsmasq capaz de verificar DNSSEC. Estupendo. Ahora solo hace falta que enviemos nuestras peticiones DNS a través de ese servicio dnsmasq.

Si estamos en un entorno de servidores, con direcciones IP fijas, etc., no hay mayor problema; bastaría con configurar apropiadamente el fichero /etc/resolv.conf [1].

En un entorno doméstico solemos tener una dirección IP dinámica asignada mediante un servicio DHCP que, típicamente, nos proporciona el router de la operadora de telecomunicaciones que nos da la conexión a internet. En esa negociación DHCP es muy normal configurar muchas cosas más además de la dirección IP, como servidores de tiempos, nombre de dominio, máscaras y ruta por defecto a internet. También nos suele entrar información sobre los servidores DNS que nuestra operadora quiere que usemos.

Hay mucha información en internet sobre cómo ignorar esa configuración de DNS a la hora de que el ordenador configure su red automáticamente al encenderlo. Lamentablemente mucha de ella está anticuada, es contradictoria o frágil. Con la irrupción, como un elefante en una tienda de cristal, de esa aberración de la filosofía Unix que es systemd, las cosas no han hecho sino complicarse aún más.

Voy a documentar cómo lo estoy haciendo yo cuando trabajo con Raspberry PI y la distribución Raspbian actual:

Leer más…

Por defecto, los sistemas Ubuntu no verifican DNSSEC en el resolver. ¿Es posible solucionarlo?

Ubuntu (y otras muchas distribuciones Linux) emplean dnsmasq como resolver DNS local. Las versiones modernas de dnsmasq soportan DNSSEC, pero no está activado por defecto.

La configuración varía según estemos usando NetworkManager (habitual en entornos domésticos) o no (lo normal en servidores). Describiré el caso de la distribución Ubuntu 16.04:

• Si no utilizamos NetworkManager:

  • Editamos el fichero /etc/dnsmasq.conf, descomentamos y modificamos las líneas:

    #conf-file=%%PREFIX%%/share/dnsmasq/trust-anchors.conf
    #dnssec
    #dnssec-check-unsigned
    

    convirtiéndolas en:

    conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
    dnssec
    dnssec-check-unsigned
    

• Si utilizamos NetworkManager:

  • Añadimos un fichero nuevo en el directorio /etc/NetworkManager/dnsmasq.d/. Supongamos que dicho fichero se llama dnssec.conf. El nombre no es importante, siempre que tenga la extensión conf.

  • El contenido de dicho fichero debe ser:

    conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
    dnssec
    dnssec-check-unsigned
    

Para comprobar si todo está funcionando correctamente, podemos realizar una consulta DNS:

Leer más…

En Activación de DNSSEC en BIND con DNS dinámico explico cómo activar DNSSEC en BIND cuando estamos trabajando con un dominio bajo DNS dinámico. Para completar nuestra gestión necesitamos documentar también cómo utilizar DNSSEC para dominios gestionados de forma manual.

# ./configure --disable-static --with-libtool \
              --enable-threads --with-libjson=yes \
              --with-openssl=/opt/local/ \
              --prefix=/opt/local/ --enable-ipv6 \
              --sysconfdir=/opt/local/etc \
              --localstatedir=/var
# make
# make install

El funcionamiento de BIND para DNSSEC cuando estamos trabajando con dominios gestionados de forma manual es diferente a lo que documento en Activación de DNSSEC en BIND con DNS dinámico para el caso de DNS dinámico:

Leer más…

OSMC es una distribución Debian para Raspberry PI (entre otros) que incluye Kodi. Con ella puedes convertir tu Raspberry PI en un centro multimedia, conectarla a la televisión, manejarla desde el mando a distancia, etc.

El OSMC se maneja fundamentalmente desde el mando a distancia de la televisión, pero es una instalación Debian que tiene acceso remoto también mediante SSH. Esto es muy útil para, por ejemplo, instalar más cosas en la Raspberry PI y utilizarla para más tareas que el propio centro multimedia que proporciona OSMC.

OSMC suele publicar una actualización mensual, accesible desde el mando a distancia de la televisión. El problema se da cuando ese OSMC está en casa de tus padres, por ejemplo, y tienes que estar recordándoles de vez en cuando que tienen que actualizar, o bien es una de esas muchas pequeñas tareas que te toca realizar cuando estás de visita.

Aprovechando el acceso remoto por SSH que proporciona OSMC, sería posible realizar las actualizaciones a distancia, pero el procedimiento Debian normal no funciona correctamente, pudiendo llegar a dañar la instalación OSMC. Ocurren cosas extrañas, como que los comandos habituales de actualización no funcionen, que la conexión SSH se corte a mitad del proceso, etc. En resumen, un desastre.

Tras un tiempo lidiando con estos problemas, me decidí a realizar una consulta en el foro oficial de OSMC. El procedimiento correcto es el siguiente:

$ sudo systemctl start manual-update

Este comando cierra el Kodi en ejecución, actualiza el sistema y vuelve a lanzar el Kodi, previo reinicio del sistema operativo si es necesario.

Este procedimiento puede cambiar en el futuro, pero, de momento, todo funciona como debe.

Veo muchos administradores de sistemas recomendando el uso de ssh -A con alegría, sin explicar los riesgos de seguridad asociados.

Todos sabemos que ssh permite entrar en servidores remotos de forma segura. Suponiendo que ese servidor sea una frontera y queramos saltar de allí a otros servidores de la red interna, tenemos diferentes posibilidades:

• Tener una clave ssh en ese servidor frontera, lanzar un ssh-agent en él y cargar la clave. El problema es que tenemos una clave ahí y, por tanto, necesitamos poder confiar en ese servidor.
• Utilizar ssh para establecer un túnel con el servidor frontera y emplear dicho túnel para enviar conexiones ssh nuevas a los servidores internos. Esta configuración es segura, pero complicada y poco transparente.
• Utilizar ssh -A para que al establecer sesiones ssh a otros servidores (una vez que estamos conectados al servidor frontera), la solicitud de autenticación se canalice al ssh-agent de nuestro propia máquina personal. La clave ssh nunca sale de nuestra máquina.

ssh -A parece perfecto y seguro, salvo por un pequeño detalle: nuestro ssh-agent local completará cualquier petición de autenticación que le llegue. Si estamos conectados a un servidor malicioso, los malos podrían solicitar a nuestro ssh-agent autenticaciones para servidores diferentes, conectarse a ellos con nuestra identidad y hacer allí lo que les de la gana, incluyendo instalar sus propias claves públicas ssh para poder entrar con posterioridad sin depender de nosotros. Todo ello en milisegundos y sin que nos enteremos.

Leer más…

En Estaciones meteorológicas de baja calidad, WeeWX y modificaciones en la base de datos "a pelo" explico los motivos por los que a veces resulta conveniente modificar manualmente los registros de la base de datos de la estación meteorológica gestionada con WeeWX.

El procedimiento cambia bastante en la última versión WeeWX, como describo a continuación. En realidad el proceso se ha simplificado.

Leer más…