¿Se puede gestionar Proxmox sin línea de comandos? La respuesta honesta

La mayoría de quienes hacen esta pregunta en realidad se preguntan dos cosas distintas: "¿podré?" y "¿me estaré perdiendo algo?". Ambas respuestas son mejores de lo que se cree, pero en medio hay una advertencia importante.

El panel no es un camino menor

La idea extendida es que la interfaz es un intérprete simplificado y que el trabajo de verdad se hace en la línea de comandos. No es así. El panel y la línea de comandos hablan con la misma interfaz: la interfaz de programación propia de Proxmox. El botón que pulsas en el panel y la orden que escribes en el terminal pasan por la misma puerta.

Así que el trabajo hecho desde el panel no es una "versión ligera". Es el mismo trabajo, desde otra superficie.

Casi todo el trabajo diario ya está en el panel

Crear máquinas, arrancarlas, pararlas, tomar instantáneas, hacer copias, definir almacenamiento, ordenar la red, crear usuarios y dar permisos, actualizar. Todo eso está en la interfaz, y para la mayor parte la línea de comandos es de todos modos más lenta.

Dónde hace falta de verdad la línea de comandos

Esos casos son pocos pero no cero, y la honestidad obliga a decirlo. Suelen caer en tres familias: cuando un componente se rompe de forma inesperada (leer los registros del sistema, ver por qué un servicio no arranca), cuando se trabaja en masa (aplicar el mismo cambio a cien máquinas), y cuando se usa una capacidad nueva o muy concreta que la interfaz todavía no cubre.

Fíjate en lo que tienen en común esas tres: todas son fuera de lo corriente. Ninguna forma parte del trabajo diario.

El peligro real no es el no saber

Esta es la frase más importante de esta entrada: el peligro no es no conocer la línea de comandos, es pegar una orden que no entiendes.

Una orden encontrada en internet se ejecuta en tu máquina con tus permisos, y nadie mira el resultado. Este wiki tiene dos ejemplos concretos: la orden de una línea que se supone que silencia el aviso de suscripción y que en realidad destroza toda la biblioteca de la interfaz, y los archivos compose que parecen configuración pudiendo entregarle al contenedor la máquina entera.

En ninguno de los dos casos el problema fue que la persona no supiera línea de comandos. El problema fue que ejecutó algo que no conocía. Quien nunca toca la línea de comandos no cae en ninguna de las dos trampas; quien la sabe a medias, sí.

Si quieres aprender, el orden correcto

No estamos diciendo que la evites. Pero el orden importa: aprende primero las órdenes que leen y después las que escriben. Las órdenes que muestran estado, leen registros y listan cosas no rompen nada, y te enseñan cómo razona el sistema. Pasa a las órdenes que escriben solo cuando sepas leer lo que hacen.

Y una regla: no ejecutes una orden que no entiendes en una máquina que carga tu trabajo. Si quieres probar, crea una máquina para probar; todas las entradas de copias y restauración de este wiki existen justo para eso.

Qué hace Atlas

Atlas está del lado de llevar el trabajo diario al panel, así que intenta ensanchar la lista del "casi todo" de arriba. Pero al hacerlo no oculta nada: dice qué va a hacer una operación y, en las operaciones sin vuelta atrás, lo dice antes de la operación.

La misma postura aparece en dos sitios directamente ligados a esta entrada. Los scripts de instalación y los archivos compose se analizan antes de ejecutarse, y las líneas que perforan la frontera del contenedor se te muestran. Los trabajos que tocan archivos, como silenciar el aviso de suscripción, se hacen dentro del producto en lugar de a mano, y tras escribir, el archivo se vuelve a leer y se verifica.

Así que el objetivo no es ocultarte la línea de comandos. El objetivo es que nunca tengas que pegar una orden que no entiendes.