Downgrade de impresoras HP

Las famosas impresoras HP Officejet x476dw que nos mandaron sin mesura nos han traído muchos momentos dificultosos. El principal problema está relacionado con trabas al uso de tinta genérica.

Ya sufrimos el bloqueo de cartuchos con aquella bomba de tiempo que metió HP en muchos de sus firmwares hace un par de años. Posteriormente los sucesivos firmwares provocan de alguna manera que los inyectores fallen o al menos eso nos parece.

En este escenario puede ser útil hacer un downgrade del firmware de la impresora para volver a una versión anterior del mismo. Seguramente cuanto más antiguo sea menos bichos tiene dentro.

El problema es que el actualizador oficial que viene con los firmwares no permite hacer downgrade y cargar un firmware mas antiguo que el que tiene instalado. Originalmente las impresoras venían con el firmware LWP1CN1502AR, que luego se fue actualizando en muchas de forma automática (ya que teníamos los "Servicios Web" activados en el menú de configuración web) hasta el LWP1CN1640AR e incluso hasta LWP1CN1819AR y LWP1CN1829BR (el mas reciente a fecha de escribir esto).

Afortunadamente, mi compañero Fernando nos puso en la pista con este enlace: Downgrade de impresora a version 1640AR, en el cual se describe como realizar el downgrade a la versión 1640 si tienes un firmware superior.

Luego encontré esta página en alemán donde cuenta como trucar el actualizador original para realizar un downgrade a cualquier versión. El problema es que el enlace que dan hacia un repositorio de firmwares ha sido vaciado por HP.

Enredando un poco me bajé un el EXE con un firmware antiguo OJPX476DW_CN1502BR.zip, y descomprimiendo el ZIP y luego el EXE que hay dentro llegué hasta un interesante archivo "lemansdw_vr5_pp1_LWP1CN1502BR_apps_signed.ful". Veamos que es esto:

# file lemansdw_vr5_pp1_LWP1CN1502BR_apps_signed.ful 
lemansdw_vr5_pp1_LWP1CN1502BR_apps_signed.ful: HP Printer Job Language data

Vaya, es un fichero de PJL, el lenguaje de los trabajos de impresión de HP.

# head lemansdw_vr5_pp1_LWP1CN1502BR_apps_signed.ful 
2345X@PJL COMMENT (null)
@PJL ENTER LANGUAGE=FWUPDATE

This device does not support FWUPDATE!
t16384sA16542Y+0Y16384VSA27020202A41D5900080100A2C359378CD1AD22A482D2BB797E683379D8F9648DBF89C9EB894F9E9C
SA27658A50D5BA358FC5BE1BB1FCE651DA793BF0FBD192E4E268A649612BDA1D6EC4D71BC568ED41C9
SA27FE3DCD0D5FCA270E926F5E7E520A13353113BA080A648ADBFE9478B6D55BF2B9137A67FCFB0184
SA273B41DC3BD7E683AD450E87640EED6179C3BBC1EB1809F5284280620F992C047EFFCA02CA8F8AB5
SA274F027A82F9A563CE96EF88C33DF8F53AD95EF9898C8B7B088CEE168921903881C45C7B9FA22CAA
SA2766BB292B82D570162BACA932E8AC0614517921DA5CAF088A51A9C45B338F04DDF8D634D0A00591
SA276609554863B5739DA6C8DDB7D66350E1A09D83378D1C86D4070724258D2FF0E9CF6E6162DE4C28

Por lo que vemos contiene dentro el blob de la actualización del firmware en forma de trabajo de impresión. También he visto luego que la extensión .rfu también se usa para este tipo de ficheros.

Estos ficheros PJL pueden ser enviados directamente a la impresora para que los interprete y ejecute. La pregunta es: ¿si enviamos este fichero a pelo lo ejecutará y realizará un downgrade del firmware sin quejarse?.

Bien, en este enlace hablan un poco sobre PJL y como enviarlo tal cual a una impresora HP. En Windows se usa un programita llamado PrintFile y en Linux seguramente se pueda usar el comando "lpr".

Por no complicarme usé el Windows, el programa PrintFile, la impresora conectada por USB con sus drivers instalados y envié el fichero lemansdw_vr5_pp1_LWP1CN1502BR_apps_signed.ful. El panel táctil de la impresora parpadeó, se reinició varias veces con un contador y una barra de progreso y...¡voilá! al reiniciar el firmware había bajado del 1640AR al 1502BR.

Esto en principio no soluciona los problemas que estamos teniendo con los cartuchos genéricos, pero es interesante conocer este método por si alguna vez nos hace falta volver a un firmware antiguo.

Como colofón, paso enlace hacia los dos firmwares mas antiguos que he podido encontrar:

• Firmware 1502. Es un ZIP con ele ejecutable para Windows. Se debe ir descomprimiendo hasta llegar al .ful.
• Firmware 1336. Este firmware es para instalar desde OSX, así que viene en un fichero .dmg. No es complicado encontrar herramientas para extraer su contenido.

---

Me despido con este divertido reportaje de Rocío Vidal, aka La gata de Schrödinger, en el primer congreso terraplanista de Barcelona:



No es broma, se empieza negando el cambio climático y la llegada del Apolo XI a la Luna y se termina defendiendo que la Tierra es plana:

Ver y grabar canales de TV por Internet desde la línea de comandos.

Lo confieso: veo la TV nacional en algunas ocasiones en que me interesa. Lo ideal sería poder verla fácilmente desde una ventana del ordenador mientras hago alguna otra cosa, pero el problema es que las cadenas tienen en tan alta estima sus contenidos que no se molestan en ponerlo fácil.

Afortunadamente hay un puñado de voluntarios que consiguen ayudarnos: confeccionan listas de enlaces m3u que apuntan a la transmisión en vivo de uno o varios canales. Y además actualizan los enlaces cada vez que las cadenas sabotean la emisión. Hay muchas, pero mi página de referencia ahora es esta.

Una vez tenemos el enlace web al fichero m3u (por ejemplo: https://pull2c-i.akamaized.net/canal/master.m3u8) cogido de la página anterior, para poder visualizarlo nada tan sencillo como hacer:

# vlc https://pull2c-i.akamaized.net/canal/master.m3u8

Aquí vemos un ejemplo:

Por otro lado, puede suceder que queramos grabar un programa concreto para verlo luego. Eso lo haremos desde la línea de comandos con el programa "ffmpeg" y los siguientes parametros:

# fmpeg -i https://pull2c-i.akamaized.net/canal/master.m3u8 -c copy -bsf:a aac_adtstoasc grabacion.mp4 

El fichero resultante se guardará en "grabacion.mp4" para su posterior visionado.

Si además queremos programar el tiempo de grabación podemos usar el parámetro "-t " de ffmpeg, por ejemplo:

# fmpeg -i https://pull2c-i.akamaized.net/canal/master.m3u8 -c copy -bsf:a aac_adtstoasc -t 00:02:00 grabacion.mp4 

Grabará 2 minutos y finalizará. De esta manera no se nos escapará nada interesante. Es una lástima que no se pueda ir viendo el contenido mientras se graba, pero no he encontrado la forma de hacer timeshift en la emisión.

---

Así ya tengo todo preparado para ver y grabar las pruebas de vuelo de esta preciosidad durante los próximos meses:

Que bonito el prototipo de la Starship de SpaceX que acabará llevándonos a Marte. Eres grande, Elon Musk.

Integración de mapas descargados de IGN en app OsmAnd

Como aficionado al senderismo (lo que antes se llamaba "andar por el campo" y ahora para masmolar se le dice "trekking") me gusta tener siempre una aplicación con mapas en el móvil. Es importante que dichos mapas funcionen offline, ya que nunca sabemos si vamos a tener cobertura o no. Ya sabemos que la cobertura 3G cubre casi todo el país, pero yo no se que hago que siempre me meto en ese ínfimo % donde no la hay.

He pasado por varias aplicaciones Android a lo largo de los años: Oruxmaps, Mapas de España, MapsMe, Google Maps,... pero ahora estoy usando preferentemente OsmAnd, ya que integra muy bien las rutas GPX descargadas de Wikiloc y permite añadir como capas diversos tipos de mapas offline.

El único hándicap que le encuentro es que por defecto solo deja descargar unos cuantos mapas de su servidor, quedando desactivada la descarga en la versión gratuita al alcanzar el límite. Aun así, podemos descargar más mapas con el PC y posteriormente copiarlos a mano al móvil.

El problema que tienen para el senderismo los mapas del servidor de OsmAnd es que, al estar basados en OpenStreetMap, son detallados para sitios urbanos y carreteras pero no para recorridos por el campo. No aparecen muchos caminos rurales ni nombres de paraje, por lo que lo ideal es complementarlos con mapas del IGN (Instituto Geográfico Nacional).

Como ejemplo, aquí vemos una localización con mapas OpenStreeMap:

Y la misma con mapas de IGN:

Como se aprecia, en esta última aparecen caminos, parajes, edificios rurales y, si nos acercamos más, curvas de nivel u otros accidentes. Todo lo que necesitamos para movernos con seguridad. Como punto flaco tenemos que son mapas que ocupan bastante espacio: la provincia de Cáceres pesa mas de 1Gb. Eso quiere decir que o tenemos una tarjeta de memoria monstruosa o solo podremos llevar algunos mapas concretos en cada momento.

Los mapas de OpenStreetMap se descargan directamente con OsmAnd. Vienen en formato vectorial propio de OsmAnd, con la extensión .obf.

Los mapas de IGN (que no son vectoriales, son raster) pueden descargarse desde múltiples lugares:

• http://centrodedescargas.cnig.es/CentroDescargas/loadMapMov.do
• http://cosasdeandroides.com/mapas/
• De nuestros hermanos de Portugal: http://www.igeo.pt/ o http://cosasdeandroides.com/mapas-portugal/
  

No todo es sencillo: no basta con descargar y copiar a la memoria interna del móvil. El formato de los mapas de IGN es mbtiles (mas información sobre el formato aquí) y OsmAnd usa otro formato para los mapas raster.

No problem, la herramienta mbtiles2osmand convierte entre formatos. La descargamos de las páginas antes indicadas, luego descargamos un mapa en mbtiles (por ejemplo, caceres.mbtiles) y ejecutamos el comando:

# ./mbtiles2osmand.py caceres.mbtiles caceres.sqlitedb

Al acabar tenemos el fichero caceres.sqlitedb con el mapa raster de la provincia de Cáceres ya compatible con OsmAnd. Podemos hurgar en las interioridades tanto de mbtiles como de sqlitedb, ya que ambos son ficheros en formato sqlite. Además, los ficheros mbtiles pueden ser vistos y editados por multitud de herramientas, por ejemplo con QGIS (con el plugin adecuado) o Cartograph.

Bueno, volviendo a lo importante, una vez tenemos el fichero sqlitedb lo copiamos en la memoria del móvil, dentro de la carpeta android/data/net.osmand/files/tiles. En muchos sitios de la web dicen que hay que copiarlos a la carpeta osmand/tiles, pero no es así, actualmente la carpeta correcta es la que yo indico.

Una vez copiado, reiniciamos la aplicación y ponemos el mapa raster como mapa superpuesto, de manera que podremos ver a la vez el mapa OsmAnd y el mapa descargado del IGN usando una barra de transparencia para hacer mas visible uno u otro. Para ello entramos en configuración de OsmAnd y allí en "Configurar Mapa":

Luego en "Mapa Superpuesto":

Y de nuevo en "Mapa Superpuesto":

Nos saldrá una lista de los mapas detectados, entre ellos esta "caceres" que ya he copiado previamente a la memoria del móvil:

Lo seleccionamos y ya tenemos el mapa puesto de fondo. Listo para irnos a caminar.

---

Este cambio de año viene cargado de noticias astronáuticas, no doy abasto y los podcasts del tema están que arden:

1) La Chang'e 4 de nuestros amigos chinos en la cara oculta de la Luna, buscando la base de los Transformers o de los nazis.

2) El cometa Wirtane en diciembre.

3) La OSIRIS-REx en el asteroide tipo apolo llamado Bennu con esta hermosa fotografía del sistema Tierra-Luna:

4) Otro asteroide apolo, el Ryugu, está siendo visitado por la sonda Hayabusa 2, que ha aterrizado varios rovers parecidos a una Roomba y que traerá a la Tierra de vuelta muestras llenas de cosas interesantes.

5) Por último, la New Horizons una vez visitado Plutón ha pasado cerca de Ultima Thule, en lo que viene siendo el quinto pino del sistema solar:

Quizá la foto esta un poco movida, pero es que la New Horizons iba a 14km/s en ese momento.

---

Un apunte curioso y triste: la India ha sido el único país que ha mandado un orbitador a Marte y ha llegado a la primera sin fallos ni accidentes. La misión costó 74 millones de euros. En la abandonada Ciudad de la Justicia de Madrid se gastaron 95 millones de euros para construir un único edificio que se oxida bajo la lluvia. Ahora que alguien me diga donde está el gasto inútil.

Compartir impresora de CUPS mediante Google CloudPrint

1. Impresión en Cloudprint.

Una de las impresoras que tenemos en nuestros centros es la Epson WorkForce WF8590, la cual tiene en su firmware la capacidad de ser compartida en la nube de forma ubicua a través de Google CloudPrint. Tan solo hay que configurar a través de su interfaz web la cuenta de Google que la compartirá y ya la tenemos disponible en Internet.

Una vez hecho esto para la Epson sucede que tarde o temprano te piden compartir otras impresoras del centro con el problema de que no tienen en su firmware esa funcionalidad. Cuando te documentas ves que es posible compartir impresoras que están en un servidor CUPS de Linux en Google CloudPrint como si tuvieran esa funcionalidad de forma nativa, como explican aquí. Vemos que para Linux hay dos paquetes que hacen esto:

• cloudprint
• google-cloud-print

2. Paquete cloudprint.

Este programa es el más antiguo, consta de 2 paquetes Debian: cloudprint y cloudprint-service, con el software y el servicio que lo encapsula respectivamente.

Al iniciar el servicio o ejecutar a mano el programa cloudprint (tal como se relata en el apartado correspondiente) nos pedirá las credenciales de las cuentas Gmail donde asociar la impresora. Si en este paso da error 403/404 o similar esto es debido a que la versión que estamos usando es demasiado antigua (para Debian Jessie en los repositorios tenemos la obsoleta versión 0.11.5). La solución es bajar la última vérsion desde este repositorio, donde tenemos la 0.14.5 para Jessie.

Una vez resuelto esto, al arrancar el programa este intenta compartir en la nube todas las impresoras que hay en el CUPS de la máquina. Eso genera un problema si hay impresoras configuradas con el driver raw (el cual no tiene ppd asociado) y dará errores aleatorios, que harán que unas veces funcione y otras no, del tipo:

Traceback (most recent call last):
File "/usr/bin/cloudprint", line 9, in 
load_entry_point('cloudprint==0.14', 'console_scripts', 'cloudprint-cmd')()
File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 620, in main
ppd, description = get_printer_info(cups_connection, name)
File "/usr/share/cloudprint/cloudprint/cloudprint.py", line 372, in get_printer_info
ppd_path = cups_connection.getPPD(printer_name)
cups.IPPError: (1030, 'No encontrado')

Lo conveniente es no tener ese tipo impresoras con driver raw en la máquina desde donde se ejecuta el programa...

Una vez resuelto esto, cuando parece que ya nada puede fallar resulta que al arrancar el programa nos dice:

Establishing connection to xmpp server talk.google.com:5223
ERROR: Could not Connect to Cloud Service. Will Try again in 60 Seconds

La causa de esto es que los chicos de Telefónica nos tienen capado el puerto 5223 de salida y por tanto el servicio no puede comunicarse con Google. Este último obstáculo me hace tirar la toalla y probar con el siguiente software, aunque seguramente fuera de la red educativa si funcionará todo esto.

3. Paquete cloud-print-connector.

Este paquete es mas moderno, tanto que no está en los repositorios de los Debian/Ubuntu mas viejunos. Pero no problem: aunque no hay versión del paquete para Jessie si la hay para Buster y si bajamos el .deb de este enlace veremos que se puede instalar sin problema:

# wget http://ftp.us.debian.org/debian/pool/main/g/google-cloud-print-connector/google-cloud-print-connector_1.12-1+b1_amd64.deb
# dpkg -i google-cloud-print-connector_1.12-1+b1_amd64.deb
# apt-get -f install

Esto es debido a que sus dependencias son bastante relajadas y no necesita versiones muy modernas de los paquetes dependientes, lo cual facilita su integración en sistemas mas antiguos. Supongo que para Ubuntu sucederá algo similar.

Un vez instalado, lo iniciamos a mano tal como cuentan aquí con:

# gcp-connector-util init

Esto nos mostrará unas instrucciones que nos llevan a abrir una página web (con Google Chrome, please) y meter un código de validación en ella. Esto vinculará las impresoras del CUPS de esa máquina con la cuenta de Gmail en la que nos autentiquemos y desde esa cuenta ya podremos imprimir o compartir la impresora hacia otras. El programa que realiza la conexión se arranca:

# gcp-cups-connector &

Pero, claro no es cuestión de arrancarlo a mano cada vez que se reinicie la máquina. Es mas sencillo crear un servicio (el paquete no lo trae, así que lo hacemos a mano):

# cat /etc/systemd/system/cloud-print-connector.service
# Copyright 2016 Google Inc. All rights reserved.
#
# Use of this source code is governed by a BSD-style
# license that can be found in the LICENSE file or at
# https://developers.google.com/open-source/licenses/bsd

[Unit]
Description=Google Cloud Print Connector
Documentation="https://github.com/google/cloud-print-connector"
After=cups.service avahi-daemon.service network-online.target
Wants=cups.service avahi-daemon.service network-online.target

[Service]
ExecStart=/usr/bin/gcp-cups-connector -config-filename /root/gcp-cups-connector.config.json
Restart=on-failure
User=root

[Install]
WantedBy=multi-user.target

Asumimos que /root/gcp-cups-connector.config.json ha sido creado con el "gcp-connector-util init" de antes. Después damos los permisos correctos y activamos el servicio:

# chmod 664 /etc/systemd/system/cloud-print-connector.service 
# systemctl enable cloud-print-connector.service
# systemctl start cloud-print-connector.service
# systemctl status cloud-print-connector.service

Tras varios reinicios se puede comprobar que el servicio funciona correctamente y las impresoras se conectan sin problema a la nube a través de él. Esta vez el firewall de la red educativa no da problemas, por lo que he supuesto usa otros puertos no bloqueados por el firewall corporativo.

4. Otra vuelta de tuerca: traer la impresora de la nube a un CUPS local.

Hemos visto como compartir en la nube las impresoras que están en el CUPS de una máquina. Ahora veremos brevemente como conectar a el CUPS de otro host (por ejemplo un portátil o una máquina que haya en otra sede o en casa) una impresora que está en la nube. La idea es CUPS maquina local-> Google CloudPrint -> CUPS maquina remota.

El conectar la impresora de la nube en un CUPS local nos permite imprimir en ella desde cualquier aplicación, no sólo estaremos limitados a la aplicaciones web de Google.

En esta parte no me voy a prodigar mucho, pongo un enlace y listo: este software. Para Windows tenemos este otro.

---

Voy a recomendar un excelente podcast sobre ciencia al que me he enganchado hace poco hecho en Canal Extremadura Radio: Principio de Incertidumbre. Es una gozada que nuestros impuestos se inviertan en algo útil e importante.

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.

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.

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.

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.