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

martes, 11 de diciembre de 2018

Multiseat en infolabs

Ya vimos como hacer funcionar multiseat en Ubuntu 18 aquí. Es conveniente mirarse el artículo enlazado y los 3 anteriores a este para refrescar conceptos.

Tenía pendiente probar a configurarlo en nuestros equipos infolabs, que son HP ProDesk 600 G1 SFF con una tarjeta nVidia GeForce GT 370 PCIe adicional, dos discos de 2TB y 16GB de RAM. En todos los centros tenemos varias decenas de ellos y puede resultar interesante poder duplicarlos y hacer que con cada uno trabajen dos alumnos a la vez. Vamos a la tarea.

Primero veremos las tarjetas VGA que tenemos:
# lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation HD GraphicHP ProDesk 600 G1 SFF)s 530 (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1)
Bien, ahi están las dos tarjetas. Destinaremos la nVidia para el seat0 y la Intel integrada en la placa base para el seat-1.

La configuración multiseat se activa sencillamente así:
# cat /etc/lightdm/lightdm.conf
[LightDM]
logind-load-seats=true
Los comandos básicos para ver la configuración son:
loginctl list-seats : listado de los seats definidos
loginctl seat-status seat0 : listado de los recursos asignados al seat0
loginctl seat-status seat-1 : listado de los recursos asignados al seat-1
loginctl seat-status seat-X : listado de los recursos asignados al seat-X
Incialmente todos los recursos disponibles (tarjetas gráficas, de sonido, puertos usb y dispositivos de entrada) están asociados al seat-0. Lo que haremos será asociar al seat-1 la tarjeta de vídeo Intel y un puerto USB donde conectaremos un HUB al que enchufaremos un teclado y ratón USB. Con eso tendremos un puesto funcional conectado a un monitor, teclado y ratón independiente. Será el seat-1.

Después de probar en otras ocasiones siempre me he encontrado que las tarjetas nVidia que usan el driver nvidia en lugar del libre nouveau dan problemas variados con multiseat y los distintos conectores de vídeo de salida. En nuestro caso el sistema de los infolab nos viene con driver nvidia por defecto y no quería cambiarlo, así que he optado por la configuración que según mi experiencia menos problemas ha dado: usar el conector VGA (el D-sub 15) en lugar del DisplayPort en ambas tarjetas gráficas. Para la tarjeta nVidia uso un convertidor DVI-VGA.

Una vez enchufado todo queda así:



Se pueden ver ambos cables VGA, uno para cada monitor. Luego el cable usb blanco es un hub usb al cual van conectados un teclado y ratón que serán para el seat-1.

Para asignar los recursos al seat-1 los comandos serían:
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:02.0/drm/card1"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:02.0/drm/renderD129"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Con esto se enlazan al seat-1 la tarjeta en el puerto PCI 02.0 (la gráfica Intel) y el puerto usb1/1-1 (el que tiene conectado el hub usb de la foto). La forma de investigar y determinar qué poner en la ruta del attach ya se mostró en anteriores artículos de esta serie.

Acabado esto ya podemos reiniciar y ver dos pantallas de login con las que iniciar sesión por separado en cada seat.

Llevo varias días de pruebas y la verdad es que está funcionando bien. El primer día tuve un problema con el seat-1 en que la imagen aparecía con colores distorsionados en el monitor, pero no se ha vuelto a repetir. No se si achacarlo a que estaba probando con distintos cableados de vídeo o a un fallo del driver xorg. De momento lo dejo funcionando y si vuelve a pasar y encuentro la solución ampliaré este post.


Esta vez vamos a oír el sonido del viento en Marte capturado por la recién llegada Insight:



Alucinante, es el susurro de otro mundo. Sorprendentemente no es la primera vez que se oyen los vientos de otra atmósfera alienígena. Cuando la alucinante Huygens de la misión Cassini-Huygens aterrizaba en Titán en 2005 grabó esto:



Áspero sonido de viento de nitrógeno a -180ºC con una suave lluvia de metano. Un mundo duro.

martes, 4 de diciembre de 2018

Error en tea4cups al procesar trabajos de impresión

Como ya conté en otra ocasión para gestionar la contabilidad de trabajos de impresión y realizar todo tipo de procesos sobre ellos tengo en uso el filtro tea4cups en cups, en comandita con pkpgcounter.

En una máquina con Manjaro Linux donde lo estaba configurando me encontré con que los trabajos no se imprimían y quedaban atascados en la cola de CUPS. Para depurar y saber que estaba pasando modifiqué el fichero de configuración de cups para activar la depuración:

# cat /etc/cups/tea4cups.conf
.....
[global]
# Should we log debugging information to CUPS' error_log file ?
# defaults to No if unset.
debug : yes
....
....
Luego he mandado un trabajo a imprimir y tras pararse me he ido a ver el log:
# grep -i tea4cups /var/log/cups/error_log
....
....
IOError: [Errno 13] Permission denied: \'/var/spool/cups/tea4cups-VGIM_CONSERJERIA-anonymous-40\'
....
....
Es un error de permisos. Por algún motivo tea4cups tiene problemas para escribir en /var/spool/cups. He intentado cambiar los permisos del directorio, pero al reiniciar el servicio cups vuelven a quedar como estaban originalmente.

La solución está en hacer que tea4cups use otro directorio para trabajar, por ejemplo /var/spool/tea4cups:
# cat /etc/cups/tea4cups.conf
.....
[global]
....

# In which directory will we create our files ? It must already exist !
# This directive MUST be present since there's no sane default value.
# Can be set either in the [global] section or any print queue section.
# The value defined in a print queue section takes precedence over the
# value defined in the [global] section.
#
directory : /var/spool/tea4cups/
....
....
El nuevo directorio lo crearemos con propietario root:cups y permisos 775. Una vez hecho ya si he podido verificar que funciona todo bien. Manjaro es maravilloso, pero al seguir una senda distinta a Debian tiene cosillas como esta.


Quiero dar la enhorabuena a mi compañero de promoción Antonio Plaza por ser reconocido estos días como investigador de referencia mundial en la computación hiperespectral. Aunque la ciencia en España esté maltratada y/o menospreciada por el 90% de los compatriotas y el 99% de los dirigentes siempre hay aldeas galas que resisten. ¡Eres un crack, Antonio!


Ya tenemos otro visitante en Marte desde hace una semana: la misión Insight. Aunque su función no es hacer fotos siempre viene bien tener algo que ver:


Tres detalles alucinantes:
  • El sismógrafo es capaz de detectar vibraciones del orden del diámetro de un átomo de hidrógeno. No tengo palabras.
  • Sus placas solares tienen una potencia máxima de 4.5kw/h: la misma que tengo contratada en mi casa con los ladrones de Iberdrola. Dan para conectar varios electrodomésticos convencionales, así que para la instrumentación optimizada que lleva ya ni te digo. Podría soportar un aula de infolabs sin problema.
  • La importantísima estación meteorológica incorporada (TWINS) es española. Ha sido desarrollada en el Centro de Astrobiología del INTA en Torrejón de Ardoz. Todo un orgullo nacional.
Bueno, pues a ver si aposenta el sismógrafo en lugar estable y empieza luego pronto a cavar en Marte a ver que hay dentro. Que emoción.

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.