...en la comunidad, trabajo en gcoop, que es una Cooperativa de Software Libre,
es decir, que trabajamos exclusivamente con Software Libre
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 para todes
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 un 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, que 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.
Bueno, y similar a los Proxmox, tenemos las Workstations.
Las 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.
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 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 querien 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 hacer esto 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 que es 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/Refish.
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 rol 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 rol 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 UPSs, para tener monitoreo de UPS.
Se está trabajando en actualizar los Debian de esas virtuales de 10 a 13.
Esto, recuerden, empezó en el 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 dar 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 a la 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.
Eh...
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
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.
Hola.
Eh...
¿Los ActiveDirectory que usan son Windows o usan también Windows Server?
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!
Primero que nada, impresionante.
Gracias a la comunidad del Software Libre! Eh...
Nosotros juntamos las piezas.
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
Sí.
Fue solicitud de seguridad informática.
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.
Sí, pero permite más detalle.
Puedes especificar exactamente qué partes querés.
No, no, no.
Entiendo.
Mi duda es, ¿ustedes están logueando las syscalls de 3.000 clientes?
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.
Ah, ah.
No, porque si no, no hay manera.
No, no, está bien.
Era eso nomás.
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.
¿Uno solo?
Sí, bueno, puede ser que sea más de un nodo.
Ah, no.
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...
¿Como SIEM?
No, otro que no me acuerdo ahora, pero que es conocido.
Ahora, si te digo, te miento.
Muchísimas gracias.
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?
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.
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 hace
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.
Buenísimo.
Yo me puedo quedar acá y charlamos.
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...
Es trabajo de gcoop igual, no mío...
De todos.
Mi pregunta va más...
Yo lo estoy vendiendo.
Va más por ese lado.
No por el lado técnico.
Sino por el equipo o grupo humano.
No por el lado 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?
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?
Tres más cinco.
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 full stack.
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.
Pensé que ibas a decir trescientas, no sé.
Muchas gracias.
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 a diario 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.
Muchas gracias.
Ahí, Alejandro.
Ahí te pongo una pregunta en el chat.
Si después podés respondérsela ahí mismo.
Sí.
Y después tengo acá compañeros que saben hablar inglés.
Y que si hay alguien que no habla español.
Dale.
Y Alejandro hoy va a estar por acá.
Así que le pueden seguir preguntando.
Muchas gracias.
OSiUX también!