Antes de ejecutar un script de la comunidad en su host Proxmox: cinco cosas que leer

Los scripts de la comunidad son realmente buenos. Llevan un conocimiento que alguien pagó con tardes perdidas, resuelven los casos incómodos con los que usted habría chocado a medianoche, y para muchas tareas el script es mejor que lo que habría escrito. Este artículo no es un alegato en su contra.

Trata de un hueco concreto. Una instalación por paquete y un script pegado en una línea se parecen en pantalla, y no son en absoluto lo mismo.

Lo que da un paquete y no da una línea pegada

Una firma. Los paquetes van firmados y la firma se comprueba. Una dirección solo se comprueba contra su suposición de que la dirección es la correcta.

Una versión. Puede decir qué versión tiene, y también quien le ayuda. "El script del readme, hace unas semanas" no es una versión.

Una vía de desinstalación. Los paquetes registran lo que colocaron y saben quitarlo. Un script suele dejar archivos en seis sitios y no lo recuerda.

Una relación con un mantenedor. Cuando un paquete cambia de comportamiento hay un registro de cambios. Un script puede cambiar bajo la misma dirección sin dejar nada que leer.

Nada de esto hace malos a los scripts. Los hace otra clase de cosa, que merece otra costumbre.

Las cinco cosas que leer

No todo el script, ni línea por línea. Estas cinco respuestas suelen verse en una pasada.

① ¿Qué toca fuera de su propio directorio? Un script que solo escribe bajo su carpeta es fácil de abarcar. Uno que edita archivos en directorios de configuración del sistema hace cambios que le sobrevivirán.

② ¿Añade un repositorio o una clave? Es la línea de mayores consecuencias en la mayoría de scripts y pasa en un segundo. Añadir una fuente de paquetes significa que toda actualización futura de esa máquina confiará en una parte nueva. Puede ser del todo razonable, y debería ser una decisión, no un efecto colateral.

③ ¿Toca arranque, núcleo o red? Son los tres que pueden dejar un host inalcanzable o sin arrancar, y en un hipervisor eso significa que se va todo lo que hay encima. Un script que instala una aplicación web no tiene nada que hacer en la configuración del gestor de arranque, y si lo toca merece entenderse antes de ejecutarlo.

④ ¿Hay camino de vuelta? Busque una vía de desinstalación o, en su defecto, una lista de lo que creó. Si no existe ninguna de las dos, su camino de vuelta es una instantánea tomada antes, lo que significa que hay que tomarla.

⑤ ¿Qué pasa si se ejecuta dos veces? Muchos scripts están escritos para una máquina limpia, y una segunda pasada duplica entradas, reinicia configuración que usted editó, o falla a medias dejando un estado a medias. Lo ejecutará dos veces alguna vez, normalmente porque la primera pareció fallar.

La línea pegada, en concreto

El patrón de descargar un script y canalizarlo directamente a un intérprete tiene una propiedad que merece nombrarse: no puede leer lo que ejecutó. No "no lo hizo", no puede, porque nunca fue un archivo.

También hay una variante más sutil. Leer el script en el navegador y ejecutar el comando descargar-y-canalizar son dos peticiones distintas. Nada garantiza que devolvieran los mismos bytes.

La solución cuesta un paso más. Descargue el archivo, mírelo y ejecute la copia local. Ahora sabe qué se ejecutó, puede repetir lo idéntico más adelante, y si algo se rompe tiene el texto real en vez del recuerdo de una página web.

Un hipervisor no es sitio para probar

Esto es lo que separa un host Proxmox de un portátil. Todo lo demás en la máquina está por debajo. Un script que deja un portátil en un estado raro le cuesta una tarde; el mismo script en un host se lleva todas las máquinas virtuales.

Dos costumbres hacen seguro casi todo esto:

Pruébelo primero en una máquina virtual si es plausible. La mayoría de los scripts que instalan un servicio no necesitan estar en el host. No es un apaño, suele ser el sitio correcto.

Si de verdad tiene que ejecutarse en el host, instantánea antes. No porque el script sea sospechoso, sino porque "voy a probarlo" es exactamente la frase que precede a necesitar un camino de vuelta.

Lo que este artículo no es

No es motivo para desconfiar de la comunidad. Los scripts compartidos son de lo mejor de este ecosistema, y quienes los escriben suelen ser más cuidadosos que quienes los ejecutan.

No es motivo para leer cada línea. Cinco preguntas en una pasada bastan para atrapar la clase de sorpresa que de verdad duele.

Qué hace Atlas

Atlas toma una instantánea antes de operaciones que cambian el estado del host, así que el camino de vuelta existe sin que usted tenga que acordarse de crearlo. Eso cubre el paso cuatro de la lista anterior, que es el que se salta.

El registro de auditoría anota quién ejecutó qué, cuándo, sobre qué y con qué resultado, lo que convierte "algo cambió el martes pasado" en una respuesta legible en lugar de una investigación.

La cadena de recursos ayuda más después que al decidir: si algo se comporta distinto tras una instalación, el mapa muestra cómo es la máquina ahora de verdad, desde los invitados hasta los discos físicos.

Y donde Atlas instala software por su cuenta, mediante el catálogo de aplicaciones, la versión queda fijada, la fuente es fija y se toma un punto de restauración antes de empezar. Es un camino deliberadamente estrecho y curado, y no sustituye a los scripts de la comunidad. Es simplemente las mismas cinco preguntas, respondidas de antemano para las aplicaciones que lleva.