Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian

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.

• Demo Site: https://filiales-gnu-linux.g.coop.ar
• Original Video: WebM (298 MB)
• Subtitle Video: WebM (298 MB)
• Spanish Subtitle: SRT (50 KB) VTT (44 KB)
• English Subtitle: SRT (48 KB) VTT (42 KB)
• English Slides: PDF (357 KB)
• Spanish Slides: PDF (357 KB)

This post has an English translation at How to Provision, Install, Configure, and Keep Thousands of Debian and Debian-Based Systems Updated

• Debian
• Ansible
• AWX
• Proxmox
• PXE
• FreeIPA
• GitLab CI/CD
• Infrastructura como Código
• Administración GNU/Linux de puestos de trabajo
• Deploy Automatizado

Este año al asistir a mi primera DebConf ¹, la DebConf26 ² 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 ³ edición 2022 que se llamaba "Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX" ⁴

Me llamo OSiRiS, me dicen OSiUX en la comunidad, trabajo en gcoop ⁵ que es una Cooperativa de Software Libre, es decir, que trabajamos exclusivamente con SoftwareLibre ⁶ 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 ⁷ porque tenemos 20 años trabajando con Software Libre y sin Debian no hubiera sido posible.

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 ⁸, 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 ⁹ y AWX ¹⁰.

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.

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 ¹¹. Que para la autenticación de ActiveDirectory dentro, en los Linux, íbamos a usar IPA. AWX, obviamente todos los servidores iban a usar Proxmox ¹². 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.

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.

La iDRAC ¹³ 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 ¹⁴. O sea, una compu nueva, recién salida de la caja.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

• Cómo migrar 6300 equipos a GNU/Linux usando Ansible y AWX
• Automatizar la configuración de la BIOS usando ansible y HP Linux Tools
• Filiales GNU/Linux FLISoL CABA
• Ansible Tools v0.3.0
• Automatizar la implementación de los recursos de AWX con GitLab CI/CD y Ansible Tools
• Usar Graphviz para generar Slides
• Cómo hacer una línea de tiempo con GraphViz