--- title: Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian date: 2026-07-21 author: Osiris Alejandro Gomez (OSiUX) osiux@osiux.com og_title: Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX og_description: Transcripción de la charla Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian en DebConf26 en Santa Fe og_type: article og_url: https://osiux.com/2026-07-21-debconf26-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.org og_site_name: OSiUX og_locale: es_AR og_image: https://filiales-gnu-linux.g.coop.ar/img/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1.png --- - [index](index.md) - [about](about.md) - [archive](archive.md) - [charlas](charlas.md) - [docs](docs.md) - [links](links.md) - [dot](dot.md) - [git](git.md) - [img](img.md) - [plt](plt.md) - [tty](tty.md) - [uml](uml.md) ## Resumen Este proyecto gestiona alrededor de `3,000` servidores *Debian* y `3,000` estaciones de trabajo *basadas en Debian* a lo largo de `300` sucursales. Se trata de un estudio de caso real sobre cómo aprovisionar, instalar, configurar y mantener miles de sistemas Debian y basados en Debian mediante Software Libre. La infraestructura combina *Ansible*, *AWX*, *Proxmox*, *PXE*, *FreeIPA*, *GitLab* `CI/CD` y varias capas de caché para automatizar el despliegue y mantenimiento de aproximadamente `6,300` sistemas a lo largo de cientos de sucursales. El proyecto comenzó en 2018 y ha evolucionado continuamente conforme cambiaron la infraestructura, el hardware, los requisitos de seguridad y el *Stack* de *Software*. ## Charla ```{=html} ``` - Demo Site: [](https://filiales-gnu-linux.g.coop.ar/) - Original Video: [`WebM (298 MB)`](https://meetings-archive.debian.net/pub/debian-meetings/2026/DebConf26/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1.webm) - Subtitle Video: [`WebM (298 MB)`](https://filiales-gnu-linux.g.coop.ar/videos/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1.webm) - Spanish Subtitle: [`SRT (50 KB)`](../videos/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1-es.srt) [`VTT (44 KB)`](../videos/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1-es.vtt) - English Subtitle: [`SRT (48 KB)`](../videos/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1-en.srt) [`VTT (42 KB)`](../videos/debconf26-265-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.av1-en.vtt) - English Slides: [`PDF (357 KB)`](2026-07-21-debconf26-how-to-provision-install-configure-and-keep-thousands-of-debian-and-debian-based-systems-updated.pdf) - Spanish Slides: [`PDF (357 KB)`](2026-07-21-debconf26-como-aprovisionar-instalar-configurar-y-mantener-actualizados-miles-de-sistemas-debian-y-basados-en-debian.pdf) This *post* has an *English* translation at [*How to Provision, Install, Configure, and Keep Thousands of Debian and Debian-Based Systems Updated*](2026-07-21-debconf26-how-to-provision-install-configure-and-keep-thousands-of-debian-and-debian-based-systems-updated.html) ## Temas - *Debian* - *Ansible* - *AWX* - *Proxmox* - *PXE* - *FreeIPA* - *GitLab* `CI/CD` - Infrastructura como Código - Administración `GNU/Linux` de puestos de trabajo - Deploy Automatizado ## *DebConf26* Este año al asistir a mi primera `DebConf` [^1], la `DebConf26` [^2] en *Santa Fe*, aproveché a dar la charla `"Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian"` como actualización de la charla que presenté en `nerdearla` [^3] edición 2022 que se llamaba `"Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX"` [^4] ## *gcoop* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con logotipos de Ansible, gcoop y AWX. ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-01-ans-awx.png)](https://filiales-gnu-linux.g.coop.ar/) Me llamo *OSiRiS*, me dicen `OSiUX` en la comunidad, trabajo en `gcoop` [^5] que es una *Cooperativa* de *Software* *Libre*, es decir, que trabajamos exclusivamente con `SoftwareLibre` [^6] y de manera horizontal, la organización. No tenemos jefes, no tenemos empleados. Vinimos cinco socios y socias de *gcoop*, al evento, es nuestra primera vez en *DebConf*. Esponsoreamos este evento y le damos gracias a `Debian` [^7] porque tenemos `20` años trabajando con *Software* *Libre* y sin *Debian* no hubiera sido posible. ## Alcance del Proyecto y Evolución (2018-Actualidad) Voy a mostrar una actualización de una charla previa que ya di en el `2022`, que se trata del proyecto de migración de *Filiales* /GNU//Linux del `Banco Credicoop Cooperativo Limitado` [^8], es un *Banco* cooperativo. Y voy a tratar de hacer una *review* del proceso de migración rápidamente y después vamos a ver las diferencias en los últimos años. Este proyecto... Básicamente es un proyecto de Infraestructura como Código utilizando `Ansible` [^9] y `AWX` [^10]. *AWX* es una plataforma *Web*, que es una interfaz gráfica por un lado de *Ansible*, pero por otro lado permite orquestar y administrar y gestionar todos los *playbooks* de *Ansible*. Y esto se hizo para *Banco* *Credicoop*. Desde *gcoop*. ## Laboratorio para la viabilidad del proyecto usando *Software* *Libre* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación del laboratorio del proyecto utilizando software libre, logos VPN, Proxmox, VMs con Debian, Workstations con Ubuntu, Ansible, GitLab e integración entre FreeIPA con ActiveDirectory ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-02-lab-tec.png)](file:img/debconf26/debconf26-filiales-gnu-linux-02-lab-tec.png) Bueno, al principio del proyecto, lo que teníamos que era, aunque fueron `6` meses, fue tratar de descubrir qué herramientas del ecosistema de *Software* *Libre* nos permitían llevar adelante toda la migración de la infraestructura de un *Banco* a lo largo y a lo ancho de todo el país de Argentina. Y lo que fuimos encontrando, bueno, es que la herramienta de automatización era *Ansible* porque ya la veníamos utilizando. Que íbamos a usar `GitLab` [^11]. Que para la autenticación de *ActiveDirectory* dentro, en los Linux, íbamos a usar *IPA*. *AWX*, obviamente todos los servidores iban a usar `Proxmox` [^12]. Nosotros ya veníamos hace años trabajando con *Proxmox*. Las *VMs* dentro de los *Proxmox* iban a ser *Debian*, obviamente. Y bueno, los puestos de trabajo, por una cuestión de que eran `3.000` puestos de trabajo y por una cuestión de soporte, elegimos una distribución basada en *Debian*. Este... Un poquito más actualizada. Y lo que teníamos ahí, no se ve muy bien ahí, pero lo que se está moviendo es que ...por debajo son todos los componentes, es una línea de tiempo, todos los componentes de dependencia que utilizamos nosotros, que se están actualizando en todo el mundo, todo el tiempo. O sea, en ese momento, en tal mes, salió una nueva versión de un componente y de otro componente y de otro componente. Y esto es a medida que vos estás pensando cómo vas a hacer la cosa, se va actualizando todo el ecosistema. Entonces es una problemática a resolver. ## Aprovisionamiento automatizado de Debian con PXE y PVE (Proxmox Virtual Environment) ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentamos la implementación automatizada de Debian y Proxmox con PXE y AWX usando GitLab como fuente de verdad ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-dep.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-dep.png) Pero bueno, a lo que llegamos es que en *Desarrollo* logramos orquestar una idea de *deploy*, que básicamente es, tenemos un *AWX*, a ver si lo puedo señalar así, esto es un *AWX*, y este *AWX*, su fuente de verdad es un *GitLab*, entonces es decir, *AWX* lee desde *GitLab* todo lo que sería... O sea, *playbooks*, y el primer paso es deployar la *iDRAC*. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación con sitio web de iDRAC con almacenamiento RAID y VNC con servidor DELL de arranque ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-pve.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-pve.png) La `iDRAC` [^13] es la computadora, de la computadora, dentro de los servidores *Dell* que utilizamos antes de que tenga nada el servidor, hay una compu que se llama *iDRAC*, por un protocolo que se llama *Redfish*, hicimos unos *playbooks* que *AWX* se conecta a la *iDRAC* y lo que hace es particionar el disco, configurar la *BIOS* y reiniciar en `PXE` [^14]. O sea, una compu nueva, recién salida de la caja. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación con depuración de arranque PXE para instalar Debian en servidor Dell ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-pxe.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-pxe.png) E inmediatamente eso va a terminar generando desde un *Proxmox*, va a terminar generando otro *Proxmox*. Dentro de ese *Proxmox* nosotros tenemos varias *VMs*. Una de esas *VMs* es un servidor *PXE*, que no veo nada acá, pero debe ser este. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación con depuración, arranque PXE e instalación desatendida de debian netinstall ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-net.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-net.png) Tenemos un servidor, bueno tenemos una *CDN*, que es un *Server* de procesamiento, un *Nginx* que tiene todos los recursos, que a su vez es *Proxy* de otro, que es un *Apache*, y un servidor que *Replica* estos *Datos*. Bueno, esto se hace de manera automatizada y desatendida, sin intervención del operador, es decir que viene un servidor recién salido de fábrica, se abre la caja, se instala *power*, se instala Red, y desde *AWX* se lanza un *script*, esta es la infraestructura de *AWX*, perdón, la de *Proxmox*, íbamos a ver, acá se ve, cómo se lanza, y esto es solo para monitoreo, digamos, se hace todo de manera desatendida y el operador no necesita ver nada funcionando, el *AWX* deploya el *Proxmox* vía *PXE*, en realidad son varias etapas, primero deploya un *Debian* *NetInstall* totalmente desatendido, o sea, no hay que tocar nada, directamente en modo, sería *OEM*, configura todo lo necesario para que ese servidor esté operativo, y cuando termina, en un hook, al final del *Debian* NetInstaller, hicimos un *script* que lo que hace es, toma la *MAC* de ese equipo, que es única, y la de alta en el inventario de *AWX*. Entonces esa máquina, que acaba de recibir una *IP* random, ya sabemos cuál va a ser su *IP*, cuál es su *iDRAC*, queda permanentemente, en todos los años que va a tener ese servidor, referenciado a esa *MAC* y a un número de serie que tiene el servidor propio del *iDRAC*. Entonces, de esa manera es fácil identificarlo. Ahí a la izquierda, lo único que hay es el *debug* de lo que se va viendo en el servidor *PXE*, y como ven, el servidor está en el servidor *PXE*, el servidor se instala solo, no hay intervención manual y termina instalado, es un *Debian*. El siguiente *playbook* que se lanza a *AWX*, convierte a ese *Debian* en un *Proxmox*, también de manera desatendida. Es decir, nosotros no instalamos *Proxmox*, nosotros instalamos *Debian* y lo convertimos en *Proxmox*. Esa es una ventaja de que *Proxmox* es una distribución basada en *Debian*, que lo único que cambia es agregar un *repo*. Y listo, se configuran todos los paquetes necesarios. Y cuando termina de configurarse, en un *Proxmox*, lanzamos otro *playbook* que lo que hace es crear las *VMs*, y otro *playbook* más que lo que hace es crear los servicios dentro de cada *VM*. Todas las *VMs* que usamos son *KVM*. Esto es un *Banco*, necesita mayor robustez en la seguridad, entonces todos los equipos están actualizados. Ahí a la izquierda se ven la creación de todas las distintas *VMs*. Hay `10` *VMs* por servidor y hay, más o menos redondeando, unos `300` servidores físicos. Eso nos da un total de `3.000` *Debian*. Instalados de manera automatizada por todo el país. ## Workstations ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación de la ejecución de un playbook de AWX a una estación de trabajo virtual en una VM de desarrollo dentro de Proxmox ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-wlp.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-wlp.png) *Workstations* hicimos una imagen. Ahí estamos viendo una *Workstation* virtual de prueba, de *Desarrollo*, dentro de un *Proxmox*. Y lo que hacemos es generar una imagen base, también una *NetInstall*, en este caso basada en una *distro* basada en *Debian*. Y después configuramos, también de la misma manera, con un *script*. Toma el *hostname* del equipo, que se puede configurar después o reconfigurar en el lugar de destino. Se da de alta en el inventario y queda disponible también con un número de serie del fabricante. Son todas *HP* *Workstations*. Las podemos identificar unívocamente, aunque cambie la *MAC* address en algún momento. Siempre es el mismo dispositivo. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación del inventario de AWX donde se ven las variables de conexión de una estación de trabajo y al mismo tiempo se muestra la información del host dentro del escritorio de la estación de trabajo virtual en una VM de desarrollo dentro de Proxmox ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-03-dev-wst.png)](file:img/debconf26/debconf26-filiales-gnu-linux-03-dev-wst.png) La interfaz gráfica del *AWX* es básicamente una página *Web* que está hecha en *Django*. Y hay un montón de operadores que trabajan lanzando distintos *playbooks* que hacemos, para que esto quede operativo. Y también el servidor *PXE* lo que hace es tomar imágenes de *Workstations*. O sea, vos podés agarrar una *Workstation* en el lugar, si se desconfiguró, le pasó algo, no anda, no importa. Se reconstruye vía *PXE* la imagen completa de la *Workstation*. No se pierde tiempo. Tiene tiempo viendo qué le pasa. No se entra manualmente al equipo. Se reconstruye desde cero. ¿Por qué? Porque no hay *Datos* locales dentro de la *Workstation*. Los *Datos* están en un servidor *NFS* kerberizado dentro de la misma red de la *Filial* donde estamos. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación del despliegue de varias estaciones de trabajo usando GitLab, AWX y mostrando el flujo de autenticación entre estaciones de trabajo y FreeIPA integrado en el cluster ActiveDirectory ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-04-dep-wst.png)](file:img/debconf26/debconf26-filiales-gnu-linux-04-dep-wst.png) ## Desafíos de Escala Bueno, y similar a los *Proxmox*, tenemos las *Workstations*. Las Para el *deploy* en la *Filial*, es un poco más complejo porque el *deploy* de la *Filial*, dijimos, tenemos `3.000` puestos de trabajo. De estos `3.000` puestos de trabajo no hay usuarios en las *Workstations*. Es decir, en esas *Workstations*, si miran el `/etc/passwd`, no hay ningún usuario local, fuera de los que ya vienen en el sistema. Lo que utilizamos es un cliente de *FreeIPA* que se conecta al *IPA* y del *IPA* se conecta a los `4` *ADs* que tenemos. Y toman al vuelo esos usuarios del dominio directamente. Y por este motivo cada *Workstation* tiene que estar enrolada también al dominio. Pero lo que se hacen es que se enrolan al dominio de *FreeIPA*. Y el *FreeIPA* se conecta al dominio de *FreeIPA*. Y el *FreeIPA* tiene una relación de confianza con el dominio de *ActiveDirectory*. O sea, es como un subdominio. Y lo que permite es que todos esos usuarios, su *password* esté en el *AD*, que es la infraestructura del *Banco*, sin haberles cambiado nada. Para ellos es transparente. Y desde todos los equipos /GNU//Linux usan el mismo usuario directamente. Lo que está en el medio y que permite esto se llama *FreeIPA*. Y para acelerar el proceso de despliegue lo que tenemos de nuevo, es una caché de caché de caché. Tenemos varios *Proxys*. Inicialmente teníamos *Apt-Cacher* de *Debian*. Ahora ya hay unos *mirrors* de *Debian* también. Y después tenemos *Nginx* de *Nginx* y *Squid* de *Squid* de *Squid*. Para que esto funcione a lo largo y a lo ancho de todo el país. ## Diversidad de *Hardware* en las *Filiales* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title presentación con las cantidades totales de hardware, 3000 estaciones de trabajo HP ProDesk 400 G5, 300 servidores Dell PowerEdge R340 y 3000 Debian/KVM virtuales en Proxmox ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-05-stg-hwd.png)](file:img/debconf26/debconf26-filiales-gnu-linux-05-stg-hwd.png) Acá un poquito el hardware con que se comenzó. `3.000` *HP* *ProDesk*. `3.000` servidores *Dell*. Perdón, `300` servidores *Dell*. `3.000` *Debian* virtuales. Después se fue cambiando un poquito. Pero además después nos encontramos con `3.500` periféricos distintos. Cosas raras como un escáner de cheque o una impresora de *tickets*. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con las cantidades totales de periféricos i3581, impresoras, escáneres, impresoras de tickets, terminales de autoservicio, etc. ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-05-stg-prn.png)](file:img/debconf26/debconf26-filiales-gnu-linux-05-stg-prn.png) ## *Stack* inicial del proyecto ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con el stack tecnológico: Ansible v2.9, AWX v9.3, Debian 10.9, Proxmox v6.3, FreeIPA v4.6 y Ubuntu 18.04 ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-05-stg-ver.png)](file:img/debconf26/debconf26-filiales-gnu-linux-05-stg-ver.png) Esto es lo que fue originalmente la infraestructura con la que comenzó el proyecto en el `2018`. Esto fue variando. Algunas *VMs* fuimos cambiando también. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con el personal en cada etapa: laboratorio (2), desarrollo (3), implementación (4), puesta en escena (4), producción (5), soporte (5), siguiente (5) ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-05-stg-ops.png)](file:img/debconf26/debconf26-filiales-gnu-linux-05-stg-ops.png) ## Repositorios de *playbooks* y *roles* de *Ansible* liberados! ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con una lista de repositorios git de utilidades, roles y manuales de estrategias de Ansible publicados en https://gitlab.com/gcoop-libre y https://github.com/gcoop-libre ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-05-stg-git.png)](file:img/debconf26/debconf26-filiales-gnu-linux-05-stg-git.png) ## Graficar logins del dominio y sincronización de cache de *FreeIPA* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentación con seguimiento de inicio de sesión de dominio FreeIPA y sincronización de caché mediante el script ipa-sss-syn ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-06-sup-ipa.png)](file:img/debconf26/debconf26-filiales-gnu-linux-06-sup-ipa.png) Y rápidamente los que nos encontramos con problemas. Problemas de escala. Esto es un gráfico de los intentos de *login* durante el día. Y lo que van a ver es que hay un problemita acá a las `10` de la mañana. Es decir, `3.000` personas se quieren loguear a las `10` de la mañana. Se ven igual cuando bajan después a partir de las `4` de la tarde. Ya empiezan a ir los *logins*. Y bueno, acá hay un problema de *delay*, de caché. Y de otros problemas que es, imagínense con `3.000` usuarios, con las políticas robustas de seguridad de un *Banco*, todos los días vencen muchas contraseñas y las tienen que recambiar y todo eso. Y ese recambio lo tienen que hacer desde la pantalla de *login* de la *distro* nuestra. Es decir, directamente desde ahí. Se le dice que la contraseña venció y en ese momento le pide la vieja, dos veces la nueva. Uno a la mañana temprano se confunde. Eso genera otra contraseña más. Pero en esto... Ahora les voy a contar que se trabajó para mejorarlo. ## Automatizar la implementación de los recursos de *AWX* con *GitLab* `CI/CD` y *Ansible* *Tools* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title Presentamos la automatización de la implementación de recursos AWX con GitLab CI/CD y herramientas Ansible ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-07-nxt-awx.png)](file:img/debconf26/debconf26-filiales-gnu-linux-07-nxt-awx.png) Y entonces, para hacerlo también, bueno, parte de la automatización que logramos es, en lugar de ir a *AWX*, que es una interfaz gráfica, y hacer clics para crear *playbooks*, para crear *workflows*, para crear *inventarios*, y dar permisos y todo eso manualmente, lo que hicimos es un *repo* *Git* que se llama *AWX*, un *repo* que se llama *Inventory*, y son todos archivos *JSON* o *YAML*, que la *CI* de *GitLab* directamente las verifica y las deploya en un *AWX* de *Desarrollo* de manera inmediata a medida que hacemos el *Git* *push*. Entonces podemos de esa manera tener todas las etapas verificadas y deployadas automáticamente en un *AWX* de *Desarrollo* para pruebas. En el *AWX* de Producción, este *deploy* se dispara manualmente, digamos, pero hace las mismas instancias. Eso nos garantiza tener toda la infraestructura como código versionada. ## Vista global de hosts gestionados centralizadamente desde *AWX* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title gráfico con vista global de todos los hosts administrados centralmente desde AWX ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-08-prd-all.png)](https://filiales-gnu-linux.g.coop.ar/prd.html) Y para darnos una idea de la escala del proyecto, esto es una visión de lo que es la infraestructura del *Banco* productiva. Dije, son más o menos unas `300` *Filiales*, distribuidas por casi todas las provincias del país. Y ahora, si vemos de cerca esto, vamos a entender un poquito más, todos estos son *hosts*. Y todos estos *hosts* están controlados por uno que está por acá, que ya lo voy a encontrar, ahí. Este que está acá es la *AWX*, es una sola virtual, ni siquiera es de un equipo físico, que controla a todas las demás y deploya a todas las demás. Obviamente no las deployan todas juntas, las van deployando por etapas. ```{=org} #+ATTR_HTML: :width 640 :height 360 :title ampliación de una parte del gráfico con una vista global de todos los hosts administrados centralmente desde AWX ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-08-prd-awx.png)](file:img/debconf26/debconf26-filiales-gnu-linux-08-prd-awx.png) Y lo que tenemos es que cada línea, por ejemplo acá, vamos a ver, esto es la provincia de... la provincia de *Santa* *Fe*. Y voy a tratar de iluminar un poquito. Todo esto son los equipos de todas las distintas *Filiales* de toda la provincia de Santa Fe. Y si nos acercamos a uno, acá, por ejemplo, es la `f0372`. Y bueno, dentro de lo que es el concepto de esa *Filial*, tenemos una caché local, que es una *CDN*, el `PVE`, que es el servidor *Proxmox*, el `REP`, que es el *file* *Server*, un *NFS* *kerberizado*, una máquina de *log*, que es la que recibe los *logs* de todas las demás y los reenvía. Inicialmente esto lo hacíamos con `rsyslog`. Hay un nodo de `VPN` que nosotros no intervenimos, pero hicimos la instalación automática, que básicamente eso lo configura el personal del *Banco*. Tenemos un *Apt-Catcher*, ahí, local, dentro de la *Filial*. ¿Qué más tenemos? Bueno, esta de *Git*, al final la volamos. El servidor de impresión, que es un `CUPS`, donde están configuradas todas las impresoras del lugar. Y después, acá está la representación de las distintas impresoras de esa *Filial*. Y después vamos a tener los distintos puestos de trabajo. Y finalmente el resto de equipamiento que hay ahí. Impresoras de *ticket* y demás. Y esta infraestructura, esta infraestructura se repite por todo el Banco. O sea que esto, si no lo haces de manera automatizada, es imposible de mantener. Y lo que logramos con esto, que es que esta infraestructura de *AWX* nos permita que ya no hace falta loguearse un equipo manualmente y ver lo que pasa. Hay un *playbook* de *AWX*, de la *CasaCentral*, donde ya hay una plantilla para solucionar cada problema. Y se corre esa plantilla y queda un registro de todo lo que sucede, un *log* *traceable*. Obviamente hay distintos niveles de permiso. ¿Quién puede hacer eso? ¿Quién no lo puede hacer? Horarios, por ejemplo. No sé, si queremos que todos los equipos se apaguen a cierta hora, bueno, hay una plantilla que establece un `poweroff` a cierto horario en cada equipo. Por ejemplo, y lo lanzás. Puedes hacer cosas como barridos de `SNMP` para saber si ciertos equipos están vivos o muertos. Es decir, todo eso queda todo en una, finalmente una base de *Datos* *PostgreSQL*, manejada desde *AWX*. ## Vista global del catálogo de *Roles* y *Playbooks* en *AWX* ```{=org} #+ATTR_HTML: :width 640 :height 360 :title gráfico con vista global de todos los playbooks y roles en el catálogo de AWX ``` [![](tmb/debconf26/debconf26-filiales-gnu-linux-09-ans-awx.png)](https://filiales-gnu-linux.g.coop.ar/ans.html) Y si quisiéramos ver un poquito lo que es, esta es, como una visión de todos los *playbooks* que hay en *AWX*. Acá está nuestro *AWX*. Acá yo intenté organizarlos un poquito. Acá tenemos el *iDRAC///Redfish*. `rsyslog`, *CDN*. Bueno, acá tenemos el inventario. No sé si se llega a ver algo. Ahí no se llega a ver. Ni yo lo veo acá tampoco. Pero, a ver, vamos a ver por acá. Acá, por ejemplo, tenemos un *rol* que clona un *VM* de *KVM* en *Proxmox*. Entonces hay un role para eso nada más. Por acá vamos a ver más. Este *rol* lo que hace es crear una *VM* *KVM* de *Proxmox* desde una `ISO` directamente. Y es una `ISO` que ya es desatendida. O sea, no hay que hacer nada. Eso es para la `VPN`. Un role de *Proxmox* para configurar el `cloud-init` de cada una de las *VMs*. Usamos la imagen *OpenStack*. Digamos cloud, pero sin cloud. Local. Para hacer un qm *Restore*. O sea, podemos restaurar una *VM* desde un *Backup* y sale andando. Y así, hay *playbook* para todo. ## Actualizaciones Recientes, Seguridad y Migración a OpenShift Bueno, esto es más o menos lo que fue el proyecto de migración. Voy a tratar de resumir, y avanzar con lo nuevo. Un poco la diferencia de esto del `2022` al `2026` en que se estuvo trabajando. Bueno, hay más de `200` repositorios de *Git* para controlar todo esto. Ahora lo que se está haciendo, parte de lo que se hizo en realidad, se trabajó mucho en seguridad informática. Se cambió de `rsyslog` a `auditd`. Se integró `NUT` para las `UPS`, para tener monitoreo de `UPS`. Se está trabajando en actualizar los *Debian* de esas virtuales de `10` a `13`. Esto, recuerden, empezó en `2018`. La automatización de *FreeIPA*, ahora se hizo un nuevo... ...o sea, lo que teníamos actualmente en producción era solo una *VM* grande de *FreeIPA*. Y como el *Banco* tiene *OpenShift*, estamos haciendo una migración del *FreeIPA* a *OpenShift*. También todo con *playbook* automatizado. Acá como un resumen de todo lo que se hizo de *Seguridad* *Informática*. Es un rol que se conecta en equipo y dice qué está bien, qué está mal. Algunas cosas las puede corregir y otras simplemente dice esto no puede salir a producción así. Se trabajó también con el tema del *Booteo* del *Kernel* para que aparecieran unos modelos de servidores y para identificar las placas de red y que funcione todo solo y el reparticionado de discos y en fin, hay distintos niveles de servidores. La regeneración de todas estas imágenes. Todo lo que sería el ciclo de vida de las *VMs* que hay que ir de alta. Varias que se bajaron. Otras que cambiaron que no necesitaban por ahí un disco secundario. El orden en que se inician. Un reporte de cuál es el estado de todo esto. Todas esas *VMs* y actualizaciones. Bueno, ahí un poquito de lo que decía de versiones de servidores. ## Desafíos de *Workstations*, Navegadores y Restricciones de Usuario Y vamos a avanzar que estamos corto de tiempo. En *Workstation* es lo que más se viene trabajando porque se había originalmente trabajado con una *Workstation* `18.04` y ahora se pasó a `24.04` si no me equivoco. Y entonces además hay unos problemas que tenían. Recuerden esta infraestructura original no era *GNU* y trabajaba con *Firefox* `9`. Nosotros lo llevamos a `v68` y ahora lo llevamos a `v120` y se están haciendo pruebas con `v140`. El problema no es tanto el entorno, sino que el problema es el ecosistema de todas las aplicaciones internas que no están actualizadas y no funcionan. Básicamente no es tarea fácil. Entonces por un momento convivieron más de una versión de *browser*. Eh... Y eso era otro desafío. Y bueno, también cuestiones de actualizar la versión de *Kernel*. Hubo que hacer el parcheo de algunos *CVEs* difíciles que estuvieron saliendo hace poco. Bueno, en algún momento también se probó *Chrome* como alternativa para algunos sitios. Hacemos con un *playbook* toda la configuración de policies de configuración de *Firefox*. El usuario básicamente no puede hacer nada. O sea, como... No puede ni cambiarle el fondo de pantalla. Este... Pero bueno, es la manera de mantener `3.000` usuarios. Bueno, entonces... Nadie entra a un equipo a configurarlo! Desde *AWX* se lanza un *playbook* directamente. Y, eh... Bueno, el tema de *WakeOnLAN*, integración, actualización del *Kernel*, correcciones de `sftp`. Es decir, bueno, todo lo que llevara a la nueva versión de *IPA*. Trabajamos bastante con *AppArmor* para restringir... Este... Algunas cosas que son importantes. El manejo del *login*. Manejo también de poder cambiar la contraseña. Este... Bueno, *Backup* y todo eso. Y, eh... Vamos a ver... Un poquito de *AWX* acá. Eh... Bueno, hay `198` *releases* desde que terminamos de migrarlo. Porque como toda infraestructura grande, cuando terminás de migrarlo tenés que empezar a migrar de nuevo. Básicamente. Está en constante cambio. Y, bueno, todo el tiempo después además van saliendo nuevas necesidades... Eh... Bueno, tenemos *CloneZilla* para esto que decía de arrancar un equipo con una imagen ya armada. Este... Y solucionar los problemas. Este... Acá, eh... Perfiles isolados. Este... Aislados unos de otros por tema de configuraciones. ## *CCTV* Se agregó una parte de *CCTV*. Equipos que están integrados a los *DVR* de las cámaras de seguridad. Este... Entonces, bueno, eso es como un nuevo inventario que se agrega. ## *HP* *Linux* *Tools* Eh... *HP* *Linux* *Tools*, por ejemplo, eso... Un detalle es en un momento, eh... Un equipo se colgaba y se colgaba en situaciones extrañas. Tardamos en investigar qué sucedía. Tenía que ver con una configuración de ahorro de energía de la *BIOS*. Y entonces la solución era simple. Era entrar a `3.000` equipos, cambiar la configuración de la *BIOS* y reiniciarlos. Ya está. Es muy simple. ¿Necesitás `3.000` técnicos? o Este... Tantos como *Filiales* en todo el país. Es imposible. Y, bueno, ahí, este... Yo me puse a investigar el *FTP* de *HP*. Y encontré un loco en Linux que tenía una herramienta que lo que permite es escribir un archivo en la *UEFI*. Este... Con la configuración de la *BIOS* que la va a tomar el próximo `reboot`. Esto hay que compilar un módulo del *Kernel* y demás. Y... Eh... Le dijimos que pidan permiso a *HP* y que garanticen que no se iban a convertir en una *BIOS*. Que se convertir en `3.000` ladrillos. Este... Dijeron... ¡Sí! Y, bueno, nosotros hicimos varias pruebas. Nunca nos pasó. Así que salieron andando todo bien. Eh... Y eso permite que, bueno, de nuevo, de administración centralizada, inclusive podrías cambiar la *password* de la *BIOS* de todos los equipos de manera centralizada y remota. Así que es súper útil. Eh... Bueno. Acá, por ejemplo, este... Modificación de los *tokens*, de *Git* y... Hay un montón de cosas. ## *Slides* en la *web* Esto... En la *URL* que está ahí abajo, [](https://filiales-gnu-linux.g.coop.ar) van a estar todo esto disponible. Así que si lo quieren ver en detalle. ## Cierre Eh... Y como quedan cinco minutos, este... Si les parece, cierro acá y pregunten lo que sea... Porque no vamos a llegar a ver todo. ## Pregunta 1 *ActiveDirectory* *Público*: Hola. Eh... ¿Los *ActiveDirectory* que usan son *Windows* o usan también *Windows* *Server*? *OSiUX*: Sí, es infra del Banco. Este... Que ya tenía preexistente. Y que no la iban a cambiar. El desafío fue que todos esos usuarios funcionen en los nuevos puestos de trabajo. Este... Y funciona. ## Pregunta 2 `rsyslog` vs `auditd` *Público*: Primero que nada, impresionante. *OSiUX*: Gracias a la comunidad del *Software* *Libre*! Eh... Nosotros juntamos las piezas. *Público*: Le sacaron todo el jugo a *Ansible*, pero no pensé que se pudiera hacer tanto realmente. Tenía una pequeña duda en particular con algo que vi. Dijiste que cambiaron de `rsyslog` a `auditd` *OSiUX*: Sí. Fue solicitud de seguridad informática. *Público*: Pero la intención... Digamos, `rsyslog` loguea un nivel, llamamos aplicación, tal vez un nivel de sistema. Y `auditd` apunta un poco más a las *syscalls* del mismo sistema. *OSiUX*: Sí, pero permite más detalle. Podés especificar exactamente qué partes querés. *Público*: No, no, no. Entiendo. Mi duda es, ¿ustedes están logueando las *syscalls* de `3.000` clientes? *OSiUX*: Eso es... No de todos los puestos. En realidad es... Eh... En general de las *VMs* mayormente, y algunas cosas. Es selectivo, no es de todo. *Público*: Ah, ah. *OSiUX*: No, porque si no, no hay manera. *Público*: No, no, está bien. Era eso nomás. *OSiUX*: Justamente es para no enviar todos los *logs*. Es decir, enviar de manera selectiva. Toda esta información va a un *SIEM* que está en *CasaCentral*. *Público*: ¿Uno solo? *OSiUX*: Sí, bueno, puede ser que sea más de un nodo. *Público*: Ah, no. *OSiUX*: Pero, digamos, conceptualmente va a un *SIEM* que ahí se visualiza después todo lo que sucede. Y también al *SIEM* va todo... el *log* del *deploy* de *AWX*. Entonces también... *Público*: ¿Como SIEM? *OSiUX*: No, otro que no me acuerdo ahora, pero que es conocido. Ahora, si te digo, te miento. (era *Splunk* el *SIEM*) *Público*: Muchísimas gracias. ## Pregunta 3 Aciertos, pivotes y próximos pasos *Público*: Coincido con el colega un arduo laburo, un arduo trabajo. Y además hecho con Software Libre. Mi pregunta es básicamente en función a la experiencia de todo el proyecto. ¿Qué salió re bien? ¿Qué van a empezar a hacer, aparte de lo que has mencionado? ¿Y qué cosas fueron por un lado y dijeron, no, esto no va por este lado, mudamos? *OSiUX*: El mayor desafío en general no es técnico en sí, sino es lidiar con las prioridades de todo lo que hay que hacer. Y con cosas que a nivel usuario, de muchas aplicaciones libres, no están pensadas para una escala tan grande. Y una problemática de donde vos querés que los usuarios no puedan tocar nada. Por ejemplo, hay unos *PDFs* que son unos formularios como inteligentes que podés completar. Y después lo tenés que imprimir. Y eso fue re complejo de solucionarlo. Y al principio tuvimos que instalar *Adobe* *Acrobat* con, no sé, *Wine* o alguna cosa así horrible. Porque era lo único que lo soportaba. *Evince* los mostraba, pero no nos permitía completar. Después teníamos una opción que no me acuerdo cuál era, pero que los permitía completar. Pero no te permitía ocultar el comentario que está en cada formulario, en cada *textbox*. Y eso salía impreso y no servía. Ahora se estuvo trabajando en *Okular*, que es el que tiene todo eso. Pero no tiene ninguna opción de configuración por archivo para deshabilitar todo eso. O sea, el usuario lo puede desactivar en el momento. Bueno, entonces trabajamos. Estamos tocando el código de *Okular* para que eso ande. Lo mismo pasó con algunos binarios que no hay traducción y no tienen soporte de traducción. Y bueno, lo que pudimos lo editamos con un editor hexadecimal. Y plantamos nuestro binario. Cosas así, digamos, con el perdón de los asiáticos, le decimos chinos. (*\"Perdón, voy a evitar este tipo de comentarios en el futuro\"*). O sea, es un chino que hay veces que hay que meter mano y resolverlo. O *Bugs* complejos de que, no sé, entrás en una pantalla y por X motivos, si moves el mouse un poquito más abajo a la derecha, se cuelga a gnome. Y entonces hay que poner un *script* que evite que vos vayas para abajo. Y además cosas que un usuario dueño de su entorno no tiene problema porque puede customizar. Y un usuario final no puede tocar nada. Y vos, como administración de esta infraestructura, tampoco querés que toquen. Pero tenés que darle una solución. Así, mil cosas. Lo que no nos metimos y lo delegamos fue la parte de integración con el escáner de cheques. Yo estuve intentando un tiempo y no lo conseguí. Eso fue tercerizado. Pero anda. Sí logramos que ande bien la impresora de *tickets*. Y eso implicó un desafío de que el *core* bancario en ese momento utilizaba unos applets *Java*. Y eso, nada, era imposible. Tuvimos que meter un chroot en el medio con algo viejo para que eso ande. Bueno, al final pudimos evitar todo eso. Porque ahora el *core* ese ya detecta cuando es un *GNU///Linux*. Y listo, tira un código y metimos un *Backend* local que hace todo lo que falta y sale andando. Pero sí, es un desafío de muchas personas. Yo actualmente no estoy en el proyecto. Estuve en la etapa de desarrollo inicial y de migración. Hay tres personas ahora... Que están a *full* con esto. Y todos los días aparece algo nuevo. *Público*: Bueno, Buenísimo. *OSiUX*: Yo me puedo quedar acá y charlamos. ## Pregunta 4 gestión y composición del equipo humano en *Filiales* *GNU//Linux* *Público*: Bueno. *OSiRiS*, primero agradecerte. Para los que vinimos acá a aprender. La admiración que generás con todo lo que contás. Mi pregunta no va por... *OSiUX*: Es trabajo de *gcoop* igual, no mío... Yo lo estoy vendiendo. *Público*: De todos. Mi pregunta va más... Va más por ese lado. No por el lado técnico. Sino por el equipo o grupo humano. Que hay en *Filiales*. *GNU///Linux*, que si no entiendo es la organización que está detrás de todo este proyecto. ¿Cuántas personas se necesitan para hacer esto? ¿Y cómo lo gestionan? *OSiUX*: Bueno, inicialmente fue un proyecto de seis meses. De dos personas. Un analista funcional y yo. Para ver si era viable el proyecto. Después empezó... Creo que empezamos tres personas. En el tope llegamos a tres personas. ¿A cinco? *gcoop*: Tres más uno. *OSiUX*: Claro, sí. Siempre con un *PM*. No, pero en el tope cinco no. O sea, creo que ahí... No lo cuento al *PM*, pobre. Porque él siempre habla de... El *PM* siempre habla de que no somos personas. Que somos *developers*. Que somos cosas raras. Entonces, bueno. Es la venganza. No, en el tope cinco personas. Hoy hay tres. De *DevOps*, digamos. Pero que hay que... Digamos, es el *FullStack*. Por así decirlo. Pero después hay que tocar o rediseñar una aplicación. O sea, tuvimos que diseñar aplicaciones para solventar cosas existentes. O sea, está lo divertido y lo complejo al mismo tiempo. *Público*: Pensé que ibas a decir trescientas, no sé. Muchas gracias. *OSiUX*: No, no, perdón. Nosotros diseñamos la automatización de todo esto. El *Banco* tiene su propio arsenal. Un ejército de personas que utilizan diariamente todo esto. Hicieron la migración en plena pandemia `2020`. En menos de un año! Pero fue un ejército físico de personas que resolvió todo eso. Operadores de *AWX* creo que son más o menos como sesenta. O sea, como... Bueno, hay muchísima gente. La *Infra* del *Banco* es muy grande. Y es todo `on-premise`. Es todo local. O sea, y todo con *Software* *Libre*. *Público*: Muchas gracias. *Organización*: Ahí, Alejandro. Ahí te pongo una pregunta en el chat. Si después podés respondérsela ahí mismo. *OSiUX*: Sí. Y después tengo acá compañeros que saben hablar inglés. Y que si hay alguien que no habla español. *Organización*: Dale. Y Alejandro hoy va a estar por acá. Así que le pueden seguir preguntando. Muchas gracias. *OSiUX*: *OSiUX* también! ## Seguro te interesará leer... - \[Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX\](2022-10-20-como-migrar-6300-equipos-a-gnu-linux-usando-ansible-y-awx.md) - \[Automatizar la configuración de la *BIOS* usando `ansible` y /HP Linux Tools/\](2021-12-30-automated-bios-configuration-using-ansible-and-hp-linux-tools.md) - \[`Filiales GNU/Linux` FLISoL CABA\](2022-04-23-filiales-gnu-linux-flisol-caba.md) - \[*Ansible Tools* =v0.3.0=\](2022-10-03-ansible-tools-v0-3-0.md) - \[Automatizar la implementación de los recursos de AWX con GitLab CI/CD y Ansible Tools\](2022-10-08-automate-deployment-of-AWX-resources-with-GitLab-CI-CD-and-ansible-tools.md) - \[Usar Graphviz para generar Slides\](2022-10-21-use-graphviz-for-slides.md) - \[Cómo hacer una línea de tiempo con GraphViz\](2022-10-25-how-to-make-a-timeline-with-graphviz-using-timeline2dot.md) ## ChangeLog - [`2026-08-14 14:15`](https://gitlab.com/osiux/osiux.gitlab.io/-/commit/30bd625d95834ff336f33bd7c4a75ca27f2f7d12) agregar *Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian* [^1]: [^2]: [^3]: [^4]: [^5]: [^6]: [^7]: [^8]: [^9]: [^10]: [^11]: [^12]: [^13]: [^14]: