Cómo aprovisionar, instalar, configurar y mantener actualizados miles de sistemas Debian y basados en Debian
index |
about |
archive |
charlas |
docs |
links
dot |
git |
img |
plt |
tty |
umlResumen
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.
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 ,
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"
gcoop
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.
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 , 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.
Laboratorio para la viabilidad del proyecto usando Software Libre
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.
Aprovisionamiento automatizado de Debian con PXE y PVE (Proxmox Virtual Environment)
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
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.
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
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.
Stack inicial del proyecto
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.
Repositorios de playbooks y roles de Ansible liberados!
Graficar logins del dominio y sincronización de cache de FreeIPA
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
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
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.
Vista global del catálogo de Roles y Playbooks en 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.
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.
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…