Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap"

Mi servidor DNS estándar es Bind sobre SmartOS, pero el paquete nativo disponible no tiene soporte dnstap de serie. Hay que compilarlo desde cero.

Los pasos son, en realidad, bastante sencillos si conoces cómo funciona SmartOS, su gestión de paquetes y el entorno PkgSrc:

  1. Tengo una zona nativa SmartOS con el software PkgSrc. En mi caso uso la versión trunk:

    [root@xXx ~]# imgadm avail|grep -i pkgbuild-trunk
99412e46-9a55-11ec-a6b4-8b38513aaa54  pkgbuild-trunk                  20220302      smartos  zone-dataset  2022-03-02
7f33bfaa-fed7-11ec-82ce-0f7efc84d370  pkgbuild-trunk                  20220708      smartos  zone-dataset  2022-07-08

  2. Entro en la zona pkgsrc-trunk por SSH y le pido que cree un entorno virtual de compilación:

    [root@PkgSrc-trunk ~]# run-sandbox trunk-x86_64

It looks like this is the first sandbox creation for this pkgbuild.  It
will take longer than normal, as support packages need to be downloaded
first.  Subsequent runs will be much faster after they have been cached.

[...]

Unpacking bootstrap-trunk-x86_64 into /data/chroot/dev-trunk-x86_64...done.
Setting up environment...done.
Installing additional tools packages...done.
Logging in.  WARNING: On logout the sandbox will be destroyed.

  ,---.                   |     ,---. ,---.
  `---. ,-.-. ,---. ,---. |---  |   | `---.  pkgbuild-trunk
      | | | | ,---| |     |     |   |     |  20220708
  `---' ` ' ' `---' `     `---' `---' `---'

--<root@PkgSrc-trunk>-(/data/chroot/dev-trunk-x86_64)-<~>--
->

Leer más…

Novedades SmartOS de 20190829 a 20200520

Artículos previos:

Han pasado tres años desde la última actualización, así que haré un poco de resumen y pondré solo lo que me llame más la atención. Tengo mucho de lo que ponerme al día. Puedes ver los cambios con detalle en inglés, pero aquí os doy una versión masticada y resumida en español (la lista no es exhaustiva, hay muchísimo más):

Creación e instalación de un perfil OpenVPN en iOS

Hace tiempo la cosa era más complicada, pero hoy en día crear y activar un perfil OpenVPN para iOS es bastante trivial.

Creación de un fichero de configuración OpenVPN

  1. Creamos un par de claves públicas y privadas para el usuario. Esas claves deben ir firmadas por la entidad de certificación asociada al servidor OpenVPN y tienen una caducidad determinada (por defecto, un año).

    Si usamos easy-rsa, los comandos a ejecutar son:

    jcea@OpenVPN_Server:~$ cd /etc/openvpn/easy-rsa/2.2.2/
jcea@OpenVPN_Server:/etc/openvpn/easy-rsa/2.2.2$ source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/2.2.2/keys
jcea@OpenVPN_Server:/etc/openvpn/easy-rsa/2.2.2$ echo $KEY_EXPIRE
365

    Lo anterior inicializa easy-rsa. Podemos ver que la expiración por defecto es de 365 días. Podemos modificarla si así lo deseamos.

    Lo normal ahora sería generar el certificado OpenVPN para el usuario, sin más. Sin embargo la versión 2.2.2 de easy-rsa no permite crear una clave nueva para un usuario ya existente, AUNQUE LA CLAVE ANTIGUA HAYA CADUCADO. En mi opinión, esto es un bug.

    Leer más…

Copiar ficheros por "scp" cuando el nombre contiene ":"

Si intentamos copiar un fichero que contiene el carácter : (dos puntos) por scp, obtendremos el siguiente error:

jcea@jcea:/tmp/ram$ scp Prueba_de_fichero_con_\:_en_el_nombre datos:/tmp/
ssh: Could not resolve hostname prueba_de_fichero_con_: Name or service not known

El problema es que scp interpreta un parámetro con : como el nombre de un servidor al que conectar por SSH.

La solución es que le quede claro que se trata de un nombre de fichero. Podemos poner el path absoluto o relativo del fichero. Por ejemplo:

jcea@jcea:/tmp/ram$ scp ./Prueba_de_fichero_con_\:_en_el_nombre datos:/tmp/
Prueba_de_fichero_con_:_en_el_nombre          100%    0     0.0KB/s   00:00

El tema me traía loco hasta que encontré esta respuesta, bastante literal: How can I scp a file with a colon in the file name? Se ve que no soy el único que se ha tropezado con el problema.

Espero que este truco te resulte útil.

PS: Este truco se puede utilizar con otros comandos, como rsync o la familia FFmpeg.

"ccache" persistente en el PkgSrc de SmartOS

En Cómo usar "ccache" para compilar en PkgSrc de SmartOS describo cómo configurar el entorno PkgSrc de SmartOS para que utilice ccache y así beneficiarnos de una mayor velocidad de recompilación.

El problema que tenemos es que la caché de ccache se guarda dentro del entorno chroot y esto tiene dos efectos:

  1. No podemos beneficiarnos del uso de ccache entre dos branches PkgSrc diferentes, algo que uso con frecuencia en SmartOS.
  2. Cuando cerramos en entorno chroot, este se destruye. Esto elimina también la caché de ccache.

Cuando estoy trabajando en un proyecto largo, es común que lance el entorno chroot de forma pesistente dentro de una sesión screen, por lo que puede sobrevivir a lo largo de varias jornadas de trabajo, pero al terminar la tarea la cerraré y perderé la caché del ccache.

Lo ideal sería que la caché ccache se almacenase fuera del entorno chroot. Eso se puede hacer con facilidad de esta manera [1]:

  1. Creamos un directorio /root/.chroot/ en la zona SmartOS.

  2. Editamos los ficheros /data/pkgbuild/scripts/mksandbox y /data/pkgbuild/scripts/rmsandbox, buscamos la línea que pone for mount in ${LOFS_RW_MOUNTS}; do y la cambiamos por lo siguiente: for mount in ${LOFS_RW_MOUNTS} "/root/.ccache=/root/.ccache"; do.

    Lo que estamos haciendo es añadir un loopback hacia /root/.ccache a la hora de crear el entorno chroot y desmontarlo a la hora de destruirlo.

De esta manera, los usos de ccache dentro de los diferentes entornos chroot utilizarán todos la misma caché y esta es persistente e independiente de la existencia de dichos entornos chroot.

[1] Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS.

Cómo usar "ccache" para compilar en PkgSrc de SmartOS

Utilizo muy frecuentemente el entorno de compilación PkgSrc para SmartOS y voy personalizándolo poco a poco para mejorar mi experiencia y ajustarlo mejor a mi forma de trabajar.

Estudiando la documentación de PkgSrc, me encuentro un capítulo interesante: Speeding up pkgsrc builds with ccache and distcc. Yo utilizo ccache en muchos de mis entornos y poder utilizarlo también en PkgSrc me resulta atractivo.

Los pasos descritos en esa web son generales para PkgSrc, pero, en el caso concreto de SmartOS, sus actualizaciones trimestrales, su entorno chroot, etc, encuentro más fácil meter esos cambios como variables de entorno que modificar ficheros de configuración (tendría que cambiar un fichero en cada uno de los branches que utilizo). Una forma simple de hacerlo en SmartOS es modificar el fichero /data/pkgbuild/scripts/run-sandbox [1] y añadirle lo siguiente en la creación del fichero .bashrc para el entorno chroot:

# Ver el comentario en
# https://wiki.netbsd.org/tutorials/pkgsrc/build_ccache_distcc/
export CCACHE_DIR=/root/.ccache/
export PKGSRC_COMPILER=ccache gcc

Obsérvese el detalle de definir CCACHE_DIR de forma explícita. La razón se explica en el comentario de Speeding up pkgsrc builds with ccache and distcc que, resumiendo, indica que si no se hace así, cada compilación utiliza una caché separada y, por tanto, no se reutiliza y no sirve de nada.

Con estos cambios, cuando intentemos compilar algo, se instalará ccache y se utilizará automáticamente.

Advertencia

Por algún motivo, la primera vez que compilamos algo con esta configuración nos va a salir el siguiente error:

checking for x86_64-sun-solaris2.11-gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details
*** Error code 77

Haciendo bmake clean y volviéndolo a intentar, ya funciona bien.

Esto es algo a estudiar en el futuro.

¿Cuánto ganamos utilizando ccache? El efecto se nota más cuanto más larga es la compilación:

  normal ccache
Apache 1:29 0:49
tor 3:25 1:02
python39 6:02 1:36
[1] Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS.

Actualización 20220824: Tal vez te interese leer "ccache" persistente en el PkgSrc de SmartOS.

Actualización 20230123: Más sobre este tema en Cómo usar "ccache" para compilar en PkgSrc de SmartOS (II).

Systemd valida DNSSEC, pero no muestra las firmas DNSSEC a sus clientes

Durante las pruebas con DNSSEC para escribir mis artículos recientes sobre el tema, observaba comportamientos extraños cuando hacía los experimentos con mi portátil. Pedía toda la información de un dominio protegido por DNSSEC y recibía validación DNSSEC de mi resolver local, pero no me llegaban las firmas digitales asociadas. Algo incomprensible considerando que el resolver necesita disponer de esas firmas digitales para que poder hacer esa validación.

Nota

En una versión inicial de este artículo utilizaba mi dominio jcea.es para las demostraciones, pero dado que los servidores DNS autoritativos para un dominio no realizan verificaciones DNSSEC para dicho dominio (no activan el flag AD [1]), el resultado era confuso.

Es por eso que he actualizado este artículo para utilizar el dominio nic.fr.

Por ejemplo, esto es lo que veo desde mi portátil cuando pido ver las firmas digitales DNSSEC (los registros RRSIG del DNS):

jcea@jcea:~$ dig +dnssec nic.fr

; <<>> DiG 9.16.1-Ubuntu <<>> +dnssec nic.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20487
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;nic.fr.                                IN      A

;; ANSWER SECTION:
nic.fr.                 600     IN      A       192.134.5.37

;; Query time: 135 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mar jun 28 14:22:40 CEST 2022
;; MSG SIZE  rcvd: 74

Aquí vemos que el resolver local hace validación DNSSEC (el flag AD [1] al principio de la respuesta). Estupendo. ¡Pero no me sale la firma digital asociada!

Leer más…

DNSSEC: Migración de "jcea.es" a ECDSAP256SHA256

La experiencia de migrar algunos de mis subdominios DNS de uso privado a ECDSAP256SHA256 en 2020, tal y como describo en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios, ha sido muy indolora y positiva. Sin embargo a la hora de migrar el dominio DNS jcea.es entero, el tema de la compatibilidad sigue sobre la mesa.

Hay novedades recientes documentadas en DNSSEC: enlaces interesantes (20220611), como que la mitad de los dominios DNS protegidos por DNSSEC en Holanda usan ya ECDSAP256SHA256, o que el registrador francés .fr acaba de migrar a ECDSAP256SHA256.

Parece que hay consenso en que usar ECDSAP256SHA256 en DNSSEC es el estado del arte actual y que debería funcionar en cualquier cosa que tenga menos de diez años (si tiene más de diez años, o no soporta DNSSEC en absoluto o, sencillamente, dejará de validar DNSSEC, como si el dominio no estuviese firmado).

Para migrar jcea.es a ECDSAP256SHA256 voy a seguir básicamente los pasos descritos en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios. Ls diferencia fundamental es que quiero editar los registros DS solo una vez, porque quiero interactuar con mi registrador DNS lo mínimo posible.

Es decir, en DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios añado las claves KSK y ZSK nuevas, manteniendo las claves viejas y añadiendo registros DS nuevos de forma que se admitan las claves KSK viejas y nuevas. Una vez que se propagan los cambios, puedo eliminar los registros DS, y las claves KSK y ZSK antiguos.

Ahora solo quiero hacer un cambio en los registro DS.

Los pasos son:

Leer más…

DNSSEC: enlaces interesantes (20220611)

Puesta al día de algunos enlaces interesantes sobre DNSSEC para quitármelos de mis marcadores del navegador web:

¿Cómo compilar un kernel nuevo en Ubuntu 20.04?

El kernel actual de Ubuntu 20.04 tiene un problema catastrófico si utilizas ZRAM, como describo en zram: Decompression failed! Lo fácil sería esperar a que Ubuntu publique una actualización, pero eso puede llevar semanas. Con eventos catastróficos diarios, no me puedo permitir esperar.

Necesito compilar mi propio kernel Linux. Lo triste del asunto es que la cosa no es ni sencilla ni está bien documentada. En la web de Ubuntu y por todo internet hay infinidad de tutoriales describiendo el proceso, pero son para versiones antiguas del sistema operativo y ya no funcionan. La verdad es que he perdido bastante tiempo leyendo y experimentando, con poco éxito y bastante frustración. Mis necesidades son bastante razonables:

  • Idealmente, compilar el mismo kernel oficial de Ubuntu, pero con la opción CONFIG_PGTABLE_MAPPING=y desactivada. Esto me permitiría reemplazar el kernel sin tener que preocuparme de paquetes y otras historias, y podría reutilizar también el initrd normal del sistema operativo. Eso me daría compatibilidad con todo lo que necesito, incluyendo ZFS y VirtualBox. Además, Ubuntu tiene parches en su kernel que no están disponibles en las versiones de kernel.org.

    Tendría que tener cuidado en recompilar un kernel nuevo cada vez que Ubuntu publicase una actualización que no incluyese la corrección, pero me parecía asumible.

    Ubuntu publica detalles sobre cómo descargar y compilar sus kernels, pero es un proceso complejo y que no he conseguido hacer funcionar satisfactoriamente.

  • Mis necesidades son algo delicadas si en vez de intentar reutilizar componentes Ubuntu, compilo un kernel genérico por mi cuenta:

    • Debe tener compatibilidad con ZFS.
    • Debe tener compatibilidad con VirtualBox. Esto supone que los módulos VirtualBox se recompilen automáticamente cuando se publica una actualización del software, lo que no es trivial.

    El plan es utilizar este kernel personal hasta que Ubuntu publique una actualización solucionando el problema.

Leer más…