Prompt Your Way to Linux: Una serie de 4 partes
Parte 1: Elige tu distro → Parte 2: Almacenamiento y cifrado → Parte 3: Instalación manual → Parte 4: Servicios y GPU
Si alguna vez has visto cómo una partición raíz se llena a las 3 de la madrugada y tu sistema se paraliza por completo, ya lo sabes: el particionado por defecto es una trampa. Pero diseñar un esquema LVM cifrado para seis cargas de trabajo distintas en tres discos físicos es una tarea que puede ocuparte un día entero entre planificación, consulta de documentación, cálculo de tamaños y dudas constantes.
Aquí te explico cómo dejar que la IA haga el trabajo pesado en el diseño del almacenamiento para que no pases el día enterrado en páginas de manual. Le darás tus requisitos de carga de trabajo, recibirás una arquitectura completa con un razonamiento que podrás seguir sin problemas, y al final entenderás cada capa de lo que estás construyendo.
En la Parte 1 elegiste tu distro y mapeaste el hardware. Ahora llega la parte donde la mayoría de la gente acepta valores predeterminados inadecuados o abandona del todo: el diseño del almacenamiento.
Empieza por las cargas de trabajo, no por los tamaños de partición
Tienes el hardware mapeado desde la Parte 1: digamos un ThinkPad antiguo con una unidad NVMe, un SSD y un HDD. Las especificaciones te dicen qué es posible. Pero las cargas de trabajo te dicen qué es necesario.
Aquí está la clave. No le pidas a la IA una tabla de particiones. No especifiques tamaños. No digas "pon /home en su propia partición". En cambio, describe comportamientos y requisitos y deja que derive la arquitectura. Algo así:
"Esta máquina ejecutará contenedores Docker, PostgreSQL con TimescaleDB, Redis, Ollama para modelos de IA locales, y almacenará artefactos de ataque de una red honeypot. También necesita un espacio de trabajo de análisis cifrado separado del sistema operativo, y almacenamiento de archivo cifrado para evidencia a largo plazo. Diseña la mejor estrategia de particionado y cifrado para los tres discos que encontramos."
¿Ves la diferencia? Estás entregando restricciones y objetivos, no micromanejando la solución. Si el razonamiento es sólido, el diseño también lo será. Y si alguna decisión no tiene sentido, lo notarás porque entiendes lo que tu máquina realmente necesita hacer.
Clasificar las cargas de trabajo por comportamiento de disco
Lo primero que hay que resolver es la separación de cargas de trabajo según el patrón de E/S. No por tamaño, no por importancia, sino por cómo cada carga de trabajo accede realmente al disco.
Los tres carriles
- Alto IOPS, baja latencia = NVMe. Aquí viven el sistema operativo, Docker, las bases de datos y los modelos de IA. Estas cargas de trabajo realizan muchas lecturas y escrituras aleatorias pequeñas. Necesitan el almacenamiento más rápido disponible.
- Espacio de trabajo rápido y aislado = SSD. El espacio de trabajo de análisis va aquí. Necesita una velocidad decente para procesar capturas y ejecutar herramientas, pero más importante aún, necesita estar separado del disco del sistema operativo. Si el trabajo de análisis corrompe un sistema de archivos o llena un disco, el sistema operativo sigue funcionando.
- Gran capacidad, escrituras secuenciales = HDD. Almacenamiento de archivo a largo plazo para pcaps, exportaciones de evidencia y copias de seguridad. El rendimiento de escritura secuencial es suficiente. La capacidad importa más que la velocidad.
Esta separación por sí sola evita el modo de fallo más común: que una carga de trabajo deje sin recursos de E/S o espacio a otra.
Por qué cada servicio tiene su propio volumen lógico
No te detengas en tres discos. En el NVMe, divide el espacio en seis volúmenes lógicos separados, cada uno con un propósito específico:
- /var/lib/docker se aísla porque Docker consume disco de forma impredecible. Una compilación de contenedor desbocada o una caché de imágenes olvidada no debería poder llenar la raíz.
- /var/lib/postgresql se aísla para un dimensionamiento independiente, instantáneas de copia de seguridad y ajuste de rendimiento futuro. Las bases de datos tienen patrones de E/S únicos que se benefician de un espacio dedicado.
- /var/lib/ollama se aísla porque los modelos de IA son enormes y crecen de forma independiente. Un solo LLM puede ocupar 8 GB o más. No quieres que las descargas de modelos compitan con tu sistema operativo por espacio.
- /home se aísla para que los datos del usuario, los dotfiles y las configuraciones personales sobrevivan a las reinstalaciones del sistema operativo.
- swap como su propio volumen lógico, dimensionado para admitir hibernación si es necesario.
- root (/) acotado a un tamaño fijo para que nada fuera de las rutas designadas pueda llenarlo. Si la raíz se llena, el sistema deja de funcionar. Acotarla es un diseño defensivo.
El cifrado no es opcional
El cifrado no es opcional aquí, y el razonamiento es sencillo. Se trata de un equipo portátil que funciona como estación de trabajo de seguridad y almacena datos sensibles en reposo: capturas de honeypot, artefactos de ataque, resultados de análisis de red. Si la máquina es robada, se pierde o se da de baja, cada disco debe ser ilegible sin la contraseña.
El cifrado de disco completo con LUKS es el punto de partida para este caso de uso. Sin excepciones.
Deja margen en tu grupo de volúmenes
Este detalle separa un buen diseño LVM del trabajo amateur. Deja aproximadamente un 5-10% de tu grupo de volúmenes sin asignar. No desperdiciado. Reservado. Aquí está el motivo:
Con LVM, puedes ampliar volúmenes lógicos al vuelo sin reiniciar. Si Docker necesita más espacio en seis meses, extiendes el LV y redimensionas el sistema de archivos en segundos. Si asignaste todo de antemano, tendrías que reducir un volumen para ampliar otro, y reducir es lento, arriesgado y a veces imposible con ciertos sistemas de archivos.
El margen intencional es una característica, no un desperdicio.
El modelo mental de la capa de almacenamiento
Este modelo mental es lo más valioso que puedes llevarte de todo este capítulo. No los tamaños de partición. No los puntos de montaje. Esta pila de 8 capas que explica cómo funciona realmente el almacenamiento en Linux, de arriba a abajo.
La pila de almacenamiento de 8 capas
Cada parte de tu almacenamiento pasa por estas capas, de arriba a abajo:
- Partición sin procesar: lo que crea
fdiskogdisken el disco físico - Cifrado (LUKS): envuelve la partición sin procesar en un contenedor cifrado
- Dispositivo mapper: lo que aparece tras desbloquear:
/dev/mapper/cryptnvme - Volumen físico LVM (PV): el dispositivo mapper registrado como almacenamiento para LVM
- Grupo de volúmenes (VG): uno o más PVs agrupados en un pool
- Volumen lógico (LV): una porción del VG, dimensionada para un propósito específico
- Sistema de archivos: ext4 o swap, formateado en el LV
- Punto de montaje: donde el sistema de archivos aparece en el árbol de directorios
Cuando algo falla, la solución casi siempre está en una capa específica. Si no puedes identificar cuál, perderás horas depurando en el lugar equivocado.
La mayoría de los fallos que encontrarás durante la instalación real, especialmente con fstab y crypttab en la Parte 3, provienen de confundir estas capas. Escribir un UUID de la capa 2 donde se esperaba la capa 6. Referenciar una ruta de dispositivo de la capa 3 en una configuración que necesitaba la capa 1. Cada error de almacenamiento se reduce a un desajuste de capas.
Guarda esta pila como referencia. Tatúatela en el antebrazo. Una vez que interiorices estas ocho capas, el almacenamiento en Linux deja de ser misterioso. Son solo ocho cosas, cada una haciendo un trabajo, conectadas en orden.
El diseño final del NVMe
Aquí está el diseño completo para la unidad NVMe principal:
NVMe principal (nvme0n1)
| Partición | Tamaño | Tipo | Propósito |
|---|---|---|---|
| nvme0n1p1 | 1 GB | Sistema EFI (FAT32) | Firmware de arranque |
| nvme0n1p2 | 2 GB | /boot (ext4) | Kernel e initramfs |
| nvme0n1p3 | Restante | Cifrado LUKS2 | Todo lo demás |
Dentro del contenedor LUKS en nvme0n1p3:
nvme0n1p3 → cryptnvme (LUKS2) → LVM PV → vgkali (Grupo de volúmenes)
| Volumen lógico | Tamaño | Sistema de archivos | Punto de montaje |
|---|---|---|---|
| root | 120 GB | ext4 | / |
| swap | 24 GB | swap | [swap] |
| docker | 220 GB | ext4 | /var/lib/docker |
| ollama | 180 GB | ext4 | /var/lib/ollama |
| postgres | 120 GB | ext4 | /var/lib/postgresql |
| home | 200 GB | ext4 | /home |
| (libre) | ~65 GB | n/a | n/a |
Discos secundarios
SSD (sdb): sdb1 → cryptanalysis (LUKS2) → ext4 → /srv/analysis
HDD (sda): sda1 → cryptarchive (LUKS2) → ext4 → /srv/archive
Tres discos cifrados. Seis volúmenes lógicos en el principal. Cada carga de trabajo en su propio carril. Nada comparte espacio con lo que no debería.
Convertir el Diseño en un Script de Construcción
Una vez que el diseño está cerrado, el siguiente prompt es sencillo:
"Dame los comandos exactos para construir todo este esquema de almacenamiento desde el entorno Kali en vivo. Asume que los tres discos pueden borrarse."
Pide un script de shell completo: borrar las firmas existentes, crear tablas de particiones GPT, tallar particiones con sgdisk, crear contenedores LUKS2 con valores predeterminados robustos, abrirlos, inicializar los volúmenes físicos de LVM, crear el grupo de volúmenes, asignar los seis volúmenes lógicos, formatear todo y luego repetir la configuración de LUKS para el SSD y el HDD.
Espera unas 80 líneas aproximadamente. Cada comando debe ser auditable. Si algo en el script no tiene sentido para ti, pídele a la IA que explique esa línea específica antes de ejecutarla.
Qué Saldrá Mal (Y No Será el Diseño)
Aviso justo: el diseño será sólido. La ejecución te dará guerra. Estas son las trampas que debes vigilar:
Saltos de línea de Windows. Si escribes el script en una máquina Windows y lo transfieres al entorno en vivo mediante USB, cada línea termina con \r\n en lugar de \n. Bash falla en cada comando y los mensajes de error son crípticos. Corrígelo con sed -i 's/\r$//' script.sh antes de ejecutar cualquier cosa.
Corrupción del shebang. Relacionado con el problema de los saltos de línea. La línea #!/bin/bash recibe un retorno de carro invisible, por lo que el kernel no puede encontrar el intérprete. El error parece indicar que el script no existe aunque claramente sí existe.
Confusión de rutas. El USB se monta en una ruta, pero estás referenciando el script desde un directorio de trabajo diferente. El autocompletado con tabulador y las rutas relativas en un entorno en vivo son poco fiables cuando estás manejando múltiples puntos de montaje. Usa rutas absolutas.
Sintaxis de ejecución incorrecta. Olvidar ./ antes del nombre del script, o no establecer primero los permisos de ejecución. Errores clásicos que no tienen nada que ver con el diseño del almacenamiento y sí mucho con la memoria muscular.
"La IA puede escribir el script, pero aún necesitas entender lo que estás pegando. Si un comando no tiene sentido para ti, detente y pregunta."
Una vez resueltos los problemas de saltos de línea y ejecución, la construcción del almacenamiento se completa en menos de dos minutos. Cada contenedor LUKS se abre. Cada estructura LVM se crea sin problemas. Cada sistema de archivos se formatea. El diseño se sostiene.
Verifica Todo con el Patrón de Pegar y Comprobar
No des el éxito por sentado. Cuando el script termine, pega la salida de tu terminal de vuelta a la IA y pídele que audite el resultado:
"Aquí está mi salida de
lsblkylvs. ¿Se construyó todo correctamente?"
Pega la salida sin procesar del terminal y pídele a la IA que la recorra línea por línea. Debería confirmar: cryptnvme activo, vgkali presente con seis volúmenes lógicos en los tamaños correctos, sistemas de archivos correctos en cada uno, discos secundarios cifrados y formateados.
Este patrón de pegar y verificar es una de las técnicas más útiles para la administración de sistemas con IA. Ejecutas un comando, pegas la salida y preguntas si la realidad coincide con el plan. Detecta problemas que pasarías por alto porque estás demasiado cerca del trabajo:
- Un volumen lógico formateado accidentalmente con el tipo de sistema de archivos incorrecto
- Un volumen dimensionado en megabytes cuando querías gigabytes
- Una partición faltante que el script omitió silenciosamente
- Un contenedor LUKS que en realidad no se abrió
Puedes hacer esto con casi cualquier estado del sistema: lsblk, lvs, pvs, vgs, blkid, fdisk -l, cryptsetup status. Pégalo. Pídele a la IA que lo audite. Es más rápido y más exhaustivo que comprobarlo todo tú mismo.
La Conclusión: Diseña a Partir de las Cargas de Trabajo, No de los Valores Predeterminados
El esquema de almacenamiento aquí presentado no se eligió de una plantilla ni se copió de un foro. Fue derivado de los requisitos reales de la carga de trabajo. Docker necesita aislamiento de espacio. Las bases de datos necesitan IO dedicado. Los modelos de IA necesitan espacio para crecer. Los artefactos de seguridad necesitan cifrado en reposo. Los archivos necesitan capacidad por encima de la velocidad.
Cada decisión se remonta a un requisito real. Esa es la diferencia entre un esquema de almacenamiento que sobrevive seis meses y uno que se desmorona la primera vez que ocurre algo inesperado.
Este enfoque funciona para cualquier construcción, no solo para estaciones de trabajo de seguridad. Dile a la IA qué hará la máquina. Describe los servicios, los patrones de datos, las expectativas de crecimiento, los escenarios de fallo que quieres superar. Luego deja que ella descubra cómo organizar los discos. El razonamiento que te muestra es más valioso que la tabla de particiones final, porque entenderás por qué se tomó cada decisión y cuándo podría necesitar cambiar.
Tus discos están particionados, cifrados y tallados en volúmenes lógicos. La arquitectura está lista. Ahora viene la parte que realmente pone a prueba a la gente: instalar un sistema operativo sobre todo esto sin un instalador gráfico que te guíe de la mano.
En Parte 3: Instalación Manual, montarás los volúmenes cifrados, arrancarás Kali desde cero, configurarás fstab y crypttab para que todo se desbloquee al iniciar, y construirás una configuración funcional del gestor de arranque. Aquí es donde el modelo de 8 capas se somete a una prueba de estrés real, y donde un UUID incorrecto puede dejarte mirando fijamente un prompt de rescate de GRUB. Trae café.
