Eclipse Luna: solucionar problemas con el proxy…

Publicado por el
Eclipse Luna

Eclipse Luna Splash Screen

Siempre me gusta estar a la última, y por eso, muy a menudo me descargo la última versión de Eclipse (www.eclipse.org), ese IDE que “casi” todos conocemos de sobras. La última versión, en el momento en el que escribo este post, es Eclipse Luna, o sea, versión 4.4.0.

Bien, el problema que me encuentro, y que parece ser algo normal desde la versión 4 de este estupendo IDE, es que si te encuentras desarrollando desde tu empresa y, como es normal, esta usa un proxy, posiblemente no puedas acceder al Eclipse Market, ni a las actualizaciones automáticas, ni por ende, a las descargas de Maven… El problema parece ser que es debido a una incompatibilidad de las librerías del proxy que se añadieron a partir de esta versión, y que son incompatibles con algunos proxies conocidos…

La solución es sencilla, aunque claro, no se te ocurre a ti, sino a otros que saben mas que tú y les gusta investigar… Por eso yo, que ya lo he probado, os lo ofrezco en mi blog.

Lo primero que hay que haces es configurar el proxy correctamente desde las opciones de configuración de Eclipse. Para ello, nos vamos a: Window > Preferences >General > Network Connections

Configuración de redes en EclipseAhí, lo recomendable es ponerlo en Manual y escribir las credenciales y direccionamiento de vuestro proxy. Tendréis que añadir, a demás, el usuario y password que os sea requerido. En la parte inferior podéis dejarlo como está, que normalmente es que no use el proxy para conexiones locales, 127.0.0.1 o localhost.

Es muy importante que no informéis la configuración de SOCKS, a no ser que estéis muy seguros de que lo necesitáis. Existe una issue desde hace mucho tiempo que hará que no funcione correctamente (este era realmente mi error…).

Tras esto, ya podéis reiniciar, ir al Eclipse Marketplace  y cruzar los dedos… Es posible que siga sin funcionar, por lo que ahora deberemos aplicar la otra solución o workaround que otros han encontrado: cambiar las librerías del proxy por las del JRE de Java… Esta solución podéis verla en StackOverflow: http://stackoverflow.com/questions/22148782/unable-to-connect-to-the-eclipse-luna-market

Os dejo la sentencia que debemos aplicar al fichero eclipse.ini de nuestro IDE, tras el modificador -vmargs:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.pro‌​vider.filetransfer.httpclient4

Con esto último ya deberíamos tener solucionado nuestro problema con la conexión a Internet de Eclipse Luna, y de cualquiera de sus hermanos de la versión 4.x.x.

Espero haberos sido de ayuda, y que me comentéis si os ha servido.

Gracias por leerme!

Jordi

 

Share Button

25a Festa de Trenet, a Cornellà de Llobregat

Publicado por el

Como cada año, el Club d’Amics del Ferrocarril de Cornellà celebra su conocida Festa del Trenet en el parque de Can Mercader de Cornellà. La cita tendrá lugar el próximo 19 de octubre de 2014, y estáis todos invitados! Habrá circulaciones en el circuito de trenes de 5″ del propio parque, como ya viene siendo habitual los domingos de cada mes, pero a demás, contaremos con la 25na Trobada de Vaporosos a nivel internacional, en la que intervendrán locomotoras a vapor de 5″ de diversos puntos y asociaciones de España, así como parte del extranjero.

Los interesados, podéis contactar conmigo o bien directamente con el club en su web, http://www.cafc.cat, dónde estarán muy orgullosos de atenderos y ofreceros toda la información que sea necesaria.

Os dejo el cartel del encuentro.

Cartell 25na Festa del Trenet

Cartell 25na Festa del Trenet

Share Button

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