Expediente X(org)

Dado que la administración de sistemas es pariente lejana del vudú, a veces pasan cosas muy misteriosas en nuestras máquinas. Hay aplicaciones que no funcionan como debieran mientras que en otros PC no dan problemas. Voy a contar 3 casos que me han tocado de cerca:

• En las LibreOffice, al ir escribiendo un documento de texto se quedaban en blanco determinadas partes de la pantalla, siendo imposible ver lo escrito.
• El pseudo-driver de las pizarras Interwrite, el Device Manager (hecho en Java, toma moreno), no arrancaba en un PC y por tanto no se mostraba el icono del driver en el panel. Lanzando el LinuxLauncher.sh a mano desde un terminal de las X acababa dando una excepción y un error del tipo:
  

  
  The error was 'BadMatch (invalid parameter attributes)'.
   (Details: serial 253 error_code 8 request_code 73 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
  

• En el software Notebook de las pizarras Smartboard hay una funcionalidad llamada Screen Shade que simula una cortinilla que puedes mover y tapar parte de la imagen (como en los chistes "se baja el telón...") desde los 4 laterales. Al usarlo no funcionaba y no tapaba nada al correr/descorrer las cortinas.

Todo estos expedientes X, que parecen problemas de la aplicación, son realmente problema de la versión o configuración del driver de las X que usamos (es decir, son expedientes X.Org). Hay una manera rápida y segura de confirmarlo: no usando dicho driver y repitiendo la acción, ¿cómo "no usamos dicho driver"?. Bueno, podríamos modificar /etc/X11/xorg.conf para cargar el driver Vesa y reiniciar las X para hacer la prueba, pero no hace falta ser tan drásticos. Hay un par de maneras más sencillas:

• Para probarlo con una aplicación concreta (problema anterior de las LibreOffice): desde otro PC entrar con
  

  # ssh -X usuario@ip-pc-problematico
  

  Y una vez aquí lanzamos la aplicación desde línea de comandos y probamos a intentar repetir el problema. En el caso de LibreOffice ya no se hacían "invisibles" los caracteres escritos.
  La solución que encontraron mis compañeros fue cambiar el driver usado de nouveau a nvidia.
  
• Para probarlo con el escritorio completo (problema anterior del Device Manager de Interwrite o del Screen Shade de Smart Notebook) lo mas rápido es usar xrdp en el PC que da el problema:
  

  # apt-get install xrdp
  

  y conectar mediante rdesktop a él remotamente desde otro:
  

  # apt-get install rdesktop
  # rdesktop ip-pc-problematico
  

  Y una vez hemos hecho login en el escritorio remoto vemos que el problema ya no sucede (ni el de Interwrite ni el de Smartboard).
  

Aquí vemos, dentro de una conexión xrdp, el Device Manager ejecutándose en la parte derecha del panel:

En este caso la solución que encontré fue cambiar el xorg.conf para que la aceleración pasase de ser EXA a SNA.

Y aquí el Notebook con el telón a medio descorrer:

En este caso no he encontrado todavía la solución, pero estoy en ello :-).

Con esto nos queda claro que haciendo la conexión con ssh -X o rdesktop, que no usan el driver X de la máquina destino para los gráficos, no existe ninguno de los problemas descritos. El problema está por tanto en el driver X o en su configuración.

A partir de aquí habría que investigar si procede cambiar el driver (actualizando o instalando la versión propietaria del mismo) o bien generar un xorg.conf y retocar sus esotéricos parámetros (como siempre, a ciegas y sin tener ni idea de lo que estamos haciendo). Con eso tendremos el Expediente X(org) resuelto.

Hasta pronto.....

Monitorizando nuestro SAI con nut (Reloaded-Parte 2)

En la entrada correspondiente a la Parte 1 contaba como monitorizar el SAI desde uno de nuestros servidores. Como estamos de renovación nos han llegado SAIs nuevos Salicru SPS 1500 One, así que voy a actualizar el documento anterior e incluir alguna cosa que quería corregir hace tiempo.

No me queda claro que sea o no un SAI online u offline (ver entrada anterior del blog para saber la diferencia) . Ya he tenido malas experiencias con SAIs offline y servidores HP Proliant (que es el nuevo servidor que nos han mandado), que se apagaban (bueno, se ponían en standby mode, que es casi apagado) antes de que al SAI le diese tiempo a activar la batería. Al primer corte de luz saldremos de dudas y podremos respirar tranquilos o bien darnos cabezazos contra la pared.

1) Configuración para el SAI Salicru SPS One 1500.

Lo primero es ver como se identifica. El lsusb me dice:

~# lsusb
Bus 004 Device 074: ID 0665:5161 Cypress Semiconductor USB to Serial

Buscando el identificador 0665:5161 por Internet el driver adecuado es blazer_usb, así que el fichero ups.conf sería:

~# cat /etc/nut/ups.conf
[salicru]
#Conexión USB falla al poco tiempo y da errores en syslog.
driver = blazer_usb
desc = "SAI Salicru"
port = auto
vendorid = 0665
productid = 5161
bus = "004"

El valor bus="004" tendrá que adaptarse al que tenga cada cual en su caso. Del resto de ficheros de configuración descritos en la anterior entrada del blog no he tocado nada. Bueno, pues solo queda reiniciar los servicios nut-server y ups-monitor:

# /etc/init.d/ups-monitor restart
# /etc/init.d/nut-server restart

Y decirle al SAI, "ola, ke ase?":

~# upsc salicru
battery.charge: 100
battery.voltage: 27.60
battery.voltage.high: 26.00
battery.voltage.low: 20.80
battery.voltage.nominal: 24.0
device.type: ups
driver.name: blazer_usb
driver.parameter.bus: 004
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: 5161
driver.parameter.vendorid: 0665
driver.version: 2.6.4
driver.version.internal: 0.08
input.current.nominal: 6.0
input.frequency: 50.0
input.frequency.nominal: 50
input.voltage: 233.6
input.voltage.fault: 233.6
input.voltage.nominal: 230
output.voltage: 233.6
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 22
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

Parece ser que todo está en orden: me da bien los parámetros y aguanta todo lo que tengo enchufado (4 servidores, 1 monitor, el switch troncal, el switch de cisco y el respaldo 4G de Telefónica). Me preocupa la línea:

ups.type: offline / line interactive. 

Como el servidor nuevo HP sea quisquilloso con los SAI offline eso nos va a dar problemas y el SAI va a ser un bonito adorno, pero seamos positivos como teletubbies y no pensemos en ello de momento.

Nota 23/11/2015: bueno, me congratula anunciar que tras una prueba involuntaria por un corte de corriente puedo afirmar que el servidor Proliant nuevo no se apaga ni se pone en standby al tener que alimentarse solo del SAI. Parece ser que el "line interactive" es suficiente para nuestro servidor.

2) Configuración del envío de correos.

En el post anterior el envío de correos de aviso lo hacia con el programa mailsend, que es una forma rápida y efectiva de enviar correos a través de un servidor SMTP externo. Para ello usaba una función bash con 2 parámetros, el título y el texto del mensaje:

~# cat /root/scripts/mail.sh
function mailSend() {
    mailsend -smtp smtp.gmail.com \
        -port 587 \
        -starttls -auth \
        -user micuenta@gmail.com \
        -pass mipassword \
        -f micuenta@gmail.com \
        -t micuenta@gmail.com \
        -sub "$1" -M "$2"
}

Esta función la incluía mediante "source mail.sh" dentro del script bash desde donde vamos a enviar los correos, en nuestro caso en el script /root/scripts/avisoups.sh descrito en la anterior entrada del blog.

El problema de usar mailsend es que es un comando que no espera: si en el momento de ejecutarlo no puede contactar con el servidor smpt.gmail.com la ejecución es abortada y el envío del mensaje no se realiza. Esto, dentro del contexto que nos ocupa, con el SAI generando eventos seguramente por un corte de corriente hace que tengamos muchas papeletas para que algún switch o router de la red no tenga corriente y no se pueda alcanzar smpt.gmail.com, por lo que la función mailSend no haría un carajo.

Por dicho motivo había que resolverlo de otra manera. Durante un tiempo implementé un sistema de colas de envío construido alrededor de mailsend y gestionado de forma artesanal. Tenía una pinta tan cutre que he decidido borrarlo de la faz de Matrix y no publicarlo aquí ni en ningún otro sitio.

Vaya tontería reinventar la rueda si podemos usar postfix para enviar correos a través de gmail. Siguiendo las instrucciones de dicho enlace ya tenemos un sistema que manda correos usando postfix, basado en hacer un relay de los mensajes a la cuenta SMTP de gmail, que envía el correo. Como postfix si que tiene un sistema de encolado serio y profesional, si intentamos enviar un correo ante un corte de corriente y si no hay respuesta de smtp.gmail.com el mensaje queda encolado para intentarlo mas tarde.

Los ficheros main.cf, sasl_passwd, mailname y sender_canonical quedan finalmente:

~# cat /etc/postfix/main.cf 
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = gmail.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.example.com, miserver.vguadalupe, localhost.vguadalupe, localhost
relayhost =  [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
sender_canonical_maps = hash:/etc/postfix/sender_canonical

~# cat /etc/postfix/sasl_passwd
[smtp.gmail.com]:587    micuenta@gmail.com:mipassword

El comando postmap a continuación crea /etc/postfix/sasl_passwd.db a partir de /etc/postfix/sasl_passwd, de manera que no se guarda la contraseña en texto plano sino en cifrado.

~# postmap hash:/etc/postfix/sasl_passwd

~# cat /etc/mailname 
gmail.com

~# cat /etc/postfix/sender_canonical
root micuenta@gmail.com
~# postmap /etc/postfix/sender_canonical

Para que los mensajes lleguen apareciendo como remitente micuenta@gmail.com en lugar de el aséptico "root" hay que retocar un poco los parámetros del comando "mail", que es el que usaremos para enviar los mensajes en lugar de "mailsend" ya que "mail" los envía a través del gestor de correos de salida por defecto, en nuestro caso postfix:

~# cat /root/scripts/mail.sh
function mailSend() {
echo "$2" | mail -s "$1" -a "From: avisos.ies "  cuenta.destino@gmail.com
}

3) Uso de knutclient para controlar el SAI desde nuestro PC de trabajo

Esta es una sugerencia de mi compañero Paco, del IES Garcia Téllez. Tengo pendiente probarla y describir aquí que tal va en una futura entrada. Se basa en que el nut es un sistema cliente-servidor, así que nada impide instalar un cliente nut gráfico en mi PC que contactará con el servidor remoto y me mostrará en la barra de tareas el estado del SAI. Una vía interesante para explorar.

Bueno, pues hasta pronto si la invasión de Microsoft y Adobe que esperamos en los centros educativos de Extremadura nos deja vivos. Siempre nos quedará Masada.

Addenda 29-marzo-2016: Bueno, pues después de unos meses monitorizando el SAI hemos tenido un problema bastante puñetero. Tarde o temprano el SAI dejaba de comunicarse con el PC y llenaba el syslog con mensajes:

Nov 12 14:27:21 servidor kernel: [  798.728084] usb 1-2: USB disconnect, device number 72
Nov 12 14:27:23 servidor kernel: [  800.628034] usb 1-2: new low-speed USB device number 73 using uhci_hcd
Nov 12 14:27:23 servidor kernel: [  800.806068] usb 1-2: New USB device found, idVendor=0665, idProduct=5161
Nov 12 14:27:23 servidor kernel: [  800.807639] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 12 14:27:23 servidor kernel: [  800.809114] usb 1-2: Product: USB to Serial
Nov 12 14:27:23 servidor kernel: [  800.810592] usb 1-2: Manufacturer: INNO TECH
Nov 12 14:27:23 servidor kernel: [  800.842240] hid-generic 0003:0665:5161.0048: hiddev0,hidraw0: USB HID v1.00 Device [INNO TECH
USB to Serial] on usb-0000:00:1d.0-2/input0
Nov 12 14:27:33 servidor kernel: [  810.136084] usb 1-2: USB disconnect, device number 73
Nov 12 14:27:34 servidor kernel: [  811.680031] usb 1-2: new low-speed USB device number 74 using uhci_hcd

Y así horas y horas. A veces se solucionaba reiniciando el servidor (que gracia), o desconectando el SAI, o reiniciando el servicio nut. La mayoría de las veces no había otra opción que desconectarlo del USB antes de que el syslog explotase.

Los de soporte técnico de HP han puesto cierto interés en arreglarlo, pero sin grandes resultados. Propusieron usar el parámetro POLLFREQ con valor 2 en upsmon.conf, pero no sirvió de nada. También intentaron convencerme de que abandonase nut y usase ViewPower/WinPower, un monstruo propietario hecho en Java (agárrate, Manuel) para monitorizar el SAI. Ni de coña.

Al final nuestro compañero Carlos Martín me configuró esto:

# cat /etc/nut/ups.conf:
......
......
# Set maxretry to 3 by default, this should mitigate race with slow devices:
maxretry = 3

[salicru]
driver = blazer_usb
port = auto

Y con ese mágico maxretry llevo varios meses en mis dos SAIs sin más problema de comunicación. Carlos: eres un crack.