PLAN DE MIGRACIÓN FARAMIR → GIMLI

• Origen: faramir (a eliminar al final)
• Destino: gimli (permanece — ya actúa como reverse proxy con SSL para faramir y otras máquinas del grupo)
• Gandalf: NO es origen de datos. Solo se migran ciertas tareas cron puntuales (ver Fase 7).

• El DNS de ambos dominios ya apunta a gimli.
• Gimli ya termina SSL y actúa como reverse proxy hacia faramir para ambos dominios: Internet → gimli (nginx, SSL) → proxy_pass → faramir.
• El objetivo de esta migración es que gimli pase a servir el contenido localmente, eliminando el proxy_pass hacia faramir: Internet → gimli (nginx, SSL) → local (PHP-FPM / archivos).
• Esto significa que el “corte” final NO es un cambio de DNS ni requiere parar nada en faramir de entrada — es simplemente cambiar la directiva proxy_pass por root/fastcgi_pass local en el vhost de gimli, una vez verificado que todo funciona. El rollback consiste en revertir esa línea.

• Dokuwiki: ~1.2 GB (archivos de texto)
• WordPress: ~450 MB (incluye PDFs e imágenes) — estrategia: copia completa (no núcleo limpio + reinstalación de plugins)
• Base de Datos: solo la(s) base(s) de datos de estos dos servicios (MariaDB 10.11.14) — NO –all-databases
• PHP: 8.4.24

• pruebaewelinapmu.my.to (WordPress)
• arocha.my.to (Dokuwiki)

• ✅ Gimli ya es reverse proxy y ya gestiona certificados SSL para estos dominios (verificar en Fase 2, no asumir que faltan)
• ✅ check_sites y scripts comunes ya existen en gimli
• ✅ DNS ya configurado correctamente
• ✅ Ambos servidores tienen la misma versión de Ubuntu
• ⚠️ Nginx (no Apache)
• ⚠️ Gimli aloja otros sitios: cualquier operación de base de datos o nginx debe ser específica a estos dos dominios, nunca global/destructiva

# En gimli
df -h /var/www
df -h /tmp
df -h /home
 
# Espacio requerido: mínimo 3GB libres (datos + backups)

# En faramir
lsb_release -a
php --version
mariadb --version
nginx -v
 
# En gimli
lsb_release -a
php --version
mariadb --version
nginx -v

# En gimli
sudo mkdir -p /var/www/dokuwiki
sudo mkdir -p /var/www/pruebaewelinapmu
sudo chown -R www-data:www-data /var/www/dokuwiki /var/www/pruebaewelinapmu
sudo mkdir -p /tmp/migracion_backup/repos

# En faramir
mkdir -p ~/backup_migracion
cd ~/backup_migracion
 
# 1. Identificar y volcar SOLO las bases de datos relevantes (WordPress + Dokuwiki si usa BD)
sudo mysql -e "SHOW DATABASES;"
grep -i "DB_NAME" /var/www/pruebaewelinapmu/wp-config.php
 
sudo mysqldump --single-transaction --routines --triggers wordpress_db > wordpress_db.sql
gzip wordpress_db.sql
 
# 2. Backup de Dokuwiki
sudo tar -czf dokuwiki_backup.tar.gz -C /var/www dokuwiki
 
# 3. Backup de WordPress (completo)
sudo tar -czf wordpress_backup.tar.gz -C /var/www pruebaewelinapmu
 
# 4. Backup de configuración Nginx (solo referencia, no se copiará entera a gimli)
sudo tar -czf nginx_config_backup.tar.gz -C /etc nginx
 
# 5. Backup de crontabs
crontab -l > crontab_usuario.txt
sudo crontab -l > crontab_root.txt
 
# 6. Backup de listas de paquetes
dpkg -l | grep '^ii' | awk '{print $2}' > paquetes_instalados.txt
dpkg --get-selections > paquetes_selecciones.txt
apt-mark showmanual > paquetes_manuales.txt
 
# 7. Verificar backups
ls -lh
tar -tzf dokuwiki_backup.tar.gz | head -20
tar -tzf wordpress_backup.tar.gz | head -20
zcat wordpress_db.sql.gz | head -50
 
# 8. Copiar backups a gimli
scp *.tar.gz *.txt ubuntu@gimli:/tmp/migracion_backup/

# En gimli
cd /tmp/migracion_backup
ls -lh
md5sum *.tar.gz *.txt  # Guardar checksums para verificar integridad

# En faramir
ls -la /etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/* ubuntu@gimli:/tmp/migracion_backup/repos/

# En gimli
sudo cp /tmp/migracion_backup/repos/* /etc/apt/sources.list.d/ 2>/dev/null
sudo apt update

# En gimli
cd /tmp/migracion_backup
 
# Método recomendado: instalar solo lo que falte (NO usar dselect-upgrade,
# que podría desinstalar paquetes que gimli ya necesita para otros sitios)
comm -23 <(sort paquetes_instalados.txt) <(dpkg -l | grep '^ii' | awk '{print $2}' | sort) > paquetes_faltantes.txt
cat paquetes_faltantes.txt
sudo apt install -y $(cat paquetes_faltantes.txt) 2>&1 | tee instalacion_paquetes.log
 
grep "Unable to locate package" instalacion_paquetes.log
grep "dependency problems" instalacion_paquetes.log

# En gimli
for pkg in nginx php8.4-fpm php8.4-mysql php8.4-xml php8.4-gd \
  php8.4-mbstring php8.4-curl php8.4-zip php8.4-intl php8.4-imagick \
  php8.4-soap php8.4-bcmath mariadb-server mariadb-client certbot \
  python3-certbot-nginx rsync git curl wget unzip zip tar htop vim nano \
  tree ncdu fail2ban ufw composer wp-cli mycli; do
    if ! dpkg -l | grep -q "^ii.*$pkg"; then
        echo "❌ FALTA: $pkg - Instalando..."
        sudo apt install -y $pkg
    else
        echo "✅ OK: $pkg"
    fi
done
sudo systemctl restart php8.4-fpm

# En gimli
sudo systemctl status nginx
sudo systemctl status php8.4-fpm
sudo systemctl status mariadb
sudo systemctl status fail2ban

# En gimli - estos vhosts YA EXISTEN (con proxy_pass a faramir). Localizarlos:
grep -rl "pruebaewelinapmu\|arocha" /etc/nginx/sites-available/
 
# Hacer backup de los vhosts actuales antes de tocarlos
sudo cp /etc/nginx/sites-available/pruebaewelinapmu /etc/nginx/sites-available/pruebaewelinapmu.bak.$(date +%Y%m%d)
sudo cp /etc/nginx/sites-available/arocha /etc/nginx/sites-available/arocha.bak.$(date +%Y%m%d)

# En gimli - lo normal es que YA existan, al ser gimli reverse proxy activo con SSL
sudo certbot certificates | grep -A5 "pruebaewelinapmu\|arocha"
 
# Solo si falta alguno de los dos:
# sudo certbot --nginx -d pruebaewelinapmu.my.to -d www.pruebaewelinapmu.my.to
# sudo certbot --nginx -d arocha.my.to

# En gimli - editar los vhosts para que apunten a local, pero dejar comentado
# el proxy_pass actual hasta la Fase 9 (corte). Ejemplo de bloques a preparar:
sudo nano /etc/nginx/sites-available/pruebaewelinapmu
# root /var/www/pruebaewelinapmu;
# index index.php;
# location ~ \.php$ { fastcgi_pass unix:/run/php/php8.4-fpm.sock; ... }
# ssl_certificate /etc/letsencrypt/live/pruebaewelinapmu.my.to/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/pruebaewelinapmu.my.to/privkey.pem;
 
sudo nano /etc/nginx/sites-available/arocha
# root /var/www/dokuwiki;
# ...
 
sudo nginx -t

# En gimli - probar el vhost local antes de activarlo en producción,
# usando el Host header directamente contra localhost (sin pasar por el proxy_pass):
curl -H "Host: pruebaewelinapmu.my.to" http://localhost/ -k -I
curl -H "Host: arocha.my.to" http://localhost/ -k -I

# En gimli
sudo systemctl start mariadb
sudo systemctl enable mariadb

# En gimli
cd /tmp/migracion_backup
sudo gunzip wordpress_db.sql.gz
 
# Crear la BD si no existe (nombre real obtenido en 0.4)
sudo mysql -e "CREATE DATABASE IF NOT EXISTS wordpress_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql wordpress_db < wordpress_db.sql
 
sudo mysql -e "SHOW DATABASES;"

# En gimli - obtener credenciales exactas de faramir
ssh ubuntu@faramir "grep -E 'DB_NAME|DB_USER|DB_PASSWORD|DB_HOST' /var/www/pruebaewelinapmu/wp-config.php"
 
# Crear usuario en gimli SOLO si no existe ya (gimli aloja otras BD/usuarios)
sudo mysql -e "CREATE USER IF NOT EXISTS 'wordpress_user'@'localhost' IDENTIFIED BY 'contraseña_segura';"
sudo mysql -e "GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wordpress_user'@'localhost';"
sudo mysql -e "FLUSH PRIVILEGES;"

# En gimli
cd /tmp/migracion_backup
sudo tar -xzf dokuwiki_backup.tar.gz -C /var/www/
ls -la /var/www/dokuwiki

# En gimli - copia completa tal cual estaba en faramir
cd /tmp/migracion_backup
sudo rm -rf /var/www/pruebaewelinapmu
sudo tar -xzf wordpress_backup.tar.gz -C /var/www/
 
ls -la /var/www/pruebaewelinapmu

# En gimli - el wp-config.php ya viene incluido en la copia completa.
# Solo hay que revisar/actualizar credenciales de BD si difieren:
sudo nano /var/www/pruebaewelinapmu/wp-config.php
# Confirmar DB_HOST, DB_NAME, DB_USER, DB_PASSWORD

# En gimli
sudo chown -R www-data:www-data /var/www/pruebaewelinapmu /var/www/dokuwiki
 
sudo find /var/www/pruebaewelinapmu -type d -exec chmod 755 {} \;
sudo find /var/www/pruebaewelinapmu -type f -exec chmod 644 {} \;
sudo chmod 600 /var/www/pruebaewelinapmu/wp-config.php

# En gimli - solo si la URL almacenada en BD difiere de la de producción
cd /var/www/pruebaewelinapmu
sudo -u www-data wp option get siteurl
sudo -u www-data wp option get home
 
# Si hace falta corregir:
# sudo -u www-data wp search-replace "http://url-antigua" "https://pruebaewelinapmu.my.to"

# En gimli
crontab -e
 
# ============================================
# CRONTAB DE USUARIO UBUNTU EN GIMLI
# ============================================
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/home/ubuntu/bin
 
# ========== DE GANDALF (a migrar — únicas confirmadas) ==========
12  * * * * check_sites
15 09 * * * check_sites Diario
 
# ========== NUEVAS, DE FARAMIR (Dokuwiki) ==========
01 00 * * * sudo find /var/www/dokuwiki -type d -exec chmod 775 {} \;
02 00 * * * sudo find /var/www/dokuwiki -type f -exec chmod 664 {} \;
08 00 * * * copias/backup
09 00 * * * copias/backup_data
08 01 * * * sudo chown www-data:www-data -R /var/www/dokuwiki
 
# ⚠️ NOTA: "copias/backup" a las 00:08 - confirmar si coincide con una tarea
# ya existente en gimli antes de fijar el horario definitivo (pendiente)
 
# ========== NO INCLUIDAS (no confirmadas por Luis) ==========
# report_fail2ban, "sudo apto update", check_reboot, notify @reboot y el
# "copias/backup" a las 00:30 aparecían en el borrador original bajo "gandalf"
# pero no han sido confirmadas como tareas a migrar. Si alguna de ellas ya
# vive en gimli, no requiere acción; si no, indicar cuáles añadir.

# En gimli
sudo crontab -e
 
# ========== NUEVAS, DE FARAMIR (WordPress) ==========
*/15 * * * * find /var/www/pruebaewelinapmu -type d -exec chmod g+rwx {} \;
*/15 * * * * find /var/www/pruebaewelinapmu -type f -exec chmod g+rw {} \;

# En gimli
ls -la /home/ubuntu/bin/
which check_sites check_reboot notify
which copias/backup 2>/dev/null
 
/home/ubuntu/bin/check_sites
/home/ubuntu/bin/check_reboot

# En gimli
sudo systemctl status nginx php8.4-fpm mariadb fail2ban
sudo netstat -tlnp | grep -E ':(80|443|3306)'

# En gimli
sudo -u www-data ls -la /var/www/dokuwiki/data/
curl -H "Host: arocha.my.to" -I http://localhost/
 
# Navegar manualmente y verificar:
# - Página de inicio, edición de página, archivos multimedia

# En gimli
sudo -u www-data wp --path=/var/www/pruebaewelinapmu core verify-checksums
curl -H "Host: pruebaewelinapmu.my.to" -I http://localhost/
curl -H "Host: pruebaewelinapmu.my.to" -I http://localhost/wp-admin
 
sudo -u www-data wp --path=/var/www/pruebaewelinapmu plugin list
sudo -u www-data wp --path=/var/www/pruebaewelinapmu theme list
 
# Verificar manualmente: frontend, admin, PDFs, imágenes, plugins críticos

# En gimli
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/php8.4-fpm.log
sudo tail -f /var/log/mysql/error.log
 
sudo grep -i error /var/log/nginx/error.log | tail -20
sudo grep -i error /var/log/php8.4-fpm.log | tail -20

copias/backup 2>&1 | head -20
copias/backup_data 2>&1 | head -20

# En gimli - sincronizar cualquier cambio reciente ANTES del corte
# (excluyendo wp-config.php para no pisar credenciales ya ajustadas en gimli)
rsync -avz --delete ubuntu@faramir:/var/www/dokuwiki/ /var/www/dokuwiki/
 
rsync -avz --delete --exclude='wp-config.php' \
  ubuntu@faramir:/var/www/pruebaewelinapmu/ /var/www/pruebaewelinapmu/
 
# Última BD de WordPress
ssh ubuntu@faramir "sudo mysqldump --single-transaction wordpress_db" > /tmp/wordpress_final.sql
sudo mysql wordpress_db < /tmp/wordpress_final.sql

# En gimli - sustituir proxy_pass por la configuración local preparada en 2.3
sudo nginx -t
sudo systemctl reload nginx
 
# Verificación inmediata en producción
curl -I https://pruebaewelinapmu.my.to
curl -I https://arocha.my.to

# En gimli - basta con restaurar el vhost con proxy_pass a faramir
sudo cp /etc/nginx/sites-available/pruebaewelinapmu.bak.$(date +%Y%m%d) /etc/nginx/sites-available/pruebaewelinapmu
sudo cp /etc/nginx/sites-available/arocha.bak.$(date +%Y%m%d) /etc/nginx/sites-available/arocha
sudo nginx -t
sudo systemctl reload nginx
# Faramir no ha sido tocado, por lo que el tráfico vuelve a funcionar de inmediato

# En gimli - monitoreo, faramir se mantiene encendido e intacto como red de seguridad
watch -n 30 'curl -s -o /dev/null -w "%{http_code}" https://pruebaewelinapmu.my.to && echo " - WordPress OK"'
watch -n 30 'curl -s -o /dev/null -w "%{http_code}" https://arocha.my.to && echo " - Dokuwiki OK"'

# En faramir - por precaución, antes de desmantelar
cd ~
sudo tar -czf faramir_final_backup_$(date +%Y%m%d).tar.gz \
  /var/www /etc/nginx /etc/mysql /var/lib/mysql
# Copiar este backup fuera de faramir (a gimli u otro almacenamiento) antes de purgar

# En faramir - solo tras confirmar que gimli funciona correctamente sin incidencias
sudo systemctl stop nginx php8.4-fpm mariadb
sudo systemctl disable nginx php8.4-fpm mariadb

# En faramir - ADVERTENCIA: esto elimina datos de forma irreversible
sudo apt-get remove --purge nginx* php* mariadb* mysql* -y
sudo rm -rf /var/www/* /etc/nginx /var/lib/mysql /etc/letsencrypt

• ☐ Verificar espacio en gimli (mínimo 3GB libres)
• ☐ Verificar versiones de Ubuntu, PHP, MariaDB, Nginx
• ☐ Crear directorios en gimli
• ☐ Backup completo en faramir (BD específica de WordPress, no –all-databases)
• ☐ Copiar backups a gimli

• ☐ Copiar repositorios adicionales
• ☐ Instalar solo paquetes faltantes (sin dselect-upgrade)
• ☐ Verificar paquetes críticos
• ☐ Verificar servicios activos

• ☐ Backup de vhosts actuales de gimli antes de tocarlos
• ☐ Verificar certificados SSL existentes (probablemente ya emitidos)
• ☐ Preparar configuración local en vhosts (sin activar aún)
• ☐ Probar vhosts locales vía Host header, sin afectar producción

• ☐ Restaurar BD específica de WordPress (no todas las BD)
• ☐ Migrar Dokuwiki
• ☐ Migrar WordPress (copia completa)
• ☐ Ajustar wp-config.php y permisos
• ☐ Verificar/actualizar URLs en BD

• ☐ Configurar crontab de usuario en gimli
• ☐ Configurar crontab de root en gimli
• ☐ Resolver duplicado de copias/backup
• ☑ Confirmado con Luis: de gandalf solo se migran check_sites y check_sites Diario
• ☐ Verificar scripts y permisos

• ☐ Servicios activos sin errores
• ☐ Dokuwiki funcional (Host header)
• ☐ WordPress frontend y admin funcional (Host header)
• ☐ Multimedia y plugins verificados
• ☐ Logs sin errores
• ☐ Backups y crons probados

• ☐ Última sincronización desde faramir (excluyendo wp-config.php)
• ☐ Activar vhosts locales en gimli (reemplazar proxy_pass)
• ☐ Verificar en producción inmediatamente
• ☐ Confirmar plan de rollback listo (vhosts .bak)

• ☐ Monitorizar 24–48h con faramir como red de seguridad intacta
• ☐ Backup final de faramir
• ☐ Desactivar servicios en faramir
• ☐ (Opcional) Purgar faramir cuando haya total seguridad

• Backup y migración de datos: horario de bajo tráfico (ej. 2:00 AM)
• Corte (Fase 7.2): bajo riesgo real gracias al rollback instantáneo, pero recomendable en horario de bajo tráfico igualmente

• Documentar accesos de soporte
• Tener acceso a la consola de Oracle Cloud por si falla el SSH