[opensuse-es] Actualización y comando man
Hola :) Actualicé ants de ayer y me pasó una cosa curiosa: $ man ls env: ‘man’: No such file or directory Ein??? Si ayer usé el comando man y men funcionó ... no pasa nada, vamos a investigar ... $ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz $ rpm -qa | grep ^man man-2.8.4-11.1.x86_64 Y las "man-pages"???? No pasa nada, ya vermos, sigamos: $ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz Ufff ... el comando está instalado ... ¿o no? $ file /usr/bin/man /usr/bin/man: broken symbolic link to /etc/alternatives/man Ein ???? Parcee ser que al actualizar (zypper dup) algo ha fallado ... y se ha desinstalado, pero no se ha vuelto a instalar. Solución: rpm -e man zypper in man man-pages Me ha pasado en 2 portátiles y 1 PC ... mucha casualidad ... En fin, por si a alguien más le ha ocurrido. HTH 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
El mar., 1 sept. 2020 a las 10:35, Rafa Griman
(
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ein??? Si ayer usé el comando man y men funcionó ... no pasa nada, vamos a investigar ...
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
$ rpm -qa | grep ^man man-2.8.4-11.1.x86_64
Y las "man-pages"????
No pasa nada, ya vermos, sigamos:
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
Ufff ... el comando está instalado ... ¿o no?
$ file /usr/bin/man /usr/bin/man: broken symbolic link to /etc/alternatives/man
Ein ???? Parcee ser que al actualizar (zypper dup) algo ha fallado ... y se ha desinstalado, pero no se ha vuelto a instalar.
Solución: rpm -e man zypper in man man-pages
Me ha pasado en 2 portátiles y 1 PC ... mucha casualidad ...
En fin, por si a alguien más le ha ocurrido.
Si, la última actualización masiva de Tumbleweed trajo algunos problemillas. 3342 paquetes y 3.5 GB. Tampoco me funcionaba man, reinstalé los paquetes: man man-pages man-pages-posix Ahora funciona de nuevo. Tampoco me funcionaba el sonido y tuve que reinstalar alsa-firmware. El único problema que no pude resolver, es que cuando arranco el sistema el Numlock queda apagado, a pesar de que en la configuración de KDE está seteado en encendido. Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- 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
El mar., 1 sept. 2020 a las 11:13, Juan Erbes (
El mar., 1 sept. 2020 a las 10:35, Rafa Griman (
) escribió: Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ein??? Si ayer usé el comando man y men funcionó ... no pasa nada, vamos a investigar ...
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
$ rpm -qa | grep ^man man-2.8.4-11.1.x86_64
Y las "man-pages"????
No pasa nada, ya vermos, sigamos:
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
Ufff ... el comando está instalado ... ¿o no?
$ file /usr/bin/man /usr/bin/man: broken symbolic link to /etc/alternatives/man
Ein ???? Parcee ser que al actualizar (zypper dup) algo ha fallado ... y se ha desinstalado, pero no se ha vuelto a instalar.
Solución: rpm -e man zypper in man man-pages
Me ha pasado en 2 portátiles y 1 PC ... mucha casualidad ...
En fin, por si a alguien más le ha ocurrido.
Si, la última actualización masiva de Tumbleweed trajo algunos problemillas. 3342 paquetes y 3.5 GB.
Tampoco me funcionaba man, reinstalé los paquetes: man man-pages man-pages-posix
Ahora funciona de nuevo.
Tampoco me funcionaba el sonido y tuve que reinstalar alsa-firmware.
El único problema que no pude resolver, es que cuando arranco el sistema el Numlock queda apagado, a pesar de que en la configuración de KDE está seteado en encendido.
También acabo de tener que reinstalar el Google Earth, porque quedaba todo negro dentro de la ventana de navegación. Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- 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
On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ein??? Si ayer usé el comando man y men funcionó ... no pasa nada, vamos a investigar ...
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
$ rpm -qa | grep ^man man-2.8.4-11.1.x86_64
Y las "man-pages"????
No pasa nada, ya vermos, sigamos:
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
Ufff ... el comando está instalado ... ¿o no?
$ file /usr/bin/man /usr/bin/man: broken symbolic link to /etc/alternatives/man
Ah. Estás hablando de Tumbleweed.
Ein ???? Parcee ser que al actualizar (zypper dup) algo ha fallado ... y se ha desinstalado, pero no se ha vuelto a instalar.
Solución: rpm -e man zypper in man man-pages
Me ha pasado en 2 portátiles y 1 PC ... mucha casualidad ...
En fin, por si a alguien más le ha ocurrido.
Haz: rpmconfigcheck y revisa el resultado fichero a fichero. Me sospecho (wild guess) que lo que te ha pasado es relacionado con la migración de /etc a /usr, que es manejado mediante el alternatives ese. Hay alguna configuración que no se ha activado porque está en un .rpmnew o .rpmorig. En la lista "factory" ya echaron la bronca los desarrolladores por no hacer lo de rpmconfigcheck Hace unos días le conté a uno el proceso en la lista inglesa, así que para ahorrarme trabajo le pido a DeepL la traducción - la pega es que esto se lo decía a alguien en concreto en cierto contexto, y no me voy a tomar el trabajo de re-editarlo para hacerlo genérico, porque estoy seguro que harás las correcciones mentales necesarias ;-) Lo que hago es copiar tanto el fichero en servicio como el fichero *rpm* a un directorio de copia de seguridad. No puede haber varios ficheros "*rpm*" del mismo fichero de configuración. Si los hay, significa que el administrador se olvidó de hacer su trabajo hace mucho tiempo. Entonces yo hago, por ejemplo: meld /etc/postfix/master.cf.rpmnew /etc/postfix/master.cf & que abre un editor de doble panel que compara el nuevo fichero propuesto con el fichero activo. Lo que hago es copiar de rpmnew a active las nuevas entradas que *considero* deberían estar ahí, y eliminar del archivo activo las líneas que *considero* no deberían estar ahí. Yo, el administrador, tengo que tomar las decisiones. Este es el trabajo del administrador, y no es trivial, pero es importante. Finalmente, yo borraría /etc/postfix/master.cf.rpmnew (recuerda que guardo una copia de seguridad). En el caso de un .rpmsave significa que la actualización hizo uso directamente del nuevo archivo, y renombró su copia original. Si nunca has alterado esa configuración, lo que hay que hacer es trivial: simplemente borra el archivo .rpmsave. Si has hecho algún cambio, bueno, reactiva esos con meld. A tí no tengo que decirte la tontería de que eres el administrador del sistema y tienes una responsabilidad etc ;-) :-p -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Wenas :)
On Tue, Sep 1, 2020 at 6:34 PM Carlos E. R.
On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ein??? Si ayer usé el comando man y men funcionó ... no pasa nada, vamos a investigar ...
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
$ rpm -qa | grep ^man man-2.8.4-11.1.x86_64
Y las "man-pages"????
No pasa nada, ya vermos, sigamos:
$ whereis man man: /usr/bin/man /usr/local/man /usr/share/man /usr/share/man/man1/man.1.gz /usr/share/man/man7mp/man.7mp.gz /usr/share/man/man1p/man.1p.gz
Ufff ... el comando está instalado ... ¿o no?
$ file /usr/bin/man /usr/bin/man: broken symbolic link to /etc/alternatives/man
Ah. Estás hablando de Tumbleweed.
Lles 0:) Se me olvidó decirlo al principio.
Ein ???? Parcee ser que al actualizar (zypper dup) algo ha fallado ... y se ha desinstalado, pero no se ha vuelto a instalar.
Solución: rpm -e man zypper in man man-pages
Me ha pasado en 2 portátiles y 1 PC ... mucha casualidad ...
En fin, por si a alguien más le ha ocurrido.
Haz:
rpmconfigcheck
y revisa el resultado fichero a fichero.
Buen apunte ;) Lo haré cuando arranque uno de los SUSE ... pero claro ... ya he mangoneado y he reinstalado el man ...
Me sospecho (wild guess) que lo que te ha pasado es relacionado con la migración de /etc a /usr, que es manejado mediante el alternatives ese. Hay alguna configuración que no se ha activado porque está en un .rpmnew o .rpmorig.
¿Están migrando cosas a /usr? ¿Igual que los BSD? ¿Tienes algún enlace? He buscado en Inet, pero no he encontrado nada 0:)
En la lista "factory" ya echaron la bronca los desarrolladores por no hacer lo de rpmconfigcheck.
La verdad es que ahora sólo estoy dado de alta en esta lista de correo. Me di de baja de las demás así que no sigo la inglesa ni la Factory ya ...
Hace unos días le conté a uno el proceso en la lista inglesa, así que para ahorrarme trabajo le pido a DeepL la traducción - la pega es que esto se lo decía a alguien en concreto en cierto contexto, y no me voy a tomar el trabajo de re-editarlo para hacerlo genérico, porque estoy seguro que harás las correcciones mentales necesarias ;-)
Nada, tranquilo, como ha dicho Juan en su correo, había unos 2800 paquetes a actualizar (IIRC) y entre prisas y otras cosas, no pones atención ... Además, ya sabes que "en casa de herrero, cuchillo de palo".
Lo que hago es copiar tanto el fichero en servicio como el fichero *rpm* a un directorio de copia de seguridad.
No puede haber varios ficheros "*rpm*" del mismo fichero de configuración. Si los hay, significa que el administrador se olvidó de hacer su trabajo hace mucho tiempo.
Entonces yo hago, por ejemplo:
meld /etc/postfix/master.cf.rpmnew /etc/postfix/master.cf &
Sí, si cuando veo el típico mensaje de "dejando fichero original y creando nuevo fichero con rpmnew" ... hago un diff y compruebo las diferencias, pero con +2000 paquetes, pues se te pasa.
que abre un editor de doble panel que compara el nuevo fichero propuesto con el fichero activo. Lo que hago es copiar de rpmnew a active las nuevas entradas que *considero* deberían estar ahí, y eliminar del archivo activo las líneas que *considero* no deberían estar ahí.
Sí, claro, lo normal 0:)
Yo, el administrador, tengo que tomar las decisiones. Este es el trabajo del administrador, y no es trivial, pero es importante.
Estoy de acuerdo, hay cosas que no puedes dejar en manos del gestor de paquetes. Como administrador debes tomar ciertas decisiones. Pero lo dicho: "en casa de herrero ..." xD
Finalmente, yo borraría /etc/postfix/master.cf.rpmnew (recuerda que guardo una copia de seguridad).
En el caso de un .rpmsave significa que la actualización hizo uso directamente del nuevo archivo, y renombró su copia original. Si nunca has alterado esa configuración, lo que hay que hacer es trivial: simplemente borra el archivo .rpmsave. Si has hecho algún cambio, bueno, reactiva esos con meld.
A tí no tengo que decirte la tontería de que eres el administrador del sistema y tienes una responsabilidad etc ;-) :-p
xD xD xD 0:) No si ya sé 0:) Gracias por recordarme lo de buscar los rpmnew y demás ;) !!! 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
On 01/09/2020 22.40, Rafa Griman wrote:
Wenas :)
...
Haz:
rpmconfigcheck
y revisa el resultado fichero a fichero.
Buen apunte ;) Lo haré cuando arranque uno de los SUSE ... pero claro ... ya he mangoneado y he reinstalado el man ...
Me sospecho (wild guess) que lo que te ha pasado es relacionado con la migración de /etc a /usr, que es manejado mediante el alternatives ese. Hay alguna configuración que no se ha activado porque está en un .rpmnew o .rpmorig.
¿Están migrando cosas a /usr? ¿Igual que los BSD? ¿Tienes algún enlace? He buscado en Inet, pero no he encontrado nada 0:)
Sip. A ver si localizo... Hay correos: Date: Mon, 22 Jun 2020 10:47:24 +0200 From: Stefan Dirsch <...@suse.de> To: opensuse-factory@opensuse.org Subject: [opensuse-factory] Issues with /etc -> /usr/etc config file switch ... y ese correo menciona https://en.opensuse.org/openSUSE:Packaging_UsrEtc) Eso es lo que veo en una búsqueda rápida. La página esa es larguita. para mi "wild guess" (¿como se traduce eso? DeepL dice "Supongo que es una conjetura salvaje.") lo que tengo en la memoria es que a mucha gente le reventó el sistema (no recuerdo exactamente que era) y les dijeron que la causa última era que habían ignorado el rpmconfigcheck con lo que no se había aplicado un cambio anterior que preparaba este. Creo que fallaba un symlink que no se creaba o que quedaba huerfano. Y estaba tambien relacionado con alternatives. Pero no recuerdo el título del hilo o hilos, o que cosa exacta era la que fallaba. Como no uso TW...
En la lista "factory" ya echaron la bronca los desarrolladores por no hacer lo de rpmconfigcheck.
La verdad es que ahora sólo estoy dado de alta en esta lista de correo. Me di de baja de las demás así que no sigo la inglesa ni la Factory ya ...
tsk tsk... factory es casi obligatoria... o la nueva de opensuse-suport, para oir que desastres se cuecen en TW.
Hace unos días le conté a uno el proceso en la lista inglesa, así que para ahorrarme trabajo le pido a DeepL la traducción - la pega es que esto se lo decía a alguien en concreto en cierto contexto, y no me voy a tomar el trabajo de re-editarlo para hacerlo genérico, porque estoy seguro que harás las correcciones mentales necesarias ;-)
Nada, tranquilo, como ha dicho Juan en su correo, había unos 2800 paquetes a actualizar (IIRC) y entre prisas y otras cosas, no pones atención ... Además, ya sabes que "en casa de herrero, cuchillo de palo".
:-D
Lo que hago es copiar tanto el fichero en servicio como el fichero *rpm* a un directorio de copia de seguridad.
No puede haber varios ficheros "*rpm*" del mismo fichero de configuración. Si los hay, significa que el administrador se olvidó de hacer su trabajo hace mucho tiempo.
Entonces yo hago, por ejemplo:
meld /etc/postfix/master.cf.rpmnew /etc/postfix/master.cf &
Sí, si cuando veo el típico mensaje de "dejando fichero original y creando nuevo fichero con rpmnew" ... hago un diff y compruebo las diferencias, pero con +2000 paquetes, pues se te pasa.
Por eso yo no uso TW... tengo esta historia con rpmconfigcheck una vez al año. No llega a los treinta ficheros que revisar. Esta vez es una de las pocas que ha estallado y que la gente se ha enterado.
que abre un editor de doble panel que compara el nuevo fichero propuesto con el fichero activo. Lo que hago es copiar de rpmnew a active las nuevas entradas que *considero* deberían estar ahí, y eliminar del archivo activo las líneas que *considero* no deberían estar ahí.
Sí, claro, lo normal 0:)
Yo, el administrador, tengo que tomar las decisiones. Este es el trabajo del administrador, y no es trivial, pero es importante.
Estoy de acuerdo, hay cosas que no puedes dejar en manos del gestor de paquetes. Como administrador debes tomar ciertas decisiones. Pero lo dicho: "en casa de herrero ..." xD
:-D ya he dicho que es un copy paste y traducción automática (DeepL) de un correo detallado para gente que no está al tanto ;-) para ahorrarme escribir
Finalmente, yo borraría /etc/postfix/master.cf.rpmnew (recuerda que guardo una copia de seguridad).
En el caso de un .rpmsave significa que la actualización hizo uso directamente del nuevo archivo, y renombró su copia original. Si nunca has alterado esa configuración, lo que hay que hacer es trivial: simplemente borra el archivo .rpmsave. Si has hecho algún cambio, bueno, reactiva esos con meld.
A tí no tengo que decirte la tontería de que eres el administrador del sistema y tienes una responsabilidad etc ;-) :-p
xD xD xD 0:) No si ya sé 0:)
:-D
Gracias por recordarme lo de buscar los rpmnew y demás ;) !!!
No, si se les olvida a todos... a mi no, porque escribí la página wiki para el "offline upgrade", y entonces lo tengo grabado a fuego. Precisamente la migración a /usr/etc dicen que es para evitar este problema en el futuro. La idea es tener un fichero de configuración RO, más otro fichero en /etc con los "overrides". Igual que lo hace el systemd. 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. Así que vosotros que tenéis TW os enteráis de como os va y me lo contáis ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hola :)
On Tue, Sep 1, 2020 at 10:00 PM Carlos E. R.
On 01/09/2020 22.40, Rafa Griman wrote:
Wenas :)
...
Haz:
rpmconfigcheck
y revisa el resultado fichero a fichero.
Buen apunte ;) Lo haré cuando arranque uno de los SUSE ... pero claro ... ya he mangoneado y he reinstalado el man ...
Me sospecho (wild guess) que lo que te ha pasado es relacionado con la migración de /etc a /usr, que es manejado mediante el alternatives ese. Hay alguna configuración que no se ha activado porque está en un .rpmnew o .rpmorig.
¿Están migrando cosas a /usr? ¿Igual que los BSD? ¿Tienes algún enlace? He buscado en Inet, pero no he encontrado nada 0:)
Sip. A ver si localizo... Hay correos:
Date: Mon, 22 Jun 2020 10:47:24 +0200 From: Stefan Dirsch <...@suse.de> To: opensuse-factory@opensuse.org Subject: [opensuse-factory] Issues with /etc -> /usr/etc config file switch ...
y ese correo menciona https://en.opensuse.org/openSUSE:Packaging_UsrEtc)
Eso es lo que veo en una búsqueda rápida. La página esa es larguita.
Con eso me vale. Muchas gracias !!! El enlace que mencionas apunta a este otro: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
para mi "wild guess" (¿como se traduce eso? DeepL dice "Supongo que es una conjetura salvaje.") lo que tengo en la memoria es que a mucha gente le reventó el sistema (no recuerdo exactamente que era) y les dijeron que la causa última era que habían ignorado el rpmconfigcheck con lo que no se había aplicado un cambio anterior que preparaba este. Creo que fallaba un symlink que no se creaba o que quedaba huerfano. Y estaba tambien relacionado con alternatives.
Pero no recuerdo el título del hilo o hilos, o que cosa exacta era la que fallaba. Como no uso TW...
No te preocupes, ya seguiré leyendo ;)
En la lista "factory" ya echaron la bronca los desarrolladores por no hacer lo de rpmconfigcheck.
La verdad es que ahora sólo estoy dado de alta en esta lista de correo. Me di de baja de las demás así que no sigo la inglesa ni la Factory ya ...
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". Ten en cuenta que es la distro en la que prueban cosas, el SW es más "moderno", actualizaciones cada 2x3, puede haber grandes cambios, ... vamos que lo usamos "bajo nuestra responsabilidad". Yo lo uso porque prefiero tener SW más "moderno". Tbn: - considero que puedo salir del apuro si me meto en un problema - si el problema es muy gordo ... puedo reinstalar porque tengo: * una partición adicional para un / de emergencia * una partición dedicada a /home * copias de seguridad de /home
Hace unos días le conté a uno el proceso en la lista inglesa, así que para ahorrarme trabajo le pido a DeepL la traducción - la pega es que esto se lo decía a alguien en concreto en cierto contexto, y no me voy a tomar el trabajo de re-editarlo para hacerlo genérico, porque estoy seguro que harás las correcciones mentales necesarias ;-)
Nada, tranquilo, como ha dicho Juan en su correo, había unos 2800 paquetes a actualizar (IIRC) y entre prisas y otras cosas, no pones atención ... Además, ya sabes que "en casa de herrero, cuchillo de palo".
:-D
Lo que hago es copiar tanto el fichero en servicio como el fichero *rpm* a un directorio de copia de seguridad.
No puede haber varios ficheros "*rpm*" del mismo fichero de configuración. Si los hay, significa que el administrador se olvidó de hacer su trabajo hace mucho tiempo.
Entonces yo hago, por ejemplo:
meld /etc/postfix/master.cf.rpmnew /etc/postfix/master.cf &
Sí, si cuando veo el típico mensaje de "dejando fichero original y creando nuevo fichero con rpmnew" ... hago un diff y compruebo las diferencias, pero con +2000 paquetes, pues se te pasa.
Por eso yo no uso TW... tengo esta historia con rpmconfigcheck una vez al año. No llega a los treinta ficheros que revisar. Esta vez es una de las pocas que ha estallado y que la gente se ha enterado.
MHO otra vez, la gente también es un poco "tocanarices": TW es una versión en la que te avisan de antemano que sufre cambios muy a menudo y que puede "romperse". Pues si no te gusta, no lo uses. Si quieres algo más estable, usa LEAP y si quieres algo aún más estable y fiable, usa SLES. [...]
Gracias por recordarme lo de buscar los rpmnew y demás ;) !!!
No, si se les olvida a todos... a mi no, porque escribí la página wiki para el "offline upgrade", y entonces lo tengo grabado a fuego.
xD xD
Precisamente la migración a /usr/etc dicen que es para evitar este problema en el futuro. La idea es tener un fichero de configuración RO, más otro fichero en /etc con los "overrides". Igual que lo hace el systemd.
La idea puede ser buena, el enlace que mencionas y el otro al que apunta tienen sentido. Pero creo que se está intentando "resolver todos los problemas" y se quiere permitir una "flexibilidad extrema". 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. 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 ;)
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 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.
Así que vosotros que tenéis TW os enteráis de como os va y me lo contáis ;-)
Sin problemas ;) Si me encuentro con otras curiosidades, lo diré :) 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
On 02/09/2020 00.51, Rafa Griman wrote:
Hola :)
On Tue, Sep 1, 2020 at 10:00 PM Carlos E. R. <> wrote:
Sip. A ver si localizo... Hay correos:
Date: Mon, 22 Jun 2020 10:47:24 +0200 From: Stefan Dirsch <...@suse.de> To: opensuse-factory@opensuse.org Subject: [opensuse-factory] Issues with /etc -> /usr/etc config file switch ...
y ese correo menciona https://en.opensuse.org/openSUSE:Packaging_UsrEtc)
Eso es lo que veo en una búsqueda rápida. La página esa es larguita.
Con eso me vale. Muchas gracias !!!
El enlace que mencionas apunta a este otro: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
Ah, otra cosa que leer.
para mi "wild guess" (¿como se traduce eso? DeepL dice "Supongo que es una conjetura salvaje.") lo que tengo en la memoria es que a mucha gente le reventó el sistema (no recuerdo exactamente que era) y les dijeron que la causa última era que habían ignorado el rpmconfigcheck con lo que no se había aplicado un cambio anterior que preparaba este. Creo que fallaba un symlink que no se creaba o que quedaba huerfano. Y estaba tambien relacionado con alternatives.
Pero no recuerdo el título del hilo o hilos, o que cosa exacta era la que fallaba. Como no uso TW...
No te preocupes, ya seguiré leyendo ;)
En la lista "factory" ya echaron la bronca los desarrolladores por no hacer lo de rpmconfigcheck.
La verdad es que ahora sólo estoy dado de alta en esta lista de correo. Me di de baja de las demás así que no sigo la inglesa ni la Factory ya ...
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
Ten en cuenta que es la distro en la que prueban cosas, el SW es más "moderno", actualizaciones cada 2x3, puede haber grandes cambios, ... vamos que lo usamos "bajo nuestra responsabilidad". Yo lo uso porque prefiero tener SW más "moderno".
Ya lo se :-)
Tbn: - considero que puedo salir del apuro si me meto en un problema - si el problema es muy gordo ... puedo reinstalar porque tengo: * una partición adicional para un / de emergencia * una partición dedicada a /home * copias de seguridad de /home
Hace unos días le conté a uno el proceso en la lista inglesa, así que para ahorrarme trabajo le pido a DeepL la traducción - la pega es que esto se lo decía a alguien en concreto en cierto contexto, y no me voy a tomar el trabajo de re-editarlo para hacerlo genérico, porque estoy seguro que harás las correcciones mentales necesarias ;-)
Nada, tranquilo, como ha dicho Juan en su correo, había unos 2800 paquetes a actualizar (IIRC) y entre prisas y otras cosas, no pones atención ... Además, ya sabes que "en casa de herrero, cuchillo de palo".
:-D
Lo que hago es copiar tanto el fichero en servicio como el fichero *rpm* a un directorio de copia de seguridad.
No puede haber varios ficheros "*rpm*" del mismo fichero de configuración. Si los hay, significa que el administrador se olvidó de hacer su trabajo hace mucho tiempo.
Entonces yo hago, por ejemplo:
meld /etc/postfix/master.cf.rpmnew /etc/postfix/master.cf &
Sí, si cuando veo el típico mensaje de "dejando fichero original y creando nuevo fichero con rpmnew" ... hago un diff y compruebo las diferencias, pero con +2000 paquetes, pues se te pasa.
Por eso yo no uso TW... tengo esta historia con rpmconfigcheck una vez al año. No llega a los treinta ficheros que revisar. Esta vez es una de las pocas que ha estallado y que la gente se ha enterado.
MHO otra vez, la gente también es un poco "tocanarices": TW es una versión en la que te avisan de antemano que sufre cambios muy a menudo y que puede "romperse". Pues si no te gusta, no lo uses. Si quieres algo más estable, usa LEAP y si quieres algo aún más estable y fiable, usa SLES.
Claro.
[...]
Gracias por recordarme lo de buscar los rpmnew y demás ;) !!!
No, si se les olvida a todos... a mi no, porque escribí la página wiki para el "offline upgrade", y entonces lo tengo grabado a fuego.
xD xD
Precisamente la migración a /usr/etc dicen que es para evitar este problema en el futuro. La idea es tener un fichero de configuración RO, más otro fichero en /etc con los "overrides". Igual que lo hace el systemd.
La idea puede ser buena, el enlace que mencionas y el otro al que apunta tienen sentido. Pero creo que se está intentando "resolver todos los problemas" y se quiere permitir una "flexibilidad extrema".
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? 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.
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.
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.
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.
Así que vosotros que tenéis TW os enteráis de como os va y me lo contáis ;-)
Sin problemas ;) Si me encuentro con otras curiosidades, lo diré :)
:-D -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, Sep 2, 2020 at 12:54 AM Carlos E. R.
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). 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 ... 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. 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. 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).
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"?
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? 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.
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? 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 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. 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". 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. 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. 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". 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 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
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)
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
On 03/09/2020 00.24, Rafa Griman wrote:
Hola :)
On Wed, Sep 2, 2020 at 9:28 AM Carlos E. R.
wrote: [...] 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.
Ondiá, vaya complicaciones que tienes en tu trabajo :-p
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).
Cierto, y el reiserfs escala mal, es mono-thread.
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.
Ah, vale, que ya llegan comprimidos. Hombre, el sistema puede darse cuenta y no comprimir, pero no ganas nada. La idea era no gzipear para tener más velocidad de acceso.
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
No puedo pensar a lo grande, no es lo mio :-) Me lo puedo sospechar, pero no pensarlo realmente. Pero espero que los que estén dirigiendo el cotarro sí que lo hayan pensado. SLES terminará por integrar esto, si no, hubieran pasado de hacerlo en TW.
[...]
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.
La intranet de openSUSE la están poniendo con Salt, eso lo sé. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ya lo están comentando en la lista inglesa. https://bugzilla.opensuse.org/show_bug.cgi?id=1175919 workaround: # update-alternatives --set man /usr/libexec/man-db/wrapper ------ y the reinstall zypper -v in --force man accomplishes the "update-alternatives" invocation. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Jolas :)
On Wed, Sep 2, 2020 at 8:47 PM Carlos E. R.
On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ya lo están comentando en la lista inglesa.
Mira qué bien !! Voy a leerlo ahora mismo :) Muchas gracias !!! 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
El mié., 2 sept. 2020 a las 19:25, Rafa Griman
(
Jolas :)
On Wed, Sep 2, 2020 at 8:47 PM Carlos E. R.
wrote: On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ya lo están comentando en la lista inglesa.
Mira qué bien !! Voy a leerlo ahora mismo :)
Ya lo había mencionado ayer: Tampoco me funcionaba man, reinstale los paquetes: man man-pages man-pages-posix Ahora funciona de nuevo. También tuve que reinstalar el Google Earth. Saludos -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- 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
On 03/09/2020 00.25, Rafa Griman wrote:
Jolas :)
On Wed, Sep 2, 2020 at 8:47 PM Carlos E. R. <> wrote:
On 01/09/2020 15.35, Rafa Griman wrote:
Hola :)
Actualicé ants de ayer y me pasó una cosa curiosa:
$ man ls env: ‘man’: No such file or directory
Ya lo están comentando en la lista inglesa.
Mira qué bien !! Voy a leerlo ahora mismo :)
Muchas gracias !!!
Encantado, para eso leo esa lista, aunque no todo. Ya es mala suerte que te hayas pegado la torta antes que los demás, por un dia o así. No, más, dijiste que actualizaste antes de ayer cuando escribiste el correo. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (3)
-
Carlos E. R.
-
Juan Erbes
-
Rafa Griman