RasPi: automatización con Cron & CronTab

Publicado por el

Hace ya algún tiempo, cuando os comentaba cómo enviar mensajes con el bot de Twitter, también os dije que lo que podíamos hacer era automatizar su activación, de manera que se pudiera enviar automáticamente cada cierto tiempo.

Cron, muy posiblemente procedente de la palabra griega chronos, es un demonio o proceso desatendido capaz de ejecutar acciones o comandos cada cierto tiempo. Es especialmente potente, ya que acepta casi cualquier tipo de programación: por segundos, minutos, horas, diario, semanal, intervalos, etc…

Yo solo os daré una pequeña pauta para poder lanzar, por ejemplo, el bot de Twitter de manera automática cada hora. Para profundizar mas en el tema, os recomiendo que consultéis la WikiPedia o la documentación específica de Unix, man cron o man crontab.

Bien, vamos al lío. Si recordáis de la anterior entrada, en la que explicábamos cómo lanzar el bot de Twitter, os decía que era posible “publicar el estado de nuestra Pi de manera autónoma y con una cadencia temporal definida”. Esto no es mas que ejecutar el script que creamos en su día cada cierto tiempo, cada hora, por ejemplo.

Cron mantiene una interfaz de configuración bastante intuitiva:

*/5 * * * * /home/user/test.sh

La siguiente tabla define los intervalos en los que se deben ejecutar los comandos deseados:

.---------------- minuto (0 - 59) 
|  .------------- hora (0 - 23)
|  |  .---------- día del mes (1 - 31)
|  |  |  .------- mes (1 - 12) O jan,feb,mar,apr ... (los meses en inglés)
|  |  |  |  .---- día de la semana (0 - 6) (Domingo=0 ó 7) O sun,mon,tue,wed,thu,fri,sat (los días en inglés) 
|  |  |  |  |
*  *  *  *  *  comando para ser ejecutado

Según la tabla anterior, para cada * corresponde un indicador de tiempo. En el ejemplo, hemos decidido que, para todos los minutos (*) con un intervalo de 5 (*/5), y para cada hora, día, etc… se debe ejecutar el comando

/home/user/test.sh

 

Esta sentencia se debe informar en un fichero de configuración de cron específico por usuario, siendo posible, pues, que ese usuario ejecute sus propios comandos, indistintamente de lo que puedan hacer otros en su mismo caso. Es decir, cron puede ser programado por cualquier usuario independientemente, por lo que un comando puede tener o no validez según quién lo ejecute (hay que tenerlo muy claro a la hora de programarlo!).

Y finalmente, para editar cron de una manera segura y eficiente, lo recomendable es hacerlo con el comando crontab. Crontab ejecutará un editor (por defecto nano) que abrirá (o creará) el fichero de configuración de cron para el usuario actual. Es muy recomendable hacerlo mediante este sistema, ya que tras guardar los cambios se realiza un test de la sintaxis de configuración de cron y, si esta no es correcta, se nos informará tras guardar dicho fichero.

Vamos a ver el caso práctico que nos ocupa.

Creamos un nuevo fichero python con el contenido que queremos que el bot muestre. Éste se llamará temp.py y se encuentra en la misma carpeta que el anterior:

#!/usr/bin/env python

import os
import sys
from twython import Twython

CONSUMER_KEY = 'XXXXXXXXXX'
CONSUMER_SECRET = 'XXXXXXXXXX'
ACCESS_KEY = 'XXXXXXXXXX'
ACCESS_SECRET = 'XXXXXXXXXX'

api = Twython(CONSUMER_KEY,CONSUMER_SECRET,ACCESS_KEY,ACCESS_SECRET)

cmd = 'sudo /opt/vc/bin/vcgencmd measure_temp'
line = os.popen(cmd).readline().strip()
temp = line.split('=')[1].split("'")[0]
statusString = 'I`m alive, and my current CPU temperature is: ' + temp + ' C'

api.update_status(status=statusString)

Guardamos el fichero y ahora podemos probarlo:

pi@raspberrypi ~/TwitterBot $ python temp.py
Test de temperatura

Test de temperatura enviado mediante el bot de Twitter

Como vemos, se ha publicado correctamente el twit. Ahora ya podemos editar nuestra tabla de cron, y programarlo para que se ejecute, por ejemplo, una vez cada hora:

pi@raspberrypi ~/TwitterBot $ crontab -e

*/60 * * * * python /home/pi/TwitterBot/temp.py

Una vez editado, lo guardamos y se iniciará automáticamente, ejecutando el comando que hemos indicado cada hora (*/60, indica para todos los minutos, cada 60 ejecutar…).

Ahora ya tenemos las primeras pautas para ejecutar comandos de manera automatizada. Recordad que es aplicable a cualquier comando que podáis ejecutar desde la shell, sin limitaciones.

Espero que os haya parecido interesante.

Jordi

Share Button

Related Images:

Raspberry Pi de 512Mb writting_raspbian_sd

NesPi: Una Raspberry Pi dentro de una NES (II)

Publicado por el

Siguiendo con el tema que comentábamos hace una semana, en el post NesPi: Una Raspberry Pi dentro de una NES (I), hoy vamos a hablar del posible emplazamiento de los primeros dispositivos dentro de la carcasa…

Bien, ahora ya tenemos la base, que es la carcasa de la NES. Hay que empezar a planificar cómo colocaremos las cosas dentro.

Mi idea es hacer el menor daño posible a la carcasa, de modo que se asemeje el máximo posible a lo que es, una NES. Por ello, no agujerearé la carcasa ni le modificaré la estructura. El único cambio que es necesario para poder adecuar los conectores a las necesidades actuales (hdmi, rj45, rca…) es en las dos partes en las que anteriormente ya se alojaban los contactos antiguos (son las dos secciones pintadas de amarillo que podéis ver en la siguiente imágen).

El planteamiento es hacer dos niveles, separados por una plancha de acero perforada (que muy amablemente me ha cedido mi buen amigo Flash). De este modo conseguiremos adaptarla fácilmente a los vástagos de plástico que sobresalen de la base, dónde iba atornillada la placa base (que por cierto, ya he vendido). Como os decía, tampoco la modificaré demasiado por dentro, no quiero cambiar nada (si, soy demasiado estricto con todas estas cosas, jejeje).

Bien, dicho esto, os adelanto un pequeño esquema en color de cómo distribuiré el material dentro de la carcasa, solo en el nivel inferior (la base). La parte superior, en el próximo post…

Veamos un pequeño esquema:

Esquema base

Esquema de la base de la NES, indicando las zonas en las que emplazaremos algunos dispositivos

Por colores:

  • azul: chapa perforada que separa la base del primer nivel, dónde se emplazará la raspberry pi y algunos otros dispositivos adicionales, como una placa de desarrollo para el GPIO
  • amarillo: son las dos entradas posibles a la carcasa por las cuales se distribuirán los diversos conectores de entrada salida de nuestra pi (hdmi, rj45, jack, rca…). Estas partes se trabajarán en chapa para emplazar los diferentes conectores, para lo cuál hará falta recortar mínimamente las mismas…
  • naranja: pequeña placa de prototipos, futuro circuito impresa, que servirá de distribuidor de alimentación, obteniendo el cable desde la entrada marcada en la parte superior en amarillo
  • verde oscuro: pequeño ventilador de 40x40x10 y 5V que encaja perfectamente en esa ranura, para absorber el flujo de aire necesario para poder distribuirlo por el interior de la caja. Luego habrá que emplazar otro similar en la parte derecha superior, ya que la parte blanca también dispone de ranuras de ventilación. La idea es ponerlo fijo en un principio, pero al poco que podamos, manejarlo por GPIO y programación, a través de la placa de prototipos que comentaba anteriormente…
  • verde lima: esta parte a priori ha de estar libre de contenido, puesto que es dónde van a emplazarse todos los conectores montados sobre panel que darán salida a las comunicaciones de la pi, como os decía, el hdmi, rj45, etc… y que como deberán ir atornillados a las chapas que aún hay que mecanizar, hará que ocupemos cierto espacio interior. Por este mismo motivo la chapa perforada no podrá ocupar este espacio, y hace esta forma de L a esta altura…
  • rojo: aquí emplazaremos uno de los dispositivos mas importantes, el disco duro. Se trata de un Seagate Expansion Portable Drive, de 1Tb, y que curiosamente encaja a la perfección entre los 4 vástagos que veis en sus dos laterales. La altura es la idónea, no llega a los 20mm que dan los vástagos y sobre los que irá la chapa perforada. Él único inconveniente que encontramos es tener que limar un poco las dos pestañas que sobresalen desde cada uno de ellos, tras lo cuál el disco quedará perfectamente acoplado, tanto en anchura como en altura (parece hecho a medida!!!). Por si os interesa, el disco duro es este: http://www.seagate.com/es/es/external-hard-drives/portable-hard-drives/standard/expansion-portable

Con esto ya tenemos un poco mas claro cómo distribuiremos algunas cosas por la carcasa. Tenía mis dudas, y poco a poco he ido viéndolo mas claro. Los diferentes materiales están en camino, comprados desde eBay. En la próxima entrega veremos cuales son y cómo los distribuiremos.

Espero que os esté pareciendo interesante y os animéis a hacer algo parecido. Si es así, por favor, compartidlo para poder ver los diseños de cada uno de nosotros.

Gracias por leerme!

Jordi

 

 

Share Button

NesPi: Una Raspberry Pi dentro de una NES (I)

Publicado por el

Bien, por fin llegó el día! Hoy mismo he recibido mi NES estropeada. Así que puedo dar por iniciada la sección NesPi.

Como este post no va a ser nada técnico (si lo serán los sucesivos), lo que voy a explicar es más o menos la idea que tengo, voy a exponer mis pretensiones y a daros algunas indicaciones de lo que tengo pensado hacer con mi Raspberry Pi. Quizá, y espero, este proyecto que hoy empiezo os sea de interés a alguno de vosotros, y os animéis a hacer algo parecido, para poder llevar a cabo una pequeña discusión de sobre cómo lo haríamos cada uno, mejoras, ideas, etc…

NesPi

Una NES y una RasPi

Voy a explicaros algunas cosillas, pues, en unos puntos muy concisos…

Idea del proyecto

Desde el primer día que me hice con mi Raspberry Pi (recordemos ese gran sorteo!!!) tuve muy claro que no podía caer en saco roto todo este movimiento, que ya es una fiebre, que se mueve por el mundo de los microordenadores. Estas cosas están muy al alcance de cualquier persona, sobre todo de niños, que nos dan mil vueltas programando y haciendo cosillas con ordenadores… Por lo tanto, tengo abiertos numerosos proyectos con la RasPi, pero hace falta mucho tiempo para todos ellos (controlador de maquetas de trenes con DCC, domótica, servidor casero…). De todos ellos podréis ver pinceladas en mi web. Pero hay uno que es muy importante: dotar de una caja con estilo a este gran artilugio…

Pero… ¿por qué una NES?

Muy sencillo: la NES es, y será por siempre, símbolo del mundo retro consolero y de los mayores avances tecnológicos de mi época, los 80. Por lo tanto, qué mejor que honrar a un micropc actual con una piel retro, haciendo honor a la historia. Os he de decir que yo siempre he sido de SEGA, pero hace un tiempo tuve la oportunidad de adquirir una NES en impecable estado, y cada vez mas la veía más próxima… Así que decidí que si mi RasPi debía tener una buena caja, debía ser con estilo, retro… Qué mejor que una NES…

Vale muy bonito, ¿pero para qué quieres eso ahora…?

Muy sencillo: para que no esté tirada por encima del escritorio cada día, desperdigada con el hub y los cables, y para poder transportarla fácilmente, como si fuera una flamante NES… Y lo mejor de todo, será un gran centro de juego con carcasa de lo que es, una gran consola. ¿Qué mejor motivo?

Futuro del proyecto

La consola está estropeada, ya me he encargado de buscarla en ese estado, para no destrozar algo que funciona (moralmente no podría!). De todos modos, he buscado algo en muy buen estado, y lo tenía el mismo vendendor que me vendió la NES “nueva”. Y ha vuelto a sorprenderme gratamente, porque la verdad es que está impecable. Algunos rasguños casi inapreciables. O sea, perfecta!

Entonces, ¿qué tengo pensado? Rápido y conciso. Por puntos:

  • Quiero un equipo totalmente funcional y manejable
  • Quiero un equipo completo, con bastantes recursos, como el hub de USBs, un disco duro interno, etc…
  • Quiero destrozar lo mínimo posible una carcasa tan emblemática, como es una NES
  • Quiero llevarme una sonrisa cada vez que la vea encendida
  • Y quiero, sobre todo, tener un centro de juegos multiplataforma, de una vez por todas, y en condiciones: emulación al poder!

Todo esto me lo da la caja de la NES, no he de buscar mas:

  • Gran espacio para la pi, el hub, el disco y un sistema de refrigeración adecuado (lleva ranuras muy amables)
  • Lleva suficientes entradas y salidas de cableado, las necesarias para poder conectar la RasPi sin problemas. Sólo tendré que agujerear para una cosa, la conexión trasera de HDMI, y quizá uno o dos de los USB…
  • La parte frontal ofrece espacio mas que de sobras para poner el resto de los puertos USB, una ranura para la SD…
  • Y, sobre todo… lleva dos puertos para controladores clásicos de la NES!!! (si si, lo que leéis, qué esperábais! hay que usarlos!)

Gracias a ello podremos usar cualquier distribución que se nos ocurra, Raspbian para uso general, XBMC para multimedia, RetroPie para emulación (y soporte de controladores clásicos…), etc…

¿Creéis que tengo o no razón eligiendo la NES como carcasa para mi RasPi? Hombre, yo creo que si, jejejeje. Y sino, me daré de bruces, pero al menos me habré entretenido un rato y vosotros lo habréis visto… 😉

Así que si os interesa, espero veros leyendo los futuros posts relacionados con este proyecto tan importante para mí…

Nos vemos en los posts!

Jordi

Share Button

RasPi: enviar correos electronicos con sendmail

Publicado por el

Siguiendo con el tema de montar nuestro propio servidor casero, hoy os explicaré cómo podemos conseguir enviar correos electrónicos desde nuestra pi, para poder informar sobre la temperatura, estado del sistema, etc… Ya os avanzo que podréis encontrar estas mismas instrucciones en otras muchas páginas relacionadas con el tema, pero como siempre, he querido explicarlo a mi manera, para ampliar, si cabe, la información y hacerla mas entendible por todos.

Haremos uso de un cliente de correo por línea de comando, el archi conocido sendmail. Parece ser que, teóricamente, Raspbian debería tener ya instalado el sendmail, pero podría darse el caso de que no fuera así. Si es este vuestro caso, lo instalaremos como ya viene siendo costumbre, con apt-get install.

Instalación de sendmail

Procederemos a actualizar el sistema, antes de nada, y posteriormente a instalar sendmail:

jordi@raspberrypi ~ $ sudo apt-get update
jordi@raspberrypi ~ $ sudo apt-get upgrade
jordi@raspberrypi ~ $ sudo apt-get install sendmail

Ahora ya tenemos sendmail en nuestro sistema. Aún así, para facilitar algo mas las cosas, instalaremos algunas herramientas adicionales, como un configurador del servidor smtp y otras utilidades:

jordi@raspberrypi ~ $ sudo apt-get install ssmtp
jordi@raspberrypi ~ $ sudo apt-get install mailutils

Tras esto ya podemos configurar nuestro servidor de correo smtp…

Configuración de la pasarela del servidor smtp

La aplicación ssmtp (https://wiki.archlinux.org/index.php/SSMTP) no es exactamente un servidor smpt, sino mas bien una pasarela sobre sendmail. Es decir, nos ayuda a redirigir nuestros correos de salida hacia un servidor de correo saliente sobre el que tenemos permiso. Para las pruebas haremos uso de una cuenta de Gmail, por dos motivos: por que hoy en día casi todo el mundo tiene una y ofrece los datos de conexión en su propia web y, casi mas importante, porque la mayoría de los tutoriales que encontraremos por la red relacionados con este tema hacen uso de ella…

Editamos el fichero de configuración:

jordi@raspberrypi ~ $ sudo nano /etc/ssmtp/ssmtp.conf

y añadimos al final:

AuthUser=tuUsuario@gmail.com
AuthPass=tupassword
FromLineOverride=YES
mailhub=smtp.gmail.com:587
UseSTARTTLS=YES

dónde tuUsuario@gamil.com deberás poner tu cuenta de Gmail y aplicar la configuración según corresponda. Si disponéis de vuestro propio servicio, también podéis ponerlo aquí. Yo por ejemplo tengo el de mi ISP, y para mi servidor uso ese. Por otro lado, hay quien prefire configurar el smtp de la pi y usar el propio host como servidor de correo saliente. No es mala idea, si no tenéis pensado recibir mensajes…

Enviando correo

Ahora ya podemos enviar un mensaje desde la línea de comando:

jordi@raspberrypi ~ $ echo "Hola Jordi!!!" | mail -s "Asunto" tuOtroCorreo@host.com

Sed pacientes, en breve recibiréis el correo en el buzón que le hayáis indicado como tuOtroCorreo@host.com.

La ejecución es muy sencilla, y si recibís algún error tras ejecutar el comando, revisad varias cosas:

  • tenéis abierto / permiso para usar el puerto de correo de salida
  • habéis configurado correctamente el ssmtp

A continuación os dejo un ejemplo de error por mala configuración:

jordi@raspberrypi ~ $ send-mail: Authorization failed (535 5.7.8 http://support.google.com/mail/bin/answer.py?answer=14257 57kj33hj5j.21 - gsmtp)

En caso de que todo vaya bien, no recibiréis ningún mensaje por pantalla, y el correo habrá sido enviado, apareciendo las credenciales de la cuenta que habéis configurado.

Enviando archivos adjuntos

Para enviar archivos adjuntos con sendmail utilizaremos una utilidad llamada mpack. Con ella simplemente pondremos un wrapper a sendmail con el que podremos adjuntar ficheros a nuestro correo.

Lo instalamos con…

jordi@raspberrypi ~ $ sudo apt-get install mpack

Y una vez instalado, podemos probar con cualquier fichero.

Creemos un sencillo fichero de texto, que adjuntaremos a nuestro próximo correo…

jordi@raspberrypi ~ $ echo "Hola buenas tardes, este es un fichero de texto adjunto a tu correo electrónico" >  attachment.txt
jordi@raspberrypi ~ $ cat attachment.txt
Hola buenas tardes, este es un fichero de texto adjunto a tu correo electrónico

Y lo enviamos…

jordi@raspberrypi ~ $ mpack -s "Este es un correo de prueba con adjunto" ./attachment.txt tuOtroCorreo@host.com

Una vez mas, si no recibimos mensajes de respuesta, es que hemos realizado el envío correctamente. Si nos equivocamos en la sintaxis, posiblemente salga la ayuda del comando mpack…

Y con esto acabamos este mini tutorial. Espero que os haya parecido interesante!

Jordi

Share Button

Related Images:

Raspberry Pi de 512Mb writting_raspbian_sd

RasPi: creando scripts de arranque

Publicado por el

Es posible que queramos que un determinado script o aplicación se ejecute en el arranque del sistema. Normalmente, cuando instalamos una aplicación mediante apt-get o un instalador, la propia aplicación genere un script de arranque si se trata de un servicio, como por ejemplo apache2 o samba. En otras ocasiones no es así, como por ejemplo si es un programa propio o un script que simplemente deseamos ejecutar en tiempo de arranque, para que realice alguna tarea de mantenimiento.

Para que un script se ejecute en el arranque del sistema, existe un directorio que se destina a tal efecto. Se trata del /etc/init.d y en él residen todos los daemos o scripts de arranque de servicios del sistema. Normalmente son scripts que aceptan parámetros de entrada para indicar la acción que deseamos ejecutar, como start, stop, restart…

Linux, y en especial Raspbian, que es la distribución con la que trabajamos con Raspberry Pi, nos acerca un poco mas a su mantenimiento, y nos ofrece un esqueleto que podemos utilizar como bootstrap (punto de inicio) a la hora de crear nuestros propios scripts. Es algo complejo, y podéis encontrarlo en /etc/init.d/skeleton.

Lo idóneo es utilizar este esqueleto. Así que lo que vamos a hacer es editarlo para ajustarlo a nuestras necesidades.

Primero lo copiamos sobre un nuevo script, que nombraremos según nos convenga. En nuestro ejemplo, myscript:

jordi@raspberrypi ~ $ sudo cp /etc/init.d/skeleton /etc/init.d/myscript

Ahora podemos editarlo:

jordi@raspberrypi ~ $ sudo nano /etc/init.d/myscript

Y lo editamos, de una manera parecida a esta, según nuestras necesidades. Yo he creado, o editado mejor dicho, el siguiente script para adaptarlo al servicio del cliente No-ip.com que hemos creado en esta entrada de mi blog:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          skeleton
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Example initscript
# Description:       This file should be used to construct scripts to be
#                    placed in /etc/init.d.
### END INIT INFO

# Author: Jordi <jordi@jormc.es>

# Do NOT "set -e"

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="No-ip.com client service"
NAME=noip2
DAEMON=/usr/sbin/$NAME
DAEMON_ARGS="--options args"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
	# Return
	#   0 if daemon has been started
	#   1 if daemon was already running
	#   2 if daemon could not be started
	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
		|| return 1
	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
		$DAEMON_ARGS \
		|| return 2
	# Add code here, if necessary, that waits for the process to be ready
	# to handle requests from services started subsequently which depend
	# on this one.  As a last resort, sleep for some time.
}

#
# Function that stops the daemon/service
#
do_stop()
{
	# Return
	#   0 if daemon has been stopped
	#   1 if daemon was already stopped
	#   2 if daemon could not be stopped
	#   other if a failure occurred
	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
	RETVAL="$?"
	[ "$RETVAL" = 2 ] && return 2
	# Wait for children to finish too if this is a daemon that forks
	# and if the daemon is only ever run from this initscript.
	# If the above conditions are not satisfied then add some other code
	# that waits for the process to drop all resources that could be
	# needed by services started subsequently.  A last resort is to
	# sleep for some time.
	start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
	[ "$?" = 2 ] && return 2
	# Many daemons don't delete their pidfiles when they exit.
	rm -f $PIDFILE
	return "$RETVAL"
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
	#
	# If the daemon can reload its configuration without
	# restarting (for example, when it is sent a SIGHUP),
	# then implement that here.
	#
	start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
	return 0
}

case "$1" in
  start)
	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
	do_start
	case "$?" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
  stop)
	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
	do_stop
	case "$?" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	;;
  status)
	status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
	;;
  #reload|force-reload)
	#
	# If do_reload() is not implemented then leave this commented out
	# and leave 'force-reload' as an alias for 'restart'.
	#
	#log_daemon_msg "Reloading $DESC" "$NAME"
	#do_reload
	#log_end_msg $?
	#;;
  restart|force-reload)
	#
	# If the "reload" option is implemented then remove the
	# 'force-reload' alias
	#
	log_daemon_msg "Restarting $DESC" "$NAME"
	do_stop
	case "$?" in
	  0|1)
		do_start
		case "$?" in
			0) log_end_msg 0 ;;
			1) log_end_msg 1 ;; # Old process is still running
			*) log_end_msg 1 ;; # Failed to start
		esac
		;;
	  *)
		# Failed to stop
		log_end_msg 1
		;;
	esac
	;;
  *)
	#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
	echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
	exit 3
	;;
esac

:

No os asustéis, después de todo este tocho solo he tocado 3 líneas:

  • línea 13, para poner mi contacto (aunque el script no es mío, o no al menos el servicio al que llama)
  • línea 19, para añadir una pequeña descripción del script
  • línea 20, el nombre del script en sí, noip2
  • línea 21, para indicar dónde se encuentra el ejecutable de nuestro servicio, en /usr/local/bin

Ahora ya podemos guardarlo y prepararlo para ser ejecutado:

jordi@raspberrypi ~ $ sudo chmod +x /etc/init.d/noip2
jordi@raspberrypi ~ $ sudo update-rc.d -f noip2 defaults 99
update-rc.d: using dependency based boot sequencing
insserv: Script noip2 is broken: incomplete LSB comment.
insserv: missing `Required-Start:' entry: please add even if empty.
insserv: missing `Required-Stop:'  entry: please add even if empty.
insserv: missing `Default-Start:'  entry: please add even if empty.
insserv: missing `Default-Stop:'   entry: please add even if empty.
insserv: script noip2 provides system facility $remote_fs, skipped!
insserv: script noip2 provides system facility $syslog, skipped!
insserv: script noip2 provides system facility $remote_fs, skipped!
insserv: script noip2 provides system facility $syslog, skipped!
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `noip2'
insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `noip2'
insserv: warning: script 'mathkernel' missing LSB tags and overrides

Le hemos dado permisos de ejecución (línea 1) y hemos informado al sistema que debe ejecutarlo en el arranque, para que esté siempre disponible (línea 2).

Ahora ya podemos tratarlo como un servicio mas:

jordi@raspberrypi ~ $ sudo service noip2 status
jordi@raspberrypi ~ $ sudo service noip2 stop
jordi@raspberrypi ~ $ sudo service noip2 start
jordi@raspberrypi ~ $ sudo service noip2 status

Notad que con este ejemplo no obtendremos nada a la salida, ya que el propio ejecutable del noip2 es “silencioso”.

Y con esto ya tenemos nuestro script funcionando. Una cosa muy importante, este proceso no implica un respawn automático. Es decir, si el servicio se mata con in kill -9, no se reiniciará, habrá que ejecutarlo a mano… Eos lo veremos en otro artículo más adelante.

Espero haberos sido de ayuda 😉

Jordi

Share Button

RasPi: cómo gestionar un DNS dinámico

Publicado por el

Seguimos con los artículos orientados a montar nuestro servidor casero, con Raspberry Pi. En esta ocasión vamos a ver cómo manetener actualizado un servicio de DNS dinámico, para poder disponer en todo momento de una url que apunte a nuestro servidor. De este modo podremos acceder al mismo desde cualquier punto del planeta en el que nos encontremos.

Qué es un DNS dinámico

Un DNS dinámico es un servicio que ofrecen algunas empresas en Internet, encargado de actualizar, cada cierto tiempo, las ip de sus hosts de manera automática. Un DNS normal mantiene una tabla de ip de manera estática, hasta que “alguien” las actualiza (visitad la Wikipedia para mas información: http://www.wikipedia.org/DNS) De este modo, los clientes como nosotros, que por lo general tienen una conexión con ip dinámica (que cambia cada vez que se reinicia el router, aunque esto cada vez sucede menos) pueden disponer de un nombre de host conocido que apunta a su ip, sin necesidad de preocuparse de actualizar un DNS para no perder el enlace.

Existen muchas compañías que ofrecen servicios de DNS dinámico, algunas gratis, otras de pago… siempre dependiendo del tipo de servicio que deseemos contratar. Para este artículo utilizaremos los servicios de DNS Dinamico ofrecidos por No-ip.com (http://www.no-ip.com). Son muy conocidos en este mundo, por ser unos de los primeros que aparecieron en el mercado, y por disponer de una buena variedad de servicios gratuitos.

Cómo funciona un DNS dinámico

Asumiré que tenéis los conocimientos suficientes para hacer que vuestra pi sea visible desde el exterior (apertura de puertos en nuestro router, activación de la DMZ, etc…).

Para poder continuar, deberéis disponer de una cuenta en No-ip.com y al menos una redirección activada. Una redirección es, símplemente, el nombre de un host al que se le asigna, cada cierto tiempo, la ip de un equipo conectado a internet. En nuestro caso, nuestra pi, o bien la puerta de enlace de la que depende (nuestro router ADSL, por ejemplo…). Deberéis indicar una ip inicial en el momento de crearla, si no conocéis la vuestra (sudo ipconfig -all o consultadlo en vuestro router, isp…). Podéis poner una temporal, como www.google.es, ya que cuando instalemos nuestro cliente se actualizará automáticamente.

Posteriormente, lo que haremos es instalar un cliente de No-ip.com. Este cliente se conectará cada cierto tiempo a su servidor de DNS y actualizará nuestro hostname con la ip de nuestro equipo. El mismo cliente se encargará de, primero, obtener nuestra ip y, posteriormente, conectarse y actualizar la ip en su servicio de DNS. Luego ellos mismos publican su DNS y tendremos acceso a nuestro sistema vía nuestro hostname.

Instalación del cliente de No-ip.com

El procedimiento es muy sencillo. Podéis consultar su tutorial en esta url: http://www.noip.com/support/knowledgebase/installing-the-linux-dynamic-update-client

Ejecutaremos las siguientes sentencias, tal cual nos indica en el tutorial:

jordi@raspberrypi ~ $ cd /usr/local/src
jordi@raspberrypi ~ $ sudo wget http://www.no-ip.com/client/linux/noip-duc-lijordi@raspberrypi ~ $ nux.tar.gz
jordi@raspberrypi ~ $ sudo tar xzf noip-duc-linux.tar.gz
jordi@raspberrypi ~ $ cd no-ip-2.1.9
jordi@raspberrypi ~ $ sudo make
jordi@raspberrypi ~ $ sudo make install

Si obtenéis algún error en el momento del make. es posible que no dispongáis de las librerías del gcc para compilar. Deberéis isntalarlas antes de volver a probar (buscad por Google install gcc raspberry pi). Normalmente si las tendremos incluidas.

Una vez compilado el código fuente, se ejecutará el configurador por defecto. Es interactivo, y para continuar nos pedirá los datos de la cuenta que queremos asociar a nuestro cliente. Lo hace de manera online, así que una vez que introduzcamos nuestras credenciales, se conectará y nos presentará todos los hostnames que hemos registrado, para poder gestionar uno de ellos (y solo uno):

jordi@raspberrypi /usr/local/src/noip-2.1.9-1 $ sudo make install
if [ ! -d /usr/local/bin ]; then mkdir -p /usr/local/bin;fi
if [ ! -d /usr/local/etc ]; then mkdir -p /usr/local/etc;fi
cp noip2 /usr/local/bin/noip2
/usr/local/bin/noip2 -C -c /tmp/no-ip2.conf

Auto configuration for Linux client of no-ip.com.

Please enter the login/email string for no-ip.com  mail@host.com
Please enter the password for user 'mail@host.com'  ********

Only one host [xxxxx.no-ip.com] is registered to this account.
It will be used.
Please enter an update interval:[30]
Do you wish to run something at successful update?[N] (y/N)  

New configuration file '/tmp/no-ip2.conf' created.

mv /tmp/no-ip2.conf /usr/local/etc/no-ip2.conf

Seleccionad el host y el tiempo de intervalo de actualización, y habremos acabado. Como véis, se nos pregunta si deseamos ejecutar alguna aplicación o script al finalizar la actualización. Esto es muy útil, para por ejemplo enviarnos un correo electrónico cada vez que se actualice la ip, para estar informados…

Configuración del cliente de No-ip.com

Una vez finalizado el procedimiento anterior, tenemos el fichero de configuración disponible en /usr/local/etc/no-ip2.conf. No intentéis editarlo, está en formato raw (crudo), es decir, es un binario…

Si quisierais cambiar algo, como el tiempo de actualización o bien el script, deberéis volver a ejecutar el make install o el comando:

jordi@raspberrypi ~ $ /usr/local/bin/noip2 -C

Esto regenerará un nuevo fichero de configuración vacío y se volverá a pedir las credenciales…

Ejecución del cliente

Para dejar el cliente ejecutándose en background, realizaremos la misma llamada que para la configuración, pero sin el modificador -C:

jordi@raspberrypi ~ $ /usr/local/bin/noip2

Para iniciarlo en cada arranque, deberemos configurar un script que se ejecute automáticamente en cada inicio del sistema.

Para ello podemos generar un nuevo daemon script en /etc/init.d. Visitad mi entrada RasPi: creando scripts de arranque para saber cómo hacerlo.

 

Jordi

 

Share Button

Related Images:

Raspberry Pi de 512Mb writting_raspbian_sd

RasPi: Añadiendo usuarios sudoers

Publicado por el

En cualquier sistema Linux el grupo sudoers es un grupo de usuarios a los que se les otorga la posibilidad o habilidad de convertirse en usuario root durante la ejecución de algunos comandos. Este es un punto fuerte en la seguridad pasiva de los sistemas basados en Unix. No es necesario disponer de todos los privilegios de root, sino que simplemente con el echo de poder ejecutar algunos comandos en su nombre, podemos conseguir que la seguridad de nuestro sistema no se vea comprometida de manera permanente.

Básicamente, lo que un usuario sudoer puede hacer es, mediante la anteposición del comando sudo a la orden deseada, ejecutar dicha orden en nombre de root.

sudo

SuperUser DO an action

Veamos un pequeño ejemplo.

En este primer caso, ejecutamos el archiconocido apt-get update, que como es lógico, espera permisos de root:

pi@raspberrypi ~ $ apt-get update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Como vemos, el usuario pi no tiene permisos para la ejecución de dicho comando. Recordemos que es una acción muy importante, que puede modificar el estado del equipo, y por ese motivo solo puede ejecutarlo un usuario root.

Veamos qué sucede si lo hace un usuario con capa de root:

pi@raspberrypi ~ $ sudo apt-get update
Hit http://archive.raspberrypi.org wheezy Release.gpg
Hit http://archive.raspberrypi.org wheezy Release
Hit http://raspberrypi.collabora.com wheezy Release.gpg
Get:1 http://mirrordirector.raspbian.org wheezy Release.gpg [490 B]
...

Bien, claramente observamos la diferencia: el sistema otorga permisos de root (sudo) y ejecuta el comando. En este caso no se solicita password al usuario, ya que se le ha concecido pleno derecho a hacerlo (lo veremos mas abajo).

Añadiendo usuarios al grupo sudoers

Para empezar, es necesario incluir el usaurio deseado en el listado de usuarios sudoers, o lo que es lo mismo, con permisos de root. Esto se debe hacer, SIEMPRE, mediante el comando visudo, ya que es una versión de nano que aplica los cambios y reinicia el servicio al mismo tiempo. También realiza comprobaciones antes de guardar el fichero, y si existen errores, nos preguntará qué queremos hacer.

El fichero que editaremos es

/etc/sudoers

No editéis el fichero a mano, ya que es posible que suframos daños irreparables… (antes de seguir es recomendable realizar una copia del fichero…).

Edición:

pi@raspberrypi ~ $ sudo visudo

Añadimos al final del fichero el nuevo usuario del  grupo. En mi caso, lo que he hecho ha sido crear un nuevo usuario, jordi, para dejar de seguir utilizando pi, que es el que viene por defecto.

pi     ALL=(ALL) NOPASSWD: ALL
jordi  ALL=(ALL) NOPASSWD: ALL

Según la línea añadida, le indicamos a sudo que debe reconocer a jordi como usuario sudoer.

Una vez hecho esto, guardamos y salimos con Ctl+X (como en nano).

Una vez el proceso se haya finalizado, lo que haré será volver a editar este fichero y dejar comentada la línea que hace referencia al usuario pi. De este modo, pi ya no podrá hacer sudo, y añadiremos un nivel mas de seguridad a nuestro sistema, ya que se trata del usuario por defecto, y a “muchos” se les puede ocurrir hacer login con el mismo…

A partir de este momento, el usuario jordi pertenece a sudoers y puede ejecutar comandos root, con restricciones.

Con sudo es posible realizar otras muchas operaciones, como listar comandos ejecutados, ejecutar comandos de otros usuarios, etc.. Si queréis profundizar un poco mas, os recomiendo un artículo que está bastante bien escrito y es muy entendible: http://www.linuxtotal.com.mx/?cont=info_admon_014

Espero que os haya parecido interesante.

Jordi

Share Button

ix2-200 Storcenter: Cómo recuperar el sistema y actualizar a Cloud Edition

Publicado por el

En el último año he sufrido diversos cortes de luz en casa que han provocado que mis dos NAS iOmega ix2-200 hayan sufrido daños en los discos. En ambos casos perdí la información en uno de los dos discos de 2Tb que monta cada uno. Por suerte, el que lleva datos sensibles era RAID1 y, como aún quedaba un disco en buenas condiciones, decidí cambiar el malo por el bueno del otro NAS, con lo que conseguí recuperar el espejado. Pero ahora me encuentro con dos discos totalmente inservibles (bueno, casi, ya que no me podía creer que se hubieran fastidiado tan fácilmente). Aparentemente lo que les sucedió es que perdieron el MBR, y eran inaccesibles…

ix2-200 iOmega Storcenter

ix2-200 iOmega Storcenter

Bien, pues decidí que lo que tenía que hacer era recuperar ambos discos defectuosos. Y no ha sido sencillo. Bueno, si… pero no queda demasiado claro cómo recuperarlo fácilmente. Por lo tanto, lo que aquí os explico no es un tutorial, sino una “adaptación” de los tutoriales que he podido encontrar por Internet y que, a base de hacer una mezcla de procedimientos, he conseguido aprovechar para recuperar mi NAS.

Al final del artículo os dejo algunos links de dónde he obtenido la información, ya que se merecen toda mi admiración.

Finalmente, el sistema también quedó maltrecho, no arrancaba y mostraba el maldito led blanco parpadeante, o led de la muerte. Por lo tanto me he visto, incluso, obligado a flashear de nuevo el sistema operativo… Con este procedimiento, a demás, conseguiremos actualizar nuestro sistema al Cloud Edition, si es que no lo era.

Qué necesitamos?

Extracción de los discos

No tiene mayor misterio: aflojáis los tornillos inferiores de cada una de las unidades y extraéis los discos, estirando de la parte trasera para poder desplazar las bahías que contienen cada uno de ellos:

ix2-200 iOmega Storcenter - Extracción de discos

ix2-200 iOmega Storcenter – Extracción de discos

También deberéis desprender las guías que llevan para emplazarlos en las bahías. Luego volveremos a colocarlas. Llevan 4 tornillos cada una. No los perdáis!

Preparación de los discos

Es importante que los discos estén en buenas condiciones y funcionales. Para ello os recomiendo que, si no son los nuevos, una vez extraídos los verifiquéis y preparéis para ser utilizados por el NAS.

Un método muy sencillo es utilizar el DISKPART de Microsoft. Es idéntico al FDISK de Unix. Teniendo los discos conectados a la controladora SATA USB, ejecutáis DISKPART y os aparecerá un menú:

  • Listar discos: LIST
  • Seleccionar disco: SELECT # (seleccionáis el número del disco a preparar, normalmente el 1 es el de sistema, el 2, 3… el resto)
  • Aplicar limpieza, preparar el disco para dejarlo operativo: CLEAN (Ojo! Como es de esperar, esto se carga todo su contenido, incluido el MBR)

Aplicadlo a ambos discos y los tendremos listos para ser utilizados por el NAS. No los formateéis ni creéis el MBR, eso lo hará el propio NAS…

Volved a insertar los discos en el NAS, tal cuál hicisteis para extraerlos.

Re-Flasheo del Sistema Operativo

El procedimiento “normal” para recuperar o actualizar el sistema operativo de estos bichos es hacerlo desde su consola de administración, pero en mi caso, a demás de quedar inservibles los discos, parece ser que al intentar cambiar los mismos, el sistema se queda corrupto. También puede ser que a causa de otra caída de tensión al final éste se viera afectado. En cualquier caso, lo que hay que hacer es flashear de nuevo el sistema operativo. Este es un procedimiento que en los foros oficiales de Lenovo no explican. Simplemente te indican que lo que debes hacer es llevar tu NAS al distribuidor y que te lo repare… Opino que no perdemos nada si probamos lo siguiente (leed bien el procedimiento, antes de ejecutarlo):

  • Preparamos un stick USB con al menos 2Gb de espacio libre, formateándolo en FAT32 (podéis usar un formateo rápido)
  • Descargamos una versión del sistema “desencriptada” desde el enlace de más arriba (las normales vienen preparadas para ser actualizadas desde la consola, por lo que vienen encriptadas)
  • Crear la estructura de carpetas que el NAS reconocerá en el arranque para leer la imagen a flashear (este es el procedimiento que no explican en los foros oficiales…)
    • Crear la carpeta emctools en la raíz del stick USB
    • Crear la carpeta ix2-200d_images dentro de emctools, de modo que el árbol de directorios sea: X:/emctools/ix2-200d_images (X: es la unidad de USB, en vuestro caso puede ser cualquier otra)
    • IMPORTANTE: os recomiendo que creéis otra carpeta, llamada ix2-200_images ya que algunos sistemas no reconocen la anterior, de modo que tendréis también  X:/emctools/ix2-200_images (yo no lo hice y he repetido el proceso hasta 5 veces sin éxito, a la 6a fue la vencida, mi caso usaba la otra carpeta…)
    • Copiad la imagen desencriptada dentro de la carpeta X:/emctools/ix2-200d_images y X:/emctools/ix2-200_images (si, por duplicado, mas vale pájaro en mano…)
    • Ya tenemos la flash preparada!
  • Insertad el stick USB en el puerto frontal del NAS (muy importante!), con el equipo desconectado de la alimentación y de la red
  • Apretad, con el clip, y con el equipo desconectado de la alimentación, el botón de reset del NAS. Éste se encuentra en la parte trasera de la caja, es el típico botón interno, marcado con RESET. Preparad una posición cómoda, ya que tendremos que aguantar un ratito
  • Enchufad el NAS a la corriente, se encenderá el led blanco, parpadeando de manera intermitente. No soltéis el RESET, es muy importante que  lo mantengáis apretado!
  • Con el botón de reset apretado, esperamos aproximadamente unos 30 segundos, entonces empiezan (por fin!!!) a girar los discos duros. No retiréis aún el clip del botón del reset.
  • Sin retirar el clip del reset, esperamos unos 20 segundos mas, y veremos parapadear el led del stick USB. Sin soltar el reset (no, aún no…), esperamos a que el led del USB parpadee, pero de manera mas continuada, sin que se apague. Es en ese momento cuando podemos, ya, soltar el botón del reset. Han transcurrido unos 70 segundos desde que empezaron a girar los discos…
  • Ahora si todo ha funcionado correctamente, el sistema ha desempaquetado la imagen en una carpeta local temporal y se dispone a flashear la rom con esta nueva versión.
  • Pasado un tiempo no muy largo, el sistema se apagará automáticamente, entonces ya lo tenemos flasheado y listo para funcionar
  • Ahora ya si podemos conectar la red y pulsamos el botón frontal de encendido

Y ya tenemos el sistema listo nuevamente. Sed pacientes, después de volver a encenderlo el sistema se reinicia totalmente, y prepara los discos. Dependiendo de la capacidad de ambos y de si montaban RAID1 el tiempo que el equipo puede estar sin responder puede ser de varias horas. En mi caso, con dos discos vacíos (nuevos) y sin RAID, ha tardado unos 35 minutos en total. Transcurrido ese tiempo, ya podréis acceder al LenovoEMC Storage Manager y comprobar que detecta nuevamente vuestro nas.

Y así finalizamos el flasheo y recuperación de los discos del ix2-200 Storcenter, versión CLoud Edition.

Espero haberos sido de ayuda. Cualquier cosa, podéis comentarlo.

Gracias!

PD: links de interés y de agradecimiento

Share Button

RasPi: conectando un SAI Salicru SPS One 900VA

Publicado por el

Muy buenas.

En esta ocasión quiero compartir con todos vosotros mi reciente experiencia con este SAI, el maravilloso SPS One de SALICRU, en su versión 900VA (http://catalogo.salicru.com/es-domestic/sais/sps-one). No voy a hacer demasiada publicidad, así que me dedicaré básicamente a explircaros cómo conseguí hacerlo funcionar bajo Linux. En especial, en mi Raspberry Pi, pero creo que podríamos aplicar sin demasiadas diferencias ni problemas, todas las indicaciones para llevarlo a cualquier Linux.

SPS-ONE

SPS-ONE

Por qué un SPS One?

Fácil: PRECIO. Es increíblemente barato para las prestaciones que ofrece. El de 900VA (más que suficiente para un par de PCs en casa), alrededor de los 57€. Los hermanos menores, a razón de unos 5 o 7€ menos por categoría.

Mi principal interés era tener un SAI que alimente mis dos NAS de manera que no pierda mas información por causas de caida de tensión, como ya me ha pasado en varias ocasiones. Sólo he encontrado compatibilidades con APC, de precios de mas del triple que este, y no con mejores prestaciones. Por lo tanto, me puse a buscar en Internet, y vi que “otra vía era posible”. Alguien ya había probado con éxisto este mini tutorial que hoy os traigo, así que me tiré a la piscina, compré el mío, y hoy mismo mientras lo pruebo, os escribo este contenido.

Espero que os parezca interesante, contadme qué tal…

Culturilla general

Bien, como os comentaba, por mucho que diga “compatible con Linux”, no es del todo cierto… Ese software que promueve la marca (View Power) no sabe demasiado bien cómo comportarse con Linux. Pero existe otra alternativa, que es la plataforma NUT (Network UPS Tools). NUT ofrece infinidad de drivers, pero “ninguno” compatible con el SPS One (bien, no es del todo cierto). Pero alguien dice por ahí que el driver blazer_usb no se comporta del todo mal. Y es cierto! No voy a entrar en detalles, podréis encontrar mas info al respecto por Internet sin problemas…

El SPS One ofrece, como digo, unas prestaciones mas que interesantes, y la garantía del fabricane (español!) es mas que reconfortante: hasta 90000€ en caso de incidencia no cubierta por el SAI.

Así que me fui, como dije a por él. Y por ahora no me ha decepcionado, esperemos a ver cuando caiga la tensión, qué sucede…

Instalación del cliente

Al tajo. Vamos a por el software que nos interesa. Instalaremos las estupendas librerías y drivers del NUT, como ya he comentado. Tiene infinidad de posibilidades que en otra entrada, mas adelante, os comentaré. Por ahora centrémonos en lo básico, establecer la primera comunicación.

Lo primero de todo, como siempre, es tener al día nuestro repositorio de software y nuestro sistema operativo:

$ sudo apt-get update & sudo apt-get upgrade & sudo apt-get autoclean & sudo apt-get autoremove

Ahora ya podemos instalar el cliente y el server (con la siguiente orden se instalan ambos por defecto):

pi@raspberrypi ~ $ sudo apt-get install nut

Si todo ha ido bien, al final de la instalación veréis una información importante, la confirmación de la instalación y las rutas de los ficheros de configuración.

En este caso se habrán instalado los paquetes:

  • nut-client
  • nut-server

Resultado para el cliente:

[info] nut-client disabled, please adjust the configuration to your needs.
[info] Then set MODE to a suitable value in <strong>/etc/nut/nut.conf</strong> to enable it.

Resultado para el server:

[info] nut-server disabled, please adjust the configuration to your needs.
[info] Then set MODE to a suitable value in /etc/nut/nut.conf to enable it.

Bien, nuestro fichero de configuración es: /etc/nut/nut.conf para ambos casos

En ese mismo directorio encontramos, a demás, el resto de ficheros que tendremos que configurar:

pi@raspberrypi ~ $ ls /etc/nut
nut.conf  ups.conf  upsd.conf  upsd.users  upsmon.conf  upssched.conf

Configuración

A continuación, un pequeño detalle de qué es cada fichero y algunas indicaciones de cómo configurarlos. Cuando accedáis a cada uno de ellos podréis ver la documentación, añadida al principio en modo de comentarios. Os recomiendo que los leáis antes de modificarlos y entonces lo hagáis en base a vuestras necesidades. Lo que a continuación os expongo son puros ejemplos muy básicos.

nut.conf

Este fichero es el que contiene la configuración “genérica” del driver. En nuestro caso le tendremos que indicar que sólo vamos a administrar o monitorizar un SAI:

MODE=standalone

 ups.conf

Este fichero es el que define cada uno de los SAIs que vamos a administrar. En nuestro caso, solo uno, un SPS One 900VA. Indicaremos el driver a utilizar, blazer_usb, el puerto serie de comunucación, debe ser auto (ya que es USB y no serial, y por lo tanto será el driver quien lo administre), y por último la descripción, desc, en la que podemos escribir aquello que mas nos convenga para describir el dispositivo configurado:

[salicru]
driver = blazer_usb
port    = auto
desc    = "Salicru SPS One 900VA"

upsd.conf

Este fichero contiene la configuración del demonio de comunicación. Define quién realiza la comunicación, así como el puerto y el número de conexiones máximas permitidas. Para nuestro caso, los valores por defecto son correctos:

MAXAGE 15
STATEPATH /var/run/nut
LISTEN 127.0.0.1 3493
MAXCONN 1024

upsd.users

Definición del (los) usuario(s) con permisos para obtener datos de la comunicación abierta. El contenido es bastante autoexplicativo. Cada sección define un usuario y los permisos otorgados. Para nuestro caso, solo hemos creado un usuario, admin (podemos crear cuantos queramos) con los valores que vienen por defecto:

[admin]
        password = 12345
        actions = SET
        instcmds = ALL

Este usuario admin puede modificar algunos parámetros del SAI (actions = SET) y ejecutar todos los comandos posibles (instcmds = ALL). Para nuestro caso ilustrativo es suficiente, pero sería recomendable aplicar un password mas seguro y repartir las posibles acciones entre diversos usuarios, según su rol (aministrador, monitor, ejecutor, etc…).

upsmon.conf

Por último tenemos este fichero, que es el que contiene los parámetros utilizados por el driver, para realizar las comunicaciones, apagar automáticamente el sistema e incluso enviar emails en caso de existir alguna emergencia. Dejaremos la mayoría de valores por defecto, excepto algunas cosillas que paso a explicaros:

MONITOR salicru@127.0.0.1:3493
NOTIFYCMD /usr/local/ups/bin/notifyme.sh # hay que crearlo!
NOTIFYMSG ONLINE        "UPS %s on line power"
NOTIFYMSG ONBATT        "UPS %s on battery"
NOTIFYMSG LOWBATT       "UPS %s battery is low"
NOTIFYMSG FSD           "UPS %s: forced shutdown in progress"
NOTIFYMSG COMMOK        "Communications with UPS %s established"
NOTIFYMSG COMMBAD       "Communications with UPS %s lost"
NOTIFYMSG SHUTDOWN      "Auto logout and shutdown proceeding"
NOTIFYMSG REPLBATT      "UPS %s battery needs to be replaced"
NOTIFYMSG NOCOMM        "UPS %s is unavailable"
NOTIFYMSG NOPARENT      "upsmon parent process died - shutdown impossible"
NOTIFYFLAG ONLINE       SYSLOG+WALL
NOTIFYFLAG ONBATT       SYSLOG+WALL
NOTIFYFLAG LOWBATT      SYSLOG+WALL
NOTIFYFLAG FSD          SYSLOG+WALL
NOTIFYFLAG COMMOK       SYSLOG+WALL
NOTIFYFLAG COMMBAD      SYSLOG+WALL
NOTIFYFLAG SHUTDOWN     SYSLOG+WALL
NOTIFYFLAG REPLBATT     SYSLOG+WALL
NOTIFYFLAG NOCOMM       SYSLOG+WALL
NOTIFYFLAG NOPARENT     SYSLOG+WALL

Con esto ya podemos conectar el SAI al usb de la Pi y lanzar el daemon. Recordad reiniciar la Pi antes, para asegurarnos que el driver obtiene los datos de configuración correctamente y que se carga el driver usb.

Probando el driver

Bien, ya podemos probar el driver. Si todo ha ido bien, tras reiniciar la Pi, se habrá lanzado el daemon automáticamente.

Así que para comprobar que está todo funcionando, podemos ejecutar el siguiente comando:

pi@raspberrypi ~ $ sudo upsc salicru@127.0.0.1:3493
battery.charge: 100
battery.voltage: 13.60
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.type: ups
driver.name: blazer_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.4
driver.version.internal: 0.08
input.current.nominal: 3.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 246.5
input.voltage.fault: 246.1
input.voltage.nominal: 230
output.voltage: 246.5
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 18
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

Y obtenemos un listado de valores, en el que se especifica, entre otros, la carga de la batería actual, voltajes de entrada / salida, de las baterías, etc…

Arranque manual del driver, del daemon y del monitor

Si algo ha fallado, y el driver no se ha iniciado automáticamente, el comando anterior no funcionará…

Podemos arrancar de manera manual de la siguiente forma:

pi@raspberrypi ~ $ sudo upsdrvctl start
pi@raspberrypi ~ $ sudo upsd
pi@raspberrypi ~ $ sudo upsmon

Bien, ¿qué estamos haciendo en cada línea?

  • primero arrancamos el driver usb: upsdrvctl start
  • luego arrancamos el daemon: upsd
  • y, finalmente, el proceso monitor de estado del sai: upsmon

No es necesario indicar la ruta física de los comandos, dado que al instalarlo con apt-get el mismo instalador nos configura el servicio y el PATH.

Si todo ha ido correctamente, no aparecerá ningún mensaje de error. En caso contrario, podemos añadir el modificador -D a cada comando para ejecutarlo en modo debug, el cuál nos ofrece algo mas de información…

Con esto concluyo esta primera entrega. En una segunda veremos cómo explotar estos datos. Como veis, no sería demasiado difícil extraer los datos y tratarlos, hay muchas maneras de hacerlo. Ya veremos alguna otra…

Espero que os haya parecido interesante.

Jordi

Share Button

Eclipse: SVN necesita JavaHL, cómo instalarlo en Ubuntu

Publicado por el

Cuando instalamos el plugin de SVN de Tigris en Eclipse, es muy probable que necesitemos instalar los conectores JavaHL para que funcione correctamente.

Bien, os dejo unos breves pasos que debemos seguir para poder llevarlo a cabo en Ubuntu.

Obtenemos la librería

$ sudo apt-get update
$ sudo apt-get install libsvn-java

 Actualizamos la base de datos de librerías

Este paso es muy importante. Me volví loco cuando lo hice, y se me olvidó. Por lo tanto, por mucho que instales la librería, Linux no se “entera” de que tenemos una nueva y hay que actualizar la base de datos… Aviso, tarda un poco.

$ sudo updatedb

Buscamos la librería

Ahora si, podemos buscar la librería.

$ locate libsvnjavahl-1.so
/usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so
/usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so.0
/usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so.0.0.0

 Actualizamos el script de arranque de Eclipse

Ahora ya estamos preparados para poder arrancar Eclipse. Para ello, le indicamos en el script de arranque que debe tener en cuenta unas librerías específicas…

-vmargs
-Djava.library.path=/usr/lib/x86_64-linux-gnu/jni

Suerte!

 

Share Button