En la publicación anterior describimos cómo synex-installer evolucionó para soportar cuatro sistemas de archivos. El paso siguiente era natural: si el instalador ya gestiona la configuración de almacenamiento, tiene sentido que también ofrezca cifrado como parte del proceso. El momento de la instalación es cuando se define la arquitectura de almacenamiento, y el cifrado es parte de esa arquitectura.
Cifrado como parte del flujo de instalación
La decisión de incluir cifrado en el instalador responde a una realidad: en muchos entornos, la protección de datos en reposo no es opcional. Normativas de cumplimiento, políticas internas de seguridad, o simplemente buenas prácticas dictan que los discos de un servidor deben estar cifrados. Cuando eso se resuelve durante la instalación, el servidor entra en producción ya protegido.
El desafío fue que cada filesystem tiene características diferentes, y forzar un único método de cifrado para todos no tenía sentido técnico. La solución fue adaptar el enfoque según el sistema de archivos elegido, aprovechando las capacidades nativas donde existen y utilizando herramientas estándar donde son la mejor opción.
ZFS: cifrado nativo con AES-256-GCM
ZFS incluye cifrado como característica integrada del sistema de archivos. No es una capa externa que se agrega encima, sino parte de la arquitectura: los datos se cifran antes de escribirse al pool, y los checksums de integridad operan sobre los datos cifrados. Esta integración significa que las características avanzadas de ZFS, como snapshots y replicación, funcionan de forma transparente con datos cifrados.
El instalador utiliza AES-256-GCM cuando se habilita cifrado en ZFS. La passphrase se solicita durante la instalación y se configura a nivel de pool, con los datasets heredando la configuración automáticamente. El único requisito técnico es que /boot permanezca sin cifrar en una partición separada, ya que GRUB necesita acceder al kernel antes de que el pool cifrado pueda desbloquearse.
Esta fue la opción más directa de implementar: ZFS ya tiene todo resuelto, solo había que exponerlo en el flujo de instalación y asegurar que la configuración de arranque funcionara correctamente.
BTRFS: LUKS2 como contenedor externo
BTRFS no incluye cifrado nativo. La solución estándar en el ecosistema Linux es LUKS, que opera como una capa de cifrado debajo del sistema de archivos. Los datos pasan por LUKS antes de llegar al disco, y BTRFS opera sin saber que está sobre un volumen cifrado.
Para BTRFS elegimos LUKS2 directamente sobre la partición, sin capas intermedias. La razón es que BTRFS ya proporciona gestión flexible de almacenamiento mediante subvolúmenes: no necesita LVM para redimensionar o reorganizar el espacio.
El flujo es simple: el instalador crea el contenedor LUKS2, formatea con BTRFS adentro, y configura los subvolúmenes igual que en una instalación sin cifrado. La partición /boot permanece sin cifrar por la misma razón que en ZFS: el bootloader necesita acceso antes del desbloqueo.
EXT4 y XFS: LUKS2 con LVM para flexibilidad
EXT4 y XFS son sistemas de archivos tradicionales sin gestión de volúmenes integrada. Una partición es una partición: tamaño fijo, sin posibilidad de ajuste dinámico. En un servidor donde los requerimientos pueden cambiar, esa rigidez es una limitación.
Aquí es donde LVM aporta valor. Al colocar LVM dentro del contenedor LUKS2, obtenemos volúmenes lógicos que pueden redimensionarse, extenderse, o reorganizarse sin tocar el cifrado. Un único contenedor LUKS protege todo el almacenamiento, mientras que LVM proporciona la flexibilidad que estos filesystems no tienen de forma nativa.
El instalador configura el esquema completo: partición LUKS2, volumen físico, grupo de volúmenes, y volúmenes lógicos según lo que el administrador defina en el particionado interactivo. Una passphrase desbloquea todo el almacenamiento, y a partir de ahí cada volumen lógico funciona de manera independiente.
Esta decisión agrega una capa de complejidad, pero es complejidad justificada. Sin LVM, el administrador quedaría con particiones cifradas de tamaño fijo, perdiendo flexibilidad en servidores donde los requerimientos de espacio pueden evolucionar.
Misma pregunta, diferentes respuestas
Los tres enfoques responden a la misma necesidad, proteger datos en reposo, pero de formas adaptadas a cada contexto. ZFS ya tiene la solución integrada; usarla era obvio. BTRFS necesita LUKS pero no LVM. EXT4 y XFS necesitan ambos para no sacrificar flexibilidad.
Desde la perspectiva del usuario, la experiencia es consistente: una pregunta sobre si desea habilitar cifrado, una passphrase para ingresar, y el instalador se encarga del resto. Las diferencias técnicas quedan abstraídas detrás de un flujo uniforme.
Próximos pasos
Esta publicación cierra la serie sobre el desarrollo de synex-installer. En conjunto, las tres notas documentan la evolución desde un instalador enfocado en ZFS hacia una herramienta integral con soporte multi-filesystem y cifrado adaptado a cada opción.
Synex Server 13 R2 incorporará todas estas mejoras. La fecha tentativa de lanzamiento es la semana del 16 de febrero. Mientras tanto, Synex Server 13 R1 está disponible para descarga desde aquí.