MANUAL ABIERTO / FEDORA 44 / RESCATE Y ASISTENCIA
Cómo construir una ISO y manifiesto de aux-rescue.iso
Una ISO de rescate reúne un sistema operativo, su arranque y herramientas en un medio que puede iniciarse sin instalarlo en el disco del cliente. Este capítulo explica la receta editable del proyecto, cada fase de construcción, sus límites y las pruebas necesarias antes de ofrecer asistencia. Las instrucciones e inventarios pueden consultarse con Links, sin JavaScript.
Estado de esta publicación: la receta distribuida es Fedora 44 x86_64, versión 5.0.1-dev.5. Se distribuyen fuentes e instrucciones. Esta página no certifica una nueva ISO compilada ni un arranque físico. Las huellas, tamaños y resultados de una compilación concreta se publican después de medirlos.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
| Capa | Función | Comprobación |
|---|---|---|
| BIOS / UEFI | Cargadores y archivos EFI | Arranque separado; Secure Boot requiere validar toda la cadena |
| Kernel / initramfs | Dispositivos, red y carga del Live | Versiones coherentes, drivers y rutas reales |
| SquashFS / overlay | Base comprimida y cambios temporales | Memoria y comportamiento al reiniciar |
| /work | Descargas, scripts y chroot manual | tmpfs 0700 con límite según memoria |
| Asistencia | Control local, SSH y observadores | Consentimiento, clave, cierre y puerto 2222 |
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.
| Trabajo | Utilidades principales |
|---|---|
| Terminal | bash, tmux, nano, less, htop, file, strace, lsof |
| Consulta y transferencias | links, wget, curl, ftp, rsync, ssh, scp y sftp salientes |
| Fedora | rpm, dnf5/dnf, fedora-repos, claves GPG y certificados CA |
| Red y Wi-Fi | nmcli, nmtui, wpa_supplicant, firmware, ip, ss, ping, dig, ethtool, tcpdump |
| Discos y volúmenes | lsblk, blkid, parted, gdisk, cryptsetup, lvm2, mdadm |
| Diagnóstico y recuperación | smartctl, nvme, ddrescue, TestDisk, PhotoRec y reparación de sistemas de archivos |
| Arranque y entornos nuevos | efibootmgr, GRUB, tar, compresores, unzip, chroot |
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 @@ISO_PACKAGE_COUNT@@ 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.
Lista completa de paquetes solicitados
@@ISO_PACKAGES@@
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.