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

martes, 18 de diciembre de 2018

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:

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.

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.