Script - Instalación y configuración base

Referencia de funcionamiento del script de instalación y configuración base para servidores

Taller Digital

Cómo funciona

Esta referencia describe el funcionamiento del script de instalación y configuración base para servidores, incluyendo la descripción de cada paso y su función.

Paso 1 - Información y confirmación

El script valida las condiciones iniciales antes de continuar. Comprueba que se ejecute como root, detecta el sistema operativo y solicita confirmación al usuario. También identifica el stack activo o, si el servidor está fresco, consulta qué stack se planea instalar.

  • 🎯 Objetivo: Bloquear ejecuciones inválidas, reducir errores operativos y definir el contexto que guía las decisiones posteriores del flujo.
  • 🔀 Decisiones: Si no hay stack instalado, el script pregunta qué stack se planea usar y guarda esa información para ajustar las siguientes ramas.
  • ⚙️ Impacto: No modifica el sistema; solo valida el entorno y recopila información inicial.

Paso 2 - Hostname

El script valida el hostname actual del servidor contra la convención estándar del proyecto. Si el hostname ya cumple con el formato esperado, lo reutiliza; si no cumple, solicita uno nuevo y lo aplica como hostname final del servidor.

  • 🎯 Objetivo: Definir un hostname consistente para identificar correctamente el servidor y reutilizarlo en configuraciones posteriores como SERVER_NAME, servicios internos, logs, backups y reglas de hardening.
  • 🔀 Decisiones: Si el hostname actual es válido, el script lo conserva. Si no es válido, solicita uno nuevo al usuario y lo configura en el sistema.
  • ⚙️ Impacto: Modifica la configuración del hostname mediante hostnamectl y actualiza /etc/hosts para reflejar el nombre final del servidor.

Paso 3 - System Update y Essentials

Actualiza el sistema e instala los paquetes base necesarios para continuar con el resto del flujo. Incluye utilidades estándar, herramientas de diagnóstico, dependencias de compilación, soporte para repositorios externos, compresión, sincronización, firewall persistente y configuración regional.

curl wget git vim htop ncdu net-tools dnsutils
build-essential software-properties-common apt-transport-https
ca-certificates gnupg lsb-release rsync unzip zip sudo locales
iptables-persistent netfilter-persistent
  • 🎯 Objetivo: Dejar el servidor preparado para ejecutar el resto de la automatización sin depender de herramientas faltantes.
  • 🔀 Decisiones: No aplica decisiones complejas; el script instala el conjunto base de paquetes requerido para todos los flujos posteriores.
  • ⚙️ Impacto: Modifica el sistema instalando y actualizando paquetes base mediante apt.

Paso 4 - Timezone y Locale

Configura la zona horaria y el locale del sistema. El flujo base usa America/Santiago como zona horaria y es_CL.UTF-8 como locale principal.

El script verifica que el locale exista, lo genera si no está disponible y aplica la configuración con update-locale para que quede persistente entre sesiones y reinicios.

America/Santiago
es_CL.UTF-8
  • 🎯 Objetivo: Evitar diferencias entre servidores nuevos y antiguos en fechas, ordenamiento, codificación de caracteres y mensajes del sistema.
  • 🔀 Decisiones: Si el locale es_CL.UTF-8 no está disponible, el script lo genera antes de aplicarlo. Si ya existe, lo reutiliza.
  • ⚙️ Impacto: Modifica la configuración regional del sistema, actualiza la zona horaria y deja el locale persistente mediante update-locale.

Paso 5 - Usuario deploy & Hardening SSH

Valida la existencia del usuario deploy. Si no existe, lo crea con directorio home, shell y permisos sudo sin contraseña. Si ya existe, verifica que cumpla con la configuración mínima esperada. Posteriormente endurece la configuración de SSH, deshabilitando acceso por root y autenticación por contraseña, manteniendo acceso mediante llaves públicas. También prepara authorized_keys y sincroniza llaves SSH existentes cuando corresponde.

  • 🎯 Objetivo: Dejar el acceso administrativo preparado para operar mediante llaves SSH, sin depender del usuario root.
  • 🔀 Decisiones: Si el usuario deploy ya existe, se reutiliza y valida. Si no existe, se crea. Si existen llaves SSH válidas en root o en el usuario administrador actual, se reutilizan o sincronizan.
  • ⚙️ Impacto: Modifica la configuración de SSH, crea o valida el usuario deploy, prepara el directorio .ssh y actualiza las llaves autorizadas.

Paso 6 - Firewall base

Aplica la configuración base de firewall mediante iptables. El script limpia reglas previas, define políticas por defecto, permite tráfico de loopback, conexiones establecidas y bloquea SSH a nivel de firewall. Posteriormente persiste las reglas mediante netfilter-persistent o iptables-save.

  • 🎯 Objetivo: Definir una política base de exposición del servidor antes de instalar servicios o aplicaciones.
  • 🔀 Decisiones: Si el servidor utiliza Cloudflare, descarga las IPs oficiales de Cloudflare, permite tráfico web únicamente desde esas redes y guarda la configuración en /etc/tdscripts/cloudflare.conf. Si no utiliza Cloudflare, mantiene los puertos web públicos sin generar configuración específica.
  • ⚙️ Impacto: Reemplaza las reglas actuales de firewall y modifica la exposición pública del servidor.

Paso 7 - Swap space

Valida la memoria disponible y la existencia de swap. Si el servidor tiene menos de 4 GB de RAM, crea o valida un swapfile y configura swappiness=10. Si ya existe swap, verifica que la configuración sea consistente sin recrearla de forma destructiva.

  • 🎯 Objetivo: Mejorar la estabilidad de servidores pequeños durante actualizaciones, compilaciones, backups u otras tareas intensivas.
  • 🔀 Decisiones: Si existe swap previamente configurado, se reutiliza y valida. Si no existe y la memoria es inferior al umbral definido, se crea.
  • ⚙️ Impacto: Puede crear un archivo de swap y modificar parámetros de memoria virtual del sistema.

Paso 8 - Optimizaciones

Aplica configuraciones globales de rendimiento y capacidad del sistema. Incluye ajustes de límites de archivos abiertos y procesos en /etc/security/limits.conf, además de parámetros de red y kernel en /etc/sysctl.conf.

  • 🎯 Objetivo: Permitir una mayor capacidad operativa y un comportamiento más estable bajo carga.
  • 🔀 Decisiones: No aplica decisiones específicas según stack; las optimizaciones se consideran transversales para todos los servidores.
  • ⚙️ Impacto: Modifica parámetros globales del sistema relacionados con procesos, archivos abiertos, red y kernel.

Paso 9 - Migración scripts legacy

Detecta instalaciones antiguas de chbackup u otros scripts legacy. Si encuentra configuraciones compatibles, las migra al nuevo esquema y desactiva tareas programadas antiguas para evitar ejecuciones duplicadas.

  • 🎯 Objetivo: Facilitar la migración al sistema unificado sin perder configuraciones existentes.
  • 🔀 Decisiones: Si se detectan configuraciones legacy compatibles, se migran. Si se detectan tareas programadas antiguas, se desactivan y se informa cuando existan referencias adicionales en el crontab de root.
  • ⚙️ Impacto: Copia configuraciones existentes, preserva permisos sensibles y deshabilita automatizaciones heredadas.

Paso 10 - Stack, features y backup

Define los módulos que se habilitarán en el servidor según el stack detectado y la confirmación del usuario. También selecciona el motor de backup cuando el módulo correspondiente está habilitado.

  • 🎯 Objetivo: Adaptar la instalación al rol real del servidor y evitar configuraciones genéricas innecesarias.
  • 🔀 Decisiones: Permite habilitar módulos como backup, wordpress, monitoring, security y system. Si el módulo de backup está activo, permite seleccionar entre rsync o restic. Si no existe stack detectado, puede solicitar el stack planificado.
  • ⚙️ Impacto: Define las ramas de instalación y configuración que se ejecutarán en los pasos posteriores.

Paso 11 - Instalación de TDScripts

Instala la estructura principal del proyecto en el servidor, incluyendo scripts, librerías, templates de configuración, directorios de logs y permisos de ejecución. También crea el archivo principal de configuración con los parámetros base del servidor.

  • 🎯 Objetivo: Dejar instalado el núcleo operativo de TDScripts.
  • 🔀 Decisiones: Utiliza la información recopilada en pasos anteriores para completar variables como nombre del servidor, tipo de servidor y módulos habilitados.
  • ⚙️ Impacto: Copia archivos al sistema, crea configuraciones base y ajusta permisos de ejecución.

Paso 12 - Configuración de módulos

Genera o prepara las configuraciones específicas de los módulos habilitados en el servidor. Esto incluye archivos relacionados con backup, monitoreo, WordPress, Telegram y otros componentes del sistema.

  • 🎯 Objetivo: Dejar todos los módulos parametrizados antes de instalar tareas automáticas o ejecutar procesos programados.
  • 🔀 Decisiones: Si existen configuraciones heredadas compatibles, pueden reutilizarse o enlazarse mediante symlinks en lugar de duplicar contenido.
  • ⚙️ Impacto: Crea y actualiza archivos de configuración específicos para cada módulo habilitado.

Paso 13 - Instalación de cron jobs

Instala las tareas programadas asociadas a los módulos habilitados en el servidor. Solo despliega cron jobs correspondientes a funcionalidades efectivamente activadas.

  • 🎯 Objetivo: Automatizar tareas operativas como backups, monitoreo y mantenimiento.
  • 🔀 Decisiones: Instala únicamente las entradas relacionadas con las features seleccionadas previamente.
  • ⚙️ Impacto: Crea o actualiza archivos en cron para ejecutar tareas automáticas de forma periódica.

Paso 14 - Configuración SSH de backup

Prepara la conexión SSH hacia el servidor de respaldo cuando el módulo de backup está habilitado. Genera o reutiliza llaves SSH, solicita la información del destino remoto y construye la configuración necesaria para realizar respaldos operativos.

  • 🎯 Objetivo: Dejar el sistema de backup completamente funcional desde el primer día.
  • 🔀 Decisiones: Si ya existen llaves SSH válidas, se reutilizan. Si el motor seleccionado es restic, también configura el repositorio y el archivo de contraseña. Puede detectar automáticamente componentes como MySQL, PostgreSQL o Dokku para ajustar la configuración.
  • ⚙️ Impacto: Genera o reutiliza credenciales SSH, crea configuraciones de backup y puede validar la conectividad remota.

Paso 15 - Stack planeado

Resuelve el stack que tendrá el servidor cuando aún no se encuentra instalado. Utiliza la información recopilada previamente para determinar cómo continuar con la preparación del entorno.

  • 🎯 Objetivo: Asegurar que las configuraciones posteriores se adapten correctamente al stack real que utilizará el servidor.
  • 🔀 Decisiones: Puede ofrecer la instalación automática de Dokku cuando esté planificado pero ausente. Para otros stacks, valida el contexto y continúa con la configuración correspondiente.
  • ⚙️ Impacto: Puede instalar componentes base del stack seleccionado o preparar configuraciones dependientes de éste.

Paso 16 - Seguridad final

Instala y configura las medidas finales de seguridad del servidor una vez que el stack ya se encuentra definido o instalado. Incluye herramientas de protección, endurecimiento adicional y reglas específicas según el tipo de servidor.

  • 🎯 Objetivo: Aplicar configuraciones de seguridad coherentes con el rol real del servidor.
  • 🔀 Decisiones: Ajusta configuraciones según el stack detectado y el tipo de servidor definido en la configuración principal.
  • ⚙️ Impacto: Instala herramientas de seguridad, modifica configuraciones del sistema y aplica reglas específicas de protección.

Paso 17 - Resumen final

Presenta un resumen consolidado de la instalación realizada, mostrando las configuraciones aplicadas, módulos habilitados y tareas pendientes para el administrador.

  • 🎯 Objetivo: Entregar una visión clara y auditable del estado final del servidor.
  • 🔀 Decisiones: No aplica decisiones adicionales; recopila la información generada durante todo el proceso.
  • ⚙️ Impacto: No realiza cambios en el sistema; únicamente muestra información de cierre y próximos pasos recomendados.