Artículos previos:
Lo cierto es que los proyectos SmartOS e Illumos son muy activos y tienen muchísima actividad. Proporcionar un repaso exhaustivo es mucho trabajo para mí, así que me limitaré a detallar lo que me parece más interesante desde un punto de vista personal.
Puedes ver los cambios con detalle en inglés.
Este artículo es una continuación de:
Iré actualizando la lista siguiente de vez en cuando:
Este artículo es una continuación de Actualización de características en un sistema de ficheros ZFS (20200528). Lee primero ese texto para saber de qué estoy hablando.
Con el paso del tiempo voy actualizando ZFS y es posible activar características opcionales adicionales. Desde la actualización de 2020 hay novedades:
encryption project_quota device_removal obsolete_counts zpool_checkpoint spacemap_v2 allocation_classes resilver_defer bookmark_v2
Al igual que hicimos en Compilar la biblioteca x264 en SmartOS con la biblioteca x264, podemos hacer lo mismo con x265 y las bibliotecas para procesar vídeo en formato AV1.
Voy a ir directamente al grano, para no explicar una vez más cómo se compila código en una zona SmartOS PkgSrc:
x265: Está en /data/pkgsrc/multimedia/x265. Se puede compilar con opciones avanzadas haciendo:
-> bmake PKG_OPTIONS.x265=x265-main10 package
Como en el caso de x264, la mejora de rendimiento al compilar nuestras propias bibliotecas adaptadas a nuestra CPU es de cinco a uno. Vale la pena invertir el esfuerzo, que es bien poco.
Se puede instalar la biblioteca x264 en una zona nativa SmartOS usando simplemente PkgSrc, pero está compilada para una CPU genérica, por compatibilidad, y no aprovechará nuestro procesador. Se puede obtener un rendimiento mucho mayor compilando nosotros mismos x264 desde el código fuente, adaptando la versión compilada a las capacidades de nuestra CPU en particular.
Lo más sencillo es utilizar una zona SmartOS PkgSrc como se ha explicado en artículos anteriores. Los pasos son simples:
Activamos el entorno de compilación para la versión de la zona SmartOS que necesitamos. Por ejemplo:
[root@PkgSrc ~]# run-sandbox 2022Q4-x86_64 [...] --<root@PkgSrc>-(/data/chroot/dev-2022Q4-x86_64)-<~>-- ->
Nos vamos al directorio de x264 en PkgSrc:
-> cd /data/pkgsrc/multimedia/x264/
Vemos qué opciones de compilación tenemos:
-> bmake show-options
Any of the following general options may be selected:
threads Enable threads support.
These options are enabled by default:
threads
These options are currently enabled:
threads
You can select which build options to use by setting PKG_DEFAULT_OPTIONS
or PKG_OPTIONS.x264.
Vemos que solo hay una opción, threads, y que está activada por defecto. No hay nada que hacer.
Compilamos el código:
-> bmake package [...] => Creating pkginfo file /data/packages/SmartOS/2022Q4/x86_64/pkginfo/x264-20220601.pkginfo --<root@PkgSrc>-(/data/chroot/dev-2022Q4-x86_64)-</data/pkgsrc/multimedia/x264>-- ->
Ahora tenemos el paquete compilado en /data/packages/SmartOS/2022Q4/x86_64/All/x264-20220601.tgz. Podemos instalarlo en la zona SmartOS deseada, desempaquetarlo y obtener la biblioteca compartida, etc.
El proceso ha sido simple, rápido y limpio.
¿Cuál es la mejora de rendimiento entre utilizar la versión precompilada o compilarla nosotros mismos para nuestra CPU?
En ciertos perfiles de vídeo la versión precompilada es capaz de procesar 0.772 fotogramas por segundo, mientras que nuestra compilación consigue 4.08 fotogramas por segundo. La mejora es de 5.28.
En otros perfiles de vídeo la versión precompilada es capaz de procesar 0.518 fotogramas por segundo, pero nuestra versión obtiene 2.33 fotogramas por segundo. La mejora es de 4.5.
¡No está mal por menos de diez minutos de trabajo!
PS: Obsérvese que se está compilando la versión 20220601 de x264, que tiene casi un año de antigüedad. Habría que probar a compilar una versión más reciente. Tema futuro.
Apache HTTP añadió soporte nativo para el protocolo ACME (renovación automática de certificados X.509) en la versión 2.4.30 del servidor, como un componente opcional y experimental del mismo. La versión del paquete PkgSrc distribuido en SmartOS no tiene dicho módulo, así que en abril de 2020 pedí que se incluyese.
La respuesta fue algo decepcionante: Se añadía a PkgSrc la opción de compilar ese módulo opcional, mod_md, pero dado que sus propios autores lo tienen marcado como experimental, el paquete precompilado para SmartOS seguiría sin incluirlo de serie.
Pero, al menos, ahora puedo compilarlo de forma trivial yo mismo si lo necesito.
No voy a entrar en detalles sobre cómo compilar paquetes en PkgSrc para SmartOS. Este blog tienen muchos artículos sobre este tema, accesibles desde el menú de Tags de la parte superior de la página.
Los pasos concretos para compilar Apache HTTP con el módulo mod_md en una zona PkgSrc de SmartOS son los siguientes:
En Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap" describo cómo compilar Bind en SmartOS con soporte dnstap, utilizando PkgSrc. Por favor, lee dicho artículo para entender qué estoy haciendo y por qué.
El principal problema en ese artículo es que estoy utilizando la versión trunk de PkgSrc para beneficiarme de una versión más moderna de Bind, pero eso implica que la versión compilada utiliza bibliotecas no disponibles en la paquetería estándar de SmartOS y tenemos que compilarlas, distribuirlas e instalarlas a mano.
Si en vez de utilizar la versión trunk de PkgSrc utilizamos la versión que se corresponda a la Zona SmartOS en la que vamos a instalar Bind, no necesitaremos hacer nada especial con las dependencias.
Nota
Para lo que sigue nos conviente conocer la filosofía de PkgSrc: En PkgSrc, de forma automática, se descarga una versión concreta del código fuente que queremos compilar, se verifica su hash para asegurarnos de que es la versión correcta y no nos están colando gato por liebre, se le aplican una serie de parches locales, que es lo que se mantiene en realidad en PkgSrc, se compila y se genera un paquete. Esta gestión separada del código fuente original y los parches locales que necesitamos en nuestro sistema es la piedra angular de PkgSrc. Permite, por ejemplo, que no se requiera colaboración por parte de los autores originales de los programas para que soporten nuestro sistema operativo. Esto va como anillo al dedo con SmartOS, porque no podemos contar con que nadie ajeno le de mimos y cuide de él.
Los cambios respecto a Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap", serán:
Usamos una zona nativa SmartOS con la versión del software PkgSrc que se corresponda a las zonas nativas SmartOS donde vamos a instalar el Bind que compilamos, en vez de la versión trunk de PkgSrc:
[root@xXx ~]# imgadm avail|grep -i pkgbuild-lts 188ee9ce-540a-11eb-9cc1-2748cd10e5e2 pkgbuild-lts 20.4.0 smartos zone-dataset 2021-01-11 bd5afd7a-7ec1-11ec-80ab-7b01241031f6 pkgbuild-lts 21.4.0 smartos zone-dataset 2022-01-26 758a4572-911d-11ed-b841-00151714048c pkgbuild-lts 22.4.0 smartos zone-dataset 2023-01-10
Queremos compilar Bind para utilizarlo en una zona 22.4.0, así que importamos esa versión de zona PkgSrc y la desplegamos en una zona de nuestra máquina SmartOS.
Entramos en la zona PkgSrc por SSH y le pedimos que cree un entorno virtual de compilación:
[root@PkgSrc ~]# run-sandbox 2022Q4-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-2022Q4-x86_64 into /data/chroot/dev-2022Q4-x86_64...done. Setting up environment...done. Installing additional tools packages...done. Logging in. WARNING: On logout the sandbox will be destroyed. ,---. | ,---. ,---. `---. ,-.-. ,---. ,---. |--- | | `---. pkgbuild-lts | | | | ,---| | | | | | 22.4.0 `---' ` ' ' `---' ` `---' `---' `---' --<root@PkgSrc>-(/data/chroot/dev-2022Q4-x86_64)-<~>-- ->
Obsérvese que le estamos pidiendo un entorno de compilación 2022Q4-x86_64. En teoría las zonas PkgSrc modernas pueden compilar código para versiones más antiguas de las zonas SmartOS, solicitando la creación del entorno de compilación adecuado.
A la hora de usar Ansible en SmartOS una molestia constante es que, a veces, al volver a ejecutar un script Ansible, nos dice que realiza de nuevo las acciones pkgin (instalación de paquetes PkgSrc) o bien salta una excepción Python. Esto no ocurre siempre, pero sí ocurre con frecuencia.
Me explico: Las acciones Ansible se diseñan para que sean idempotentes. Es decir, que lanzar una acción que ya se ha realizado en el pasado debe marcar la acción como "ya realizada", en vez de realizarla de nuevo. En el caso concreto de las acciones pkgin, si le pedimos que instale un paquete que ya está instalado, debería decirnos que ya está hecho y no, en cambio, decirnos que ha realizado la acción de nuevo o fallar sin motivo. Es decir, el resultado de la acción debería ser ok y no changed o, peor aún, que salte una excepción.
En pocas palabras, cuando ejecutamos un script Ansible dos veces, la segunda vez debería darnos ok en todas las acciones porque no ha tenido que hacer nada.
Pero Ansible no lo hace así en el caso de acciones pkgin siempre. A veces lo hace y a veces no, por motivos desconocidos. Y cuando no lo hace, puede saltar una excepción Python.
Cuando ocurre así, si lanzamos de nuevo el script Ansible termina correctamente... casi siempre.
Molesto con la situación, estudio el código fuente de Ansible, que está escrito en Python. Me encuentro lo siguiente, entre otras cosas, en ansible_collections/community/general/plugins/modules/pkgin.py:
if rc == 0: if re.search('^nothing to do.\n$', out): module.exit_json(changed=False, msg="nothing left to upgrade") else: module.fail_json(msg="could not %s packages" % cmd, stdout=out, stderr=err)
Aquí se está buscando que el comando pkgin de SmartOS devuelva la cadena "nothing to do.", tal cual. El problema es que pkgin, al menos en las versiones modernas de SmartOS, termina con esa cadena cuando no tiene nada que hacer, pero puede ir precedida por bastante más texto y eso el código de Ansible no lo contempla.
En Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap" describo cómo compilar Bind en SmartOS con soporte dnstap, utilizando PkgSrc. Por favor, lee dicho artículo para entender qué estoy haciendo y por qué.
El principal problema en ese artículo es que estoy utilizando la versión trunk de PkgSrc para beneficiarme de una versión más moderna de Bind, pero eso implica que la versión compilada utiliza bibliotecas no disponibles en la paquetería estándar de SmartOS y tenemos que compilarlas, distribuirlas e instalarlas a mano.
Si en vez de utilizar la versión trunk de PkgSrc utilizamos la versión que se corresponda a la Zona SmartOS en la que vamos a instalar Bind, no necesitaremos hacer nada especial.
Los cambios respecto a Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap", serán:
Usamos una zona nativa SmartOS con la versión del software PkgSrc que se corresponda a las zonas nativas SmartOS donde vamos a instalar el Bind que compilamos, en vez de la versión trunk de PkgSrc:
[root@xXx ~]# imgadm avail|grep -i pkgbuild-lts 188ee9ce-540a-11eb-9cc1-2748cd10e5e2 pkgbuild-lts 20.4.0 smartos zone-dataset 2021-01-11 bd5afd7a-7ec1-11ec-80ab-7b01241031f6 pkgbuild-lts 21.4.0 smartos zone-dataset 2022-01-26
Entramos en la zona pkgsrc por SSH y le pedimos que cree un entorno virtual de compilación:
[root@PkgSrc ~]# run-sandbox 2021Q4-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-2021Q4-x86_64 into /data/chroot/dev-2021Q4-x86_64...done. Setting up environment...done. Installing additional tools packages...done. Logging in. WARNING: On logout the sandbox will be destroyed. __ . . _| |_ | .-. . . .-. :--. |- |_ _| ;| || |(.-' | | | |__| `--' `-' `;-| `-' ' ' `-' / ; Instance (pkgbuild-lts 21.4.0) `-' https://docs.joyent.com/images/smartos/pkgbuild --<root@PkgSrc>-(/data/chroot/dev-2021Q4-x86_64)-<~>-- ->
En Cómo usar "ccache" para compilar en PkgSrc de SmartOS explico cómo utilizar ccache a la hora de compilar paquetes PkgSrc.
Ahí propongo realizar un cambio en el fichero /data/pkgbuild/scripts/run-sandbox [1] para añadir lo siguiente al fichero .bashrc del 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
La segunda línea no funciona correctamente en SmartOS porque ahí el fichero /opt/local/etc/mk.conf dentro del entorno chroot ignora la variable de entorno PKGSRC_COMPILER y fuerza un valor explícito de PKGSRC_COMPILER=gcc a la hora de compilar.
Por tanto, lo mejor es cambiar el fichero /data/pkgbuild/scripts/run-sandbox [1] para que modifique ese fichero a la hora de crear el entorno chroot. Sería cuestión de añadirle una línea como esta poco antes del final del fichero:
sed -i "s/^PKGSRC_COMPILER=/PKGSRC_COMPILER?=/g" ${chrootdir}${PKGBUILD_SYSCONFDIR}/mk.conf
Ese cambio en el fichero /opt/local/etc/mk.conf dentro del entorno chroot mantiene la definición por defecto de PKGSRC_COMPILER cuando no le hemos puesto un valor concreto por variable de entorno, pero la variable de entorno manda si existe. Así debería venir de serie en SmartOS. Usando expansiones shell, modificamos el fichero correcto sea cual sea el branch PkgSrc que estamos utilizando para generar el entorno chroot.
Además, el export estaba mal. Hay que poner el valor entre comillas. Por ejemplo:
export PKGSRC_COMPILER="ccache gcc"
| [1] | (1, 2) Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS. |