"Después del juego es antes del juego"
Sepp Herberger

viernes, 23 de noviembre de 2018

Error al actualizar desde mirrors locales de Ubuntu Bionic

Tras crear un mirror local en mi red de los repositorios de Ubuntu Bionic, Google y alguno más siguiendo las indicaciones de nuestro compañero Esteban me he encontrado con que al hacer "apt-get update" en los clientes me saltaba el error de que no podía descargar el fichero:
http://servidor/html/archive/ubuntu/dists/bionic/main/dep11/icons-48x48.tar
Lo cual es una sorpresa ya que "dep11" no es una rama que yo haya incluido en el mirror, ya que solo puse a bajar las ramas amd64 e i386. La causa es al parecer algo que trae el paquete appstream y la solución es borrar mediante puppet el fichero:
/etc/apt/apt.conf.d/50appstream
en todos los PC clientes. De esta manera ya podemos actualizar los puestos a una velocidad más razonable desde dentro de nuestra red.

Clonado de salidas de vídeo en pantalla de login

Ya hemos empleado en varias ocasiones scripts basados en xrandr para configurar el clonado de la pantalla en 2 dispositivos diferentes, normalmente un monitor y un cañón proyector. El script resultante se llama desde un fichero /etc/xdg/autostart/xxx.desktop y así garantizamos que se ejecuta cuando el usuario inicia sesión.

El problema que tuve estos días es que debia clonar la imagen entre una TV LED colgada en un muro y un monitor y no daba con la tecla para que se mostrase la imagen clonada antes de iniciar sesión, en la pantalla de login de lightdm. En este caso el script es mas o menos:
# cat /usr/bin/resolucion_tv_monitor
#!/bin/bash

#En el PC del Taller de Peluqueria las salidas son DVI (Monitor) y HDMI (TV plana): DVI-I-1 y HDMI-1 

test -e $HOME/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml && rm $HOME/.config/xfce4/xfconf/xfce-perchannel-
xml/displays.xml

HDMI=$(xrandr | grep " connected" | grep HDMI | cut -d" " -f1)
DVI=$(xrandr | grep " connected" | grep DVI | cut -d" " -f1)
xrandr --output $DVI --mode 1024x768 --pos 0x0 --rotate normal --output $HDMI --mode 1920x1080 --pos 0x0 --rotate normal --same-as $DVI --scale-from 1024x768
exit 0
Por si fuera poco el PC tiene un sistema multiseat, por lo que hay otra tarjeta de vídeo más con un monitor independiente para otro usuario que no debe ser clonado y debe mostrar su propia sesión privada.

Lo que se suele hacer en estos casos en generar un fichero xorg.conf que se pondrá en /etc/X11/xorg.conf.d forzando el clonado de ambas salidas, pero tras varios intentos no he sido capaz de dar con la configuración correcta.

La solución por la que me he decantado es olvidarme del xorg.conf y llamar al script antes de mostrar la pantalla de login. ¿Cómo?, pues ejecutándolo al inicio de ligthdm:
# cat /etc/lightdm/lightdm.conf.d/10-resolucion.conf 
[SeatDefaults]
display-setup-script=/usr/bin/resolucion_tv_monitor
Solo debemos tener cuidado de que display-setup-script no esté siendo usado para otro script, ya que solamente puede definirse una única vez.


Acabemos con el maravilloso vídeo grabado desde otro satélite del despegue de una Progress para abastecer la Estación Espacial Internacional:



Seguro que lleva en algún recoveco la pequeña ración de vodka de contrabando que los cosmonautas rusos acostumbran a pasar para consumir desde la época de la Mir y todas las Salyut.

Examinar los puertos de un switch Juniper

Los switchs que nos están instalando últimamente son de la marca Juniper con sistema operativo embebido Junos, que al parecer se basa en el entrañable FreeBSD. Tienen un interface web pero este es bastante lento y va a tirones, por lo que es mejor conectar por SSH para realizar las pocas tareas que nos permiten con ellos.

En esta ocasión estaba mapeando a mano las conexiones del switch y quería examinar que puertos estaban con señal "link up" y que MAC's habia tras ellos.

Para ver el estado de los enlaces de cada puerto el comando es:
> show interfaces terse
 
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0                up    down
ge-0/0/0.0              up    down eth-switch
ge-0/0/1                up    down
ge-0/0/1.0              up    down eth-switch
ge-0/0/2                up    up
ge-0/0/2.0              up    up   eth-switch
ge-0/0/3                up    down
...
...
...
Para ver la tabla MAC con las direcciones mapeadas tras cada puerto:
> show ethernet-switching table

Ethernet-switching table: 60 entries, 56 learned, 0 persistent entries
  VLAN             MAC address       Type         Age Interfaces
  default           ec:3e:f7:5a:9f:c1 Static         - Router
  datos             *                 Flood          - All-members
  datos             00:00:74:9a:f5:68 Learn       3:11 ge-0/0/23.0
  datos             00:14:2a:97:05:cb Learn       1:58 ge-0/0/23.0
  datos             00:16:17:d4:57:dd Learn          0 ge-0/0/23.0
  datos             00:16:e6:82:8e:72 Learn       4:29 ge-0/0/23.0
  datos             00:16:e6:88:0d:21 Learn       4:33 ge-0/0/23.0
  datos             00:19:21:2d:7a:8f Learn         44 ge-0/0/10.0
  datos             00:19:21:2d:7c:b9 Learn         49 ge-0/0/8.0
  datos             00:19:21:2d:7e:f0 Learn       1:03 ge-0/0/12.0
  datos             00:19:99:fd:39:3a Learn         56 ge-0/0/23.0
  ...
  ...
  ...
Con esto he podido realizar un mapeo rápido de lo que buscaba.

Aquí un manual de referencia de Junos.



Hablando de Juno, una fotito de Júpiter tomada por la sonda Juno de la NASA:


Que bonito, lástima que haga tanto frío y haya tanta radiación.

jueves, 8 de noviembre de 2018

Lentitud de páginas web multimedia en thinclients de LTSP Ubuntu 18.

Me ha llegado una incidencia sobre la lentitud de un aula de thinclients sobre LTSP en Ubuntu 18 al abrir páginas web. Tras hacer pruebas in situ pude comprobar que al abrir varias páginas con 10 o mas thincliens encendidos todo se hacía enormemente lento, incluido el servidor LTSP, de tal manera que era imposible trabajar.

Descartado un problema de red me centro en ver que páginas usan: son unas páginas de idiomas que tienen mucho Flash (Odín maldiga al Flash) y que además abren muchas pestañas de Firefox. Haciendo un "ps aux | grep firefox" veo que hay una burrada de instancias de Firefox abiertas (mas de 40 procesos) y que eso puede provocar la fastidiosa lentitud de alguna manera que se me escapa.

En las últimas versiones de Firefox se ha implementado una feature llamada Electrolysis que, al igual que tiene hace tiempo Chrome, implica que Firefox abra procesos a tutiplén (uno o más por cada pestaña) para mejorar el rendimiento. Eso está muy bien para un entorno monousuario, pero en un entorno donde hay 10 o 12 usuarios en la misma máquina abriendo pestañas puede llevar las cosas al límite, especialmente en nuestros servidores LTSP con CPU Intel Core2 Quad de casi 10 años de antigüedad.

¿Se puede controlar este desmadre procesil? Pues en parte si, tocando varias configuraciones. Para hacerlo automático y que se aplique de forma obligatoria a todos los usuarios del PC (evitando tener que tocarlo perfil a perfil) lo mejor es usar el fichero syspref.js global de /etc/firefox:
# cat /etc/firefox/syspref.js
...
...
...
//Limitar el nmero de procesos firefox. Thinclients.
pref("browser.tabs.remote.autostart", false, locked);
pref("extensions.e10sMultiBlockedByAddons", false, locked); 
pref("dom.ipc.processCount", 1, locked); 
y distribuir dicho fichero mediante puppet a las máquinas que lo necesiten.

Con esto el número de instancias de Firefox se queda en 1-2 para cada usuario y la cosa se hace sensiblemente mas manejable: antes iba como el culo y ahora va casi medio bien.

Otra opción podría ser ejecutar Firefox de forma local en los thinclients, con sus propios recursos. Eso se hace lanzándolo así:
# ltsp-localapps firefox
El problema de esto es que:
  • Se ejecuta el Firefox y el Flash de 32bits contenido en la imagen de los thinclients, sensiblemente mas antiguo que el del servidor LTSP. Las imágenes de los thinclients están basadas en Ubuntu 14.
  • Al ejecutarse con el procesador y memoria de los thinclients tarda en arrancar y puede ir bastante ralentizado (suelen ser Pentiums IV con 512Mb de RAM). La ventaja es que no satura el servidor ni los thinclients ajenos.
Si aún así queremos hacerlo funcionar la forma mas adecuada es poner un script en los servidores LTSP que detecte si estamos en un thinclient o el servidor (examinando el contenido de la variable $LTSP_CLIENT) para lanzar el Firefox de una manera u otra:
# cat /usr/local/bin/firefox
#!/bin/bash
if [ ! -z "$LTSP_CLIENT" ]; then
       ltsp-localapps firefox
else
       /usr/lib/firefox/firefox "$@"
fi
exit 0
# chmod +x /usr/local/bin/firefox
Al estar /usr/local/bin por delante de cualquier otro directorio en $PATH siempre se ejecutará primero el script al llamar a "firefox".

Con esto conseguimos que la cosa tire mejor en tanto en cuanto Flash no sea purgado de la faz de la Tierra.

miércoles, 7 de noviembre de 2018

Software Reporter Tool y ralentización de los Windows.

Esta va de Windows. Después de hacer este curso un downgrade de Windows 10 a Windows 7 en varios equipos usados en los ciclos de FP en el centro porque entre actualizaciones, cortanas y demás enredos se hacían inmanejables ha habido un período de calma hasta que me avisaron que algunos empezaban a ir muy lentos de forma injustificada.

Tras mirar con el explorador de procesos no vi ningún proceso desbocado, pero si me chocaba que el procesador estaba siempre por encima del 60%, aún cuando no se hiciese nada. Para dilucidar que pasa en estos casos lo mejor es usar el programa "Process Explorer", que muestra mucha mas información que el explorador de procesos tradicional del Windows.

Ahora si pude ver que había un proceso (antes oculto no se por qué motivo) llamado "Software Reporter Tool" que era el responsable del alto uso de la CPU. Este programa es algo que viene con el Google Chrome y que básicamente no hace nada que no sea hacer la puñeta. Se instala en cada perfil de usuario en la ruta "c:\users\*usuario*\AppData\Local\Google\Chrome\User Data\SwReporter\..." y se arranca cuando buenamente le parece para hacer sus maldades.

No se puede desinstalar pero si borrar, aunque comentan que cuando se actualice Chrome seguramente volverá a aparecer. De momento lo he limpiado en todos los pc ejecutando:
cd c:\users
for /d /r . %d in (SwReporter) do @if exist "%d" rd /s/q "%d"
Y de repente los pc afectados han revivido. Tendremos que estar al acecho para cuando vuelva a aparecer.

lunes, 5 de noviembre de 2018

Volvemos con los libros digitales Santillana: Parachute y C'est à dire / Oxford


1. Actualización de libros de Santillana

Este curso nos han cambiado los libros digitales de Francés de la editorial Santillana: aunque los tenemos instalados de forma local en la red del IES han empezado a amenazar con que no se verán a partir de una fecha si no se actualizan. En su día ya contamos como instalarlos aquí:
Para actualizarlos he descargado la versión nueva de los libros desde la página con las credenciales que me ha dado el profesor, suministradas por la editorial.

Pensaba que la instalación sería similar a la relatada en el primero de los enlaces anteriores, pero mi sorpresa ha sido que ya no puedo abrir el libro con "firefox /home/.../dpto/Frances/ParaChute_1/exeBrowser.htm". La causa es que exeBrowser.htm ya no viene con los libros de Parachute (con los de C'est à dire, que son para Bachillerato, si vienen por ahora). En su lugar tengo un /home/.../dpto/Frances/ParaChute_1/exeLinux que debo hacer funcionar en Linux sí o sí. Esta vez no puedo usar el comodín del navegador Firefox como la otra vez.

Los pasos para hacerlo funcionar son:
  • Descargar el fichero .zip de la página de Santillana y descomprimirlo en la ruta destino, /home/.../dpto/Frances/*libro*. Poner permisos 777 a la carpeta creada con chmod 777 *carpeta*.
  • Hacer ejecutable el fichero exeLinux con chmod +x.
  • Instalar los paquetes auxiliares necesarios en las máquinas clientes que ejecutarán el programa. Son todos paquetes i386 ya que exeLinux es un programa de 32bits.
    # apt-get install libgtk2.0-0:i386 libxt6:i386 libidn11:i386 libnss3:i386 libxxf86vm1:i386 libcurl4:i386
    
  • Crear el fichero .desktop que se pondrá como enlace directo a la aplicación y ponerlo en el Escritorio de los profesores interesados:
    # cat Parachute1.desktop
    
    #!/usr/bin/env xdg-open
    [Desktop Entry]
    Name=Parachute 1
    Version=4.1.0.0
    Type=Application
    Terminal=true
    StartupNotify=true
    Exec=/home/.../dpto/Frances/ParaChute_1/exeLinux
    Categories=Education
    Icon=/home/.../dpto/Frances/ParaChute_1/recursos/intro01.jpg
    Path=/home/.../dpto/Frances/ParaChute_1/
    
  • Por último probamos la aplicación. En condiciones normales se abrirá y se ejecutará sin problema (al principio pide unas claves de licencia de acceso que debe obtener el profesor) aunque no descartamos nada ya que el ejecutable usa un flash versión 10 embebido (no es que Santillana use una tecnología obsoleta...es que usa una librería anterior a Göbekli Tepe)
  • He encontrado máquinas aisladas donde se queda la ventana en blanco (* ver mas abajo). Atribuyo el fallo a problemas con la configuración de la tarjeta gráfica y las X. Habría que generar y tocar el xorg.conf a mano (seguramente por prueba/error como cuento en el apartado 2) para encontrar la solución, pero no urge y no me he puesto con ello. Con las SIATIC y los LTSP de nuestros centros no hay problema.
  • Donde si hemos encontrado problemas es al abrir los vídeos desde el exeLinux: debe haber algún fallo al llamar al navegador web porque no encuentra el html que muestra el vídeo. De momento como truco para salir del paso lo que hacemos es abrir la carpeta /home/.../dpto/Frances/ParaChute_1/contenido/videos y ejecutar el vídeo directamente.
Bueno, a ver si Santillana se pone las pilas y se pasa a HTML5, que a Flash le quedan 14 meses de vida.

(*) Addenda 2/2/2021: las máquinas donde exeLinux se abre con la ventana en blanco se muestran bien si instalamos estas dos librerias de 32bits:
libidn11:i386 
libcurl4:i386

2. Libros de Oxford Key.

En cuanto a los libros de Oxford hemos tenido que reinstalarlos también tras actualizar a Ubuntu 18. Los pasos para Oxford Key (no serán muy distintos para otros libros de esa editorial) son:
  • Descargamos el programa en la páginas web de OxfordPremium con las credenciales que nos ha dado el profesor. Entramos en el Libro->Recursos para el aula-> Material para la PDI y allí está el enlace.
  • Instalar los paquetes auxiliares necesarios en las máquinas clientes que ejecutarán el programa. Son todos paquetes i386:
    # apt-get install libasound2:i386  libdbus-glib-1-2:i386 libxt6:i386
    
  • La descarga e instalación se realiza en el home de un usuario de prueba, luego se copiará a una ubicación de red. La instalación se lanza con:
    # ./Key/Key to Bachillerato 1/setup-linux-x64
    
  • Si aparece el error:
    Warning: Problem running post-install step. Installation may not complete correctly
     Error running linux-x64/utils/unzip64 -o "/media/reyesmp74/spectrum_ipack_2/dist/archives/books0.zip" -d .shared/books : unzip64: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed. Aborted
    
    Es debido a que la versión de unzip64 que trae el instalador no es compatible con Ubuntu 18.04. Solución, sobreescribir el unzip64 que trae con el unzip que viene con Ubuntu y relanzar la instalación:
    # cp /usr/bin/unzip "~/Key/Key to Bachillerato 1/dist/default/program_files_linux_x64/linux-x64/utils/unzip64"
    # ./Key/Key to Bachillerato 1/setup-linux-x64
    
  • Copiar la instalación realizada a una carpeta de red tipo /home/.../dpto/Ingles/OxfordKey1.
  • Crear el .desktop hacia el ejecutable /home/.../dpto/Ingles/OxfordKey1/oup tal como hemos visto otras veces
  • Dar, como ya contamos en episodios anteriores, permisos a Flash sobre /home/.../dpto/Ingles/OxfordKey1 abriendo http://www.macromedia.com/support/documentation/es/flashplayer/help/settings_manager04.html con Firefox. Si no hacemos esto los vídeos no se visualizarán.
  • Probamos la aplicación lanzando el .desktop. Todo debería ir bien.
Después de instalar nos hemos dado cuenta de que en algunos equipos al maximizar los vídeos se quedaba colgado el escritorio, teniendo que matar el proceso "oup" para volver. Estos PC tenían todos una tarjeta VGA ATI Radeon HD 3450 y este tipo de cuelgues de Flash suele estar relacionado con ello.

Probando y probando encontré esta configuración para las Xorg que elimina el problema:
# cat /etc/X11/xorg.conf.d/10-xorg.conf 
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24

    Option "DRI" "2"

    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
La linea "Option 'DRI' '2'" es la clave. ¿Como he logrado saber este parámetro? Pues no tiene ningún encanto ya que he usado un nada emocionante método de prueba y error. He creado a mano un fichero xorg.conf con todas las opciones posibles:
# cat /etc/X11/xorg.conf.d/10-xorg.conf 
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24

    #Option "SWcursor" "boolean"
    #Option "Accel" "boolean"
    #Option "ZaphodHeads" "string"   #          For example: Option "ZaphodHeads" "LVDS,VGA-0" will assign xrandr outputs LVDS and VGA-0 to this instance of the driver.
    #Option "ColorTiling" "boolean"
    #Option "ColorTiling2D" "boolean"
    #Option "DRI" "integer"         
    #Option "EnablePageFlip" "boolean"
    #Option "TearFree" "boolean"
    #Option "AccelMethod" "string"  # glamor/EXA
    #   The following driver Options are supported for glamor :
    #Option "ShadowPrimary" "boolean"
    #   The following driver Options are supported for EXA :
    #   Option "EXAVSync" "boolean"
    #   Option "EXAPixmaps" "boolean"
    #   Option "SwapbuffersWait" "boolean"

    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
Y luego con paciencia he ido probando valores, reiniciando las X y probando la aplicación hasta que ha sonado la flauta. La lista de opciones de cada driver gráfico las saco con "man". Por ejemplo, en este caso usamos el driver "radeon" y la lista de opciones la he obtenido con:
# man radeon
Y luego con calma he puesto cada opción y su posibles valores en las distintas pruebas hasta dar con la solución.

Bueno, esperemos que el próximo año no nos toquen los libros.