Nueva incidencia del sistema...

Esta vez y no será la última, la culpa no es de la estación ni de la raspberry.
Esta vez la culpa la ha tenido el FTTH. Escapándose de mi control, el FTTH donde está ahora conectado no tiene la dirección IP fija, si es cierto que no cambia todos los días. Desde que la puse no ha cambiado, pero esta mañana no accedía al servidor web y meteoclimatic no tenía datos. Tras investigar descubrí que había cambiado la IP pública.
Bueno pues ante este incidente no queda mas remedio que tirar de un DNS dinámico.
Como ya tengo cuenta en DnsDynamic y registrado el dominio para la raspberry pues no tengo mas que reutilizarlo. Ahora bien, para la actalualización de la IP en el servidor he instalado en la Raspberry el cliente DDclient.  No tiene mas historia que instalarlo con:

sudo apt-get install ddclient

Durante la instalación te pide datos para su funcionamiento. Aunque se los demos después hay que editar el archivo /etc/ddclient.conf para actualizar unos parámetros.
Este es el archivo que uso.

# Configuration file for ddclient generated by debconf

#

# /etc/ddclient.conf

daemon=900-->El tiempo que quieres que tarde en actualizar la IP en segundos.

protocol=dyndns2

use=web, web=http://myip.dnsdynamic.org/---> Esto es lo que hay que cambiar. El original coge la ip del interfaz ethernet y esa dirección es privada y no sirve, como no lo hagas te quedas tirado sin acceso desde remoto.

server=www.dnsdynamic.org

login=tuemail@elquesea

password='tupassword'

tudomino.dnsdynamic.com

Con esto ya no debería de tener mas este problema.

Ya vendrán otros.

P.D. ; No se han hecho esperar. Todo está configurado correctamente y el daemon de la raspberry actualiza correctamente la IP pública en el servidor, pero el servidor no devuelve la dirección¡¡¡¡¡.....parece que es un problema de DnsDynamic. Quiero recordar que ya hace tiempo ocurría y por eso lo abandoné. Otra cosita mas....buscar un servicio de DNS dinámico que funcione y que sea gratuito.

P.D.2; Como Dnsdynamic no me presentaba la página, me he registrado en Dynu.com y esta si que funciona. Así que ya tengo DNS dinámico y ya se puede encontrar la página y la plantilla si cambia la IP. Al menos eso espero.
http://ulisespi.dynu.com/weewx/

Haciendo un backup de la base de datos

2016-1-5.
Buscando por internet he encontrado un metodo por el cual se puede realizar un backup de la base de datos online, esto es, sin necesidad de realizar una copia del archivo ya que ese procedimiento puede dar lugar a un error en la copia o dejar la base de datos inoperativa.
Este método al realizarse desde el propio SQlite, establece los mecanismos para acceder y bloquear la base de datos mientras está en uso.
La información fundamentalmente la he sacado de la siguiente página web:
http://www.ibiblio.org/elemental/howto/sqlite-backup.html

Y este es el extracto que me interesa:

Backing up the database

To make a backup copy of the database, simply do a "dump" and redirect the results to a file.

cd /home/sqlite
sqlite3 sample.db .dump > sample.bak

En principio y desde la consola de comandos he comprobado que funciona y que se realiza el volcado correctamente. Ya solo queda crear un archivo de comandos del sistema operativo e incluirlo en el directorio crondaily$ para que se ejecute diariamente o con la periodicidad que nos parezca oportuno para nuestra seguridad.

Bien pues este es el archivo que he creado para realizar la copia de seguridada automática:
#!/bin/bash
cd /mnt/datos/home/pi/backups
if [ -e weewx.sdb.bak ];
then
mv weewx.sdb.bak weewx.sdb.bak2
else
echo "El archivo weewx.sdb.bak no existe"
fi
sudo sqlite3 /var/lib/weewx/weewx.sdb .dump > weewx.sdb.bak

exit

Lo incluyo en el cronweekly$ directorio y a esperar a que cumpla con su tarea voluntariosamente.

Preparando el entorno de pruebas. Segunda Parte.

2016-1-5.
Tras configurar y dejar funcionando el registro de log's del entorno de pruebas, paso a configurar el espacio de pruebas. Esto basicamente se basa en los siguientes puntos:

1. Crear un archivo pruebas.conf basado en el archivo weewx.conf. Este está situado en el directorio /etc/weewx/.
2. Editar este archivo para que las páginas que se generen lo hagan en el directorio dedicado a ello. El apartado a modificar es el siguiente:
   [StdReport]
   
       # Where the skins reside, relative to WEEWX_ROOT
       SKIN_ROOT = /etc/weewx/pruebas
   
       # Where the generated reports should go, relative to WEEWX_ROOT
       HTML_ROOT = /mnt/var/www/pruebas
3. Copiar el directorio Skins completo en otro llamado pruebas, quedará situado en el directorio apuntado por Skin_Root del punto anterior. Esto no es obligatorio, podemos llevarnos todo esto al espacio que nos de la gana tanto de la Sd como del disco duro si lo tuvieramos.
4. Crear un espacio Pruebas donde alojar las páginas generadas de prueba y que estas puedan ser servidas por el servidor WEB. En mi caso como tengo todo alojado en el disco duro pues le creo un directorio como apunta en HTML_ROOT del punto 3. Tal como se crea este directorio no se puede ver desde el servidor web, ya que el servidor sirve las páginas desde /var/www. Tengo que crear un enlace simbólico desde el disco duro a la Sd. El comando sería este:
   ln -s /mnt/var/www/pruebas/ /var/www/pruebas
   De esta manera ya se puede ver desde internet.
5. Si todo está correcto podemos comenzar a lanzar el primer comando de pruebas:
   sudo wee_reports /etc/weewx/pruebas.conf
   Si no lanzamos el comando con sudo nos da error de permisos, ya que weewx se instaló y corre bajo root, sus directorios y archivos le pertenecen y aunque son accesibles como lectura no se dejan sobreescribir ya que somo pi o el usuario correspondiente con el que nos logueemos.
6. Podemos realizar el seguimiento del resultado de la generación de las páginas con el comando:
   tail -f /path hacia el archivo log/wee_reports.log

Esto es todo de momento.

Preparando el entorno de pruebas. Primera parte

2016-1-5.
Bueno pues como de los errores se aprende, tras el último estropicio que ha sido el cargarme la página principal de la estación (index.html), acometo lo que tenía que haber hecho hace ya tiempo.
Con esta entrada documento el principio de lo que voy a llamar el entorno de pruebas o desarrollo, según he estado viendo por internet también se le llama sandbox. Esto creo que es una alegoría a lo que hacen los niños pequeños en los parques, pues eso jugar en un cajón de arena.

Como he aprendido a probar las modificaciones realizadas en la plantilla sobre la marcha sin esperar a que cumpla la temporización por el proceso principal WEEWX, lo primero es separar las acciones y los mensajes generados por ambos procesos diferenciados.
El proceso que lanzo para probar es el WEE_REPORTS. Por tanto lo primero es redirigir los mensajes que genere este proceso a un archivo log independiente para poder visualizarlos y llevar un seguimiento de los resultados.
La tarea de mantener un registro de todos los mensajes la realiza el proceso RSYSLOG del SO.
Este proceso por defecto lee todos los archivos de configuración que se incluyan en su directorio RSYSLOG.D. Bueno pues he copiado el archivo de configuración existente 99-weewx.conf en el archivo 99-wee_reports.conf y lo he modificado quedando de esta manera:
:programname,startswith,"wee_reports" /mnt/var/log/wee_reports.log
:programname,startswith,"wee_reports" ~
El proceso Rsyslog se lanza con el sistema operativo y funciona permanentemente.

Como este archivo se está alimentando continuamente de mensajes y mas si es de pruebas, pues como el resto de los archivos log's lo voy a incluir en la tarea LOGROTATE para que se reciclen de tal manera que cambie de nombre y se compriman cada cierto periodo de tiempo.
Para ello hago algo parecido a lo anterior.
La tarea LOGROTATE por defecto tambien lee todos los archivo *.conf que existen en su directorio /etc/logrotate.d/, por lo que copio el archivo weewx en el archivo wee_reports y lo modifico quedando de la siguiente manera:
/mnt/var/log/wee_reports.log {
  weekly
  missingok
  rotate 52
  compress
  delaycompress
  notifempty
  create 644 syslog adm
  sharedscripts
  postrotate
  reload rsyslog > /dev/null 2>&1
  endscript
}
Con esto mantengo la misma politica sobre los archivos log's que para el resto de aplicaciones.
El proceso Logrotate se lanza con la tarea CRON y es ejecutado cada cierto tiempo según se haya configurado en el demonio CRON. En mi caso se encuentra dentro del directorio cron.daily$, por lo que se lanza diariamente.

Página para la generación de scripts para la sindicación de Feeds RSS

2016-1-3.
He encontrado la siguiente página Web para la generación de scripts y poder incluirlos en página web. Así podré tener los titulares de un blog por ejemplo. En mi caso mi blog en el que llevo todo lo referente a mi estación meteorológica y todo lo que relacionado con ella.
La dirección de la web es la siguiente:
http://rss.sindicacion.net/

Administrador de bases de datos SQLITE

2016-1-1. Instalación de SqliteBrowser.
Para la administración de la base de datos de Weewx he instalado el administrador de bases de datos Sqlite SqliteBrowser.
El comando como siempre es:
sudo apt-get install sqlitebrowser

El programa se abre en entorno gráfico por lo que hay que acceder a la Raspberry en entorno gráfico.
Desde mi Mac, las opciones para ello pueden ser:

1. Acceso remoto de Windows, instalando el servidor Remote Desktop Protocol XRDP en Raspberry y el cliente de Conexión de Acceso Remoto para Mac.
   
2. Acceso VNC, instalando el Servidor TightVncserver en Raspberry y el cliente VNC viewer en Mac.
3. Acceso X11 con la aplicación XQuartz de Mac OSX.

La diferencia es que las dos opciones primeras lo que hacen es arrancar el escritorio en la Raspberry y te la traen a tu escritorio local, mientras que la aplicación X11 es un protocolo nativo de Linux y se trata de un servidor de ventanas, por lo que lo único que te traen a tu escritorio local es la aplicación que tu arranques, no el escritorio completo de Raspbian. Por tanto para el tema de la carga aplicada a la pequeña Raspberry le viene mejor esta última, así como para la transmisión de datos por línea que será menor también.

Archivos Log's en Raspberry. Apache2 y Weewx

2016-1-1. Para minimizar los accesos continuos sobre la SD de la Raspberry, dirigí el archivado de los archivos Log's de las aplicaciones Apache y Weewx al disco duro que tengo instalado en un puerto Usb de la Raspberry. Este lo tengo montado en /mnt/var/log/
A día de hoy el archivado se está realizando correctamente en el disco duro.

-rw-r--r-- 1 root adm  1228789 ene  1 17:06 weewx.log

-rw-r--r-- 1 root root 406596 ene  1 16:55 access.log

..etc.

Instalación de PHP5 en Raspberry

2015-12-31.
Para poder incluir en la página web de la estación el feed de RSS he encontrado una función en internet que funciona desde la propia Raspberry y para ello necesitaba tener instalado PHP.
Las páginas web desde donde he sacado la información son estas:
http://www.webtaller.com/maletin/articulos/agregar-feeds.php
http://magpierss.sourceforge.net/

El comando para instalar PHP es el siguiente:

sudo apt-get install php5

Con ello queda instalado PHP5, el resto es seguir las indicaciones para poder utilizar la función magpierss dentro de la página web de la estación.