Instalación de openSUSE Leap 15.6: la configuración ‘Linux estable’ que conservarás durante años

Por qué Leap 15.6 es la distribución para «conservarla durante años»

Leap es la versión que eliges cuando valoras tus fines de semana. No intenta ser lo más nuevo. Busca ser correcto, consistente y soportable. La idea clave: obtienes una distribución que sigue una base estable de SUSE Linux Enterprise, con una envoltura comunitaria que la mantiene accesible.

Para cargas de trabajo de tipo producción—servicios de laboratorio doméstico, servidores de pequeñas empresas, estaciones de trabajo de desarrollador que también deben ejecutar Zoom sin descontrolarse—Leap se comporta como un inquilino a largo plazo. Paga la renta a tiempo. No organiza fiestas.

Lo que hace que Leap sea especialmente instalable y olvidable es la combinación de:

• YaST para la configuración del sistema que sigue siendo legible años después, incluyendo almacenamiento y red.
• Btrfs + Snapper integrados que convierten muchos incidentes de “creo que reinstalamos” en “revertir y seguir adelante”.
• zypper y sus flujos de trabajo de parches que encajan bien con la gestión de cambios controlada.
• AppArmor como una capa pragmática de endurecimiento que realmente se usa y mantiene.

Una opinión desde el inicio: si quieres “todo lo más reciente”, esta no es tu distribución. Si quieres “puedo explicar cada cambio a un auditor”, estás en casa.

Datos y contexto interesantes (lo que explica la cultura)

1. openSUSE tiene dos personalidades por diseño: Tumbleweed (rolling) y Leap (estable). Esa división es intencional, no un compromiso.
2. YaST existe desde antes que la mayoría de los instaladores modernos: ha sido un rasgo definitorio de SUSE durante décadas, y el módulo de almacenamiento sigue siendo una de las mejores herramientas para “verlo todo en un solo lugar”.
3. La base de Leap está ligada al trabajo empresarial de SUSE: la conservadurismo es heredado. Por eso se siente más lento—y por eso se rompe menos.
4. Btrfs se volvió por defecto en openSUSE antes que en la mayoría de las distros: no por moda, sino porque los snapshots y las reversiónes reducen la carga de soporte.
5. El modelo «pre/post» de Snapper es gestión de cambios codificada en herramientas: convierte las operaciones de paquetes en estados del sistema auditables.
6. El concepto de parche en zypper es un flujo de trabajo de primera clase: no es solo “actualiza todo”; es “aplica un conjunto de correcciones revisadas”.
7. AppArmor es históricamente una fortaleza de SUSE: filosofía distinta a SELinux, más centrado en perfiles, generalmente más fácil de operacionalizar en equipos mixtos.
8. Wicked existe porque la red empresarial es compleja: NetworkManager es excelente para portátiles; los servidores a menudo quieren comportamiento declarativo y aburrido.
9. openSUSE ha tratado durante mucho tiempo el empaquetado y los pipelines de compilación como competencia central: la cultura espera reproducibilidad, no improvisación.

Decisiones que importan antes de arrancar el instalador

Elige el objetivo correcto: workstation, server, o “una caja que lo haga todo”

Sé honesto. Si esta máquina es un servidor, no instales un escritorio “por si acaso”. Las interfaces gráficas están bien, pero las pilas GUI aumentan la rotación: más paquetes, más actualizaciones, más piezas móviles.

• Server: sistema mínimo, SSH, firewalld, NTP, tus servicios.
• Workstation: KDE Plasma es una opción sólida por defecto en Leap. GNOME también está bien. Elige uno.
• Single box lab: aun así instala lo mínimo + una UI ligera si es necesario. Evita instalar “todos los escritorios”. Así terminas depurando dos pilas de audio en un servidor.

Elección de sistema de archivos: Btrfs donde ayuda, XFS donde es aburrido

El root por defecto en Btrfs de Leap es una característica, no un truco. Snapshots y reversiónes te salvan cuando las actualizaciones van mal. Pero no pongas todo en Btrfs solo porque está ahí.

Mi predeterminado:

• / en Btrfs con Snapper habilitado.
• /home en XFS para una estación de trabajo (simple, rápido, poca complicación) o en Btrfs si valoras snapshotear datos de usuario y aceptas la sobrecarga operativa.
• /var/lib para bases de datos en XFS (o ext4) a menos que tengas una razón clara para usar Btrfs y comprendas comportamiento copy-on-write y ajuste.

Broma #1: los snapshots de Btrfs son como cinturones de seguridad: solo los notas cuando algo intenta arruinarte el día.

Particionado y arranque: UEFI, GPT y “no te pongas creativo”

Usa UEFI si tu hardware lo soporta. Usa GPT. Crea una partición EFI System Partition (ESP) de al menos 512 MiB. No compartas ESPs entre demasiados sistemas operativos a menos que disfrutes la arqueología.

Si planeas cifrado de disco, decide ahora: cifrado total para portátiles, cifrado selectivo para servidores (a menudo solo volúmenes de datos). Si necesitas reinicios desatendidos después de pérdida de energía, mantén / sin cifrar o usa desbloqueo basado en TPM con un plan que hayas probado.

Pila de red: Wicked para servidores, NetworkManager para portátiles

Wicked es excelente cuando quieres “la interfaz se levanta igual cada vez”. NetworkManager es ideal cuando te desplazas entre redes Wi‑Fi. No los mezcles sin motivo.

Disciplina de repositorios: menos repos, menos misterios

La forma más rápida de convertir una distro estable en una frágil es añadir repositorios al azar porque un blog lo dijo. Empieza con repos oficiales. Añade uno extra solo cuando puedas explicar por qué existe y cómo lo eliminarás luego.

Guía de instalación con valores predeterminados opinados

1) Medios de arranque y ajustes de firmware

Usa el ISO oficial del instalador (el instalador offline está bien para servidores; el instalador por red está bien si tu red es fiable). En la configuración del firmware:

• Habilita el modo UEFI.
• Desactiva el modo “RAID” si en realidad es fake RAID y prefieres mdadm en Linux.
• Deja Secure Boot activado a menos que tengas una razón concreta para desactivarlo (módulos de kernel personalizados, controladores raros).

2) Selección de patrones de instalación: mantenlo mínimo

En servidores: comienza con una instalación mínima y añade paquetes intencionalmente. En estaciones de trabajo: KDE Plasma es un predeterminado práctico en Leap. Tiende a comportarse y está bien integrado.

3) Propuesta de almacenamiento: acepta el espíritu, edita los detalles

YaST propondrá un diseño. A menudo es decente, pero no lo aceptes sin mirar. Tu trabajo es facilitar operaciones futuras:

• ESP: 512 MiB–1 GiB (FAT32, montada en /boot/efi).
• Root: Btrfs, con snapshots habilitados.
• Swap: el tamaño depende de las necesidades de hibernación y la RAM. Para servidores, swap pequeño está bien; para portátiles con hibernación, hazlo coincidir con la RAM.
• Datos: partición/LV separada para /var/lib (contenedores, bases de datos) si vas a ejecutarlos.

4) Usuarios y SSH: establece la política ahora

Crea un usuario normal. Si esto es un servidor, evita habilitar inicios de sesión SSH con contraseña. Planea autenticación por claves. Si debes usar contraseñas temporalmente, pon una fecha para eliminarlas.

5) Sincronización horaria y nombre de host: detalles aburridos que muerden después

Configura la zona horaria correcta. Habilita NTP. Elige un hostname que no te avergüence en los logs. “server2-final” no es un plan.

6) Primer reinicio: verifica arranque y herramientas de snapshot

Después de que la instalación termine, no te apresures a personalizar. Primero confirma que el arranque es limpio, la red es estable y los snapshots funcionan. Luego continúa.

Plan de almacenamiento: Btrfs, XFS, LVM, RAID y lo que yo desplegaría

Btrfs en /: trátalo como un sistema de seguridad para el SO

El root Btrfs de Leap con Snapper está diseñado alrededor de una idea: la mayoría de las fallas ocurren durante cambios. Si puedes revertir rápidamente el estado del SO, reduces el tiempo de inactividad y el pánico.

Para qué es bueno el root Btrfs:

• Snapshots antes/después de operaciones de paquetes.
• Reversión rápida tras una mala actualización o mala configuración.
• Rendimiento razonable para archivos del sistema.

Para qué no es automáticamente bueno el root Btrfs:

• Bases de datos con muchas escrituras sin ajuste y comprensión del copy-on-write.
• “Instalar y olvidar” cuando nunca revisas la retención de snapshots y el espacio libre.

XFS para datos con muchas escrituras

XFS es el sistema de archivos maduro y aburrido: escalable, probado y predecible bajo carga de escritura intensa. Si alojas bases de datos, imágenes de VM o capas de contenedor con gran churn, XFS suele ser la predeterminada más segura.

LVM: opcional, pero útil para humanos

LVM no es obligatorio, pero a menudo vale la pena en servidores porque te da crecimiento flexible y separación clara entre SO y datos. YaST lo hace manejable y es una herramienta que tu yo futuro reconocerá.

RAID por software: mdadm para RAID nativo en Linux

Si necesitas RAID1/10 para disponibilidad, mdadm es sólido y transparente. Evita el “fake RAID” salvo que tengas una razón fuerte, porque complica la recuperación.

Si consideras ZFS: es un gran sistema de archivos, pero no está integrado en la ruta de instalador por defecto de Leap como Btrfs. Si quieres “conservarlo años” y mínimo extrañeza, quédate con los valores nativos a menos que estés dispuesto a asumir la integración.

Retención de snapshots: no permitas que las copias se conviertan en un evento de disco lleno

Los snapshots no son backups. Viven en el mismo disco. Te protegen contra cambios malos, no contra hardware muerto. Aun así, pueden salvarte de ti mismo—siempre que gestiones la retención y monitorices el espacio libre.

Tareas al primer arranque que evitan futuros arrepentimientos (comandos incluidos)

A continuación hay tareas prácticas que puedes ejecutar justo después de la instalación. Cada una incluye: un comando, qué significa su salida y la decisión que tomas a partir de ello.

Tarea 1: Confirma la versión del SO y del kernel

cr0x@server:~$ cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.6"
ID="opensuse-leap"
PRETTY_NAME="openSUSE Leap 15.6"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.6"

Qué significa: Estás realmente en Leap 15.6, no en el ISO equivocado ni en un sistema parcialmente actualizado.

Decisión: Si no es 15.6, detente y corrige la base antes de hacer cualquier otra cosa. “Lo actualizaré después” es como heredar caos.

Tarea 2: Comprueba el modo de arranque (UEFI vs legacy)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo BIOS
UEFI

Qué significa: UEFI está en uso. Bueno para sistemas modernos y gestión de arranque predecible.

Decisión: Si esperabas UEFI y ves BIOS, revisa la configuración del firmware antes de continuar sobre la instalación.

Tarea 3: Verifica sistemas de archivos y opciones de montaje

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /
/dev/nvme0n1p3 btrfs rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@/.snapshots/1/snapshot

Qué significa: Root es Btrfs y estás en un subvolumen snapshot (común con la integración de Snapper).

Decisión: Si root no es Btrfs y querías reversión con Snapper, arréglalo ahora en lugar de hacerlo después de instalar medio mundo de paquetes.

Tarea 4: Confirma que Snapper funciona y tiene un snapshot base

cr0x@server:~$ sudo snapper list
 # | Type   | Pre # | Date                     | User | Cleanup | Description | Userdata
---+--------+-------+--------------------------+------+---------+-------------+---------
0  | single |       |                          | root |         | current     | 
1  | single |       | 2026-02-05 09:18:24      | root |         | first root filesystem | 

Qué significa: Snapper ve al menos un snapshot. El sistema puede revertir el estado del SO cuando sea necesario.

Decisión: Si Snapper no está configurado, decide si lo quieres. En Leap, yo normalmente sí para /.

Tarea 5: Inspecciona dispositivos de bloques y confirma que estás en el disco que crees

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME        SIZE TYPE FSTYPE MOUNTPOINTS
nvme0n1   953.9G disk        
├─nvme0n1p1   1G part vfat   /boot/efi
├─nvme0n1p2  32G part swap   [SWAP]
└─nvme0n1p3 920G part btrfs  / /.snapshots

Qué significa: El particionado coincide con lo esperado: ESP, swap y root Btrfs.

Decisión: Si ves tu disco de datos usado accidentalmente para root, detente y corrígelo antes de almacenar algo valioso.

Tarea 6: Comprueba el espacio libre como lo ve Btrfs

cr0x@server:~$ sudo btrfs filesystem usage /
Overall:
    Device size:                 920.00GiB
    Device allocated:             60.00GiB
    Device unallocated:          860.00GiB
    Used:                         18.50GiB
    Free (estimated):            900.00GiB      (min: 900.00GiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00

Qué significa: Mucho margen; las asignaciones son sensatas.

Decisión: Si el metadata está casi lleno mientras el “espacio libre” parece bien, necesitas reequilibrar o ajustar la retención de snapshots. Btrfs puede fallar de formas sorprendentes cuando el metadata se llena.

Tarea 7: Valida repositorios (y detecta la deriva de «repos aleatorios» temprano)

cr0x@server:~$ sudo zypper lr -u
#  | Alias                       | Name                        | Enabled | GPG Check | Refresh | URI
---+-----------------------------+-----------------------------+---------+-----------+---------+---------------------------
1  | repo-oss                    | Main Repository (OSS)       | Yes     | (r ) Yes  | Yes     | https://download...
2  | repo-non-oss                | Main Repository (NON-OSS)   | Yes     | (r ) Yes  | Yes     | https://download...
3  | repo-update                 | Update Repository (OSS)     | Yes     | (r ) Yes  | Yes     | https://download...

Qué significa: Tienes una línea base limpia: repos principales más actualizaciones.

Decisión: Si ves un montón de repos de terceros el primer día, pregunta quién los añadió y por qué. Reduce ahora. La estabilidad es una dieta, no una vitamina.

Tarea 8: Aplica parches de seguridad (enfocado en parches, no en «actualizar todo sin mirar»)

cr0x@server:~$ sudo zypper patch
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 3 patches are going to be installed:
  openSUSE-SLE-15.6-2026-1234 security  openssl security update
  openSUSE-SLE-15.6-2026-2345 security  openssh security update
  openSUSE-SLE-15.6-2026-3456 recommended  systemd bugfix update

3 patches to install.
Overall download size: 4.2 MiB. Already cached: 0 B. After the operation, additional 12.0 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y

Qué significa: Estás aplicando parches seleccionados. Esto tiende a ser más seguro que actualizaciones completas cuando quieres cambio controlado.

Decisión: En servidores, prefiere zypper patch rutinariamente; programa actualizaciones completas cuando puedas probar y reiniciar.

Tarea 9: Confirma servicios y salud de arranque

cr0x@server:~$ systemctl --failed
0 loaded units listed.

Qué significa: No hay unidades systemd fallidas actualmente.

Decisión: Si tienes unidades fallidas, arréglalas ahora mientras el sistema está fresco y la diferencia con “funcionando” es pequeña.

Tarea 10: Revisa los últimos logs de arranque en busca de advertencias importantes

cr0x@server:~$ sudo journalctl -b -p warning --no-pager | tail -n 8
Feb 05 09:22:11 server kernel: ACPI: \_SB.PCI0... AE_NOT_FOUND
Feb 05 09:22:12 server systemd[1]: Found device /dev/disk/by-uuid/...
Feb 05 09:22:14 server wicked[915]: eth0: link detected
Feb 05 09:22:15 server chronyd[1022]: System clock was stepped by 0.423 seconds

Qué significa: Las advertencias pueden ser ruido de firmware o problemas reales. El ajuste de tiempo de chrony en el primer arranque es normal.

Decisión: Si ves errores repetidos de I/O de disco, fluctuaciones de red o advertencias de sistema de archivos, investiga antes de desplegar servicios.

Tarea 11: Confirma sincronización horaria (porque certificados y clústeres odian viajar en el tiempo)

cr0x@server:~$ timedatectl status
               Local time: Thu 2026-02-05 09:25:21 UTC
           Universal time: Thu 2026-02-05 09:25:21 UTC
                 RTC time: Thu 2026-02-05 09:25:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El reloj está sincronizado y NTP está activo.

Decisión: Si no está sincronizado, arregla la hora antes de depurar TLS, Kerberos o fallos de autenticación “aleatorios”.

Tarea 12: Confirma la pila de gestión de red (Wicked vs NetworkManager)

cr0x@server:~$ systemctl is-active wicked NetworkManager
active
inactive

Qué significa: Wicked está gestionando la red, NetworkManager no. Esa es una postura sensata para servidores.

Decisión: Si ambos están activos, elige uno. El control dual es como obtienes “funciona hasta que reinicias”.

Tarea 13: Confirma estado del firewall y zona por defecto

cr0x@server:~$ sudo firewall-cmd --state
running

cr0x@server:~$ sudo firewall-cmd --get-default-zone
public

Qué significa: firewalld está activo; la zona por defecto es public (típicamente restrictiva).

Decisión: Mantenlo en ejecución. Abre solo lo que necesites. “Desactivar el firewall mientras pruebo” tiene un largo currículum de arrepentimiento.

Tarea 14: Comprueba CPU, presión de memoria y postura de swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi       1.2Gi        27Gi       120Mi       2.8Gi        29Gi
Swap:           32Gi          0B        32Gi

Qué significa: Mucha RAM libre; swap sin usar (normal en un sistema inactivo).

Decisión: Si el swap se usa mucho con carga normal, probablemente tienes presión de memoria o una carga mal dimensionada.

Tarea 15: Revisa salud del disco rápidamente (ejemplo NVMe)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | sed -n '1,18p'
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.14.21-lp156.12-default] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       ACME NVMe 1TB
Serial Number:                      ABCD123456
Firmware Version:                   1.0.3
PCI Vendor/Subsystem ID:            0x1234
IEEE OUI Identifier:                0xdeadbe
Total NVM Capacity:                 1,000,204,886,016 [1.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          1,000,204,886,016 [1.00 TB]
Namespace 1 Utilization:            54,321,098,752 [54.3 GB]

Qué significa: Los datos SMART son legibles; modelo y firmware identificados.

Decisión: Si SMART no puede leer o muestra advertencias críticas, no confíes el disco con nada importante.

Tarea 16: Confirma que AppArmor está habilitado

cr0x@server:~$ sudo aa-status | sed -n '1,10p'
apparmor module is loaded.
30 profiles are loaded.
28 profiles are in enforce mode.
2 profiles are in complain mode.
0 profiles are in kill mode.

Qué significa: AppArmor está activo, la mayoría de los perfiles en modo enforce.

Decisión: Manténlo en enforce a menos que tengas un problema de compatibilidad específico. Si debes aflojarlo, hazlo por servicio, no globalmente.

Tarea 17: Verifica lo básico de la política SSH

cr0x@server:~$ sudo sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication)'
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes

Qué significa: El acceso root está bloqueado; SSH por contraseña está deshabilitado; las claves están habilitadas.

Decisión: Esta es la línea base que deseas para servidores. Si necesitas acceso por contraseña temporal, pon un recordatorio para quitarlo el mismo día.

Estrategia de actualizaciones: zypper, parches y cuándo ser conservador

Leap recompensa ventanas de cambio predecibles. No hagas “actualiza todo cuando quieras” si quieres estabilidad. En su lugar:

• Cadencia rutinaria: aplica parches de seguridad y recomendados con zypper patch.
• Actualizaciones controladas: programa zypper update o zypper dup solo cuando quieras cambiar más ampliamente (y cuando puedas reiniciar).
• Flujo consciente de snapshots: asegúrate de que Snapper cree snapshots pre/post para operaciones de paquetes. Si algo falla, la reversión es un plan, no una plegaria.

Revertir tras un cambio malo

Cuando una actualización rompe el arranque o un servicio, la vía de recuperación debería ser procedimental. En un root Btrfs+Snapper, a menudo puedes revertir.

cr0x@server:~$ sudo snapper list | tail -n 5
98  | pre    |       | 2026-02-05 10:12:01 | root | number | zypp(zypper patch) | 
99  | post   | 98    | 2026-02-05 10:13:12 | root | number | zypp(zypper patch) | 
100 | single |       | 2026-02-05 10:20:44 | root | number | before-nginx-config | 

Qué significa: Tienes un par pre/post alrededor del parcheo y un snapshot manual “before config”.

Decisión: Si el sistema falló después del parche #99, sabes qué probar o a qué revertir. No estás adivinando.

Un principio guía, de ingeniería de confiabilidad: La esperanza no es una estrategia. — Gene Kranz

Línea base de seguridad: firewall, SSH, AppArmor y registro

Firewall: puertos abiertos solo cuando un servicio esté listo

En servidores, mantén la zona por defecto restrictiva. Añade servicios explícitamente. Ejemplo: permitir SSH y (solo si es necesario) HTTP/HTTPS.

cr0x@server:~$ sudo firewall-cmd --permanent --add-service=ssh
success

cr0x@server:~$ sudo firewall-cmd --reload
success

cr0x@server:~$ sudo firewall-cmd --list-services
ssh

Qué significa: SSH está permitido; nada más está expuesto implícitamente.

Decisión: No abras puertos para “servicios futuros”. Abre puertos cuando el servicio esté instalado, configurado y monitorizado.

SSH: claves, no root, superficie de ataque mínima

Configura PasswordAuthentication no, PermitRootLogin no. Mantén una vía de emergencia: acceso por consola o gestión fuera de banda si esto es producción real.

Registro: no puedes depurar lo que no registraste

El journal de systemd es potente, pero no lo trates como almacenamiento infinito. Si esto es un servidor, decide dónde viven los logs y cuánto tiempo los conservas. Si envías logs centralmente, empieza pronto—la recolección retroactiva de logs es un mito.

AppArmor: aplicar, no desactivar

AppArmor no es solo “teatro de seguridad” en Leap; está integrado en cómo se espera que corran los servicios. Si encuentras una violación de perfil, usa el modo complain tácticamente para ese servicio, aprende lo que necesita y luego vuelve a enforcement.

Tres mini-historias corporativas (qué falla realmente)

Incidente: la suposición equivocada (“los snapshots son backups”)

Una compañía mediana ejecutaba algunos servicios internos en un host VM basado en Leap. Les encantaban los snapshots Btrfs. Tenían snapshots semanales y se sentían seguros. El equipo de admins incluso practicó una reversión tras una actualización rota una vez. La confianza aumentó.

Luego la matriz de almacenamiento tuvo un problema de controlador. No un desastre total—solo suficiente corrupción y timeouts para que el hipervisor marcara el datastore como no saludable. Las VMs se pausaron, luego algunos discos volvieron, luego se fueron otra vez. Fue el peor tipo de fallo: intermitente y ruidoso.

La primera intención del equipo fue “revertir snapshots”. Eso funcionó para una VM… brevemente. Luego los fallos subyacentes de almacenamiento reaparecieron. Los snapshots, por supuesto, viven en el mismo almacenamiento. Protegen contra malos cambios, no contra hardware malo o un mal día en el SAN.

La larga noche la pasaron restaurando desde un sistema de backups real que sí tenían—pero no tan recientemente probado como debería haber sido. Su postmortem fue franco: la suposición no era maliciosa, era semántica y perezosa. Snapshot no es backup. Mismo disco significa mismo dominio de fallo.

Lo que cambiaron después fue aburrido y correcto: pruebas de restauración mensuales y un widget en el dashboard que muestra la frescura del backup junto a la cuenta de snapshots. El equipo dejó de pelear por palabras y empezó a medir la recuperación.

Optimización que salió mal: “afinemos para velocidad”

Otra organización tenía una flota Leap 15.x ejecutando servicios en contenedores. Alguien notó picos de uso de disco e I/O en horas punta y decidió que el sistema “perdía tiempo” por el comportamiento copy-on-write de las capas de contenedor.

Hicieron un cambio rápido: movieron el almacenamiento de contenedores al root Btrfs y empezaron a experimentar con opciones de montaje y políticas agresivas de limpieza. El sistema se sintió más rápido en pruebas sintéticas. Todos contentos. Un ticket se cerró con la palabra “optimizado”.

Dos semanas después, el primer incidente real: un nodo se reinició tras parcheo y arrancó con quejas del sistema de archivos y capas de contenedor faltantes. No siempre—solo a veces. Resultó que la política de limpieza, combinada con la retención de snapshots y churn, creó presión de metadata y patrones de fragmentación que hicieron la recuperación impredecible.

Volvieron a un diseño más simple: mantener Btrfs para el SO, poner rutas de contenedor y bases de datos con muchas escrituras en XFS, y mantener la retención de snapshots sensata. El rendimiento volvió a “un poco menos emocionante” y la disponibilidad a “aburridamente consistente”. El equipo también aprendió una lección que debería estar bordada en una almohada: la optimización sin una estrategia de salida es solo experimentación en producción.

Práctica aburrida que salvó el día: ventanas de cambio + comprobaciones previas

Una pequeña empresa financiera ejecutaba servidores Leap para apps internas. No eran llamativos. Tenían una ventana de parches mensual, una checklist y la costumbre de tomar un snapshot manual con una etiqueta legible antes de cualquier cambio significativo.

Un mes, un parche rutinario introdujo una regresión sutil para un driver de nicho usado por su flujo de trabajo de escaneo. El servicio no falló de forma estrepitosa. Se volvió lento, luego se colgó bajo carga. Los usuarios reportaron “está raro” en lugar de “está caído”. Esos son los tickets que pudren tu día.

Porque tenían una checklist, el on-call no empezó a depurar la app del proveedor del escáner. Siguió el guion: confirmó que la regresión se correlaciona con el parche, comparó logs entre el snapshot pre/post y revirtió el snapshot del SO en un servidor canario.

El canario recuperó la salud al instante. Revirtieron los servidores restantes, fijaron la versión del paquete problemática y abrieron un ticket al proveedor con logs y versiones exactas de paquetes. Sin drama. Sin heroísmos. Solo un equipo que trató las operaciones como proceso, no como vibra.

Guía de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando un sistema Leap se siente lento o “roto”, no empiezas por reinstalar paquetes. Empiezas por localizar la constricción. Aquí está el orden que consistentemente encuentra la verdad rápido.

Primero: ¿es una falla sistémica o un solo servicio?

cr0x@server:~$ uptime
 09:41:03 up  1:12,  2 users,  load average: 6.21, 5.98, 5.10

Interpretación: La carga alta puede significar saturación de CPU, acumulación de procesos ejecutables o I/O bloqueado (la carga incluye sleep ininterrumpible).

Decisión: Si la carga es alta, pasa a la triage CPU/memoria/I/O. Si la carga es normal, céntrate en el servicio específico y sus dependencias.

Segundo: CPU vs memoria vs I/O (elige la guerra correcta)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 2780000  42000 820000    0    0    12    25  220  410  8  2 89  1  0
 7  3      0  120000  43000 790000    0    0  8800  9200 1200 3500 10  5 40 45  0

Interpretación: La columna b (procesos bloqueados) y wa alto (espera I/O) apuntan hacia un cuello de botella de almacenamiento.

Decisión: Si wa es alto, deja de culpar a la app. Mira la latencia del disco, el sistema de archivos y el hardware subyacente.

Tercero: encuentra el proceso más caliente, luego verifica que sea la causa

cr0x@server:~$ top -b -n 1 | head -n 15
top - 09:42:55 up  1:14,  2 users,  load average: 6.80, 6.05, 5.20
Tasks: 214 total,   3 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.0 us,  4.0 sy,  0.0 ni, 40.0 id, 45.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  32000.0 total,   118.0 free,  1250.0 used,  30632.0 buff/cache
MiB Swap:  32768.0 total, 32768.0 free,     0.0 used.  30100.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3221 postgres  20   0 3248000 220000  12000 D  12.0   0.7   0:34.11 postgres

Interpretación: Proceso en estado D (sleep ininterrumpible) más alta I/O wait sugiere fuertemente stalls en almacenamiento.

Decisión: Pasa a comprobaciones de almacenamiento. No reinicies servicios a ciegas; solo añadirás carga de recuperación a un disco en problemas.

Cuarto: latencia y errores de almacenamiento (los asesinos silenciosos)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         10.70    0.00    4.10   44.90    0.00   40.30

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  r_await  w_await
nvme0n1          85.0   120.0  9800.0 11000.0     0.0     5.0   98.0    12.4    35.8

Interpretación: %util cerca de 100 y await alto indican que el disco está saturado o no saludable, o que estás topando con un tema de colas.

Decisión: Si la latencia es alta, revisa SMART, dmesg/journal por errores I/O y los patrones de carga. Considera mover rutas con muchas escrituras fuera del root Btrfs.

Quinto: red, pero solo después de exonerar disco y CPU

cr0x@server:~$ ss -s
Total: 278
TCP:   41 (estab 25, closed 8, orphaned 0, timewait 6)

Transport Total     IP        IPv6
RAW       0         0         0
UDP       7         5         2
TCP       33        22        11
INET      40        27        13
FRAG      0         0         0

Interpretación: Te da una vista rápida de la carga de sockets; no es un análisis profundo pero sirve para “¿estamos ahogados en conexiones?”

Decisión: Si el conteo de conexiones es anormal, investiga el servicio y los balanceadores upstream, luego revisa errores NIC y DNS.

Errores comunes: síntoma → causa raíz → solución

1) “Después de actualizaciones, el sistema no arranca”

Sintomas: El arranque cae a un shell de emergencia, o la pila de servicios no arranca tras parchear.

Causa raíz: Desajuste kernel/initramfs, actualización de driver mala o un montaje de sistema de archivos mal configurado introducido durante el cambio.

Solución: Usa la reversión de Snapper (si estás en root Btrfs) para volver al snapshot pre-actualización; luego reaplica parches con un enfoque canario.

2) “El disco está lleno pero df muestra espacio” (edición Btrfs)

Sintomas: Fallan escrituras; servicios se caen; df -h parece bien.

Causa raíz: Agotamiento de metadata de Btrfs o retención de snapshots consumiendo espacio asignado.

Solución: Revisa btrfs filesystem usage /, poda snapshots de Snapper y considera reequilibrar. También establece políticas sensatas de limpieza de snapshots.

3) “La red funciona hasta que reinicio”

Sintomas: ip addr add funciona manualmente; tras reinicio se pierde; a veces desaparece el Wi‑Fi.

Causa raíz: Managers de red en competencia (Wicked y NetworkManager), o configuración editada en una herramienta pero gestionada por otra.

Solución: Elige un manager. En servidores: deshabilita NetworkManager. En portátiles: deshabilita Wicked. Mantén configuraciones en el lugar apropiado.

4) “SSH de repente rechaza inicios de sesión”

Sintomas: Claves que antes funcionaban dejan de funcionar tras hardening o actualizaciones.

Causa raíz: Permisos/propiedad en ~/.ssh o authorized_keys demasiado abiertos; o el home del usuario en un filesystem montado con opciones inesperadas.

Solución: Corrige permisos y confirma la configuración de sshd. Valida con sshd -T y logs del journal.

5) “AppArmor rompió mi servicio”

Sintomas: El servicio arranca y luego falla, con operaciones denegadas en los logs.

Causa raíz: El perfil de AppArmor bloquea una nueva ruta, socket o capacidad introducida por cambios de configuración.

Solución: Pon ese perfil en modo complain temporalmente, ajusta el perfil y luego vuelve a enforce. No desactives AppArmor globalmente.

6) “zypper conflictos y infierno de dependencias”

Sintomas: zypper quiere cambiar proveedor de paquetes o eliminar la mitad del sistema.

Causa raíz: Demasiados repositorios, prioridades desajustadas o mezclar Leap con repos incompatibles de terceros.

Solución: Elimina o deshabilita repos no esenciales, alinea el proveedor y mantén el conjunto de repositorios mínimo. Si debes usar extras, documenta la propiedad y el plan de reversión.

Listas de verificación / plan paso a paso

Checklist de instalación (30 minutos, sin heroísmos)

1. Firmware: UEFI habilitado, modo de disco correcto seleccionado, política de Secure Boot decidida.
2. Objetivo de instalación: servidor minimal vs estación de trabajo con escritorio elegido conscientemente.
3. Almacenamiento: ESP ≥ 512 MiB, root en Btrfs, decide ubicación de /home y /var/lib.
4. Gestor de red: Wicked para servidor, NetworkManager para portátil.
5. Usuarios: crea admin no-root; planifica claves SSH.
6. Hora: habilita NTP, configura zona horaria.
7. Reinicia y verifica: arranque limpio, repositorios sanos, Snapper operativo.

Checklist de hardening post-instalación (primer día)

1. Parchea: ejecuta zypper patch; reinicia si cayeron kernel/systemd.
2. SSH: deshabilita auth por contraseña; bloquea root; verifica con sshd -T.
3. Firewall: permite solo servicios necesarios; confirma zona y reglas activas.
4. Monitorización: al menos recoge journalctl, salud SMART de discos y uso de sistema de archivos.
5. Snapshots: confirma la política de retención y asegúrate de margen de espacio libre.
6. Backups: implementa backups reales; prueba restauración.

Checklist de cordura en almacenamiento (antes de ejecutar bases de datos/contenedores)

1. Confirma dónde vivirán los datos con muchas escrituras (prefiere XFS para rutas con mucho churn).
2. Asegúrate de tener sistemas de archivos/volúmenes separados si necesitas controlar el blast-radius.
3. Valida salud del disco con SMART y revisa logs del kernel por errores I/O.
4. Decide nivel de RAID y dominio de fallo; prueba un escenario degradado si es posible.

Broma #2: Si no pruebas tus restauraciones, tu sistema de backup es solo un lugar muy caro para almacenar optimismo.

Preguntas frecuentes

¿Debo elegir Leap 15.6 o Tumbleweed?

Si la máquina debe ser predecible y de bajo mantenimiento, elige Leap. Si necesitas kernels, controladores y stacks de desarrollo más recientes y puedes tolerar la rotación, elige Tumbleweed.

¿Es seguro Btrfs como sistema raíz?

Sí, especialmente en Leap donde es predeterminado e integrado con Snapper. Úsalo como red de seguridad del SO. Para datos con muchas escrituras, considera XFS en volúmenes dedicados.

¿Los snapshots son lo mismo que backups?

No. Los snapshots son vistas puntuales en el mismo disco. Los backups deben vivir en almacenamiento separado (y idealmente en un dominio de fallo distinto) y probarse en restauración.

¿Debo usar Wicked o NetworkManager?

Servidores: Wicked. Portátiles/escritorios con roaming Wi‑Fi: NetworkManager. Elige uno para evitar comportamientos en conflicto.

¿Cuál es el comando de actualización más seguro en Leap?

zypper patch para correcciones de seguridad/recomendadas rutinarias. Programa actualizaciones más amplias deliberadamente y reinicia cuando cambien componentes críticos.

¿Cómo revierto tras una mala actualización?

Si root es Btrfs con Snapper, usa snapshots: identifica el snapshot pre-cambio y revierte. Si no usas Snapper, tu reversión es “restaurar desde backup o reconstruir”, que es más lento y arriesgado.

¿Necesito desactivar AppArmor para ejecutar contenedores o servicios web?

Normalmente no. Si un perfil bloquea tu servicio, ajusta ese perfil o ponlo en modo complain mientras diagnosticas. Desactivar AppArmor globalmente es una herramienta burda.

¿Cuál es el mejor sistema de archivos para una base de datos en Leap?

Comúnmente XFS (o ext4) en un volumen dedicado. Si usas Btrfs, hazlo con conocimiento y prueba rendimiento y comportamiento ante fallos con tu carga de trabajo.

¿Cómo mantengo estable mi configuración de repositorios?

Mantén repos minimalistas, prefiere fuentes oficiales y evita mezclar repos incompatibles. Si añades un repo, documenta por qué, qué provee y cómo eliminarlo limpiamente.

¿Cuál es la forma más rápida de diagnosticar «el servidor está lento»?

Revisa la carga y la I/O wait, luego la latencia del disco y SMART, después la presión de memoria y finalmente la red. La mayoría de las “lentitudes misteriosas” son almacenamiento o un servicio con mal comportamiento.

Conclusión: pasos prácticos siguientes

Si quieres una instalación de Linux que puedas conservar durante años, constrúyela como si tuvieras que explicarla después—porque lo harás. Usa las fortalezas de Leap 15.6: YaST para claridad, snapshots Btrfs para reversión, parches zypper para cambio controlado y AppArmor para endurecimiento pragmático.

Pasos siguientes que rinden frutos de inmediato:

1. Realiza las tareas post-instalación arriba y corrige sorpresas mientras el sistema aún es “nuevo”.
2. Decide dónde viven los datos con muchas escrituras y muévelos fuera del filesystem del SO si es necesario.
3. Establece una cadencia de parches y haz el primer reinicio en tu horario, no durante un incidente.
4. Implementa backups reales y realiza una prueba de restauración esta semana. No más tarde.
5. Escribe tu lista de repos, el esquema de almacenamiento y la elección del gestor de red en una nota de operaciones que puedas encontrar en un año.

Eso es la configuración estable: no perfecta, no llamativa, simplemente sobrevivible de forma fiable.