Cómo construir una ISO y manifiesto de aux-rescue.iso

0. Manifiesto de aux-rescue.iso

Una terminal de trabajo, un procedimiento visible y una autorización explícita. AUX Rescue facilita diagnóstico, recuperación de datos, mantenimiento y preparación de instalaciones desde un Live de terminal. Un técnico autorizado trabaja con herramientas conocidas y el cliente observa la sesión. La asistencia puede prestarla el técnico elegido; requiere una identidad y una clave verificadas, además de una ruta de red disponible.

El proyecto organiza tres funciones: aux./ presenta recursos y documentación; PXE_ permite navegar por terminal y arrancar medios inspeccionados; tec.* mantiene perfiles y solicitudes. Excalibur sirve PXE y los archivos internos de las imágenes. Bastion ofrece descargas completas. Cada fase del servidor se ejecuta por separado para leer, probar y rectificar su resultado.

1. Identidad antes del acceso. Confirmar técnico, contacto y huella de la clave mediante un canal reconocido por el cliente. Un nombre en un formulario o una clave descargada no sustituye esa comprobación.
2. Consentimiento comprensible. La consola local presenta técnico y huella; el listener SSH de la receta se inicia después de AUTORIZO. Explicar que root puede leer datos, modificar discos y reinstalar. Confirmar por separado cualquier operación destructiva.
3. Observación accesible. F6 conserva controles locales; F7 muestra tmux en solo lectura; F8 muestra estado y memoria. Root puede modificar el sistema: esos visores describen la interfaz prevista y no constituyen una barrera frente al técnico autorizado.
4. Sesiones delimitadas. Informar del inicio y cierre de la intervención. Cerrar desde los controles del Live, comprobar que el listener deja de escuchar y retirar la configuración privada utilizada. Las claves SSH efímeras y sesiones tmux se eliminan al cerrar; /work se conserva hasta reiniciar.
5. Datos bajo control del cliente. Acordar copias, destinos y conservación antes de transferir información. Separar registros técnicos de documentos personales. Redactar informes sin contraseñas, tokens, claves privadas ni información identificable innecesaria.
6. Fuentes y límites visibles. Publicar receta, paquetes solicitados, inventario RPM real, huella de la ISO y pruebas. Distinguir comprobación de archivos, arranque en VM y prueba física. Un menú generado no demuestra por sí mismo que un instalador funcione.
7. Crédito y reciprocidad. Mantener el crédito de Fedora, GNU/Linux, Lorax, dracut, las herramientas y el proyecto. Conservar las licencias de cada componente. El apoyo voluntario “Buy me a beer” puede acompañar la distribución; los términos de los componentes se documentan individualmente.

La netiquette también se aplica al soporte: describir cambios con claridad, pedir solo información necesaria, respetar tiempos de respuesta y aportar pruebas útiles. Los perfiles aprobados de TEC ayudan a elegir contacto; aceptar una solicitud web no abre automáticamente SSH ni VPN. La ISO pública contiene perfiles públicos y ninguna clave privada compartida.

1. Anatomía del Live

El arranque BIOS o UEFI carga kernel e initramfs. Dracut prepara la red y localiza el sistema Live comprimido. SquashFS conserva la base; overlayfs recoge cambios del sistema durante la sesión. /work proporciona espacio en tmpfs. El medio también incluye cargadores, configuración de arranque, metadatos y firmware.

El nombre de un archivo no establece su capacidad de arrancar por HTTP. El generador inspecciona los archivos y configuración originales, comprueba kernel, initrd y rootfs y crea una receta cuando reconoce un conjunto completo. Conservar rutas como LiveOS/squashfs.img mantiene el medio coherente. Un kernel de otra ISO puede ser incompatible.

Los cambios del Live se pierden al reiniciar. Las escrituras manuales en discos reales permanecen. /work, overlay y rootfs descargado por PXE comparten RAM física; sus límites no crean memoria adicional.

2. Alcance y selección de herramientas

La receta prioriza una base de terminal utilitaria: root con /bin/bash, gestor de paquetes Fedora, red, transferencias y rescate. No incorpora escritorio ni Anaconda precargado. Dnf permite añadir paquetes; consume memoria y requiere repositorios accesibles. El técnico puede preparar un chroot o instalación manual siguiendo la guía de Fedora, Debian, Ubuntu, Gentoo y Arch.

Ethernet, Wi-Fi y linux-firmware se solicitan por defecto. Esa cobertura aumenta el tamaño y permite probar portátiles sin una conexión Ethernet. Identificar adaptadores con lspci -nnk y lsusb y probar el hardware real. El tamaño final y RAM mínima del cliente deben medirse: los 4096 MiB del comando de compilación corresponden a la VM constructora.

3. Fuentes, procedencia e inventario

La unidad editable contiene prepare.py, assist.ks.in, dracut.conf, packages.txt y payload/. El payload implementa trabajo en RAM, consentimiento, observadores y preparación EFI. test_sources.py comprueba la receta sin montar discos del cliente. Revisar los archivos antes de construir como root.

Fuentes / ZIP · SHA256 del ZIP · Manifiesto de receta / JSON · Paquetes editables

El manifiesto describe fuentes y 94 paquetes solicitados. RPM añade dependencias. Tamaño, SHA-256 de la ISO e inventario instalado permanecen pendientes hasta compilar. prepare.py escribe source-manifest.json con las huellas de la receta concreta; el Live guarda packages-requested.txt y packages-rpm.txt para comparar intención y resultado.

fedora-release
fedora-repos
fedora-gpg-keys
glibc-langpack-en
glibc-langpack-es
systemd
systemd-udev
dbus-broker
bash
coreutils
grep
sed
gawk
findutils
diffutils
procps-ng
psmisc
util-linux
shadow-utils
rpm
dnf5
ca-certificates
openssl
python3
kbd
kernel-core
kernel-modules-core
kernel-modules
dracut
dracut-config-generic
dracut-live
dracut-network
grub2-efi-x64
grub2-efi-x64-cdboot
grub2-efi-x64-modules
grub2-pc
grub2-pc-modules
grub2-tools
shim-x64
syslinux
efibootmgr
selinux-policy-targeted
policycoreutils
policycoreutils-python-utils
links
tmux
nano
less
htop
file
strace
lsof
openssh-server
openssh-clients
curl
wget2-wget
ftp
rsync
tar
gzip
bzip2
xz
zstd
unzip
NetworkManager
NetworkManager-tui
NetworkManager-wifi
wpa_supplicant
linux-firmware
chrony
iproute
iputils
bind-utils
ethtool
traceroute
tcpdump
wireguard-tools
pciutils
usbutils
parted
gdisk
e2fsprogs
dosfstools
xfsprogs
btrfs-progs
ntfs-3g
ntfsprogs
lvm2
mdadm
cryptsetup
smartmontools
nvme-cli
ddrescue
testdisk

Conservar versión, fecha, arquitectura, mirrors, logs e inventarios. Las claves privadas, registros de clientes y configuraciones VPN privadas quedan fuera de Git y de ZIP públicos. Cada componente conserva su licencia. Una declaración global de licencia debe describir expresamente los archivos que cubre y respetar los componentes incluidos.

4. Preparar un constructor Fedora

Construir en Fedora 44 x86_64, preferiblemente en una máquina o VM dedicada a este trabajo. Utilizar livemedia-creator en modo virtual: su instalador actúa sobre un disco de construcción. La receta contiene clearpart y no debe aplicarse como instalación de un equipo real ni con --no-virt sobre un servidor de producción.

sudo dnf install lorax lorax-lmc-virt pykickstart openssl xorriso squashfs-tools

Obtener Fedora Server netinst 44 x86_64 desde Fedora y verificar su CHECKSUM firmado con las claves oficiales. La firma identifica la procedencia del archivo de comprobación; el hash comprueba la descarga. Consultar seguridad y claves de Fedora y conservar el resultado.

Prever espacio para la ISO instaladora, el disco virtual de unos 8 GiB más particiones de arranque, temporales y resultados. La receta recomienda al menos 20 GiB libres como punto de partida; revisar el uso real de Lorax. Usar carpetas nuevas por intento y conservar logs anteriores.

df -h . /var/tmp
free -h
rpm -q lorax lorax-lmc-virt pykickstart xorriso squashfs-tools
livemedia-creator --help
test -c /dev/kvm

Si no hay aceleración KVM, revisar --no-kvm en el constructor; la emulación será más lenta. Registrar el entorno utilizado. Los comandos del capítulo son fases manuales que pueden ejecutarse y revisarse individualmente.

5. Preparar y revisar Kickstart

Desde las fuentes descomprimidas, comprobarlas y crear una salida nueva:

python3 test_sources.py
python3 prepare.py --output work-5.0.1-dev.5
ksvalidator -v F44 work-5.0.1-dev.5/assist.ks

prepare.py incluye Wi-Fi, resuelve el payload y calcula huellas. Prepara el hash de una contraseña aleatoria no divulgada para conservar el estado de root; la autenticación SSH por contraseña permanece deshabilitada. Esa aleatoriedad y los repositorios de actualizaciones impiden prometer reproducibilidad bit a bit.

Leer assist.ks antes de compilar. El esquema usa reqpart y una raíz ext4 de 8 GiB en la VM. Lorax controla la pantalla de Anaconda: no añadir text, cmdline ni graphical. ksvalidator comprueba sintaxis; no valida toda la semántica específica del constructor.

%packages contiene solicitudes explícitas y excluye dependencias débiles y documentación del medio. %post instala el payload, prepara /work y root, habilita controles y observadores y mantiene SSH estándar enmascarado. La receta conserva SELinux enforcing, registra el puerto 2222 y no configura montajes de discos del cliente.

Para perfiles públicos fijos, prepare.py admite --profiles perfiles-publicos.json. Incluir únicamente información pública y claves públicas válidas. Las claves privadas de WireGuard, secretos de correo y claves privadas de técnicos quedan fuera de una ISO pública.

6. Compilar AUX Rescue

Definir la ruta del netinst oficial verificado. El comando produce una ISO versionada; aux-rescue.iso es el nombre público propuesto para una versión aceptada. Conservar el archivo versionado permite identificar el medio usado en cada intervención.

pth_netinst="/ruta/Fedora-Server-netinst-x86_64-44-1.7.iso"

sudo livemedia-creator \
  --make-iso \
  --iso="$pth_netinst" \
  --ks="$PWD/work-5.0.1-dev.5/assist.ks" \
  --releasever=44 \
  --project="1-s AUX Rescue" \
  --volid=AUX_RESCUE_501 \
  --rootfs-type=squashfs \
  --dracut-conf="$PWD/dracut.conf" \
  --extra-boot-args="aux.assist rd.live.overlay.overlayfs=1 rd.luks=0 rd.lvm=0 rd.md=0" \
  --ram=4096 --vcpus=2 \
  --iso-only \
  --iso-name=aux-rescue-5.0.1-dev.5-x86_64.iso \
  --resultdir="$PWD/results-5.0.1-dev.5" \
  --logfile="$PWD/compile-5.0.1-dev.5.log"

El constructor instala en la VM y empaqueta el Live. Seguir el log: una instalación terminada no implica que xorriso haya terminado. Conservar últimas líneas y logs de Anaconda si falla. La documentación de Lorax explica las fases; contrastar con --help de la versión instalada.

El fallo EFI/BOOT observado

Si xorriso encuentra EFI/BOOT ausente, revisar los cargadores. La receta solicita grub2-efi-x64-cdboot, shim-x64 y módulos y herramientas GRUB. boot_check.py prepara y comprueba gcdx64.efi, shimx64.efi, mmx64.efi y unicode.pf2 desde los RPM antes del empaquetado. Un directorio vacío no aporta los binarios de arranque.

rd.luks=0, rd.lvm=0 y rd.md=0 limitan descubrimiento temprano; las herramientas siguen disponibles para intervención manual. Mantener aux.assist en la configuración real permite reconocer asistencia. Kernel, initrd y SquashFS deben pertenecer a la misma compilación.

7. Verificar y aceptar una compilación

Calcular tamaño y SHA-256 sobre el archivo final. Conservar log y manifiesto de fuentes junto a la versión. Publicar nombre versionado y huella; un alias estable debe actualizarse con los mismos bytes y una huella coherente.

sha256sum results-5.0.1-dev.5/aux-rescue-5.0.1-dev.5-x86_64.iso
du -h results-5.0.1-dev.5/aux-rescue-5.0.1-dev.5-x86_64.iso
cat work-5.0.1-dev.5/source-manifest.json

Arrancar primero una VM sin discos de cliente. Probar BIOS y UEFI por separado, después hardware de pruebas y HTTP/iPXE sin ISO local. La presencia de shim no certifica Secure Boot: validar toda la cadena del medio, firmware y configuración.

# Run from the authorized Live shell
cat /usr/share/aux-assist/packages-requested.txt
sort /usr/share/aux-assist/packages-rpm.txt
getent passwd root
free -h
df -h / /work
findmnt -t tmpfs,overlay,squashfs
dnf repolist
ss -ltn

Probar una instalación pequeña con dnf, Wi-Fi, Ethernet, DNS y TLS. Medir RAM inicial, tamaño y tiempo PXE. Verificar ausencia de listener antes de AUTORIZO, rechazo de otra clave y cierre del puerto al terminar. Comprobar huellas, observadores y SELinux enforcing. Guardar resultados por hardware y versión.

/work limita su uso al mínimo entre un cuarto de RAM total, un tercio de RAM disponible al iniciar y 2 GiB. Antes de un stage3 o recuperación grande, revisar memoria y acordar un destino persistente suficiente. Reiniciar elimina trabajo temporal; las escrituras en discos reales permanecen.

8. Publicar en Excalibur e iPXE

Tras aceptar la compilación, copiar ISO versionada y SHA-256 a /var/www/aux.1-s.es/isos. Conservar la versión anterior durante las pruebas. El generador reconoce aux-rescue.iso y aux-rescue-version-arquitectura.iso como asistencia; exige los archivos y marcadores reales para habilitar arranque automático.

# From the AUX/PXE command directory, after copying the accepted ISO to cache
sudo bash deploy.sh ram --only aux-rescue --verbose
sudo bash generate.sh --verbose

La asistencia aparece en capítulo 0. El menú puede arrancar la versión más reciente compatible tras 60 segundos; cualquier tecla detiene la cuenta. Ese arranque lleva al control local del Live: autorizar técnico es un paso posterior. La llave USB del proyecto utiliza GRUB visible durante 5 segundos antes de iPXE.

Si se mantiene aux-rescue.iso como alias, comprobar que sean los mismos bytes que la versión aceptada. Evitar cargar alias y versión simultáneamente en RAM sin necesidad: son dos nombres y pueden consumir dos copias. Preparar réplica FTP después de generar; contenidos navegables y PXE permanecen en Excalibur.

Utilizar las listas ligera y pesada para el resto. Añadir la URL real de la ISO propia a la ligera cuando exista una publicación comprobada. El generador rastrea RAM y disco y reúne contenidos, catálogo, menú y sitemaps.

9. Mantenimiento e informes

Una versión útil incluye fuentes, inventario e instrucciones revisables. Conservar número de receta, cambios y pruebas de cada función prometida. Si cambia un repositorio o paquete, recompilar y medir. Una actualización de web no constituye una ISO nueva probada.

Informar de fallos con versión y hash, arquitectura, BIOS/UEFI, Secure Boot, RAM, adaptador, USB/iPXE, comando y últimas líneas del log. Redactar datos personales y secretos. Explicar qué ocurrió, qué se esperaba y qué fase terminó; una descarga correcta no valida el arranque.

Para un fork, definir objetivo: base mínima, diagnóstico, recuperación o instalación. Mantener créditos y licencias, publicar diferencias y actualizar manifiesto. Cambiar servicios o automatismos exige revisar consentimiento, cierre y acceso. Una recuperación empieza con un plan de datos y termina con un informe verificable.

Author & Credits: https://www.alawise.es/1-s. Componentes principales: Fedora Project, Lorax, dracut y autores de los paquetes enumerados. Volver al inicio.