commit 8f7e4295335be82f8016772cc8c80260a3585048
parent 9cf4fc1e7c6b9c33bad9b1e9176f4b9719269103
Author: fjbalon <fjbalon@templier.es>
Date: Fri, 26 Jun 2026 17:17:09 +0200
Refactorización de císter-software, añadido artículo de SlackBuild y eliminado artículo de yihad a C
Diffstat:
6 files changed, 186 insertions(+), 32 deletions(-)
diff --git a/cister-software-libre/imagen1.jpeg b/cister-software-libre/imagen1.jpeg
Binary files differ.
diff --git a/cister-software-libre/imagen2.jpeg b/cister-software-libre/imagen2.jpeg
Binary files differ.
diff --git a/cister-software-libre/index.html b/cister-software-libre/index.html
@@ -16,11 +16,9 @@
<h2>Expertos técnicos</h2>
<p>Estos monjes se organizaban en abadías y monasterios que, con frecuencia, se levantaban en lugares apartados del bullicio de las ciudades y del mundo secular. Lo que convertía la autonomía y la autosuficiencia en una necesidad para ellos: cada comunidad debía producir su propio alimento, mantener sus edificios y gestionar sus recursos.</p>
<p>Esto impulsó a los monjes a convertirse en hábiles agricultores, arquitectos, ingenieros hidráulicos y artesanos. Desarrollaron técnicas avanzadas de cultivo, sistemas de irrigación, molinos y construcciones que transformaron el paisaje rural europeo. Todo ello se enmarca en el espíritu resumido por la locución latina <i>ora et labora</i>, atribuida tradicionalmente a San Benito de Nursia (aunque realmente es posterior, refleja fielmente el equilibro entre oración y trabajo manual o intelectual).</p>
-<img src="imagen1.jpeg" />
<p>Estos hechos los hacían unos técnicos-artesanos, con gran amor y respeto por el trabajo manual y con un enorme sentido de comunidad; primero a su propia comunidad, y después al resto que conformaban la orden. ¿No os recuerda al usuario de Linux?</p>
<h2>Distribucionismo de la comunidad</h2>
<p>La orden experimentó una expansión espectacular en los siglos XII y XIII, partiendo de la abadía madre de Cîteaux (en la Borgoña, Francia), se extendieron rápidamente por toda Europa occidental. La mayor concentración estaba en Francia, claro, pero hubo una significativa presencia en España, Portugal, Inglaterra, Irlanda, Italia, Países Bajos, Alemania, Austria, Bohemia, Polonia… Incluso llegaron Escocia, Suecia y Tierra Santa (evidentemente explicado usando naciones modernas para no liarnos).</p>
-<img src="imagen2.jpeg" />
<p>Cada abadía nueva era hija de una abadía madre. Por ejemplo, muchas eran hijas de Clairvaux, fundada por San Bernardo. Esto creaba una red de parentesco institucional, dependencia, herencia y observancia entre ellas. Eran comunidades separadas, pero unidas y fuertemente cohesionadas por esta estructura. El abad de la casa madre tenía la obligación de visitar cada año las abadías hijas para inspeccionar que se mantuviera la observancia correcta, corregir abusos y ofrecer apoyo. Era una forma de control y ayuda mutua.</p>
<p>¿Esto no os recuerda al modelo de distribuciones de las comunidades GNU/Linux? ¿al desarrollo de UNIX? ¿a la estructura de distros madres e hijas? ¿Podríamos decir que Clairvaux es Debian? ¿Molesme sería Slackware?</p>
<h2>Registros monásticos y comunicación</h2>
diff --git a/index.html b/index.html
@@ -59,6 +59,11 @@
<p class="info">12 de febrero de 2026 · fjbalon</p><p>Habiéndome levantado con la filtración, se supone involuntaria, del panel de control del spyware de la empresa israelí Paragon, motivado por una imagen publicada por el abogado general de la empres...</p>
</a>
+<a href="./slackbuild/" class="article">
+ <p class="title">Anatomía de un SlackBuild</p>
+ <p class="info">12 de diciembre de 2025 · fjbalon</p><p>Como usuario de Slackware, he usado alguna vez scripts de SlackBuild para crear un paquete de software que pueda ser instalado fácil y limpiamente, y eliminado más tarde si es necesario con la misma...</p>
+</a>
+
<a href="./selinux/" class="article">
<p class="title">Mi primer SELinux denial</p>
<p class="info">15 de mayo de 2025 · fjbalon</p><p>Os pongo en contexto. Un Rocky 9.5 (derivado de RHEL, para quien no lo conozca) que he empezado a administrar, sirve un servidor Apache (httpd). He importado una configuración propia en forma de fich...</p>
@@ -79,11 +84,6 @@
<p class="info">11 de septiembre de 2024 · fjbalon</p><p>Lingua::Romana::Perligata es un módulo del lenguaje de programación Perl creado por Damian Conway, un experimentado programador australiano que forma parte de la comunidad de Perl, autor de Perl Bes...</p>
</a>
-<a href="./yihad-c/" class="article">
- <p class="title">¿Existe una yihad contra C/C++?</p>
- <p class="info">3 de septiembre de 2024 · fjbalon</p><p>El 19 de julio de 2024 se produjo uno de los mayores fallos informáticos de la historia. No fue un ciberataque per se, sino un fallo provocado por una actualización defectuosa de software de CrowdSt...</p>
-</a>
-
<a href="./le-roman-de-la-rose/" class="article">
<p class="title"><i>Le Roman de la Rose</i> y la disyunción medieval</p>
<p class="info">27 de julio de 2024 · fjbalon</p><p>Como ya vengo defendiendo tiempo atrás, existe una disyunción entre la Cristiandad y el mundo grecorromano, totalmente naturalizado y cotidiano para el hombre medieval, pero muy ignorado para el hom...</p>
diff --git a/slackbuild/index.html b/slackbuild/index.html
@@ -0,0 +1,181 @@
+<!DOCTYPE html>
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+<meta name="viewport" content="width=device-width, initial-scale=1" />
+<title>Anatomía de un SlackBuild</title>
+<link rel="icon" type="image/png" href="/favicon.png" />
+<link rel="stylesheet" type="text/css" href="../article.css" />
+</head>
+<body>
+<header>
+<p class="title">Anatomía de un SlackBuild</p>
+<p class="date">12 de diciembre de 2025 • fjbalon</p>
+</header>
+<p>Como usuario de Slackware, he usado alguna vez scripts de SlackBuild para crear un paquete de software que pueda ser instalado fácil y limpiamente, y eliminado más tarde si es necesario con la misma facilidad y limpieza. Lo veremos en más profundidad más adelante, pero resumidamente sabemos que un SlackBuild es un script de shell que nos permite compilar e instalar paquetes desde el código fuente, creando un paquete -generalmente <emb>txz</emb>, aunque también <emb>tgz</emb>- y se instala mediante la herramienta nativa de Slackware <emb>installpkg</emb>. Se distribuyen principalmente en el repositorio oficial de <a href="https://slackbuilds.org">slackbuilds.org</a>.</p>
+<p>Al final, los SlackBuilds constituyen la forma oficial, digamos, de instalar software que mno viene en los repositorios base de Slackware.</p>
+<p>Existen diferentes enfoques de un script de SlackBuild, por ejemplo <i>Alien Bob</i> tiene su muy útil <a href="https://alien.slackbook.org/AST/">creador de SlackBuilds</a> y, en términos generales, lo respetaremos. Y como ejemplo mediante el cual encarnar lo que vamos a describir, usaré el paquete <a href="https://slackbuilds.org/repository/15.0/system/ksh-openbsd/">ksh-openbsd</a>. La descarga, generalmente, viene en un paquete comprimido <emb>.tar.gz</emb>, que se destarea y descomprime con <emb>tar xzvf</emb>, siendo el contenido del directorio:</p>
+<pre><code>ls
+doinst.sh ksh-openbsd.info ksh-openbsd.SlackBuild README slack-desc</code></pre>
+<p>Siendo el que nos interesa realmente el script <emb>ksh-openbsd.SlackBuild</emb> (téngase en cuenta que he eliminado comentarios para una mejor legibilidad):</p>
+<pre><code>#!/bin/bash
+
+cd $(dirname $0) ; CWD=$(pwd)
+
+PRGNAM=ksh-openbsd
+VERSION=${VERSION:-20190804}
+BUILD=${BUILD:-1}
+TAG=${TAG:-_SBo}
+PKGTYPE=${PKGTYPE:-tgz}
+
+if [ -z "$ARCH" ]; then
+ case "$( uname -m )" in
+ i?86) ARCH=i586 ;;
+ arm*) ARCH=arm ;;
+ *) ARCH=$( uname -m ) ;;
+ esac
+fi
+
+if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
+ echo "$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE"
+ exit 0
+fi
+
+TMP=${TMP:-/tmp/SBo}
+PKG=$TMP/package-$PRGNAM
+OUTPUT=${OUTPUT:-/tmp}
+
+if [ "${ARCH}" == "i586" ];then
+ SLKCFLAGS='-march=i586 -mtune=i686'
+ LIBDIRSUFFIX=""
+elif [ "$ARCH" == "i686" ]; then
+ SLKCFLAGS="-march=i686 -mtune=i686"
+ LIBDIRSUFFIX=""
+elif [ "${ARCH}" == "x86_64" ];then
+ SLKCFLAGS='-fPIC'
+ LIBDIRSUFFIX="64"
+else
+ SLKCFLAGS="-O2"
+ LIBDIRSUFFIX=""
+fi
+
+set -e
+
+rm -Rf $PKG
+mkdir -p $TMP $PKG $OUTPUT
+cd $TMP
+rm -Rf $PRGNAM-$VERSION
+tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
+cd $PRGNAM-$VERSION
+chown -R root:root .
+find -L . \
+ \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 -o -perm 511 \) \
+ -exec chmod 755 {} \+ -o \
+ \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
+ -exec chmod 644 {} \+
+
+CFLAGS="$SLKCFLAGS $(getconf LFS_CFLAGS)" make
+
+case "$(ps -o stat= -p $$)" in
+ *+*) make check ;; # running in foreground
+ *) echo '*** Not running "make check" because we are in the background.' ;;
+esac
+
+make install DESTDIR=$PKG
+
+if [ -n "${PDKSH_BINNAME}" ];then
+ mv $PKG/bin/pdksh $PKG/bin/"${PDKSH_BINNAME}"
+ mv $PKG/usr/man/man1/pdksh.1 $PKG/usr/man/man1/"${PDKSH_BINNAME}".1
+ mv $PKG/usr/man/man1/pdksh-sh.1 $PKG/usr/man/man1/"${PDKSH_BINNAME}"-sh.1
+fi
+BINNAME=${PDKSH_BINNAME:-pdksh}
+
+strip --strip-unneeded $PKG/bin/"${BINNAME}"
+gzip -9 $PKG/usr/man/man1/"${BINNAME}".1
+gzip -9 $PKG/usr/man/man1/"${BINNAME}"-sh.1
+
+mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
+cp -a \
+ Changelog.ksh-openbsd LEGAL README \
+ $PKG/usr/doc/$PRGNAM-$VERSION
+cp $CWD/README $PKG/usr/doc/$PRGNAM-$VERSION/README.ksh-openbsd
+cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
+
+mkdir -p $PKG/install</code></pre>
+<p>Tras el <i>shebang</i> definimos las variables principales del paquete, como son <emb>PRGNAM</emb> (nombre del paquete, o sea, <emb>ksh-openbsd</emb>), <emb>VERSION</emb> (versión del software), <emb>BUILD</emb> (número de build del paquete Slackware, por defecto 1), <emb>TAG</emb> (etiqueta que se añade al paquete, como <emb>_SBo = SlackBuilds.org</emb>) y <emb>PKGTYPE</emb> (tipo de paquete, <emb>tgz</emb> en este caso).</p>
+<pre><code>if [ -z "$ARCH" ]; then
+ case "$( uname -m )" in
+ i?86) ARCH=i586 ;;
+ arm*) ARCH=arm ;;
+ *) ARCH=$( uname -m ) ;;
+ esac
+fi</code></pre>
+<p>Detectamos automáticamente la arquitectura del equipo si el usuario no la tiene
+definida.</p>
+<pre><code>if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
+ echo "$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE"
+ exit 0
+fi</code></pre>
+<p>Es una parte muy útil para herramientas de gestión de paquetes como <emb>sbopkg</emb> o <emb>sbotools</emb>. Si la variable <emb>PRINT_PACKAGE_NAME</emb> está definida, aunque vacía, el script imprimirá el nombre completo del paquete (<emb>ksh-openbsd-20190804-x86_64-1_SBo.tgz</emb>). Esto permite a los gestores de paquetes saber el nombre sin tener que construir todo.</p>
+<p>Después definirá los entornos de trabajo en <emb>TMP</emb> (por defecto <emb>/tmp/SBo</emb>), <emb>PKG</emb> (directorio donde se va a instalar el software en la fase de compilación) y <emb>OUTPUT</emb> (dónde se almacenará el <emb>.tgz</emb> final).</p>
+<pre><code>if [ "${ARCH}" == "i586" ];then
+ SLKCFLAGS='-march=i586 -mtune=i686'
+ LIBDIRSUFFIX=""
+elif [ "$ARCH" == "i686" ]; then
+ SLKCFLAGS="-march=i686 -mtune=i686"
+ LIBDIRSUFFIX=""
+elif [ "${ARCH}" == "x86_64" ];then
+ SLKCFLAGS='-fPIC'
+ LIBDIRSUFFIX="64"
+else
+ SLKCFLAGS="-O2"
+ LIBDIRSUFFIX=""
+fi</code></pre>
+<p>En este punto definimos las variables <emb>SLKCFLAGS</emb> y <emb>LIBDIRSUFFIX</emb>, utilizadas para optimización en función de la arquitectura previamente reconocida; y para la toma de decisión del uso del directorio <emb>/usr/lib</emb> o <emb>/usr/lib64</emb>, en función -de nuevo- de la arquitectura.</p>
+<p>A partir de aquí podemos decir que la técnica se inicia, una vez realizadas las parametrizaciones técnicas iniciales. La línea que contiene <emb>set -e</emb> indica al intérprete que si cualquier comando devuelve un error (código de salida distinto de 0), el script se detiene inmediatamente. Es una medida de seguridad muy común en este tipo de scripts.</p>
+<pre><code>rm -Rf $PKG
+mkdir -p $TMP $PKG $OUTPUT
+cd $TMP
+rm -Rf $PRGNAM-$VERSION
+tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
+cd $PRGNAM-$VERSION
+chown -R root:root .
+find -L . \
+ \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 -o -perm 511 \) \
+ -exec chmod 755 {} \+ -o \
+ \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
+ -exec chmod 644 {} \+</code></pre>
+<p>Entonces elimina el directorio <emb>$PKG</emb>, por si hubiera una compilación anterior fallida o lo que fuera. Después, crea -si no existen- los directorios de trabajo previamente definidos. Nos movemos a <emb>/tmp/SBo</emb>, borra cualquier directorio que pudiera haber de código fuente, extrae con <emb>tar xvf</emb> el tarball que debe estar en la misma carpeta que el SlackBuild (<emb>$CWD</emb>) y accedemos a la carpeta del código fuente.</p>
+<p>Entonces, aplicamos una "reparación de permisos", que inicia cambiando el propietario recursivamente a <emb>root:root</emb> y, mediante el comando <emb>find</emb>, buscamos archivos y carpetas con permisos inusuales, o demasiado permisivos. Los ejecutables o directorios se pondrán en permiso 755 (<emb>rwxr-xr-x</emb>), el resto de archivos en 644 (<emb>rw-r--r--</emb>).</p>
+<p>Después, con <emb>CFLAGS="$SLKCFLAGS $(getconf LFS_CFLAGS)" make</emb> definimos variables de entorno para el comando <emb>make</emb>, utilizando los parámetros del inicio y ejecutando <emb>getconf</emb> para obtener otros parámetros necesarios.</p>
+<pre><code>case "$(ps -o stat= -p $$)" in
+ *+*) make check ;; # running in foreground
+ *) echo '*** Not running "make check" because we are in the background.' ;;
+esac</code></pre>
+<p>Es entonces cuando iniciamos la fase de compilación. En términos generales se realiza directament el <emb>make</emb>, pero se ve que el programador de este paquete de ejemplo le añadió algo de complejidad: a veces, parece qu eel paquete en instalación (<emb>ksh-openbsd</emb>, recuerdo) se cuelga durante el <emb>make check</emb>, que indica una fase de testing, cuando se ejecuta en segundo plano. Esto ocurre con más frecuencia cuando se usa <emb>sbopkg</emb>, <emb>queue</emb> o scripts de compilación masiva. El test se quedaría esperando algo de terminal/entrada y bloquea toda la cola. ¿La solución? sencilla: si estoy ejecutando el SlackBuild manualmente en una términal, haga los test; si no, ignórelos.</p>
+<p>Entonces, sí hacemos el make con <emb>make install DESTDIR=$PKG</emb> sobre el directorio de trabajo final.</p>
+<pre><code>if [ -n "${PDKSH_BINNAME}" ];then
+ mv $PKG/bin/pdksh $PKG/bin/"${PDKSH_BINNAME}"
+ mv $PKG/usr/man/man1/pdksh.1 $PKG/usr/man/man1/"${PDKSH_BINNAME}".1
+ mv $PKG/usr/man/man1/pdksh-sh.1 $PKG/usr/man/man1/"${PDKSH_BINNAME}"-sh.1
+fi
+BINNAME=${PDKSH_BINNAME:-pdksh}</code></pre>
+<p>Si el usuario define la variable de entorno <emb>PDKSH_BINNAME</emb> antes de ejecutar el script, entonces renombra todo para que el shell no se llame <emb>pdksh</emb>. Por ejemplo, si el usuario ha ejecutado antes <emb>PDKSH_BINNAME=ksh ./ksh-openbsd.SlackBuild</emb>, el binario pasaría a llamarse <emb>ksh</emb> en lugar de <emb>pdksh</emb> (renombrando a su vez las páginas de manual correspondientes, claro está).</p>
+<pre><code>strip --strip-unneeded $PKG/bin/"${BINNAME}"
+gzip -9 $PKG/usr/man/man1/"${BINNAME}".1
+gzip -9 $PKG/usr/man/man1/"${BINNAME}"-sh.1</code></pre>
+<p>El comando <emb>strip</emb> sobre el binario principal elimina todos los símbolos de depuración y sesiones innecesarias del ejecutable, pero sin romper las funciones necesarias (de ahí que se use <emb>--strip-unneeded</emb> en lugar de <emb>--strip-all</emb>). Esto reduce considerablemente el tamaño del binario final. Es una práctica estándar en todos los paquetes de Slackware.</p>
+<p>Después, comprime las páginas de manual con <emb>gzip</emb> usando el nivel máximo de compresión (<emb>-9</emb>).</p>
+<pre><code>mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
+cp -a \
+ Changelog.ksh-openbsd LEGAL README \
+ $PKG/usr/doc/$PRGNAM-$VERSION
+cp $CWD/README $PKG/usr/doc/$PRGNAM-$VERSION/README.ksh-openbsd
+cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild
+
+mkdir -p $PKG/install</code></pre>
+<p>Y finalmente, creamos el directorio con la documentación, copiamos ésta y, encima, copiamos el propio SlackBuild dentro de dicha carpeta. Esto está encarecidamente recomendado por las buenas prácticas de un SlackBuild, puesto que permite al usuario final ver cómo se compiló el paquete en cualquier momento. Es útil además para depuraciónh y para reproducción, en caso necesario.</p>
+<p>Además, crea el directorio <emb>/install</emb> dentro del propio paquete. Aquí almacenará los archivos de metadatos del paquete, como <emb>slack-desc</emb>, <emb>doinst.sh</emb>, <emb>slack-required</emb>, <emb>slack-conflicts</emb>, etcétera.</p>
+<p>Como hemos visto, el contenido de un SlackBuild es muy completo, contando con todas las fases de despliegue de un software: preparación, parametrización, configuración de compilación o pre-compilación, extracción y limpieza, compilación, instalación, optimización, documentación, empaquetado final... Se trata de un guión y hoja de ruta poderosa para el usuario de Slackware, desde luego, y muy útil y práctica en el día a día de la administración de este sistema.</p>
+</body>
+</html>
diff --git a/yihad-c/index.html b/yihad-c/index.html
@@ -1,24 +0,0 @@
-<!DOCTYPE html>
-<html>
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-<meta name="viewport" content="width=device-width, initial-scale=1" />
-<title>¿Existe una yihad contra C/C++?</title>
-<link rel="icon" type="image/png" href="/favicon.png" />
-<link rel="stylesheet" type="text/css" href="../article.css" />
-</head>
-<body>
-<header>
-<p class="title">¿Existe una yihad contra C/C++?</p>
-<p class="date">3 de septiembre de 2024 • fjbalon</p>
-</header>
-<p>El 19 de julio de 2024 se produjo uno de los mayores fallos informáticos de la historia. No fue un ciberataque per se, sino un fallo provocado por una actualización defectuosa de software de CrowdStrike, una empresa de ciberseguridad que mantiene una herramienta llamada Falcon Sensor. Uno de los archivos de configuración que liberaron con la actualización llevaba un error que provocaba BSOD (pantallazo azul) en los ordenadores afectados, provocando a aproximadamente 8,5 millones de dispositivos Windows.</p>
-<p>Esto provocó caos global durante horas: aerolíneas caídas, hospitales, bancos, servicios de emergencia, medios de comunicación, etcétera.</p>
-<p>Siendo más concreto, al parecer, el error venía de un mal puntero a memoria en el código C++. Al principio parecía que el error se relacionaba con una desreferencia de un puntero NULL, después, parece que el programa leía punteros de una tabla en bucle, y algunos no eran válidos, provocando el error. Probablemente la causa del mal puntero venía de un archivo de configuración con entradas sin inicializar, como decía. No entraré en más detalle técnico preciso.</p>
-<p>Sea como fuera, parece obvio que el causante del problema fue un puntero a memoria. Ahora, sin afán de ser conspiranoico, ¿no parece curioso que ocurra esto tan solo unos meses después de que la Oficina de su Director Nacional de Ciberseguridad (ONCD) de la Casa Blanca hiciera público un llamamiento a la industria del software para promover lenguajes memory-safe? ¿y que posteriormente haya eliminado la publicación? Desde luego, tranquilizador no es.</p>
-<p>Básicamente, la Casa Blanca exhorta a dejar de utilizar lenguajes que no garanticen la seguridad de la memoria (mediante punteros) como C o C++, y recomiendan el uso de otros lenguajes que sí la garanticen como Rust, Python, Java, C#, Go…</p>
-<p>Es un intento de "ilegalización" positiva (en el sentido de derecho, no moral) de C y C++ por parte del gobierno de EEUU.</p>
-<p>También la NSA, que para nada es sospechosa de buscar "inseguridad por diseño", ha desaconsejado el uso de C/C++ por el mismo motivo.</p>
-<p>Seguramente haya sido una enorme casualidad que, en el mismo curso, instituciones de gobierno de EEUU desaconsejen programas no memory-safe, y ocurra un fallo a escala global provocado por un fallo de puntero a memoria.</p>
-</body>
-</html>
-\ No newline at end of file
