PXE>_Downloads & network boot

Los contenidos de una ISO montada se mantienen en solo lectura. La versión 5.0.6 evita cambiar sus permisos y mantiene isolinux.bin, EFI y las ISOs internas en Browse contents, sin convertirlos en descargas independientes del catálogo.

Actualizar generate.sh y src/common.py juntos desde el ZIP, conservando fast-boot.json y las listas locales. Después repetir únicamente la generación:

sudo bash generate.sh --verbose

No es necesario volver a descargar ni desplegar las ISOs. Los permisos de archivos gestionados en sistemas escribibles siguen normalizándose.

light-url.txt reúne 29 recursos, incluidos Alpine Netboot y Standard; heavy-url.txt reúne 20, incluidos Extended, cloud, Ubuntu y Boot-Repair. Solo hay una ISO Arch. Los pequeños clientes iPXE de Arch quedan en RAM; sus ISOs quedan en disco para evitar dos copias grandes en memoria.

Las listas son editables. Ambos destinos publican en el mismo html; generate rastrea los enlaces RAM y las carpetas físicas juntos. Cada fase se ejecuta por separado:

# Light selection: cache, then RAM
sudo bash download.sh --list light --verbose
sudo bash deploy.sh ram --list light --verbose

# Heavy selection: same cache, then persistent disk
sudo bash download.sh --list heavy --verbose
sudo bash deploy.sh disk --list heavy --verbose

# One catalogue from both deployments
sudo bash generate.sh --verbose

También se puede seleccionar directamente un archivo. deploy solo usa las copias del cache; una descarga ausente aparece como fallo y nunca se descarga durante deploy:

sudo bash download.sh --url-file light-url.txt --verbose
sudo bash deploy.sh ram --url-file light-url.txt --verbose

# Inspect the selection before making changes
bash deploy.sh disk --list heavy --dry-run

Las ISOs locales de asistencia no tienen una URL remota inventada. Si ya están en el cache, desplegarlas también en RAM antes de generate, o añadir su URL real a light-url.txt cuando esté publicada:

sudo bash deploy.sh ram --only assist --verbose
sudo bash generate.sh --verbose

url.txt conserva la lista conjunta por compatibilidad. Sin selector, deploy continúa leyendo todo el cache. download conserva los registros de las dos listas entre ejecuciones. FTP replica el conjunto completo y no acepta filtros de lista.

Pasar una ISO gestionada de RAM a disk actualiza sus enlaces y desmonta su montaje anterior. La copia antigua permanece en tmpfs: apartarla después de verificar el despliegue en disco para recuperar memoria. No retirar todo /dev/shm ni archivos ajenos.

El nginx conjunto utiliza /etc/letsencrypt/live/ntp1.1-s.eu/fullchain.pem y privkey.pem para aux, pxe y tec. Verificar que subjectAltName incluye los seis dominios .es/.eu; el nombre de la carpeta no garantiza esa cobertura:

sudo openssl x509 \
  -in /etc/letsencrypt/live/ntp1.1-s.eu/fullchain.pem \
  -noout -ext subjectAltName

# Test the installed configuration before reloading
sudo nginx -t && sudo systemctl reload nginx

Configuración conjunta AUX / PXE / TEC

Comprobar free -h, df y findmnt. El objetivo es 22 GB para el catálogo RAM. No modificar un tmpfs que contenga montajes activos; preparar un destino vacío para una prueba aislada. Los archivos comprimidos requieren su copia y extracción. Ubuntu y Boot-Repair forman parte de heavy; las instrucciones antiguas para retirarlos han quedado reemplazadas.

Prueba Alpine desde cero

Primero preparar RAM o disco y ejecutar generate. FTP publica el contenido de html/ y los archivos del cache en la misma raíz remota: /assets/, /index.php y /imagen.iso. Los archivos internos de las ISOs se sirven desde Excalibur. Las fases se ejecutan por separado.

# Inspect the merge without connecting
sudo bash deploy.sh ftp \
  --output /var/www/aux.1-s.es/html \
  --cache /var/www/aux.1-s.es/isos \
  --ram-dir /dev/shm/aux-fast-boot \
  --ftp-root / --dry-run

# Replace host/user; password is requested privately
sudo bash deploy.sh ftp \
  --output /var/www/aux.1-s.es/html \
  --cache /var/www/aux.1-s.es/isos \
  --ram-dir /dev/shm/aux-fast-boot \
  --ftp-host HOST_FTP --ftp-user USUARIO_FTP \
  --ftp-root / --verbose

Usar el ram-dir real. Si la cuenta publica desde /www, sustituir ftp-root por /www. FTPS explícito es el valor predeterminado; --no-ftp-tls selecciona FTP sin cifrar. No poner la contraseña en el comando ni en fast-boot.json. Repetir el mismo deploy permite reanudar archivos parciales.

Detalles de FTP, verificación y réplica

Los archivos gestionados quedan con 0644; directorios y scripts ejecutables con 0755. Las fases reparan los archivos reutilizados. Con sudo en Fedora y grupo nginx disponible, el valor predeterminado es root:nginx: el servidor puede leer y el propietario administra. Sin ese grupo se conserva el grupo del proceso; sin sudo se utiliza el usuario y grupo del proceso.

# Explicit Fedora owner/group; each phase remains independent
sudo bash download.sh --list light --user root --group nginx --verbose
sudo bash deploy.sh ram --list light --user root --group nginx --verbose
sudo bash generate.sh --user root --group nginx --verbose

# Equivalent persistent deployment
sudo bash deploy.sh disk --list heavy --user root --group nginx --verbose

owner y group también se admiten en fast-boot.json. Solo se ajustan los archivos creados o gestionados por las fases; los enlaces no cambian propietarios de destinos externos. Las ISOs montadas en solo lectura conservan sus permisos de origen. Los JSON privados de TEC siguen fuera de la web.

FTP asigna el propietario de la cuenta del alojamiento. chown local no cambia ese propietario remoto. deploy ftp intenta SITE CHMOD 0755 en las carpetas publicadas y 0644 en los archivos; si el servidor no admite SITE CHMOD, se indica y los modos dependen del alojamiento.

# Inspect SELinux before applying a mount context
ls -lZ /var/www/aux.1-s.es/html
sudo restorecon -Rv /var/www/aux.1-s.es/html

# Read-only RAM ISO mounts can receive an HTTP-readable context
sudo bash deploy.sh ram --list light \
  --mount-context system_u:object_r:httpd_sys_content_t:s0 \
  --user root --group nginx --verbose

SELinux se comprueba aparte de chmod/chown. Un montaje ISO de solo lectura no se reetiqueta con restorecon; utilizar mount-context al desplegar y revisar los AVC del servidor.

Estos comandos preparan el Live de origen. El gestor de paquetes que se use dentro del chroot será el del sistema destino. Un Fedora Live puede rescatar un Debian instalado y viceversa si la arquitectura y el kernel son compatibles.

Desde Fedora

sudo dnf install util-linux coreutils cryptsetup lvm2 btrfs-progs
sudo -i

Desde Debian o Ubuntu

sudo apt update
sudo apt install util-linux coreutils cryptsetup lvm2 btrfs-progs
sudo -i

Para rescatar una raíz existente de Fedora, Debian, Ubuntu, Gentoo o Arch, continuar con los montajes comunes. Instalar paquetes en el Live no los instala en el destino. Si el rescate ya tiene estas utilidades, no hace falta reinstalarlas.

Crear una raíz nueva es otra operación: Fedora usa DNF; Debian/Ubuntu usa debootstrap; Gentoo usa stage3; Arch usa pacstrap. Para crear Fedora desde Debian, usar preferentemente una VM Fedora y la receta DNF documentada. Para crear Debian desde Fedora, preparar debootstrap y el keyring Debian antes; no omitir la verificación de firmas.

lsblk -f
findmnt
pth_raiz=/mnt/target
mkdir -p "$pth_raiz"

# Replace with the identified root partition or logical volume
dev_raiz=/dev/REEMPLAZAR_RAIZ
mount "$dev_raiz" "$pth_raiz"
cat "$pth_raiz/etc/os-release"
cat "$pth_raiz/etc/fstab"

Si la raíz ya está montada por el rescate, asignar pth_raiz a ese montaje sin repetir mount. Para Fedora Btrfs, identificar el subvolumen y usar mount -o subvol=root cuando root sea su nombre real. Montar también /usr, /var, /boot y /boot/efi separados según el fstab del destino antes de trabajar con paquetes o arranque.

# Optional encrypted/LVM root; replace both placeholders first
cryptsetup open /dev/REEMPLAZAR_LUKS cr_root
vgchange -ay REEMPLAZAR_VG
lsblk -f

Esas dos órdenes son alternativas para los equipos que las necesiten. No formatear ni crear particiones para entrar en chroot.

Usar una sola vez por sesión. Comprobar que pth_raiz apunta al destino, nunca a /. Los rslave impiden propagar desmontajes hacia el Live.

mkdir -p "$pth_raiz"/{dev,proc,sys,run}
mount --rbind /dev "$pth_raiz/dev"
mount --make-rslave "$pth_raiz/dev"
mount -t proc proc "$pth_raiz/proc"
mount --rbind /sys "$pth_raiz/sys"
mount --make-rslave "$pth_raiz/sys"
mount --bind /run "$pth_raiz/run"
mount --make-slave "$pth_raiz/run"
chroot "$pth_raiz" /bin/bash -l

# Inside the target
cat /etc/os-release
pwd

Comprobar DNS antes de descargar paquetes. /run permite usar el resolv.conf habitual que enlaza a systemd-resolved/NetworkManager. Si el destino requiere otro resolver, respaldar su /etc/resolv.conf antes de cualquier cambio y restaurarlo al salir. No iniciar servicios del sistema instalado desde este chroot de rescate.

Desde el Live, antes de entrar: guardar el resolver original si existe, sin sobrescribir un respaldo de otra sesión. La copia temporal sustituye el enlace del destino; no escribe a través de ese enlace hacia el Live.

# Only when the original target resolver exists; keep its file/link type
cp -a "$pth_raiz/etc/resolv.conf" "$pth_raiz/etc/resolv.conf.chroot-backup"

# Also usable when a new root has no resolver yet
cp -L --remove-destination /etc/resolv.conf "$pth_raiz/etc/resolv.conf"

Después de exit, restaurar únicamente el respaldo creado en esta sesión:

mv -- "$pth_raiz/etc/resolv.conf.chroot-backup" "$pth_raiz/etc/resolv.conf"

Si era una raíz nueva sin resolver original, conservar o configurar su resolver según la distribución. Los cambios en un sistema instalado persisten en disco.

En el rescate del instalador, comprobar el montaje anunciado (/mnt/sysroot o /mnt/sysimage según versión). En un Live, seguir los pasos comunes, incluido el subvolumen Btrfs real. Dentro del destino:

rpm -q fedora-release
dnf repolist

Para crear una raíz nueva y vacía en RAM desde Fedora con DNF5, usar repositorios y claves oficiales de la release elegida. Revisar espacio con free -h y df -h /work. Este paso instala paquetes en /work; no crea un sistema arrancable en disco.

pth_raiz=/work/fedora
mkdir -p "$pth_raiz"
dnf5 --use-host-config --installroot="$pth_raiz" --releasever=44 \
  --setopt=install_weak_deps=False install \
  bash coreutils filesystem fedora-release fedora-repos dnf5

Después usar la preparación común de montajes y chroot. use-host-config utiliza la configuración del Fedora Live para poblar la raíz vacía; comprobar sus repositorios antes. DNF5: installroot

El instalador en rescue puede abrir directamente una shell dentro del sistema elegido; si ofrece la shell del instalador, la raíz elegida suele estar en /target. Evitar montar de nuevo lo que ya esté preparado. Desde un Live, seguir los pasos comunes.

# Inside the installed Debian target
dpkg --audit
apt-cache policy

Raíz nueva en RAM: se necesita debootstrap y el keyring Debian en el Live. Ejemplo amd64 con trixie, en un directorio vacío y con firmas obligatorias:

pth_raiz=/work/debian
debootstrap --arch=amd64 --variant=minbase --force-check-sig \
  trixie "$pth_raiz" https://deb.debian.org/debian

Después preparar montajes y entrar. Rescate Debian · debootstrap

Desde un Live, montar la raíz y las particiones separadas del Ubuntu instalado, preparar los montajes comunes y entrar. Dentro del destino:

cat /etc/os-release
dpkg --audit
apt-cache policy

Raíz nueva amd64 en RAM: se necesita debootstrap compatible con noble y ubuntu-keyring en el Live. Comprobar la ruta del keyring, conservar la verificación y usar un directorio vacío:

pth_raiz=/work/ubuntu
debootstrap --arch=amd64 --variant=minbase --force-check-sig \
  --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg \
  noble "$pth_raiz" https://archive.ubuntu.com/ubuntu

Después preparar montajes y entrar. Manual Ubuntu de debootstrap

Para una instalación existente, usar los pasos comunes sin cambiar make.conf ni sus perfiles. Para un entorno nuevo, descargar un stage3 oficial compatible, comprobar su firma y digests antes de extraerlo como root a un directorio vacío.

pth_raiz=/work/gentoo
mkdir -p "$pth_raiz"
arc_stage=/ruta/REEMPLAZAR_STAGE3.tar.xz
tar xpf "$arc_stage" --xattrs-include='*.*' --numeric-owner -C "$pth_raiz"

Preparar los montajes comunes y entrar; dentro de Gentoo:

source /etc/profile
export PS1="(gentoo chroot) ${PS1}"
eselect profile show
emerge --info

Sin árbol Portage en un stage3 nuevo, emerge-webrsync prepara el snapshot; comprobar DNS antes. Guía Gentoo

En el medio oficial Arch, arch-chroot prepara los sistemas virtuales y DNS; no ejecutar además los montajes comunes sobre el mismo destino. La raíz debe estar montada.

# After mounting the installed Arch root and separate filesystems
arch-chroot "$pth_raiz" /bin/bash

Dentro del destino:

pacman -Q filesystem bash
pacman -Dk

Para crear una raíz nueva, usar pacstrap desde el Live oficial Arch con keyring/mirrorlist vigentes; una carpeta en /work puede hacerse mountpoint mediante bind. Luego arch-chroot administra sus montajes internos:

pth_raiz=/work/arch
mkdir -p "$pth_raiz"
mount --bind "$pth_raiz" "$pth_raiz"
pacstrap -K "$pth_raiz" base
arch-chroot "$pth_raiz" /bin/bash

El Live Fedora de asistencia no incluye pacstrap ni arch-chroot por defecto. Para rescatar Arch desde Fedora, utilizar el chroot común con la raíz Arch ya instalada; para bootstrap, arrancar el Live Arch o instalar previamente sus herramientas oficiales. arch-chroot · pacstrap

# Exit the target shell first
exit
cd /
findmnt -R "$pth_raiz"

# Only for the mounts created manually in this session
umount -R "$pth_raiz/run"
umount -R "$pth_raiz/sys"
umount "$pth_raiz/proc"
umount -R "$pth_raiz/dev"

Después desmontar las particiones separadas en orden inverso y finalmente la raíz en disco o el bind de /work/arch. arch-chroot suele retirar sus propios montajes al salir; comprobar findmnt y no repetir desmontajes inexistentes. Si un montaje está ocupado, cerrar shells/procesos que lo utilicen; no forzar desmontajes del Live.