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

martes, 29 de diciembre de 2015

Configuracion de una impresora Multifunción Epson WorkForce Pro WF-8590 en el IES

En esta lluvia de millones que nos atenaza nos han llegado unas impresoras multifunción A3 Epson WorkForce Pro WF-8590 Series que nos vendrán muy bien con la impresión de planos y diseños varios y con la cartelería del centro. El problema es que son de inyección de tinta y esta por ver cuanto cuestan los repuestos y que tal aguantan nuestro verano extremo-y-duro. Ya haré un memorándum el próximo septiembre si sobrevivimos a la flama.

La he configurado para el uso normal sin problemas, pero he tenido algunos contratiempos para hacerla funcionar tal como quiero y paso a relatarlos por si hay que usarlos otra vez.

Drivers para Linux.

Los drivers se descargan como paquete .deb de la página de epson, en concreto estoy usando estos:
# dpkg -l | grep epson
ii  epson-inkjet-printer-escpr            1.6.1-1lsb3.2                     i386         Epson Inkjet Printer Driver (ESC/P-R) for Linux
En cups se da de alta sin problema, apareciendo como Epson WF-8590 (Seiko Epson Corporation LSB 3.2) (color, 2-sided printing).

Un primer problema es que al imprimir desde Linux lo hace con tonos muy tenues, como si estuviese en modo borrador. Eso se soluciona configurando en cups, dentro de las propiedades predeterminadas de la impresora el parámetro "Media Type->Plain papers – high".

Google Cloud Print.

La impresora es compatible con Google Cloud Print, lo que permite asociarla a una cuenta de Gmail e imprimir en ella desde cualquier lugar del mundo y desde la Estación Espacial Internacional habiendo iniciado sesión en dicha cuenta con Google Chrome. Esta opción es muy cómoda para la directiva, que puede mandar imprimir desde casa y encontrarse las cosas impresas al llegar al centro.

En las pruebas preliminares esta opción fallaba: al intentar registrar la impresora me decía que no había conexión y que revisase la configuración de red, pero mi compañero Esteban decía que en su IES la habían hecho funcionar: actualicé el Firmware a la última versión con el programa de Epson para tal fin (en esta ruta está dentro de la opción firmware), me aseguré de que el puerto 5222 estaba abierto en mi red (con http://portquiz.net:5222/ se comprueba en un periquete), .....

Al final el problema estaba en que, preso de la paranoia, había puesto un filtrado IP en la impresora para permitir imprimir solo a determinadas IP del IES. Dicho filtrado IP por lo visto también afecta a Google Cloud Print e imposibilita su uso. Desactivando el filtrado en cuestión se resuelve el problema. Es una lata dejarlo asi pero no hay otro remedio.

Conteo de paginas con tea4cups y pkpgcounter

Como siempre, al ser una impresora de red, me interesa que se cuenten las páginas que se imprimen desde determinados sitios. En las pruebas descubro que pkpgcounter siempre cuenta 1 página, independientemente del tamaño del documento. Estaba claro que no era capaz de procesarlo bien.

Como otras veces, lo primero que hago es capturar el fichero bruto .prn enviado a la impresora mediante el script asociado a tea4cups y me dispongo a analizarlo.

Después de investigar un rato averiguo que el fichero viene en formato ESC/P-R, que es una evolución del formato ESC/P2 tradicional de Epson. Pkpgcounter lo reconoce como ESC/P2 pero al ser un formato diferente no es capaz de contar bien las páginas. Tenía que averiguar cual es la cadena de bytes que hace la separación de páginas.

Afortunadamente, el driver de Epson es GPL, lo cual significa que tenemos el código fuente disponible. Lo descargo del primer lugar donde encuentro los fuentes: la página del paquete en Ubuntu (es la version 1.1.1, un poco antigua, pero no creo que esa parte haya cambiado mucho). Es un fichero epson-inkjet-printer-escpr-1.1.1.targ.gz que descomprimo y tras investigar un rato en los ficheros .c y .h y con un poco de intuición encuentro, que en el fichero ./epson-inkjet-printer-escpr-1.1.1/lib/escpr_cmd.c:

static const ESCPR_UBYTE1 cmd_EndPage[] = {
     0x1B,  'p', 0x01, 0x00, 0x00, 0x00,  'e',  'n',  'd',  'p'};
Por tanto, esta secuencia de 10 bytes son los números mágicos del fin de pagina.

Para que se tengan en cuenta al ejecutar pkpgcounter hay que modificar el fichero /usr/share/pyshared/pkpgpdls/escp2.py, quedando en negrita lo que debo añadir:
.....
....
marker4 = "\f\033@"
        
#  En ESC/P-R el fin de pagina es
#   {0x1B,  'p', 0x01, 0x00, 0x00, 0x00,  'e',  'n',  'd',  'p'}
#  Sacado del codigo fuente fichero escpr_cmd.c
marker5 = "\033p\001\000\000\000endp"
     
pagecount2 = max(data.count(marker2r), data.count(marker2rn))
pagecount3 = data.count(marker3)
pagecount4 = data.count(marker4)
pagecount5 = data.count(marker5)
         
if pagecount2 :    
 return pagecount2
elif pagecount3 > 1 :  
 return pagecount3 – 1
elif pagecount4 :    
 return pagecount4
elif pagecount5>=1:
 return pagecount5
else :
 return int(pagecount1 / 2)
....
....

Y con esto conseguimos que cuente bien este formato. Mandaría el parche al creador de pkpgcounter, pero ya he mandado otro y no me ha dicho nada, lo cual me hace pensar que nadie mantiene ya el programa. Bueno, pues aquí queda.

Compartir la impresora desde CUPS.

Al compartir la impresora desde CUPS con una máquina que hará de servidor de impresión me surgió un problema adicional: si imprimo desde clientes Windows y algunos Linux (tengo varios tipos de Debian, Ubuntu, Mint y luego mi Manjaro), los trabajos se pierden en el limbo y nunca llegan, sin dar ningún error visible.

Los únicos que no se perdían eran los enviados desde aquellos clientes en que la versión del driver era exactamente igual en máquina cliente y servidora. Por supuesto, eso eliminaba de forma fulminante a los Windows como posibles clientes y con ello el control de páginas impresas mediante tea4cups. Había que encontrar una solución.

Tras varias pruebas descubro el truco para evitarlo: dar de alta la impresora en el servidor de impresión con el driver “Local Raw Printer”, que debe ser un driver que envía las cosas tal cual le llegan, sin procesar. De esta manera el fichero de impresión llega ya preparado en ESC/P-R desde el driver del cliente, las páginas son contadas por pkpgcounter y todo es reenviado sin mayor problema a la impresora.

El único problema que tiene esto es intentar imprimir algo en local en la máquina servidora. Al ser el driver “Local Raw Printer” se envía sin procesar y obtenemos esa impresión tan espectacular de folios y folios de lo que los usuarios semiavanzados llaman “código máquina”.

Conteo de impresión a varias copias.

Otro problema que encontré con determinados drivers de Linux es que si enviaba una impresión de varias páginas y varias copias se producía un error muy irritante que sucede a veces: si el documento es de 3 paginas y se hacen 2 copias, el driver envía un documento de 6 páginas (3 x 2) y dice que haga 2 copias. La impresora ignora el parámetro número de copias y todo sale bien, excepto el conteo en tea4cups que cuenta 6x2=12 páginas en lugar de las 6 impresas.

Para evitarlo hay que modificar el script de seguimiento de impresión que es invocado desde tea4cups en los PC donde el driver haga esa pirula, quedando:

# cat /../.../..../ seguimiento_impresion

.....
.....
#Hay que convertir el valor de TEACLIENTHOST en un nombre de equipo.
if [ "$TEACLIENTHOST" == "localhost" -o "$TEACLIENTHOST" == "" ]
then
   equipo=$(hostname -s)
else
   if valid_ip $TEACLIENTHOST
   then
      equipo=$(host $TEACLIENTHOST | cut -d" " -f5 | cut -d"." -f1)
   else
      equipo=$TEACLIENTHOST
   fi
fi

#La impresora VGIM_JEFATURA mete el numero de copias en el conteo de paginas. 
# Un documento de 2 paginas impreso con 3 copias
# se manda con determinados drivers de linux  como "documento de 6 paginas con 3 copias", 
# lo que da un conteo de 18 en lugar de 6. Hay que corregir eso ajustando el $paginas que se ha
# obtenido con pkpgcounter. 
if [ "$TEAPRINTERNAME" == "VGIM_JEFATURA" ]
then
  $paginas = $(( $paginas / $TEACOPIES ))
fi

.....
.....

exit 0

De esta manera, al dividirlo por el número de copias el número de páginas coge su valor correcto.

Y con estas pequeñas recetas ya tenemos nuestra impresora operativa e integrada en la red del centro. Seguiremos informando....

domingo, 27 de diciembre de 2015

La conjura de los necios (II): cuando el río suena, agua lleva (y pulseaudio funciona).


Un problema que sucede frecuentemente en la vida es la sensación de "falsa unanimidad" o al menos "falsa mayoría" en muchos temas, en los que buena parte de aquellos con los que nos relacionamos, o a quienes escuchamos, coinciden con nosotros. No se dejen engañar: eso es un sesgo cognitivo.

Por eso es una costumbre buena para la salud mental escuchar opiniones de terceros y de contrarios, para salir de nuestro pequeño círculo y comparar hasta que punto tenemos razón o no, poniendo a prueba nuestras convicciones.

En todos estos quebrantos sobre la nueva dotación TIC que nos tienen ocupados (La conjura de los necios (I)) nos encontramos que al menos 125 de 160 administradores informáticos opinamos de igual manera (y el resto no se pronuncia en contra) sobre todo este proceso de introducción del software propietario como Caballo de Troya dentro un contrato TIC que se está ejecutando con un caos que ni el ejército de Pancho Villa. Esta mayoría "a la búlgara" hace sospechar a mi espíritu crítico que quizá no tengamos toda la razón....o quizá si la tengamos y que nuestras afirmaciones sean producto del sentido común mas evidente.

Este post que aquí enlazo del blog de Ramón Besonías, coordinador TIC del IES San José de Badajoz (tras este anuncio de reunión), en el que comparte las opiniones de los administradores informáticos además de reclamar también aspectos de su labor me hace pensar que efectivamene tenemos razón. Toda la razón. Gracias por tu apoyo, compañero.

Hay que recordar que la mayor parte de los coordinadores TIC hasta ahora han sido ajenos a todo este proceso, debido seguramente a su aislamiento y dispersión sin herramientas de comunicación de uso masivo y compartido (adicionalmente algunos, como los coordinadores TIC de las CEPA no han sido ni convocados a estas reuniones). Por tanto, el que la postura de un tercero, con la cualificación pertinente para que su opinión sea tenida en cuenta, sea similar a la de nuestro colectivo es un indicio de que vamos por el camino correcto.

Quizá nuestros superiores podrían pensar en el chiste:

Un conductor que circula por la autopista oye una noticia que daban en esos momentos por la radio que decía:
-Atención, se informa que hay un conductor loco por la autopista que circula en sentido contrario, se ruega precaución.
A lo que el conductor en cuestión dice asustado y dando sucesivos volantazos:
-¡Qué coño uno, si son todos!
Y aplicar algo de autocrítica, dejándose de noticias triunfalistas, y tramposas como esta que enlazo.

Feliz Saturnalia y entrada de año, compañeros.

miércoles, 16 de diciembre de 2015

Monitorizando nuestro SAI con nut (Parte 3)

Bueno, salimos del fango de la política, lo dejamos para mas adelante y seguimos con nuestras cosas.

Venimos de aquí y de aquí, donde vimos como controlar nuestro SAI con nut y poder manejar los eventos para enviar notificaciones a través del correo electrónico y ejecutar acciones personalizadas.

En esta entrada vamos a ver como monitorizar el SAI desde un PC donde no está conectado directamente (por ejemplo, desde nuestro PC de trabajo o desde un servidor distinto al que tiene el SAI conectado) para ello usaremos el sistema maestro-esclavo que implementa nut.

1. Configuración del maestro.

El maestro es el PC al que tenemos conectado nuestro SAI con un cable USB/Serie y se encarga de monitorizarlo directamente. En las dos entradas previas vimos como configurarlo en gran medida, pero si queremos que tenga esclavos que se conecten a él hay que modificar algunas cosas. Daremos un rápido repaso:

En /etc/nut/hosts.conf:
........
MONITOR salicru@localhost "SAI Salicru IES Virgen de Guadalupe"
En /etc/nut/nut.conf hay que cambiar el mode (antes estaba en standalone):
.....
MODE=netserver
......
El fichero /etc/nut/ups.conf lo dejamos igual. En /etc/nut/upsd.conf ponemos localhost y la IP de la máquina donde esta conectado el SAI:
LISTEN 127.0.0.1
LISTEN 172.X.Y.Z #IP de la máquina donde esta corriendo el nut.
En /etc/nut/upsd.users debemos incluir un usuario para los clientes/esclavo:
[admin]
password = pwd_admin
allowfrom = localhost local_network
actions = SET
instcmds = ALL

[control]
password = pwd_control
allowfrom = localhost local_network
upsmon master

[clientes]
password = pwd_clientes
upsmon slave
El fichero /etc/nut/upsmon.conf (es el que configura el proceso upsmon que monitoriza el SAI):
MONITOR salicru@localhost 1 control pwd_control master
RUN_AS_USER nut
MINSUPPLIES 1
SHUTDOWNCMD "/root/scripts/apagar_servidores.sh"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower

NOTIFYCMD "/sbin/upssched"

NOTIFYMSG ONLINE "UPS: Normal state"
NOTIFYMSG ONBATT "UPS: On battery"
NOTIFYMSG LOWBATT "UPS: Battery low"
NOTIFYMSG FSD "UPS: Starting shutdown"
NOTIFYMSG COMMOK "UPS: Communication restored"
NOTIFYMSG COMMBAD "UPS: Communication lose"
NOTIFYMSG SHUTDOWN "UPS: Shutting down"
NOTIFYMSG REPLBATT "UPS: Replace battery"

NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC
NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC

RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 0

Los ficheros /etc/nut/upssched.conf, /etc/nut/upsset.conf y /etc/nut/upsstats.html quedan igual. Después de modificar todo esto reiniciamos los procesos:

# /etc/init.d/nut-server restart
# /etc/init.d/nut-client restart

2. Configuración del esclavo.

En el esclavo (que puede ser un PC normal desde el que queremos acceder al estado del SAI o bien otro servidor que quiere monitorizar el SAI pero no lo tiene conectado directamente) basta con instalar el paquete nut-client:
# apt-get install nut-client
Veamos ahora los ficheros que hay configurar para el esclavo. El primero es /etc/nut/nut.conf:
.....
MODE=netclient
......
Siguiente, /etc/nut/upsmon.conf:
MONITOR salicru@172.X.Y.Z 1 clientes pwd_clientes slave
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

El fichero /etc/nut/upssched.conf no lo tocamos a no ser que queramos actuar ante los distintos eventos, en ese caso configurariamos upsmon.conf y upssched.conf como se hizo en la primera parte de esta serie de artículos. El resto de ficheros tampoco los tocamos.

Ahora reiniciamos el servicio:
# /etc/init.d/nut-client restart
Y preguntamos al SAI en el servidor remoto "Ola, ke ase?":
# upsc salicru@172.X.Y.Z
Si todo está bien nos contestará con:
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
.....
.....

Si no funciona siempre podemos ejecutar a mano:
# upsmon -D 
que arranca el cliente nut en modo debug, lo cual nos muestra los posibles errores por pantalla.

3. Usando en Debian Wheezy knutclient.

Otra forma interesante de monitorizar el SAI que usa Paco, mi compañero del IES García Téllez, es con el cliente gráfico knutclient, que ejecuta un programa en el systray del escritorio de tu PC y con un clic de ratón te muestra el estado del SAI.

El paquete no existe para Debian, pero podemos bajar la versión knutclient-1.0.4-2.mga2.i586.rpm de Mageia en este enlace y luego convertirla en un paquete .deb con el comando alien de Debian, instalando después el paquete creado:.

# wget ftp://fr2.rpmfind.net/linux/mageia/distrib/2/i586/media/core/release/knutclient-1.0.4-2.mga2.i586.rpm
....
# alien knutclient-1.0.4-2.mga2.i586.rpm
....
# dpkg -i knutclient_1.0.4-3_i386.deb

Esta versión es totalmente compatible con nuestro Debian Wheezy, aunque quizá para versiones mas modernas de Debian habría que coger también una versión mas moderna del paquete. El contenido del paquete es:

/.
/usr
/usr/share
/usr/share/applications
/usr/share/applications/kde4
/usr/share/applications/kde4/knutclient.desktop
/usr/share/icons
/usr/share/icons/locolor
/usr/share/icons/locolor/16x16
/usr/share/icons/locolor/16x16/apps
/usr/share/icons/locolor/16x16/apps/knutclient.png
/usr/share/icons/locolor/32x32
/usr/share/icons/locolor/32x32/apps
/usr/share/icons/locolor/32x32/apps/knutclient.png
/usr/share/icons/hicolor
/usr/share/icons/hicolor/22x22
/usr/share/icons/hicolor/22x22/apps
/usr/share/icons/hicolor/22x22/apps/knutclient.png
/usr/share/icons/hicolor/16x16
/usr/share/icons/hicolor/16x16/apps
/usr/share/icons/hicolor/16x16/apps/knutclient.png
/usr/share/icons/hicolor/48x48
/usr/share/icons/hicolor/48x48/apps
/usr/share/icons/hicolor/48x48/apps/knutclient.png
/usr/share/icons/hicolor/32x32
/usr/share/icons/hicolor/32x32/apps
/usr/share/icons/hicolor/32x32/apps/knutclient.png
/usr/share/locale
/usr/share/locale/pt_BR
/usr/share/locale/pt_BR/LC_MESSAGES
/usr/share/locale/pt_BR/LC_MESSAGES/knutclient.mo
/usr/share/locale/ru
/usr/share/locale/ru/LC_MESSAGES
/usr/share/locale/ru/LC_MESSAGES/knutclient.mo
/usr/share/locale/uk
/usr/share/locale/uk/LC_MESSAGES
/usr/share/locale/uk/LC_MESSAGES/knutclient.mo
/usr/share/locale/de
/usr/share/locale/de/LC_MESSAGES
/usr/share/locale/de/LC_MESSAGES/knutclient.mo
/usr/share/locale/fr
/usr/share/locale/fr/LC_MESSAGES
/usr/share/locale/fr/LC_MESSAGES/knutclient.mo
/usr/share/locale/pl
/usr/share/locale/pl/LC_MESSAGES
/usr/share/locale/pl/LC_MESSAGES/knutclient.mo
/usr/share/locale/es
/usr/share/locale/es/LC_MESSAGES
/usr/share/locale/es/LC_MESSAGES/knutclient.mo
/usr/share/locale/cs
/usr/share/locale/cs/LC_MESSAGES
/usr/share/locale/cs/LC_MESSAGES/knutclient.mo
/usr/share/locale/it
/usr/share/locale/it/LC_MESSAGES
/usr/share/locale/it/LC_MESSAGES/knutclient.mo
/usr/share/doc
/usr/share/doc/HTML
/usr/share/doc/HTML/cs
/usr/share/doc/HTML/cs/knutclient
/usr/share/doc/HTML/cs/knutclient/mkicker-cs.png
/usr/share/doc/HTML/cs/knutclient/knutclient-cs.png
/usr/share/doc/HTML/cs/knutclient/variables-cs.png
/usr/share/doc/HTML/cs/knutclient/index.docbook.gz
/usr/share/doc/HTML/cs/knutclient/psetting-cs.png
/usr/share/doc/HTML/cs/knutclient/msetting-cs.png
/usr/share/doc/HTML/cs/knutclient/index.cache.bz2
/usr/share/doc/HTML/cs/knutclient/fsetting-cs.png
/usr/share/doc/HTML/cs/knutclient/new-cs.png
/usr/share/doc/HTML/cs/knutclient/ksetting-cs.png
/usr/share/doc/HTML/cs/knutclient/tkicker-cs.png
/usr/share/doc/HTML/cs/knutclient/usetting-cs.png
/usr/share/doc/HTML/cs/knutclient/asetting-cs.png
/usr/share/doc/HTML/en
/usr/share/doc/HTML/en/knutclient
/usr/share/doc/HTML/en/knutclient/asetting-en.png
/usr/share/doc/HTML/en/knutclient/knutclient-en.png
/usr/share/doc/HTML/en/knutclient/index.docbook.gz
/usr/share/doc/HTML/en/knutclient/variables-en.png
/usr/share/doc/HTML/en/knutclient/fsetting-en.png
/usr/share/doc/HTML/en/knutclient/index.cache.bz2
/usr/share/doc/HTML/en/knutclient/mkicker-en.png
/usr/share/doc/HTML/en/knutclient/ksetting-en.png
/usr/share/doc/HTML/en/knutclient/psetting-en.png
/usr/share/doc/HTML/en/knutclient/msetting-en.png
/usr/share/doc/HTML/en/knutclient/new-en.png
/usr/share/doc/HTML/en/knutclient/usetting-en.png
/usr/share/doc/HTML/en/knutclient/tkicker-en.png
/usr/share/doc/knutclient
/usr/share/doc/knutclient/README
/usr/share/doc/knutclient/ChangeLog.gz
/usr/share/doc/knutclient/AUTHORS
/usr/share/doc/knutclient/changelog.Debian.gz
/usr/share/doc/knutclient/copyright
/usr/share/apps
/usr/share/apps/knutclient
/usr/share/apps/knutclient/knutclientui.rc
/usr/share/apps/knutclient/knutclient.notifyrc
/usr/share/apps/knutclient/pics
/usr/share/apps/knutclient/pics/knc_conn.png
/usr/share/apps/knutclient/pics/knc_batt.png
/usr/share/apps/knutclient/pics/knc_ups.png
/usr/share/apps/knutclient/pics/knc_mpref.png
/usr/share/apps/knutclient/pics/knc_dock.png
/usr/share/apps/knutclient/pics/knc_panel.png
/usr/share/apps/knutclient/pics/knc_upses.png
/usr/share/apps/knutclient/pics/knc_mset.png
/usr/share/apps/knutclient/pics/knc_error.png
/usr/share/apps/knutclient/pics/knc_main.png
/usr/share/apps/knutclient/pics/knc_analog.png
/usr/bin
/usr/bin/knutclient
/usr/share/doc/HTML/cs/knutclient/common
/usr/share/doc/HTML/en/knutclient/common
Para que se arranque automaticamente al iniciar sesión habría que copiar /usr/share/applications/kde4/knutclient.desktop en /etc/xdg/autostart/knutclient.desktop. Durante las pruebas de configuración lo mejor es arrancarlo a mano desde terminal tecleando "knutclient". Al ejecutarla se minimiza al systray, en la parte derecha del panel:


Pulsando sobre ella con el botón derecho aparece el menú:


Elegimos "Opciones" para configurar:


Y damos de alta nuestro SAI (basta con dar dirección del SAI-ip o nombre de host-, nombre, usuario y contraseña, tal como hicimos en el apartado 2 en upsmon.conf):


Una vez configurado, pulsando sobre el icono en el systray con el botón izquierdo aparecerá el cuadro de mandos con los indicadores:
La configuración se hace mediante el entorno gráfico, pero se guarda en un fichero que quedaría mas o menos así:
# cat ~/.kde/share/config/knutclientrc 
APanelBackGroundColor=192,192,192
ActiveUps=Salicru
AnalogErrorColor=255,0,0
...............
...............
Width 1440=978

[UPS 0]
Delay=5000
Name=Salicru
Password=pwd_cliente
Port=3493
SavePassword=true
UpsAddress=172.X.Y.Z
UpsName=salicru
UserName=cliente
...............
...............
Var 9=7

Si no nos funciona la conexión desde knutclient, la forma mas sencilla de revisar todo es configurar el cliente como en el apartado 2, con nut-client y una vez funcione, meter la configuración que ya hemos probado en knutclient.

4. Bonus track: comandos útiles y curiosos.

Veamos varios comandos y trucos que pueden venir para manejar el nut y probarlo.

El primero es como generar eventos para verificar que funciona el log, el envío de correos e incluso el apagado. Si hacemos
# upssched
Error: UPSNAME and NOTIFYTYPE must be set.
This program should only be run from upsmon.
Nos da un error diciendo que no va, pero si lo hacemos así:
# export UPSNAME="salicru@localhost"
# export NOTIFYTYPE="ONBATT"
# upssched
Se genera el evento ONBATT que será procesado por el script upssched-cmd como si el SAI se hubiera puesto en modo batería realmente.

El segundo es como dar ordenes inmediatas al SAI:
# upscmd -l salicru
Instant commands supported on UPS [salicru]:

beeper.toggle - Toggle the UPS beeper
load.off - Turn off the load immediately
load.on - Turn on the load immediately
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
shutdown.stop - Stop a shutdown in progress
test.battery.start - Start a battery test
test.battery.start.deep - Start a deep battery test
test.battery.start.quick - Start a quick battery test
test.battery.stop - Stop the battery test
Por ejemplo, con:
# upscmd salicru@localhost beeper.toggle
Desactivamos el molesto beeper (pitido) si está sonando.

El tercero es como simular una orden de apagado inmediata (fsd=forced shutdown):
# upsmon -c fsd
Hay varios comandos más de todo tipo, estos son solo un repasito de lo que me ha resultado mas interesante.

5. Bonus track 2: apagado de los servidores desde nut.

Creo que la última cosa que queda pendiente es el apagado de los servidores desde nut cuando la batería está ya tiritando. Hay dos maneras:
  • La primera es al ejecutarse el comando definido en upsmon.conf mediante SHUTDOWNCMD. Se supone que dicho comando se ejecuta mas o menos cuando salta el evento LOWBATT, pero en mis pruebas no hay manera de hacer que salte automáticamente dicho evento (ni de definir un umbral de carga para que salte), quizá porque el driver del SAI no interpreta bien el dato de la carga de la batería.
  • La segunda es con el método de usar en upssched.conf un TIMER -de los minutos que estimemos oportunos- que llame al script de manejo de eventos con "ups-on-battery-shutdown". Esto hará que cuando el sistema lleve tirando de batería X minutos se llame a dicho script, que a su vez llama a otro script que denominé en anteriores entradas "apagar_servidores.sh", que se encarga de hacer shutdown en los servidores. El problema encontrado aquí es que upssched-cmd se ejecuta como usuario "nut" y por tanto, no puede hacer un shutdown así por las buenas donde nos plazca.
Como se ve, ninguno de los dos métodos funciona por lo que mis máquinas no se apagan de forma ordenada si se agota la batería, algo muy lamentable. ¿Como solucionarlo?. Cuando lo sepa lo cuento, ya que:


Continuamos pronto, ya con el R78 mas debilitado si hubiere suerte tras las próximas elecciones.



miércoles, 9 de diciembre de 2015

La conjura de los necios (I): cuando Microsoft entra por la puerta, el software libre salta por la ventana.

En los últimos meses ha habido bastante agitación en nuestro colectivo de administradores informáticos de los IES, IESO y CPR de la red de centros públicos de la Junta de Extremadura. La causa son dos problemas independientes pero interrelacionados:

El primero es la total ausencia de comunicación con la jefatura del Servicio de Tecnologías de la Información y la Comunicación, del que dependemos directamente para el desempeño de nuestras funciones. No es de recibo que dicha estructura nos haya ignorado de forma reiterada durante años, sin ningún tipo de comunicación y menos aún de feedback. Eso ha provocado los siguientes problemas:

  • Años después muchos usuarios todavía no tienen claras cuales son nuestras funciones, lo cual es normal que pase con el personal informático pero no de forma tan exagerada como es nuestro caso, lo que da lugar tanto a anécdotas divertidas como a malentendidos.
  • Nunca se nos ha tenido en cuenta a la hora de la toma de decisiones en nuestra faceta de técnicos, minusvalorando nuestra formación como Ingenieros Técnicos en Informática e Ingenieros en Informática.
  • Nunca se nos ha tenido en cuenta a la hora de la toma de decisiones en nuestra faceta de personal de primera línea. Estamos en la base de la pirámide del soporte a los centros y tener en cuenta nuestra opinión, simplemente por la experiencia que da estar en el frente, antes de implantar algunas soluciones (tomada en despachos lejanos y ajenos a la realidad) hubiera ahorrado mucho dinero y quebrantos a la Administración Educativa.

De todas maneras, esto son disputas internas que han de resolverse también internamente, aunque su existencia haya motivado la aparición del problema más grave.

El segundo problema quiebra los principios que han fundado la política en materia de TIC de Extremadura en los últimos 13 años, según esta secuencia de hechos:

  1. El anterior gobierno de la Junta de Extremadura (PP) dejó como herencia una licitación por importe de 38 millones de euros (recibidos de fondos europeos y de Red.es) en la que se incluía el pago de licencias para la introducción de forma generalizada del software propietario (principalmente Microsoft y Adobe) en la red de centros públicos.
  2. Como al parecer el nuevo gobierno no tenía interés en enmendar la licitación y nuestro Servicio la redactó y la convocó tal cual estaba diseñada desde un principio, nuestro colectivo, que no había sido consultado para nada en los detalles técnicos de la los pliegos y como conocedores de primera mano de la realidad de los centros educativos, se movió: se publicó una carta abierta de protesta, se hicieron entrevistas en radio y se consiguió visibilidad en los medios de comunicación.
  3. Debido seguramente al pánico que sienten los políticos a aparecer así en los medios de comunicación, se convocó una reunión en julio de 2015 a la que asistimos miembros de mi colectivo y de varios mas: profesorado TIC, directores de centros educativos, personal de nuestro Servicio y varios altos cargos del gobierno del PSOE.
  4. En dicha reunión el sentir mayoritario era volver a la situación anterior, con apoyo total al software libre, aunque la Jefatura de Servicio (tanto el Jefe de Servicio como sus asesores) defendían la introducción del software propietario en igualdad de condiciones en base a una encuesta realizada hace años a los docentes (la cual, curiosamente, la inmensa mayoría de los docentes consultados por mí no recuerda haber hecho), encuesta de la que no tenemos datos brutos y solo conclusiones (lo cual es una ofensa mayúscula para un defensor a ultranza de la transparencia como es mi caso) y que esas conclusiones apuntan al disparate de que si se da una oportunidad al software propietario, las TIC serán mas usadas por el profesorado.
  5. Durante la reunión, después de oír a todas las partes, los altos cargos reafirmaron su apuesta por el software libre y al finalizar se consensuó que se volvía al sistema anterior: prioridad absoluta del software libre y se dejaba al software propietario solo para casos debidamente justificados. Se acordó no paralizar la licitación en marcha ya que los plazos se agotaban, pero no se daría uso a las licencias de software propietario adquiridas. En pocos días se emitieron esperanzadoras notas de prensa al respecto.
  6. Una vez se ha resuelto la licitación (sobre cuyos claroscuros hablaré en otro momento) y los centros han empezado a recibir el material asignado, nos hemos llevado la sorpresa de que lo comprometido se ha obviado por completo: los dispositivos vienen con arranque dual (Windows-Ubuntu) activado y no tenemos instrucción alguna de como manejar esta situación. Nadie responde a nuestras preguntas.
  7. Nuestras quejas, tanto en foros internos como en medios públicos (1, 2) y nuestros intentos de nuevos contactos con la Administración Educativa que hay por encima de la Jefatura de Servicio no han tenido éxito y lo más que hemos conseguido es una convocatoria de reunión con la Jefatura de Servicio en enero de 2016 (ya hemos tenido varias convocatorias de reunión no celebradas) en la que sospechamos se aplicará una política de hechos consumados y se nos comunicará que esto son lentejas...
  8. Mientras tanto el PSOE quizá seguirá manteniendo un discurso cuando no gobierna ("apoyamos el software libre") y unas acciones y hechos totalmente contrarios cuando gobierna ("es que ..."), como bien avisan ahora sus oponentes políticos.
  9. Y finalmente mis compañeros administradores de los centros seguirán sacando el trabajo adelante, con las escasas herramientas y formación que nos dan, y aplicando mucha solidaridad y trabajo colaborativo. Como dice el Cantar del Mio Cid "¡Que buen vasallo si hubiese un buen Señor!".

Mis conclusiones:

  • Pensar que por implantar software propietario, contraviniendo la legislación y Estatuto de Autonomía propios, se va a incrementar el uso de las TIC en el sistema educativo es muestra de no tener ni la menor idea de cual es la causa de que una parte del colectivo docente no use las TIC en el aula.
  • Meter software propietario como opcional al software libre es dinamitar el uso del software libre, que no se usará por simple pereza.
  • Como ya está mas que probado, el software propietario te lleva a un mercado cautivo del que es muy difícil salir. Un paso en esa dirección puede atarte durante años .

Y hasta aquí puedo leer....por ahora.

miércoles, 2 de diciembre de 2015

Una modesta propuesta sobre el montaje de pizarras digitales

A estas alturas del baile llevamos ya experimentadas varias soluciones de implantación de pizarras digitales en nuestras aulas. Las mas extendidas (las SmartBoard y Galneo) nos han obligado a adaptar el aula a las limitaciones del cableado de la pizarra. Me explico:

  • En las SmartBoard 480 el cable USB es de datos y alimentación, mientras que el PC que la controla está en la mesa del profesor. Hace falta un cable USB activo de no más de 5 metros que obliga al PC a estar como máximo a 5m de la pizarra, lo que provoca cables tirantes y problemas de señal inestable en cuanto este se afloja un poco alguna de la conexiones.
  • En las Galneo tenemos el mismo problema con el cableado, pero se adopta la idea de dejar el PC debajo de la pizarra en una caja que sobresale hasta 30cm de la pared y que parece hecha aposta para quebrar rótulas, convirtiendo "ergonomía" en una palabra utópica. Del PC salen cables de VGA, red y usb para teclado/ratón/pendrive que van canalizados hasta el puesto del profesor

En resumidas cuentas, el diseño ha optado por adaptar el aula al dueto PC-pizarra, que deben estar separadas por un máximo de 5 metros de cable (menos en línea recta) en lugar que sean PC y pizarra los que adapten su ubicación a la morfología del aula, como sería lo razonable. Me recuerda esta bonita historia:

Un señor acudió un sastre y le entregó una pieza de fino cachemir a fin de que le confeccionara un traje. Le tomó las medidas el maestro y unas semanas después lo llamó por teléfono a su casa para avisarle que el traje estaba listo. Se lo probó el señor. El traje era un desastre: las perneras del pantalón le llegaban apenas al tobillo; una manga de la chaqueta le colgaba casi hasta tocar el suelo, en tanto que la otra ni siquiera alcanzaba a cubrirle el codo. "Oiga, maestro -le dice- este traje está mal hecho. Mire qué mal me queda". "El traje está perfecto, caballero -contesta el ruin tijera-. El problema es de postura. Mire: levante usted el brazo derecho hacia adelante. Muy bien. Ahora encoja el izquierdo y llévelo hacia atrás. Perfecto. Ahora quiébrese usted por la cintura y doble las piernas abriéndolas un poco. Excelente. ¿Lo ve? Así las mangas de la chaqueta alcanzan su debida dimensión, y las perneras del pantalón le cubren ya lo necesario".

No reclamó ya más el cliente, pues era hombre apocado, y procuraba siempre evitar las discusiones. Salió, pues, de la sastrería caminando en la postura que el sastre le había indicado: un brazo estirado hacia arriba y adelante; el otro doblado hacia atrás; el cuerpo encorvado, y con las piernas torcidas. Comparado con él Quasimodo estaba más derecho que una vela. Así, todo deforme y contrahecho, iba por la calle el lacerado cuando lo vieron dos sujetos que pasaban. Le dice uno al otro, compasivo: "Pobre infeliz. Mira qué jodido está". "Sí -concede el otro-. Pero qué buen sastre tiene"

Entonces, yo me pregunto si no se puede enfocar el problema de esta manera que voy a proponer. Primero hablemos del hardware:

  • El PC en su sitio, en la mesa del profesor.
  • La pizarra donde mejor quede en el aula, sea cual sea la distancia que la separe del PC.
  • Junto o tras la pizarra una Raspberry Pi o cualquier miniordenador alimentado por un enchufe normal de corriente y que por su puerto USB se conecta a la pizarra con un cable corto que le da alimentación eléctrica y le permite comunicarse con ella.
  • La Raspberry Pi y el PC están conectados por un cable ethernet debidamente canalizado, que puede tener decenas de metros de largo e ir por sitios donde sea poco llamativo y/o molesto.


En cuanto al software, podría haber dos soluciones:

  • Solución A: usando usb-over-ip instalando el server en la Raspberry Pi para compartir la conexión USB con el pc mediante una conexión IP. El PC remoto tendría instalados el cliente usb-over-ip y los drivers, detectando la pizarra como si estuviese conectada a un puerto USB real propiamente suyo. Este sistema ya lo implementé por mi cuenta de forma bastante satisfactoria reutilizando un router con OpenWrt, un aparato mucho menos versátil que una Raspberry.
  • Solución B: la Raspberry Pi tendría instalado el driver de la pizarra, que tras procesar la señal que llega obtiene unas coordenadas X-Y y un evento de botones de ratón. Esos datos se comparte via TCP/IP con el PC. Si hay que hacer algún pre-procesado de la señal (por ejemplo la triangulación de señal de las cámaras de la SmartBoard 480 para determinar la posición X e Y, realizada por el ejecutable binario nwfermi_daemon) se hace en la propia Raspberry, liberando de esta tarea al PC del profesor.

    ¿Como llega la información de coordenadas y botones al PC?: pues como se hace en cualquier herramienta de "ratón remoto", Synergy por ejemplo o la miríada de ellas que hay en en Google Play que convierten un móvil/tablet Android en un touchpad que controla remotamente el PC: hay un programa servidor, que se ejecuta en la Raspberry y un programa cliente en el PC del profesor, que conectan por un socket TCP/IP y se transmiten la información. El programa cliente utiliza cualquiera de las múltiples herramientas que hay (por ejemplo ésta) para emular el movimiento del ratón.

    Un enfoque mas trabajado y bonito sería implementar un driver para el PC, con un frontend con apariencia de dispositivo HID/ratón que se muestra al sistema como un dispositivo /dev/XXXX y un backend que conecta via TCP/IP con la Raspberry Pi para leer las coordenadas y estado de los botones del servidor que se ejecutaría en la misma. Parece rimbombante pero no es muy difícil de hacer si se cuenta con el tiempo para ello.

Bueno, pues eso es todo: una modesta, barata y sencilla propuesta para montajes futuros y que pueden aplicarse también a montajes presentes donde queramos romper la cadena inelástica que obliga a tener muy próximos pizarra y PC, con grandes problemas derivados de tan absurda limitación.

Fin de impresión.

lunes, 23 de noviembre de 2015

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.....

martes, 10 de noviembre de 2015

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.




miércoles, 28 de octubre de 2015

Clonar pantalla y cañón de vídeo en el inicio de sesión.

Las tarjetas VGA son bastante rebeldes, cuando tienen dos salidas (típicamente una VGA D-sub 15 y una HDMI) a las que conectamos un monitor y un cañón de vídeo el comportamiento es bastante errático en función de la tarjeta de vídeo y los drivers usados: unas veces aparecen clonadas, otras veces como escritorio extendido y, por último, algunas veces aparece apagada una de ellas.

Como normalmente nuestra intención es que ambas aparezcan clonadas (ya que es lo que desea el usuario el 99% de las veces) lo mejor es poner un script que nos las clone usando el comando "xrandr". Luego, el propio usuario puede cambiar esa configuración por si mismo usando el programa "arandr".

En mi caso tengo un PC con 2 salidas de vídeo: VGA-0 (que va al monitor) y DVI-I-0 (que va al cañón de vídeo). El nombre de cada salida se conoce ejecutando "xrandr" sin parámetros, tal como conté aquí.

El comando que debemos ejecutar es:
xrandr --output VGA-0 --rate 60 --mode 1024x768 --output DVI-I-0 --mode 1024x768 --same-as VGA-0
En el que se fuerza una resolución de 1024x768 en ambas pantallas y hago que DVI-I-0 se clone de VGA-0. El monitor es realmente de 16:9, mientras que el cañón es de 4:3, por lo que la resolución de 1024x768 en el monitor queda un poco deforme, pero si queremos tener lo mismo es lo que hay. Se podría jugar con los parámetros "panning" y "scale" de xrandr para intentar conciliar 2 resoluciones distintas en el clonado, pero al final queda como el discurso de C's: totalmente amorfo por querer mezclar 2 agua y aceite, así que no he seguido por ese camino.

Para que esto se ejecute automáticamente en el arranque del sistema hay que poner el comando en algún script de inicio. En mi caso, como uso gdm3 para iniciar sesión lo añado al final de "/etc/gdm3/PreSession/Default", que es un script que se ejecuta justo antes de que el usuario inicie sesión en la máquina. De esta manera garantizo que cada vez que se haga login se configuren ambas pantallas como clonadas, independientemente de que alguien lo haya cambiado durante la sesión anterior.

martes, 27 de octubre de 2015

Desactivar el audio HDMI y dejar solo el sonido analógico mediante una tarea puppet.

En algunos de nuestros PC el sistema identifica 2 tarjetas de sonido: la tarjeta analógica tradicional y otra salida digital vinculada a la salida HDMI de la tarjeta VGA. Tenemos los altavoces conectados a la salida analógica, de tal manera que si por cualquier motivo en pulseaudio se selecciona (y pasa, no sabemos como, pero pasa) de forma espontánea la salida digital, el sonido deja de salir por los altavoces normales, que quedan mudos ante el desconcierto de los usuarios.

Lo solucionaremos en dos partes: primero veremos como hacer desaparecer la tarjeta de sonido digital y luego como automatizarlo vía puppet.

1. Desactivar la tarjeta de sonido.

En Debian Squeeze esto se evitaba blacklistando el módulo del kernel que maneja la tarjeta digital de audio (snd_hda_codec_hdmi), pero en Wheezy este método no funcionaba así como así. Menos mal que nuestro compañero Ricardo encontró la solución con el siguiente comando:
# echo 1 > "/sys/bus/pci/devices/..../remove"
Este comando enviado al dispositivo pci en concreto que representa nuestra tarjeta digital de audio hace que se vaporice, desapareciendo del hardware de la máquina, de pulseaudio y de todos lados. La tarjeta analógica queda como única salida de audio.

Antes hay que saber exactamente cual es el dispositivo pci asociado a la tarjeta de audio:
bus=$(lspci | grep "RV620 HDMI Audio" | cut -d" " -f1)
if [ -n $bus ]
then
      echo 1 > "/sys/bus/pci/devices/0000:00:01.0/0000:$bus/remove"
fi
Siendo "RV620 HDMI Audio" la cadena que identifica nuestra tarjeta de audio HDMI (la descripción se saca con la orden lspci) y debería adaptarse la tarjeta que tenga cada cual. Escrito de forma mas breve sería:
bus=$(lspci | grep "RV620 HDMI Audio" | cut -d" " -f1); test -n $bus && echo 1 > "/sys/bus/pci/devices/0000:00:01.0/0000:$bus/remove"
Como debe ejecutarse al arrancar el sistema, para que quede desactivado desde el principio, el sitio mas adecuado es en /etc/rc.local, antes del exit 0 con el que acaba dicho script.

2. Insertar una línea en rc.local de forma automatizada vía puppet.

Si queremos meter esta línea en rc.local vía puppet (para así poder aplicarlo de forma automatizada en un grupo de máquinas) tenemos que encontrar la manera de añadir dicha línea en el fichero antes del exit 0, verificando que no estuviera ya. Hay varias maneras de hacerlo, pero me he decantado por usar un define de puppet.

Actualmente tengo en /etc/puppet/defines/* de mi servidor puppet un conjunto de funciones puppet útiles para tratar con ficheros y lineas de texto. Es una gran idea cogida de mi compañero Esteban Navas y son una serie de funciones descritas en https://projects.puppetlabs.com/projects/puppet/wiki/Simple_Text_Patterns/1:

  • delete_lines.pp
  • line.pp
  • prepend_if_no_such_line.pp
  • replace.pp

Aunque ninguna servía para hacer lo que quiero (añadir una línea que no está antes del "exit 0" del rc.local), los defines anteriores me sirven de base para hacerlo. El nuevo define en cuestión queda:
# cat /etc/puppet/defines/add_line_above.pp

#Añade la linea "line" al fichero "file", siempre que la cadena "search" no esté en el fichero.
#La línea la añade inmediatamente por encima de la línea que contenga la cadena "above".
#Usado por ejemplo para añadir lineas a /etc/rc.local por encima del "exit 0" con el cual
#siempre finaliza dicho script.

define add_line_above($file, $line, $search, $above) {
    exec { "/bin/sed -i '/${above}/i\\${line}' '${file}' ":
           unless => "/bin/grep -q '${search}' '${file}'"
    }
}
A continuación tenemos que referenciar este define metiéndolo en el init.pp de una tarea puppet específica que hagamos o bien añadiéndolo a una ya hecha (yo prefiero eso: hacer tareas omnibús que aplican conjuntos de pequeños ajustes de configuración antes que llenar todo de pequeñas tareitas haiku muy especializadas)

Sea como fuere, en el init.pp que escojamos tenemos que importar los .pp de /etc/puppet/defines, poniendo al principio del fichero, antes del "class":
import "/etc/puppet/defines/*.pp"
Y luego dentro del "class":
add_line_above { desactiva_audio_hdmi:
              file=> "/etc/rc.local",
              line=> 'bus=$(lspci | grep "RV620 HDMI Audio" | cut -d" " -f1); test -n $bus && echo 1 > "/sys/bus/pci/devices/0000:00:01.0/0000:$bus/remove"',
              search=> "RV620",
              above=> "^exit 0$"
}

Y ya está. Eso lo que hará será modificar el fichero rc.local de todos los equipos que usen la clase puppet para añadir:
bus=$(lspci | grep "RV620 HDMI Audio" | cut -d" " -f1); test -n $bus && echo 1 > "/sys/bus/pci/devices/0000:00:01.0/0000:$bus/remove"
Justo antes del exit 0 con el que finaliza dicho fichero. Y con esto ya tenemos ambos objetivos conseguidos, trabajo hecho :-).


miércoles, 21 de octubre de 2015

Como cambiar la contraseña de root de un Linux cuando no la sabemos previamente.

A veces heredamos o nos llega un sistema Linux en el que la contraseña de root es desconocida. Puesto que las contraseñas de Linux son en principio cuasi-imposibles de descifrar, no nos queda otra que cambiar la contraseña de root por una que conozcamos, ¿cómo se hace esto?.

Primero debemos arrancar con un CD o Pendrive conteniendo un Linux. Puede ser un SystemRescueCD, un Clonezilla o cualquier disco de instalación Live (uno de Ubuntu o Mint, por ejemplo). Una vez hemos arrancado tendremos que abrir un terminal. En un SystemRescueCD el terminal está allí mismo, en un Clonezilla hay que seleccionar la opción "Enter shell..." enlos menús y sobre un Linux Live habría que ir al menú de inicio y ejecutar la aplicación de terminal desde allí.

Ahora pasamos a ejecutar los siguientes comandos (el "sudo su" puede que no sea necesario, dependiendo de que distribución estemos usando):
$ sudo su
# fdisk -l

Esto nos mostrará las particiones del disco duro del PC, algo así como:
Disco /dev/sda: 160.0 GB, 160040803840 bytes
.....
.....
Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *        2048   156250111    78124032   83  Linux
/dev/sda2       156264255   312576704    78156225   83  Linux
En esta lista de particiones estará la que contiene el sistema Linux al cual queremos cambiar la contraseña. En el ejemplo anterior sería /dev/sda1 (es una partición de Linux y está marcada como arrancable).

Una vez identificada la partición, la montamos:
# mount /dev/sda1 /mnt
Y entramos en ella con una jaula chroot:
# chroot /mnt
Puede que nos de algún error relacionado con "zsh" u otra shell, en ese caso lo haremos así:
# chroot /mnt /bin/bash
Con esta orden chroot estamos dentro del Linux contenido en el disco duro, ya que nuestro / ha pasado a ser /dev/sda1. Eso quiere decir que cualquier comando que tecleemos se hará y tendrá efecto sobre dicho Linux y no sobre el sistema con el que hemos arrancado. Por tanto, haciendo:
# passwd root
Nos pedirá la nueva contraseña de root: la introducimos por duplicado y ya está, esa será la contraseña de root del sistema instalado en el disco duro. Salimos de la jaula y desmontamos:
# exit
# umount /mnt
Si por algún motivo el comando "passwd root" no funciona podemos optar por lo siguiente una vez averiguada la partición donde está nuestro Linux:
# mount /dev/sda1 /mnt
# nano /mnt/etc/shadow
# # Borrar contraseña root
# umount /mnt
Si no funciona el editor "nano" probaremos con "vi". Por "borrar contraseña de root" quiero decir localizar en /etc/shadow la línea parecida a:
root:$6$0UeP/qy$XzJ3Ztmd0wsNrNx1rEnnp8K2VYtHsEO1so5UN7FsfaDPEXTxImxYyKAWpeIvQrQwxNwTNjUD25gz6aVq5/:16280:0:99999:7:::
y borrar todo lo que hay entre el primer y segundo ":", quedando:
root::16280:0:99999:7:::
Con esto quedamos la contraseña de root en blanco, pudiendo entrar con facilidad.

Una vez hecho esto reiniciamos el sistema, quitando el pendrive o el CD y arrancando con el sistema en el disco. Ahora podremos entrar como root con la contraseña que hemos establecido. Como vemos, es mucho mas fácil de lo que parecía.