On 02/09/2020 09.50, Rafa Griman wrote:
On Wed, Sep 2, 2020 at 12:54 AM Carlos E. R.
wrote: On 02/09/2020 00.51, Rafa Griman wrote:[]
tsk tsk... factory es casi obligatoria... o la nueva de opensuse-suport, para oir que desastres se cuecen en TW.
MHO: yo no diría que en TW se "cuecen desastres".
Es mi manera irónica de hablar ;-p
xD xD xD
[...]
Personalmente soy "Dr. NO" en el trabajo y cuando me piden montar un servidor web o instalar un antivirus en un contenedor en un nodo de cálculo ... pues les digo que no. Y sí, me lo han pedido.
Antivirus en un nodo de cálculo... esto... ¿En Windows? ¿Y la velocidad?
No, no, ... en un nodo (corriendo Linux) en un clúster de cálculo (HPC).
Afortunadamente, no creo que haya antivirus para Linux que hagan escaneo al acceder a un fichero ;-) El clamav no lo hace, la ultima vez que miré. En de pago, no sé. Tendría su utilidad para un servidor samba.
Claro, claro, ... el rendimiento se te va "a la porra" y, encima, afectas al resto de usuarios porque estos son clústers para Bioinformática en los que tienes dos situaciones al mismo tiempo: - cientos de millones de ficheros pequeños: IOW, unos IOPs del carajo que te matan el almacenamiento - millones de ficheros grandes (de hasta 130 GB cada uno): así que requieres gran bandwidth para esto
Imagínate que le metes un antivirus a escanear ese sistema de almacenamiento ...
Me lo puedo imaginar.
Como curiosidad, tuve un usuarios en otro clúster que tenía 6 directorios y cada uno tenía 12 millones de ficheros ... SIN subdirectorios !!! Una vez, sin saberlo, hice un "ls" que tardó varias horas.
Ostras. Se supone que reiserfs brillaba en esa situación, la publicidad decía que le daba igual millones de ficheros en un sólo directorio. Lo probé con cien mil. No recuerdo el ls... :-?
Tenía otro usuario con 250 millones de ficheros ... A eso súmale que tenemos miles de usuarios realizando cálculos copiando y borrando millones de ficheros, comprimiendo, ... Ahora súmale un antivirus ... te cargas el sistema.
Del todo.
Además, como les dije, eso es cosa de los de seguridad que se debería hacer a nivel de "entrada" de datos a la organización, no una vez que está el dato en el meollo de todo. Si quieres hacer un doble escaneo, lo haces cuando entra el fichero y cuando lo mueves al cluster.
Por cierto, no sólo es el número de ficheros sino que los grandes van comprimidos (generalmente con gzip, pero te encuentras de todo).
Uuuu, comprimir eso... Horas. ¿Y un sistema de ficheros que comprima al vuelo, aunque sea el mínimo? Yo lo estoy probando con btrfs en un disco de copia de seguridad.
Siempre que puedas controlar que no metan pinchos... Estoy pensando en stuxnet. Metieron un pincho en la red segura, que metió un troyano que reprogramó los PLC que se cargó las centrifugadoras al aumentar las revoluciones. Claro, que eso era un "targeted attack", van a entrar sea como sea y hagas lo que hagas.
Claro, claro, por eso digo, intentar frenarlo a la entrada, durante la copia de datos, formar a los usuarios (para evitar phishing), separar tareas (en el clúster se hace HPC y punto, en el SAP se hace SAP ... y punto) y flujos de trabajo, ...
¿A que a los de financiero no les dicen: "Me dejas usar tu servidor de SAP y el de Oracle para correr mi servidor web"?
jejeje :-D
Creo que estamos dejando que el usuario "haga lo que le dé la gana" con la informática ... y que encima funcione !!! ¿A que eso no lo hace con su lavadora? xD ;)
Calla, que ya tienen Wifi.
No me lo recuerdes ... Pero aún así, ¿a que no "exigen" al fabricante de lavadoras poder instalar un monitor de 30" para poder jugar al Fortnite?
Juas.
Que me perdone los "jugones", pero no sé qué juego es el que está de moda ahora ... sólo me sé ese título 0:) ¿A que no le exigen al fabricante poder crear usuarios, cambiar el fondo de pantalla, poner un entorno que gira, ...? Saben que es una lavadora.
Te encuentras un juego en el lector de libros Kobo :-p (creo recordar. Añadieron dos o tres tonterias para demostrar que se podía hacer. Mi kobo lo tengo desmontado para intentar cambiar la bateria)
Con lo cual saber cual es la opción activa tiene narices si no hay un editor que lo soporte, porque tienes que leer el RO, y luego los machaques en el fichero RW si es que existe, y luego las modificaciones del nuevo rpm.
No estoy contento.
Ya Carlos, ¿pero realmente es necesario que el usuario realice tantos cambios? ¿O es porque todas estas modas de Agile y Scrum te dicen que hay que cambiar poco y muy a menudo? Yo no recuerdo tanto cambio cuando llevaba servidores web, correo, FTP y ahora con los clústers, yo no tenía (ni tengo) esa "necesidad". A lo mejor es que soy un "aburrido" xD
Hombre, mi postfix tiene poquitos cambios respecto a "fábrica", pero tiene que tener ajustes de configuración por narices. No es el usuario, es el administrador.
Ya, ya, pero me refiero a ¿es realmente necesario cambiarlo tanto todo? Me da igual que sea el usuario o el amdinistrador. Obviamente, hay que aplicar algún cambio alguna vez por novedades en el SW o novedades en el trabajo, por ejemplo. Pero ¿llegar al nivel de tener que separar y tener 2 directorios /etc porque no te da la vida con los cambios que hay? ¿Tantos cambios tienes? O mejor aún, ¿tantos cambios NECESITAS?
Una sola linea de un "cambio" en el main.cf y ya haces que el .rpmnew sea un problema, porque hay que generarlo (al actualizar), y el administrador tiene que revisarlo. Estamos hablando, no se, de activar "submission" o "greylisting", que te exigen ajustar la configuración sí o sí. O tan simple como decirle la interfaz de red en la que tiene que escuchar. No te puedes escapar sin tocar algo, aunque una vez que lo haces no vuelves a mirarlo en años. A partir de ahí, todas las actualizaciones generan un rpmnew que tienes que estudiar. De la forma que quieren, el /usr/etc/postfix/main.cf no cambia y no se genera el rpmnew, es eso. Ahora bien, el problema ahora es que el señor Wietse SÍ va a añadir opciones y a cambiar las que vienen por defecto, con lo cual te tienes que estudiar el /usr/etc/postfix/main.cf antiguo y el nuevo y tu /etc/postfix/main.cf con los overrides, a no ser que haya un editor de configuración que te combine todo (ala "systemctl edit clamav.service").
Lo dicho, habrá casos justificados en los que sea necesario. Lo que digo es que eso de decirle al usuario/cliente siempre que sí ("el cliente siempre tiene la razón") ... no estoy de acuerdo. Hay veces que el usuario/cliente NO tiene razón. Con "usuario" no me refiero sólo al usuario, también al administrador (por eso pongo cliente).
No, claro, no siempre tiene razón.
No digo que no haya casos, y puedo estar equivocado.
Uno de mis ex-jefes cambiaba todos los días cosas (muchísimas) en Puppet simplemente por cambiar (según él, eran mejoras ... pero nadie las notaba y, de hecho, complicaba todo), hasta el punto de modificar el propio Puppet que teníamos y no te podías descargar configuraciones y módulos que otras personas habían hecho y puesto a tu disposición en Internet ... ¿Por qué y para qué? Si no lo necesitamos y no se notaban mejoras (todo lo contrario). De hecho, otro equipo que llevaba la supercomputadora y su propio Puppet se lo preguntaba también: ¿para qué tanto cambio? Los de aplicaciones estaban desesperados porque no había continuidad ni estabilidad.
Tampoco es eso. Yo una vez que tengo algo funcionando no lo vuelvo a tocar.
A eso me refiero. Pero desde hace un tiempo se está "imponiendo" lo de cambiar todo a todas horas.
Buf.
Otro ejemplo. En bioinformática ahora lo que se lleva es Python. Pues lo que más te piden los usuarios es "la últma versión de Python".
Ondiá.
cuando les preguntas que por qué ... te dicen que "porque la necesito" ... Ya, pero ¿por qué? ¿Qué nueva característica necesitas? ... Silencio.
:-)
Tengo usuarios con entornos Conda de 100s de Giggas ... WTF ... si no lo usas. Y luego claro, se quejan que se quedan sin cuota.
El viejo mantra: "Si funciona, no lo toques".
Otro ejemplo es Ansible, Puppet, Salt, Chef, ... son ahora la excusa perfecta para cambiar cosas cada 2x3 ... Como es "fácil" y me ayuda a hacerlo ... Ele !! A empujar cambios en la config del sistema.
Me tengo que enterar como va lo de Salt. Se usa en la intranet de openSUSE, y estoy colaborando como voluntario. Se han inventado el nombre de "héroes", que no me gusta nada. De momento yo no uso Salt, pero... tendré que enterarme.
Total, lo enlazo con git y si el cambio no funciona, hago un rollback y tan contento ... Pues no, tan contento no, porque has tirado varias máquinas y has jorobado a un usuario que lleva 14 días corriendo una simulación ... Hablo de mi caso particular.
Buff.
Ojo, creo que Ansible, Puppet, Salt, chef, ... son herramientas muy útiles, pero recordemos las Leyes de Murphy: "Cuando tienes un martillo en la mano, todo son clavos".
:-D
La tecnología ha dejado de ser una herramienta (útil) a usarse como un mensaje de márketing.
Bueno, dejo de quejarme que no paro xD xD xD
:-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)