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
hostnamectly actualiza/etc/hostspara 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-8no 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
deployya 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.sshy 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,securityysystem. Si el módulo de backup está activo, permite seleccionar entrersyncorestic. 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.