commit 58e60d6eb8ae7acb7626dd5ac220e90eb912a39f
parent bf7ab015c9721f50f42826089535440a3ad9327b
Author: fjbalon <fbalon@templier.es>
Date: Mon, 8 Jun 2026 16:47:12 +0200
Breve corrección de errores de artículos
Diffstat:
11 files changed, 62 insertions(+), 125 deletions(-)
diff --git a/archlinux/index.html b/archlinux/index.html
@@ -16,61 +16,47 @@
<p>Esta distribución tiene sus raíces en 2002, cuando Judd Vinet la construyó en un enfoque de entorno simple y elegante, permitiendo a sus usarios modelar su sistema de acuerdo a sus necesidades y preferencias. Se trata además de un sistema de actualización <i>rolling release</i>, lo que aporta un mantenimiento continuo sin necesidad de reinstalaciones periódicas; característica que, unida a su gestor de paquetes <emb>pacman</emb> ofrece una experiencia de usuario ágil y, sobretodo, rápida de gestión de las últimas versiones del software.</p>
<p>Realmente, el uso de Arch es muy simple, siendo incluso más simple que distribuciones basadas en Debian (sobretodo, por su gestor de paquetes, que lo hace excesivamente sencillo de utilizar incluso para un novato). Sin embargo, si hay una barrera de entrada para comenzar a usar este sistema operativo no es otra que cosa que la instalación. La instalación del sistema no cuenta con formularios gráficos ni diálogos que guien al usuario; sino simplemente ofrece una sesión de shell y otorga libertad total sobre ella al usuario.</p>
<p>Es por esta razón que he compendiado los pasos que realizó personalmente a la hora de construir mi sistema de Arch.</p>
-<p>El inicio es sencillo, el console keymap por defecto es US (inglés americano). Para modificar el diseño, agregue el nombre de layout correspondiente. Por ejemplo, para establecer una distribución de teclado en español utilice:</p>
-<pre><code># loadkeys es</code></pre><h2>Verificación de modo de arranque (boot mode)</h2>
+<p>El inicio es sencillo, el console keymap por defecto es US (inglés americano). Para modificar el diseño, se puede agregar el nombre de layout correspondiente. Por ejemplo, para establecer una distribución de teclado en español utilizo:</p>
+<pre><code>loadkeys es</code></pre>
+<h2>Verificación de modo de arranque (boot mode)</h2>
<p>En términos simples, la BIOS (Sistema Básico de Entrada/Salida) y UEFI (Interfaz de Firmware Extensible Unificada) son dos tecnologías diferentes utilizadas para iniciar un sistema operativo en una computadora.</p>
<p>La BIOS, que significa Sistema Básico de Entrada/Salida, ha sido la interfaz estándar durante décadas. Se encarga de las operaciones básicas del sistema, incluido el proceso de arranque. Sin embargo, tiene limitaciones en cuanto a la capacidad de manejar discos duros grandes y sistemas operativos modernos.</p>
<p>Por otro lado, UEFI, que significa Interfaz de Firmware Extensible Unificada, es una tecnología más reciente que reemplaza gradualmente a la BIOS. UEFI proporciona una interfaz más avanzada y versátil, permitiendo un arranque más rápido y una mayor capacidad para gestionar hardware y sistemas operativos modernos. Además, UEFI supera las limitaciones de tamaño de disco asociadas con la BIOS.
-<p>Para verificar el modo de arranque, liste el directorio <emb>efivars</emb>:</p>
-<pre><code># ls /sys/firmware/efi/efivars</code></pre>
+<p>Para verificar el modo de arranque, bastaría listar el directorio <emb>efivars</emb>:</p>
+<pre><code>ls /sys/firmware/efi/efivars</code></pre>
<p>Si la salida muestra el contenido del directorio (stdout) sin error, entonces el sistema de inicio es UEFI. Si por el contrario ofrece error (stderr) debido a que el directorio no existe, entonces el sistema se inicia en modo BIOS (ó CSM).</p> <h2>Conexión a Internet</h2>
-<p>Si tenemos comunicación ethernet con salida a Internet, conéctelo. De lo contrario será necesario establecer conexión con la red a través de WiFi (siempre que el equipo cuente con el hardware necesario). Utilizaremos <emb>iwctl</emb> para autenticarnos a la red inalámbrica.</p>
-<p>Para obtener un prompt interactivo haga:</p>
-<pre><code># iwctl</code></pre>
-<p>El prompt interactivo se mostrará con el prefijo [iwd]#.</p>
-<p>Para conectarse a una red, si no conoce el nombre de su interfaz inalámbrica puede enumerar todos con:</p>
-<pre><code>[iwd]# device list</code></pre>
-<p>Entonces, para escanear las redes disponibles haga (donde d es la interfaz inalámbrica obtenida anteriormente):</p>
-<pre><code>[iwd]# station d scan</code></pre>
-<p>Puede listar las redes escaneadas con:</p>
-<pre><code>[iwd]# station d get-networks</code></pre>
-<p>Finalmente, para conectar con una de estas redes conociendo su SSID indique:</p>
-<pre><code>[iwd]# station d connect SSID</code></pre>
-<p><emb>iwd</emb> le indicará que indique la contraseña en caso de contar con seguridad (lo que es altamente recomendable).</p><h2>Particionado de discos</h2>
+<p>Si tenemos comunicación ethernet con salida a Internet, bastaría conectarlo; generalmente el DHCP trabajará solo. De lo contrario será necesario establecer conexión con la red a través de WiFi (siempre que el equipo cuente con el hardware necesario). Utilizaremos <emb>iwctl</emb> para autenticarnos a la red inalámbrica, identificaremos la interfaz de red, escanearemos las conexiones WiFi disponibles y conectaremos con la que identifiquemos por su SSID:</p>
+<pre><code>iwctl
+[iwd]# device list
+[iwd]# station d scan
+[iwd]# station d get-networks
+[iwd]# station d connect SSID</code></pre>
+<h2>Particionado de discos</h2>
<p>Cuando son reconocidos por el sistema live, los discos son asignados a un dispositivo de bloques como <emb>/dev/sda</emb>, <emb>/dev/nvme0n1</emb> ó <emb>/dev/mmcblk0</emb>. Para identificar estos dispositivos, utilice <emb>lsblk</emb> ó <emb>fdisk</emb>. El siguiente presupondrá la siguiente partición de discos:</p>
<pre><code>boot /dev/sda1 /boot 150MB *Bootable
root /dev/sda2 / -
home /dev/sda3 /home -
swap /dev/sda4 /swap 2GB Type: Linux Swap / Solaris</code></pre><h2>Formateo de particiones</h2>
<p>Una vez particionados los discos y sus particiones, éstas deben ser formateadas con un sistema de archivos apropiado.</p>
-<p>En caso de contar con un sistema UEFI, formatearemos la partición de <emb>/boot</emb> en <emb>VFAT</emb>:</p>
-<pre><code>mkfs.vfat -F32 $boot</code></pre>
-<p>En caso de contar con un sistema BIOS, formatearemos la partición de <emb>/boot</emb> en <emb>ext2</emb>:</p>
-<pre><code>mkfs.ext2 $boot</code></pre>
-<p>El resto de particiones para <emb>/</emb> y <emb>/home</emb> en <emb>ext4</emb>. Posteriormente, utilizaremos la herramienta <emb>mkswap</emb> y <emb>swapon</emb> para formatear como memoria Swap la partición <emb>/swap</emb> y activarla como tal.</p>
-<pre><code>mkfs.ext4 $root
+<pre><code>mkfs.vfat -F32 $boot # UEFI
+mkfs.ext2 $boot # BIOS
+mkfs.ext4 $root
mkfs.ext4 $home
mkswap $swap
swapon $swap</code></pre><h2>Montaje de sistema de archivos</h2>
-<p>Monte primero el volumen raíz en /mnt: </p>
-<pre><code>mount $root /mnt
-if [ $uefi = true ]; then
- mkdir -p /mnt/boot/efi
- mount $boot /mnt/boot/efi
-else
- mkdir /mnt/boot
- mount $boot /mnt/boot
-fi
-mkdir /mnt/home
-mount $home /mnt/home</code></pre><h2>Instalación del sistema base</h2>
+<p>El montaje en el directorio /mnt debe comenzar siempre con la raíz: </p>
+<pre><code>mount $root /mnt
+mkdir -p /mnt/boot/efi && mount $boot /mnt/boot/efi # UEFI
+mkdir /mnt/boot && mount $boot /mnt/boot # BIOS
+mkdir /mnt/home && mount $home /mnt/home</code></pre>
+<h2>Instalación del sistema base</h2>
<p>Los paquetes a instalar se descargarán de los servidores espejo, que se definen en /etc/pacman.d/mirrorlist. Cuanto más alto se coloca un espejo en la lista, más prioridad se le da al descargar un paquete; por lo que es posible que desee inspeccionar el archivo para ver si se encuentra en una prioridad deseable. Si no fuera así, edite el archivo en consecuencia y mueva los espejos geográficamente más cercanos a la parte superior de la lista (aunque existen otros criterios).</p>
<p>Use el script pacstrap para instalar el paquete base, el kernel de Linux y el firmware para hardware común: </p>
-<pre><code># pacstrap /mnt base linux linux-firmware</code></pre>
+<pre><code>pacstrap /mnt base linux linux-firmware</code></pre>
<p>Puede sustituir linux por un paquete de kernel de su elección, por supuesto. Tenga en cuenta que el paquete base no incluye todas las herramientas de la instalación en vivo, por lo que la instalación de otros paquetes puede ser necesaria para mantener el sistema base funcional. Como es mi caso, que añado:</p>
<pre><code>pacstrap /mnt base-devel grub networkmanager nano dhcpcd
-if [ $uefi = true ]; then
- pacstrap /mnt efibootmgr
-fi</code></pre><h2>Configuración del sistema base</h2>
+pacstrap /mnt efibootmgr # UEFI</code></pre>
+<h2>Configuración del sistema base</h2>
<p>Genere el archivo fstab (use -U ó -L para definir por UUID o labels, respectivamente):</p>
<pre><code># genfstab -U -p /mnt >> /mnt/etc/fstab</code></pre>
<p>Enjáulese ahora (chroot) en su nuevo sistema montado en /mnt:</p>
diff --git a/dd/index.html b/dd/index.html
@@ -76,7 +76,7 @@ do
done
echo $base$(echo $unidades | cut -f$i -d, )</code></pre>
<p>Cuyo resultado se basa en la escritura de datos provenientes de <emb>/dev/zero</emb> ó <emb>/dev/urandom</emb> en un disco pasado como argumento, de tal forma que analiza el rendimiento dado por el obs:</p>
-<pre><code>$ sudo ./dd-obs.sh /dev/sdd
+<pre><code>sudo ./dd-obs.sh /dev/sdd
512 (512b) : 7 MB/s
1024 (1K) : 9 MB/s
2048 (2K) : 0 MB/s
@@ -109,7 +109,7 @@ do
printf "$BLOCK_SIZE ($(human_bytes $BLOCK_SIZE)) : $TRANSFER_RATE \n"
done</code></pre>
<p>Ofreciendo un resultado similar, permitiéndonos ajustar el tamaño del bloque con mayor inteligencia:</p>
-<pre><code>$ sudo ./dd-ibs.sh example
+<pre><code>sudo ./dd-ibs.sh example
512 (512b) : 275 MB/s
1024 (1K) : 373 MB/s
2048 (2K) : 276 MB/s
diff --git a/interpolacion-lineal/index.html b/interpolacion-lineal/index.html
@@ -26,7 +26,7 @@
<p>Sin embargo, debido a la diferente resistencia nominal, las lecturas de los sensores Pt1000 son mayores en un factor de 10 en comparación con los sensores Pt100. Esta diferencia se hace evidente cuando se comparan configuraciones de 2 cables, donde se aplica el error de medición del cable. Por ejemplo, el error de medición en un Pt100 podría ser <emb>+1.0ºC</emb>, y en el mismo diseño, un Pt1000 podría ser <emb>+0.1ºC</emb>.</p>
<p>Tras contextualizar expongo el problema: leyendo mediante modbus los datos recibidos de un par de termorresistencias Pt100, me percaté que recibía, evidentemente, los datos raw. Pero no encontraba en documentación de los sensores ni en Internet el factor de conversión de esta unidad a grados. Mi única pista era la interfaz web del aparato, que establecía el rango de limitación como <emb>-100~100ºC</emb>.</p>
<p>Tengo entonces, por comprobación o por determinación (<emb>"By default, the High Alarm value is +32767 (0x7FFF) and the low alarm value is -32768 (0xFFFF)"</emb>) que el valor límite absoluto es <emb>32768</emb>; siendo entonces un rango de <emb>-32768~32767</emb>.</p>
-<pre><code>$ ./modpoll -r2 -1 -t3 172.16.20.13
+<pre><code>./modpoll -r2 -1 -t3 172.16.20.13
Protocol configuration: MODBUS/TCP, FC4
Slave configuration...: address = 1, start reference = 2, count = 1
@@ -37,7 +37,7 @@ Data type.............: 16-bit register, input register table
[2]: 6372
-$ ./modpoll -r3 -1 -t3 172.16.20.13
+./modpoll -r3 -1 -t3 172.16.20.13
Protocol configuration: MODBUS/TCP, FC4
Slave configuration...: address = 1, start reference = 3, count = 1
@@ -194,9 +194,9 @@ int main(int argc,char *argv[])
return(0);
}</code></pre>
<p>De tal forma que, pasando como parámetro el valor obtenido por modbus, y estando x1, x2, y1, e y2 calibrados en código, sólo cabría obtener la variable esperada y.</p>
-<pre><code>$ ./interpolacion-lineal 6372
+<pre><code>./interpolacion-lineal 6372
Interpolación lineal = 19.447624
-$ ./interpolacion-lineal 8388
+./interpolacion-lineal 8388
Interpolación lineal = 25.600060</code></pre>
<p>Es decir, obtendríamos 19,45ºC y 25,60ºC, respectivamente.</p>
</body>
diff --git a/kernel-compression/index.html b/kernel-compression/index.html
@@ -14,13 +14,11 @@
</header>
<p>Para la realización de una práctica de preparación de LPIC-1/2, debía averiguar el tipo de compresión del kernel de Linux empleado en mi sistema. En ese momento, usando la distribución <emb>archlinux</emb>.</p>
<p>Ejecutando file sobre el fichero de kernel obtengo:</p>
-
<pre><code>$ file /boot/vmlinuz-linux
/boot/vmlinuz-linux: Linux kernel x86 boot executable bzImage, version 5.14.16-arch1-1 (linux@archlinux) #1 \
SMP PREEMPT Tue, 02 Nov 2021 22:22:59 +0000, RO-rootFS, swap_dev 0X9, Normal VGA</code></pre>
<p>Y revisando la documentación teórica, observo que bzImage debería ir comprimido por <emb>gzip</emb> (<emb>z</emb>). Véase <a href="http://www.linfo.org/vmlinuz.html">vmlinuz.html</a>. De hecho, existe la idea errónea popular de que el prefijo <emb>bz</emb> significa que se utiliza la compresión <emb>bzip2</emb>, pero este no es el caso, por lo que el bz en bzImage no tiene relación con <emb>bzip2</emb>, y <emb>bzImage</emb> no tiene que ser comprimido con <emb>bzip2</emb>, como algunas veces se postula. De hecho, el modo de compresión predeterminado del kernel sigue siendo <emb>gzip</emb>, y hay pocas razones para usar bzip2 hoy en día: es más lento que <emb>LZMA</emb> y <emb>xz</emb>, pero no se comprime tan bien.</p>
-
- <h1>Pero, ¿cómo puedo probarlo empíricamente?</h1>
+<h2>Pero, ¿cómo puedo probarlo empíricamente?</h2>
<p>Para determinar de manera concluyente qué compresión se utilizó para una imagen dada del kernel, sin necesidad de ejecutarla o encontrar su configuración, podemos seguir el enfoque utilizado por el propio script <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/extract-vmlinux">extract-vmlinux</a> del kernel.</p>
<p>Buscando primero la firma del compresor en la imagen:</p>
<ul>
@@ -33,7 +31,6 @@ SMP PREEMPT Tue, 02 Nov 2021 22:22:59 +0000, RO-rootFS, swap_dev 0X9, Normal VGA
<li>zstd: (\265/\375</li>
</ul>
<p>Pretendiendo extraer los datos de la imagen, comenzando por el desplazamiento de cualquier firma que haya encontrado y comprobando que el resultado (si lo hubiera) sea una imagen de ELF. Con una breve adaptación del script -por <a href="https://gist.github.com/skitt/288c0c52b51b5863947a5d6c1180c9f3">Stephen Kitt</a>-. para sólo reportar el tipo de compresión, obtenemos sencillamente el tipo:</p>
-
<pre><code>4c4
< # extract-vmlinux - Extract uncompressed vmlinux from a kernel image
---
@@ -77,11 +74,11 @@ SMP PREEMPT Tue, 02 Nov 2021 22:22:59 +0000, RO-rootFS, swap_dev 0X9, Normal VGA
--------------------------------------------------------------------
-$ ./nuevo /boot/vmlinuz-linux
+./nuevo /boot/vmlinuz-linux
The image was compressed using zstd</code></pre>
<p>Otra forma de validarlo es comprobar qué métodos de compresión soporta el núcleo. Sólo puede haber uno seleccionado, el cual determinará el algoritmo empleado:</p>
-<pre><code>$ zgrep CONFIG_KERNEL_ /proc/config.gz
+<pre><code>zgrep CONFIG_KERNEL_ /proc/config.gz
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
diff --git a/machine-id-privacidad/index.html b/machine-id-privacidad/index.html
@@ -15,9 +15,9 @@
<p>Ya conocemos el <emb>machine-id</emb>, pero, ¿qué tiene que decir dicho identificador en cuanto a la privacidad? En un esfuerzo por asegurar la privacidad, tener un identificador único e inmutable vinculado directamente al dispositivo no parece un enfoque adecuado.</p>
<p>Recordamos además que el propio manual indica que el contenido es confidencial y no debe ser compartido. Sin embargo, no existe mecanismo ni inconveniente en que cualquier software tenga acceso a estos ficheros, permitiendo leer y almacenar el <emb>machine-id</emb> para el uso que fuera, sea accidental o malintencionado. Es cierto que también es accesible /sys, que contiene información sobre cada dispositivo conectado al sistema -inclusive las series de dispositivos USB únicas-. Por lo que si se requiere protección de confianza contra aplicaciones locales, se requerirá una solución de espacio aislado. Aún así, mantener o asegurar la no-integridad -de cara a terceros- del identificador parece algo deseable.</p>
<p>De nada sirve que nos indiquen que debe guardarse confidencialmente, cuando los permisos son de lectura para todos:</p>
-<pre><code>$ ls -hal /etc/machine-id
+<pre><code>ls -hal /etc/machine-id
-r--r--r-- 1 root root 33 jul 11 14:28 /etc/machine-id
-$ cat /etc/machine-id
+cat /etc/machine-id
9f00b9e6f49f45299a05a5ff8fd697df</code></pre>
<p>Su exclusión o eliminación en un sistema basado en <emb>systemd</emb> tampoco parece ser una acción conveniente, pues este identificador se utiliza para identificar máquinas en <emb>journalctl</emb>, así como para identificar máquinas en comunicaciones D-Bus. ¿Quizá podamos ponerlo a 0? Tampoco, espera una cadena de 32 caracteres.</p>
<p>Sabiendo entonces la facilidad que hay para cambiarlo, ¿por qué no automatizar un <emb>cronjob</emb> para que se cambie cada cierto tiempo? Por poner un modo paranoico, se podría hacer para que cambie cada minuto:</p>
diff --git a/machine-id/index.html b/machine-id/index.html
@@ -22,11 +22,11 @@
</ul>
<p>Aunque probablemente tenga más usos obtusos que no serán conocidos hasta estudiar profundamente el código.</p>
<p>El fichero que almacena dicho <emb>machine-id</emb> es <emb>/etc/machine-id</emb>. Observará que este valor también se almacena en <emb>/var/lib/dbus/machine-id</emb> y que existe un enlace simbólico entre los dos. Cualquier cambio en un archivo, se reflejará en el otro.</p>
-<pre><code>$ cat /etc/machine-id
+<pre><code>cat /etc/machine-id
35f7f8a5f915453782892638656ad9fd
-$ cat /var/lib/dbus/machine-id
+cat /var/lib/dbus/machine-id
35f7f8a5f915453782892638656ad9fd
-$ ls -l /var/lib/dbus/machine-id
+ls -l /var/lib/dbus/machine-id
lrwxrwxrwx 1 root root 15 nov 11 2021 /var/lib/dbus/machine-id -> /etc/machine-id</code></pre>
<p>Como decíamos, el <emb>machine-id</emb> se genera aleatoriamente en la instalación del sistema utilizando la utilidad <emb>systemd-machine-id-setup</emb>, que llama a su vez a <emb>dbus-uuidgen</emb>. Cambiarlo manualmente es muy sencillo y puede hacerse desde cualquiera de las utilidades citadas:</p>
<pre><code>sudo rm /etc/machine-id
diff --git a/passwd/index.html b/passwd/index.html
@@ -13,38 +13,29 @@
<p class="date">12 de febrero de 2016 • fjbalon</p>
</header>
<p>El contenido del fichero <emb>/etc/passwd</emb> determina el esqueleto de usuarios del sistema, constituyéndose como la primera linea de defensa del sistema contra accesos no deseados, por lo que debe mantenerse escrupulosamente y libre de errores y fallos de seguridad. En él mantenemos registrados las cuentas de usuarios, asi como las claves de accesos y privilegios. Separado por :, indica respectivamente el nombre del usuario, la clave cifrada, UID, GID, nombre completo del usuario, directorio de trabajo (<emb>/home</emb>) e intérprete usado. Si el campo de contraseña, en lugar de contener la clave cifrada contiene una x indica que la clave se encuentra cifrada en el archivo <emb>/etc/shadow</emb>, dando un mayor grado de seguridad. La sintaxis de passwd es:</p>
-
<pre><code>usuario1:FXWUuZ.vwXttg:500:501:usuario pepito:/home/usuario1:/bin/bash</code></pre>
<p>Los permisos predeterminados de passwd son 644 y los propietarios son root:root, evitando modificaciones erróneas, de modo que cualquier usuario sólo pueda leer el archivo.</p>
<p>Por otro lado, el archivo <emb>/etc/shadow</emb> almacena información sensible de los usuarios; que separados por :, indica respectivamente el nombre del usuario, la clave cifrada, el lastchanged o último cambio de contraseña en días transcurridos desde el 1 de enero de 1970, el mínimo número de días entre cambios de contraseña, el máximo número de días de validez de la cuenta, los días que avisa antes de caducar la cuenta, los días desde que caduca una contraseña para deshabilitar la cuenta y la fecha de caducidad de la cuenta en días transcurridos desde el 1 de enero de 1970. Su sintaxis es:</p>
-
<pre><code>test:$1$CQoPk7Zh$370xDLmeGD9m4aF/ciIlC.:14425:0:99999:7:::</code></pre>
<p>Los permisos predeterminados de passwd son 400 y los propietarios son root:root, sólo puede leer root. La contraseña se puede cifrar utilizando diferentes métodos, que son reconocidos por el identificador presente después del primer carácter $$. A continuación puedes tener el valor del id y la técnica de cifrado correspondiente que indica:</p>
-
-<pre><code>$1$: MD5: $1$5df9f63916ebf8528697b629022993e8/li>
+<pre><codeb>$1$: MD5: $1$5df9f63916ebf8528697b629022993e8/li>
$2a$: blowfish (pez globo): $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy</li>
$5$: SHA-256: $5$93fa3e4624676f2e9aa143911118b4547087e9b6e0b6076f2e1027d7a2da2b0a
-$6$: SHA-512: $6$6859f96680702a57a951eabe43fec49964ea51dde72df97e43a1fcf6f8b41b89a51cae8f3162c0cbb3e7fd0850577759aa653e25c4bdfd57264015fa6588360f</code></pre>
+$6$: SHA-512: $6$6859f96680702a57a951eabe43fec49964ea51dde72df97e43a1fcf6f8b41b89a51cae8f3162c0cbb3e7fd0850577759aa653e25c4bdfd57264015fa6588360f</codeb></pre>
<p>De la misma forma que se organiza y componen los ficheros anteriores sobre los usuarios, tenemos los ficheros <emb>/etc/group</emb> (similar a <emb>/etc/passwd</emb>) y <emb>/etc/gshadow</emb> (similar a <emb>/etc/shadow</emb>); ambos con la diferencia que no se centran en los usuarios, sino en los grupos, que separados por :, indica respectivamente el nombre de grupo, la clave cifrada, GID y la lista de usuarios que pertenecen al grupo separados por ,. La sintaxis es:</p>
-
<pre><code>root:x:0:root</code></pre>
-
- <h1>Verificación de integridad de passwd</h1>
+<h2>Verificación de integridad de passwd</h2>
<p><emb>pwck</emb> comprueba la integridad y la información de autenticación, comprobando que cada entrada de passwd y shadow tienen el formato adecuado y que los datos sean válidos:</p>
-
-<pre><code># pwck /etc/passwd
+<pre><code>pwck /etc/passwd
usuario malvado: el directorio /home/malvado no existe
pwck: sin cambios</code></pre>
-
- <h1>Descifrando claves con john</h1>
+<h2>Descifrando claves con john</h2>
<p>En caso de tener acceso a passwd y shadow, algo que por lo general ya supone un reto debido a la estructura de permisos, podemos unshadow y buscar descifrarla mediante fuerza bruta o diccionario, usaremos john the ripper para ello.</p>
-
-<pre><code># unshadow /etc/passwd /etc/shadow > unshadowed</code></pre>
+<pre><code>unshadow /etc/passwd /etc/shadow > unshadowed</code></pre>
<p>De tal forma que obtenemos las líneas passwd puras, en fusión con los datos necesarios secretos de shadow. De al forma que este nuevo fichero podemos pasarlo a john:</p>
-
-<pre><code># john unshadowed # Fuerza bruta
-# john --incremental unshadowed # Fuerza bruta
-# john --wordlist=diccionario.lst --rules unshadowed # Diccionario
+<pre><code>john unshadowed # Fuerza bruta
+john --incremental unshadowed # Fuerza bruta
+john --wordlist=diccionario.lst --rules unshadowed # Diccionario
Using default input encoding: UTF-8
Loaded 4 password hashes with 4 different salts (sha512crypt, crypt(3) $6$ [SHA512 128/128 AVX 2x])
@@ -54,15 +45,10 @@ Will run 2 OpenMP threads
Proceeding with single, rules:Single
...</code></pre>
<p>Una vez finalizado el proceso, si todo ha ido bien, podremos revisar las claves cracked desde:</p>
-
-
-<pre><code># john --show passwords
-
+<pre><code>john --show passwords
maria:Passw0rd2233:1006:1006::/home/maria:/bin/bash
-
1 password hashes cracked, 3 left</code></pre>
-
- <h1>Descifrando claves con hashcat</h1>
+<h2>Descifrando claves con hashcat</h2>
<p>Hashcat es otra herramienta archi-conocida de craking para una amplia variedad de tipos de hashes de passwords, soportando los algoritmos de hash comunes de GNU/Linux y sus códigos hashcat:</p>
<ul>
<li>DES (Unix) = 1500</li>
@@ -75,8 +61,6 @@ maria:Passw0rd2233:1006:1006::/home/maria:/bin/bash
<li>SHA-512 = 1700</li>
<li>SHA-512 (Unix $6$) = 1800</li>
</ul>
-
-<pre><code># hashcat -m 1800 -a 0 passwords diccionario.code -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule -o cracked.code --force</code></pre>
-
+<pre><code>hashcat -m 1800 -a 0 passwords diccionario.code -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule -o cracked.code --force</code></pre>
</body>
</html>
\ No newline at end of file
diff --git a/qemu/index.html b/qemu/index.html
@@ -5,7 +5,8 @@
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Virtualización y emulación con qemu</title>
<link rel="icon" type="image/png" href="/favicon.png" />
-<link rel="stylesheet" type="text/css" href="article.css" /></head>
+<link rel="stylesheet" type="text/css" href="../article.css" />
+</head>
<body>
<header>
<p class="title">Virtualización y emulación con qemu</p>
@@ -17,17 +18,12 @@
<p>A diferencia de otros programas de virtualización como VirtualBox y VMware, Qemu no proporciona una interfaz gráfica de usuario para administrar máquinas virtuales, tampoco proporciona una forma de crear una máquina virtual persistente con valores guardados, ya que todos los parámetros de ejecución se especifican en la línea de cada puesta en marcha.</p>
<h2>Gist</h2>
<p>Creación de disco virtual qcow2.</p>
-
<pre><code>qemu-img create -f qcow2 arch.cow 10G</code></pre>
<p>Iniciación de imagen ISO sobre disco creado (instalación de sistema operativo).</p>
-
<pre><code>qemu-system-x86_64 -cdrom Descargas/arch.iso -boot order=d -drive file=arch.cow,format=qcow2 -m 2G -enable-kvm</code></pre>
<p>Inicialización regular de sistema.</p>
-
<pre><code>qemu-system-x86_64 -boot order=d -drive file=arch.cow,format=qcow2 -m 2G -enable-kvm</code></pre>
<p>Acceso por SSH a través de host forwarding sin necesidad de cambiar la red.</p>
-
<pre><code>qemu-system-x86_64 -boot order=d -drive file=arch.cow,format=qcow2 -m 2G -enable-kvm -nic user,hostfwd=tcp::8888-:22</code></pre>
-
</body>
</html>
\ No newline at end of file
diff --git a/ssh-tunneling/index.html b/ssh-tunneling/index.html
@@ -15,18 +15,16 @@
<p>El tunneling es un proceso por el que se utiliza el protocolo SSH para fortificar la comunicación entre otros protocolos inseguros, por ejemplo para realizar peticiones HTTP, SMTP, etc.</p>
<p>Los túneles pueden ser locales o remotos. En los túneles locales, la máquina del administrador o cliente redirecciona un puerto local hacia un puerto de la máquina remota, a la que se disponga de acceso. En los túneles remotos se redirecciona un puerto remoto dela máquina remota, a la que se disponga de aacceso, a un puerto de la máquina local, donde se encuentra el administrador.</p>
<p>La sintaxis para la creación de un túnel local hacia el puerto remoto de la máquina remota es la siguiente:</p>
- <pre><code>$ ssh -L [direccion de escucha:]puerto escucha:maquina remota: puerto remoto usuario@server</code></pre>
+<pre><code>ssh -L [direccion de escucha:]puerto escucha:maquina remota: puerto remoto usuario@server</code></pre>
<img class="color-invertible" src="resources/ssh01.png"/>
-
- El escenario idóneo para la utilización de túneles SSH locales es el siguiente:
+<p>El escenario idóneo para la utilización de túneles SSH locales es el siguiente:</p>
<ul>
<li>Máquina A con conexión a Internet requiere conexión a máquina C, que se encuentra detrás de un servidor que impide el paso. En otras palabras, la máquina C no es accesible desde Internet.</li>
<li>El usuarioo de la máquina A dispone de cuenta en una máquina B. La máquina B es el servidor que proporciona la salida a Internet a la máquina C. La máquina A creará un túnel con la máquina B y a través del forwarding (véase sección \ref{sshforwarding} para más detalle) de la máquina B llegará a la máquina C.</li>
<li>Lo importante es proteger la comunicación en Internet entre la máquina A y B. La comunicación entre B y C puede ir sin cifrar, ya que se encentra en una Intranet. Aunque también puede ser altamente recomendable fortificar dicha comunicación.</li>
</ul>
<p>El túnel remoto, por su lado, generará un socket a la escucha en un servidor, el cual al recibir una petición reenviará el tráfico mediante SSH a la máquina local donde se encuentre el administrador. La sintaxis es:</p>
-
-<pre><code>$ ssh -R puerto local:maquina remota:puerto remoto</code></pre>
+<pre><code>ssh -R puerto local:maquina remota:puerto remoto</code></pre>
<img class="color-invertible" src="resources/ssh02.png"/>
<p>Un ejemplo sería querer que una máquina en Internet llegase al interior de la Intranet a través de una máquina puente de la propia red privada, manteniendo una interfaz hacia Internet. El escenario sería el siguiente:</p>
<ul>
@@ -37,19 +35,19 @@
<p>Estas técnicas cuentan con una serie de escenarios muy interesantes, siendo los más usuales:</p>
<ul>
<li>Usar un túnel externo para atravesar el firewall y acceder a un recurso que ofrece un equipo de la intranet:</li>
- <pre><code>$ ssh -L 7900:localhost:5900 usuario@internal
+<pre><code>ssh -L 7900:localhost:5900 usuario@internal
</code></pre>
<li>Usar un túnel externo para atravesar el firewall y acceder a un recurso de una intranet. Pero además cualquier equipo puede conectarse a dicho equipo de la intranet a través de una conexión con el equipo externo:</li>
- <pre><code>$ ssh -L 0.0.0.0:7900:localhost:5900 usuario@internal
+<pre><code>ssh -L 0.0.0.0:7900:localhost:5900 usuario@internal
</code></pre>
<li>Usar un túnel interno para que los equipos de fuera de la red se conecten al interior. Esta acción se realizará mediante túneles remotos:</li>
- <pre><code>$ ssh -R 7900:localhost:5900 usuario@internal
+<pre><code>ssh -R 7900:localhost:5900 usuario@internal
</code></pre>
<li>Túnel interno para que equipos de fuera de la red se conecten al interior, pero además que otros equipos del exterior puedan conectarse a través del externo remoto:</li>
- <pre><code>$ ssh -R 0.0.0.0:7900:localhost:5900 usuario@internal
+<pre><code>ssh -R 0.0.0.0:7900:localhost:5900 usuario@internal
</code></pre>
<li>Utilizar un túnel para que desde una máquina externa se pueda atravesar el firewall y realizar el forwarding en una máquina interna, y que esta reenvíe el tráfico a la segunda máquina interna:</li>
- <pre><code>$ ssh -L 7900:internal2:5900 usuario@internal
+<pre><code>ssh -L 7900:internal2:5900 usuario@internal
</code></pre>
</ul>
diff --git a/tanque-gasoil/index.html b/tanque-gasoil/index.html
@@ -89,7 +89,7 @@ distance = (TimeElapsed * 34320) / 2
print ("Distance = %.1f cm" % distance)</code></pre>
<p>Obteniendo unos resultados positivos como:</p>
-<pre><code>$ ./distance.py
+<pre><code>./distance.py
Distance = 85.8 cm</code></pre>
<h2>Cálculo de subcuboide</h2>
<p>Dado un cuboide de 112x100x71, que corresponde a las medidas aproximadas del tanque de gasoil:</p>
@@ -194,7 +194,7 @@ def subcuboide(x,y,z,d):
l = subcuboide(ancho,alto,profundidad,distance)/1000 # Divsion by 100 for cm^3 to liters
print ("%.1f" % l)</code></pre>
<p>Así:</p>
-<pre><code>$ ./gasoil40kHz.py
+<pre><code>./gasoil40kHz.py
119.4</code></pre>
<h2>Instalación en tanque</h2>
<p>Con todo ideado y probado, aquí os muestro unas fotografías reales de cómo conseguí dejarlo más o menos estable, de la forma más perpendicular posible al eje x del tanque.</p>
diff --git a/the-rider/index.html b/the-rider/index.html
@@ -1,23 +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>The Rider (2017) de Chloé Zhao</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">The Rider (2017) de Chloé Zhao, «Dios nos da a cada uno un propósito, el del caballo es correr por la pradera; el del vaquero es montar»</p>
-<p class="date">26 de enero de 2020 • fjbalon</p>
-</header>
-<p>Sacrificio proviene de sacrum facere; es decir, hacer lo sagrado, entregarse, honrarlo. Por el uso y la costumbre -en este caso no tan positiva-, la vinculamos hoy día con dolor y pérdida, sin ser éste su sentido real. Así, en las costumbres arcaicas, era común el sacrificio de animales como ofrenda a los dioses, sea en homenaje o en expiación. En la pérdida del bien que supone per se el animal, se ofrece por aquello que es superior y sagrado.</p>
-<p>«Dios nos da a cada uno un propósito, el del caballo es correr por la pradera; el del vaquero es montar». Pero, ¿qué ocurre cuando un caballo ya no puede correr la pradera? «tendrían que sacrificarlo», ya no puede responder a la vocación y al propósito de Dios. «No sería justo para el caballo».</p>
-<p>La cinta, que representa la vida real de sus protagonistas y se cocina con prudencia y templanza. Es una película escrita en el lenguaje del varón, no sólo porque verdaderamente hay poca presencia femenina en la obra, sino porque reflexiona e introspecciona en la psicología masculina. ¿Qué es un hombre sin su propósito? ¿qué es un hombre que no provee? ¿qué es un vaquero que no puede montar?. Admiro mucho el ¿papel? de Brady, y valoro enormemente las largas escenas en las que cumple con su trabajo, con su vocación con los caballos, en su doma, su monta, el respeto y dedicación que les tiene. El amor del hombre a su trabajo, porque el trabajo dignifica al hombre.</p>
-<p>Sin embargo, Brady también se ha hecho daño, como el caballo; pero es una persona, así que tiene que vivir. «Si cualquier animal de por aquí tuviese una herida como la mía, tendrían que sacrificarlo». Así, la película entra en una recta final, al más puro estilo del western, en el que todos sabemos y esperamos lo que ocurrirá: Brady montará una última vez, el último rodeo para el vaquero, que morirá sobre un portentoso bronco haciendo aquello para lo que ha nacido. O en el mejor de los casos, quedando como su mejor amigo: totalmente inválido. Es el momento del sacrificio, el sacrificio del vaquero por su oficio.</p>
-<p>Sin embargo, la cinta nos presenta un giro que para mí, ha sido tan inesperado como bello. Brady encuentra en su familia, especialmente en su hermana y en su amigo, una razón por la que luchar, descubre que tiene otro propósito, otra vocación a la que responder, una forma de sacrificarse -hacer lo sagrado- por ellos, y no sacrificarse en la arena de rodeos.</p>
-<p>Brady Jandreau, eres un hombre.</p>
-
-</body>
-</html>
-\ No newline at end of file
