Activación/Desactivación de extensiones Mercurial de forma puntual

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.

Que tus "futures" de larga duración no impidan que tu programa Python termine (Python 3.7)

Advertencia

El uso de las técnicas descritas en este artículo es peligroso. Más vale que sepas lo que estás haciendo.

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.

Verificar contenido DNS con DNSSEC y Python

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:

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…

Ignorar la configuración DNS que nos llega por DHCP (y usar dnsmasq)

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].

[1] En un entorno de servidores yo no usaría dnsmasq, ya que está pensado para cosas "pequeñas" y domésticas. Mejor usar un servidor DNS de verdad como BIND.

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…

Activar verificación de DNSSEC en "dnsmasq"

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…

Activación de DNSSEC en BIND con DNS gestionado de forma manual

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.

Advertencia

Mis primeros intentos DNSSEC con zonas de gestión manual fue con BIND 9.10.x. En principio debería funcionar, el soporte de esta funcionalidad viene de BIND 9.9, pero tuve problemas con la renovación de firmas y con las notificaciones a los servidores DNS secundarios.

Todo fue bien cuando instalé una versión 9.11 de BIND compilada a mano. Fue muy fácil bajo SmartOS:

# ./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…

Activar SSH y WIFI en una Raspberry PI con Raspbian, en el primer arranque y sin teclado ni monitor

1   Antecedentes

Por defecto, cuando instalamos una distribución Raspbian en una Raspberry PI no tendrá el servicio SSH activo ni tampoco acceso a través de WIFI, solo Ethernet.

Si dicha Raspberry PI no tiene una conexión Ethernet y no la tenemos conectada a una pantalla y un teclado, no habrá forma de conectar.

Veamos cómo solucionarlo, considerando que las dos particiones de la tarjerta microSD se han montado en /media/jcea/boot/ y /media/jcea/rootfs/.

Leer más…

Actualizar una instalación OSMC desde la línea de comandos

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.

¡Cuidado!, "ssh -A" puede ser muy peligroso

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…

WeeWX y modificaciones en la base de datos "a pelo" (II)

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…