Hola :)
On Wed, Sep 2, 2020 at 9:28 AM Carlos E. R.
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 ;-)
Ni idea. Lo que quería el usuario es que el antivirus se ejecute antes de correr su job y le escanee los ficheros lo cual es un problema porque no sabemos a ciencia cierta cuánto va a durar el escaneo. Por ejemplo, vamos a suponer que el job suyo tarda 4 horas de media cuando se ejecuta sobre X genomas. Ahora metemos el antivirus a escanear los ficheros, ¿cuánto va a tardar el antivirus en escanear los ficheros? Ni idea. ¿Cómo afecta esto a su job? Pues tienes que saber cuánto dura para poder reservar ese número de horas. Es decir, tendría que reservar 4 horas + lo que tarde el AV. ¿Qué ocurre si no define bien el tiempo? Que el gestor de colas le cancela el trabajo en cuanto haya consumido ese número de horas ... y viene el llanto y el rechinar de dientes porque su trabajo ha sido cancelado. ¿Puedes pedir 1000 horas? No, porque hay un tiempo máximo definido por el Admin para que la gente no se aproveche.
El clamav no lo hace, la ultima vez que miré. En de pago, no sé. Tendría su utilidad para un servidor samba.
Claro, al igual que para NFS y correo. Por eso digo que el escaneo tiene que hacerse cuando se baja el fichero (a nivel de cortafuegos u otro dispositivo justo detrás del cortafuegos) y/o cuando se transfiera el fichero al cluster (generalmente por rsync, sftp, scp, NFS, CIFS/SMB, GridFTP, Globus, Aspera, ...).
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... :-?
Pero ... eras 1 usuario, en este clúster teníamos 1700 usuarios. Y este usuario en concreto tenía 72 millones de ficheros, otro tenía 250 millones de ficheros ... suma y sigue. Había usuarios corriendo cientos de jobs. Te hablo de cerca de 1000 nodos de calculo (y 320 NVIDIA v100 y 32 rtx2080ti).
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.
Y eso que teníamos NVMe, SSD y SATA, separados para IOPS, throughput, metadatos, ...
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.
Sí y no. Teníamos varios ZFS. Lo que ocurre es que cuando los usuarios reciben los genomas, ya están comprimidos con gzip (generalmente) así que el sistema de ficheros intentaría comprimir un fichero ya comprimido. Comprimir no me preocupa porque puedes paralelizarlo con pigz, pbzip2, lbzip2, pxz, zstd si son ficheros muy grandes y va muy bien. También puedes usar parallel si son muchos ficheros "pequeños" y también va muy bien. [...]
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 que pregunto es si realmente "tu sistema" (no me refiero al sistema de Carlos en particular, sino el de un Admin) tiene tantos cambios que no te da tiempo a comparar los ficheros de configuración (rpmsave, rpmnew, ... lo que sea) y aplicar en un tiempo razonable las novedades. Por ejemplo, yo tengo una VM (en algunos casos una máquina física) a la que le aplico los parches, actualizaciones, ... (obviamente hago clones y snapshots) de forma que sé lo que me espera y hasta que no lo tengo bajo control ... NO aplico. Esto en el trabajo ... en mi casa ... pues ya has visto: a lo burro xD xD xD [...]
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.
Estas herramientas son útiles, pero para lo que se diseñaron. Hay gente que se cree que van a salvar el Mundo. Lo mismo pasó con el Big Data, la virtualización, Cloud, Containers, ... Aquí usan Ansible. Una cosa que no me gusta de Ansible es que una misma cosa la puedes hacer de 175.34 formas diferentes (ya ya, estoy exagerando). Así que te lías, se te olvida, maldices, te pierdes, ... Por lo menos es lo que me pasa a mi xD xD xD Me tengo que poner en serio. Y Puppet ... la poca experiencia que tengo ha sido con el engendro ese de un trabajo anterior así que no era realmente Puppet. Empecé con Salt en mi casa para probar, pero lo dejé por falta de tiempo al poco así que no te sé decir. Pero sí me gustaría aprender Salt, un compi enamorado de Puppet me dijo que estaba muy bien y que es lo que debería aprender y ya te digo que era un enamorado de Puppet. Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org