# Crónicas de una maestría: Un SysAdmin que regresa a las aulas

Regresar a las aulas académicas para cursar un Máster Universitario en Desarrollo y Operaciones (DevOps) tiene sus peculiaridades. Después de años administrando sistemas, lidiando con contenedores, SELinux y automatizando infraestructuras complejas, volver a las bases académicas te enfrenta a una realidad curiosa: muchas de las planeaciones de los profesores están diseñadas asumiendo que el alumno usa Windows.

En la materia de *Herramientas de Automatización de Despliegues*, la planeación académica está fuertemente orientada a usuarios de Windows, por lo que el entorno de prácticas oficial requiere el uso de Vagrant y VirtualBox (o WSL para los usuarios de Microsoft). Quienes me conocen saben que mi entorno de trabajo principal es Fedora Linux y que para la automatización de despliegues y virtualización local suelo apostar por `libvirt` + `qemu` (gestionado con scripts en Python, Bash o Ansible).

Sin embargo, la premisa de la asignatura es completamente válida: necesitamos un entorno aislado donde podamos cometer errores sin afectar nuestra máquina principal, y que nos facilite "resetear" todo de forma limpia. Vagrant es ideal para esto porque nos permite definir toda la infraestructura programáticamente.

Así que, en lugar de nadar contra la corriente, decidí documentar mi proceso. Si estás en una situación similar, o simplemente quieres tener este stack funcionando nativamente en Fedora, aquí te comparto cómo lo adapté paso a paso.

1. **Preparando el entorno de desarrollo:** Dado que VirtualBox requiere compilar módulos del kernel específicos para nuestra versión, el primer paso es asegurarnos de tener las herramientas de desarrollo y los headers del kernel instalados.

```bash
$ sudo dnf install @development-tools
$ sudo dnf install kernel-devel kernel-headers
```

2. **Instalación de VirtualBox (El reto de los repositorios):** A diferencia de las herramientas KVM nativas, VirtualBox no se encuentra en los repositorios oficiales de Fedora por temas de licenciamiento. Para instalarlo, necesitamos habilitar el repositorio de RPMFusion.

```bash
# Obtenemos nuestra versión de Fedora (en mi caso, 44)
$ FEDORA_VERSION=$(rpm -E %fedora)

# Instalamos el repositorio RPMFusion Free
$ sudo dnf install "https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-${FEDORA_VERSION}.noarch.rpm"
```

Una vez habilitado, instalamos VirtualBox junto con `akmod-VirtualBox`, que es vital para que los módulos del kernel se recompilen automáticamente cuando Fedora se actualice:

```bash
$ sudo dnf install VirtualBox VirtualBox-server akmod-VirtualBox
```

Para asegurar que los módulos del kernel estén listos y evitar problemas de permisos, forzamos la compilación, reiniciamos el servicio y nos agregamos al grupo vboxusers (para no depender de root al levantar VMs):

```bash
$ sudo akmods
$ sudo systemctl restart vboxdrv.service
$ sudo usermod -a -G vboxusers $USER
```

*(Nota: Cerramos sesión y volvemos a entrar para que el grupo aplique).*

3. **Instalación de Vagrant (y cómo esquivar el error de versión):** Si instalan Vagrant directamente de los repositorios de Fedora (`sudo dnf install vagrant`), se van a topar con este bonito error al intentar levantar una máquina:

```plaintext
Vagrant has detected that you have a version of VirtualBox 
installed that is not supported by this version of Vagrant.
```

**¿Qué pasa aquí?** Fedora empaqueta la versión 2.3.4 de Vagrant, la cual tiene un validador que solo acepta VirtualBox hasta la versión 7.0. Sin embargo, RPMFusion nos acaba de instalar VirtualBox 7.2.22.

La solución limpia es desinstalar la versión de Fedora e instalar el repositorio oficial de HashiCorp, que trae la versión 2.4.9 con soporte actualizado.

```bash
# Removemos el de Fedora si lo instalamos por error
$ sudo dnf remove vagrant

# Agregamos el repo de HashiCorp
$ sudo curl -Lo /etc/yum.repos.d/hashicorp.repo https://rpm.releases.hashicorp.com/fedora/hashicorp.repo

# Instalamos la versión correcta
$ sudo dnf install vagrant
```

Finalmente, como Vagrant en Fedora asume que usarás `libvirt`, le indicamos que VirtualBox será nuestro motor principal agregando esto a nuestro `~/.bashrc`:

```bash
$ echo 'export VAGRANT_DEFAULT_PROVIDER=virtualbox' >> ~/.bashrc
$ source ~/.bashrc
```

4. **Configuración de Red: El error de las Host-Only:** El profesor nos entregó un archivo base de configuración (`Vagrantfile`) que debemos usar y no podemos modificar, ya que él evaluará las actividades clonando nuestro repositorio y ejecutando un simple `vagrant up`.

El `Vagrantfile` de la materia asigna la IP `192.168.33.10` a la máquina. Pero si ejecutamos Vagrant así, VirtualBox nos arrojará este error:

```plaintext
The IP address configured for the host-only network is not within the allowed ranges. [...] Valid ranges can be modified in the /etc/vbox/networks.conf file.
```

A partir de la versión 6.1.28, VirtualBox introdujo una restricción de seguridad en Linux que solo permite crear redes en el rango `192.168.56.0/21`. Como tenemos que cumplir cabalmente con la rúbrica de la materia y no podemos editar el `Vagrantfile`, la solución es configurar VirtualBox para que confíe en el segmento de red de la escuela.

```bash
$ sudo mkdir -p /etc/vbox
$ sudo bash -c 'echo "* 192.168.0.0/16" > /etc/vbox/networks.conf'
```

*(Autorizamos todo el segmento 192.168.X.X para curarnos en salud ante futuras prácticas).*

5. **El Vagrantfile y el Despliegue de la VM:** Con el entorno configurado, revisemos qué hace exactamente el `Vagrantfile` que nos dio el profesor:

```ruby
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
  # Usaremos una imagen base de Ubuntu 22.04 empaquetada por el proyecto Bento
  config.vm.box = "bento/ubuntu-22.04"

  config.vm.define "master" do |master_node|
      master_node.vm.hostname = "master"
      
      # Red Host-Only para comunicarnos con la VM (la que acabamos de autorizar)
      master_node.vm.network "private_network", ip: "192.168.33.10"
      
      # Port Forwarding: El puerto 8080 del anfitrión va al 8080 de la VM
      master_node.vm.network "forwarded_port", guest: 8080, host: 8080
      
      # Configuración de hardware específica para VirtualBox
      master_node.vm.provider "virtualbox" do |vb|
        vb.name = "master" 
        vb.memory = "2024"
        vb.cpus = "2"
      end
    end
end
```

Teniendo este archivo en nuestro directorio, ejecutamos la magia:

```bash
$ vagrant up
```

Vagrant descargará la imagen, configurará las dos interfaces de red (NAT y la Host-Only), mapeará los puertos y arrancará la máquina sin que toquemos la interfaz gráfica de VirtualBox.

Para validar que todo funciona, entramos por SSH:

```bash
$ vagrant ssh master
```

*Si ven el prompt* `vagrant@master:~$...` *¡Misión cumplida!*

6. **Bonus Track: Chuleta de Comandos (Sysadmin Cheat Sheet):** Como sysadmins, no nos gusta estar a ciegas. Si están acostumbrados a usar `virsh`, los comandos por defecto de Vagrant (`vagrant status` o `vagrant global-status`) se sienten algo escuetos. Aquí les dejo una pequeña chuleta para extraer la información "dura" de las VMs:

- **Ver puertos mapeados (Port Forwarding):**

```bash
$ vagrant port
```

*Salida:* `22 (guest) => 2222 (host) / 8080 (guest) => 8080 (host)`

- **Extraer configuración y llaves SSH (Ideal para Ansible):**

```bash
$ vagrant ssh-config
```

- **Diagnóstico profundo directo al motor de VirtualBox:** Como Vagrant es solo un orquestador, podemos usar la herramienta CLI nativa de VirtualBox (`vboxmanage`) para ver qué pasa realmente por debajo.

```bash
# Obtenemos el UUID de la VM corriendo
$ vboxmanage list runningvms

# Consultamos hardware e IPs directamente a VirtualBox
$ vboxmanage showvminfo "98dd9b1a-a263-42d0-af1a-c6a478f63da8" | grep -i 'NIC\|Memory\|Hardware UUID'
```

Con esto, veremos el detalle exacto de las interfaces NAT, Host-Only y los puertos asociados a nivel de hipervisor.

#### Lo que sigue: Preparando el terreno para Puppet

Con este entorno 100% funcional en Fedora, ya tenemos las bases de la materia cubiertas. En las próximas entregas de esta serie, pasaremos al siguiente nivel de la orquestación: instalar y configurar Puppet para automatizar el estado interno de estas máquinas de forma programática.

¡Nos leemos en el próximo despliegue!