Translate

martes, febrero 23, 2016

Iniciarse en domotica casera, Raspberry Pi y Z-WAVE, Parte II: Instalar jeedom

Las instrucciones oficiales estan aqui y están en francés.
Para instalar este software gratuito para la administración de periféricos Z-WARE necesitaremos las siguientes herramientas:

-Raspberry PI B+, 2...
-PC con WIndows XP, 7 ó 10
-Descargar la herramienta win32diskimager , hacer click. Herramienta para grabar en la microSD la imagen de jeedom.
-Descargar la imagen jeedom-rpi-X.XXX.rar desde aqui

Descomprimiremos la imagen con una herramienta común como winrar, posteriormente la grabaremos en la microsd con win32diskimager.

Es cómodo usar un teclado y un tv hdmi conectados a la raspberry pero no son necesários, yo la he conectado a mi router por cable rj45 y alimentar la raspberry con un cargador microusb de móvil.

La raspberry recibe por DHCP la ip del router, para saber que IP le a dado podermos entrar en la página de administración del router y ver que IP le a dado o más facil todavía instalarse ne el móvil o tablet la app FING y darle a un broadcast de tu red wifi, enseguida ver´ças a tu rasp. con la ip asignada.

Una vez conocida la IP hacer login por SSH con PuTTy, las credenciales son:

jeedom/Mjeedom96

Una vez estamos en la shell tendremos que modificar parámetros del Sistema operativo para adaptarlos a nuestras necesidades y expandir la capacidad del espacio de disco al total de nuestra microsd, ejecutaremos :

$sudo raspi-config


Una vez aplicados los parámetros reiniciaremos nuestra rasp. para tener al dia la distribución intalada pasaremos los siguientes comandos:
$sudo apt-get update
$sudo apt-get dist-upgrade


Por último ya tendremos jeedon funcionando en el siguiente enlace:

http://IPraspberry/

Los parámetros para entrar son admin\admin
Una vez logeados estará todo en francés, necesitamos ir a ajustes para asignar la localización al español.

Fin:
Con este artículo pretendo dar los parámetros para tener instalado jeedom en nuestro rasp. podremos verlo operativo y empezar a toquetearlo pero apara trabajar con dispositivos Z-WAVE necesitamos la instalación de la tarjeta GPIO raZbeery y el software Z-WAY, temas que trataré en el siguiente artículo.



lunes, febrero 22, 2016

Iniciarse en domotica casera, Raspberry Pi y Z-WAVE, Parte I Hacerse con los materiales.

Mi casa es un piso de unos 95 metros y tenemos calefacción central controlada por un termostato siemens, aunque podamos programar cosas (horas del día, horario, etc..) es muy simple y solo subimos y bajamos la temperatura de forma manual según el frío que tengamos.
He visto que en jeeddom se pueden hacer cosas interesantes, como programar el termostato de forma remota, mi duda es qué termostato Z-WAVE puedo usar, uno que me indique además el gasto acumulado.
Y el control eléctrico, básicamente ver los consumos acumulados de forma instantánea, así sabría más o menos lo que llevamos gastando en lo que va de mes.. aunque sinceramente, le veo poca utilidad.
Aprovechando que en el trabajo un compañero me a cedido su Raspberry Pi B+ me lanzo al verde y empiezo con el proyecto. Acabo de hacerme con el siguiente material para “arrancar”:
-RaZberry para Raspberry PI
-Enchufe Z-Wave GreenWave con control de consumo

Total: puesto en casa 112€ Iva incluido
Mi intención es cargar jeedom en la rasp. y empezar a jugar con el enchufe y ver como va el control de consumo, además aterrizar en el mundo Z-Wave.
He intentado documentarme lo mejor posible para no encontrarme con incompatibilidades de hard/soft y tener un primer controlador z-wave lo mas compatible posible.
Mas adelante me regalaré un PIPER CLASSIC, veo que es un dispositivo ultra completo así que todo dispositivo que vaya comprando quiero que sea compatible con él, segiré manteniendo la rasp. con jeedrom ya que he visto que PIPER no controla consumo , solo interruptores de tipo ON/OFF…
Foro de ayuda domotica:
http://www.domoticadomestica.com/foro/index.php#c4



martes, febrero 16, 2016

Combinando SSH, cron y at


De nuevo vamos a tratar de un tema en donde la terminal en modo texto y programas desde la linea de comandos son los protagonistas. Probablemente, este articulo no le sirva de mucho a un usuario domestico, con un solo ordenador en casa, pero si quieres ir conociendo tu sistema mas a fondo, y tienes que administrar mas de una maquina/servidor, sigue leyendo que puede que aprendas algo.
En este articulo vamos a ver como conectarse sin clave de acceso a otros ordenadores, de una manera segura, con ssh. Tambien veremos como configurar nuestro sistema para que trabaje por nosotros, automatizando tareas con cron y at. Y por ultimo, como combinando estas tecnicas, podemos ejecutar trabajos y recoger informacion de forma automatica de muchos ordenadores a un servidor central.

SSH sin clave de acceso

No vamos a tratar como instalar SSH (cliente/servidor) en vuestras maquinas. Esto no deberia de ser un problema en las distribuciones de hoy en dia y muchas de ellas instalan este programa por defecto. Suponemos antes de seguir que tanto el cliente como el servidor SSH estan instalados y funcionando en vuestros ordenadores.
SSH (Security SHell) es un programa que permite conectarse de forma segura entre maquinas que tengan este programa instalado (cliente y servidor). Entre muchas de las cosas que SSH ofrece, la mas importante es que todo el trafico entre dos maquinas (incluido cuentas y claves de acceso) es encriptado. Con esto se evita que informacion importante y confidencial caiga en manos ajenas en el caso que alguien este 'escuchando' lo que viaja por la red con un programa 'packet sniffer'.
Para conectarse con SSH, como el usuario 'user', de una maquina llamada 'servidor1' a otra llamada 'servidor2', podemos escribir en una terminal lo siguiente:
[user@servidor1]# ssh user@servidor2
user@servidor2's password: xxxxxxx
 
Last login: Sun Oct  1 15:46:02 2006
[user@servidor2]# 
Lo normal es que haya que escribir la clave de acceso cuando nos conectamos a otro servidor. Esto no es un problema siempre y cuando estemos trabajando de forma interactiva y podamos escribir la clave, tampoco es un gran problema si nos conectamos pocas veces. Pero si queremos que una maquina se conecte de forma automatica a otra para realizar un trabajo, o tenemos que conectar muchas veces a diferentes maquinas, el tener que escribir la clave todo el tiempo termina siendo un problema. Esto lo podemos solucionar usando lo que se llaman claves privadas y publicas. No vamos a explicar que significa esto, esto se escapa del tema del articulo, pero al final damos unos enlaces que podeis usar para profundizar en el tema si quereis.
Para generar nuestras claves publica y privada vamos a utilizar el programa ssh-keygen que forma parte de SSH. A continuacion teneis un ejemplo de como podemos generar estas claves:
[ralf@servidor1]# ssh-keygen -t rsa
 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ralf/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/ralf/.ssh/id_rsa.
Your public key has been saved in /home/ralf/.ssh/id_rsa.pub.
The key fingerprint is:
09:f7:58:bc:07:3f:f4:70:7b:d7:ce:cb:6b:61:f8:9c ralf@servidor1
En este ejemplo hemos generado dos claves, una privada (/home/ralf/.ssh/id_rsa) y otra publica (/home/ralf/.ssh/id_rsa.pub) del tipo RSA con una longitud de 2048 bits. No hemos utilizado 'passphrase' para no tener que escribirla cada vez que nos conectemos.
A continuacion podeis ver el contenido de la clave privada y publica del ejemplo:
[ralf@servidor1]# cat /home/ralfm/.ssh/id_rsa
 
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAw0a4dn8wGAaRcMuIPY8/pk11YPV5Nk6R5VCtHNLnH2+hmsMw
47wMdJ8PC9Vu6bDYLgSwRIpV83kEJSE1DdHB93qExqjXnA7EWOzgmjjbSTbi2kfN
xB4Vh9tS3dXCy/9xfcUrYj8LZH931I3y46YQAswmDqS9nZCvoE9xmzDmt9uecSOE
39e5aZiHwOGXlyNkExRRBT2JIDcL9aeAa1HclnRTbsZVWsxX8+K6koVvsmMhRZNq
XoSuU+CWGse/UsLbo2sWHUKaFVMBVc2h0E4j08Rm/R85BgwzgxXr+ql6Tv1qJjyd
lFJkUuD6RJ78X/Wp9HqVwM9i9v/hyE6FK9GtMQIBIwKCAQB6vr0XSKHjN1QbA5d3
JteNGr7POzY/ZJY4XpizCDmBeV5EBamzuAfURrkAH8IPO/WZRMaRe4Z7yGkBZVSM
V/ZDyVrGA7q53WV5uXc8XkCxrXimdkbTC5iBSAgzqu946bUNOhtFEa9jvdZLF2V5
Jo24nZRDuAIohtTLKp8uWUCQ0hbq+NIg85tZhHuIgQtqFZNBF2YIOTNN6v532Ena
YvNZUGfmYwJG1CurA1dUseL06bSB9LpOIaOG2j5bYWnhogshih0CYShzi1S8tJCN
tpfMz2WWYGN/Mxa6Itq0xI+kVH0hLFkhoU/ryJ76toklFs7yZR2APPcgCJVxX3b/
DLoTAoGBAOvAd5Raz+Wc1LU5sH5diHNEYz+6etyUR3p5k7cLLMQ9Ye7u1NjBLWzF
NRpF3md+I88X4qZCu6OKL/Dj4+ah9uXoi850D/G9rLfUIgtpLwxpx6jeseJuvGLr
GB49lE6wFDlf460eaHhB5ndLX2i9UQ0Oqbyp0n9zYSpmqUsyQBqfAoGBANQMTqI5
Vbm+WcguBrWceJ3P3UwPIdrtEPymJGsnnvJK+zORaz7L2QLNKE+LupOAEVXqlCdZ
qsxzJuTrVIGyj/tLVQI8r1xaAs5VdQ2FqyXp+JyApXJ7fomHI3HMCwFIBa+F73nu
9OzrUp1THS3QXWrv0uRWm+X/M/gtR4hMiPYvAoGAf/rEkl0vB55HlZRYfxzVC1+j
l5+/CgdaAKhmIYm5N1SFnvauD0RL2/YG4mBxa2G7qu+1jXSvAQHfgsTazahhdX49
RDBgbUm1iF03DYI+HK5zs3GTxBA6YZWQv/WLBiUSSwgrI3boQUhYiecWiVDUOknJ
23Ih0CixFwSHybwxbYkCgYEAwd9d1iXKuHOFSU6nDHHNXRXRpKAe9AvyRhQ+jdsU
+sg2IIT0Vqu/GIEO6aRS0AAP2YYDzDS5anfpC8/YPBD4qz2PjQRIjvM1w/ZcZCJw
l7FYVJLgaKtsYHuOHuZwdjM4ZfbMUjmPeYax7uznelga5W2NnZEDkHRMxaW9vnHc
TssCgYEAifwa8oq5eVl5qw/gh4s3Tv3Qjk6SCxIXCF2FwKUfYmkl7v/Yq4xL1Owp
kQ7jT6Zi20endNT2a4mCFu79rztDzfPR/7BgOCFxu88IYO+0fgp4VeBZb0G9T3GG
g/k0XSpd5Zjgn9SHVD1u5NRacUpeIPqX3cbwPxP5Xh7XlfEXcmw=
-----END RSA PRIVATE KEY-----
 
[ralf@servidor1]# cat /home/ralfm/.ssh/id_rsa.pub ssh-rsa
 
AAAAB3NzaC1yc2EAAAABIwAAAQEAw0a4dn8wGAaRcMuIPY8/pk11YPV5Nk6R5VC
tHNLnH2+hmsMw47wMdJ8PC9Vu6bDYLgSwRIpV83kEJSE1DdHB93qExqjXnA7EWO
zgmjjbSTbi2kfNxB4Vh9tS3dXCy/9xfcUrYj8LZH931I3y46YQAswmDqS9nZCvo
E9xmzDmt9uecSOE39e5aZiHwOGXlyNkExRRBT2JIDcL9aeAa1HclnRTbsZVWsxX
8+K6koVvsmMhRZNqXoSuU+CWGse/UsLbo2sWHUKaFVMBVc2h0E4j08Rm/R85Bgw
zgxXr+ql6Tv1qJjydlFJkUuD6RJ78X/Wp9HqVwM9i9v/hyE6FK9GtMQ==ralf@desktop 
Antes de seguir, hay dos cosas muy importantes a tener en cuenta con respecto a la seguridad de nuestros sistemas cuando utilicemos SSH sin clave de acceso:
  1. La primera es que, nuestra clave privada nunca se debe hacer publica. Tenemos que tener cuidado de que nadie, tenga acceso a nuestra clave privada para no comprometer la seguridad de nuestro sistema.
  2. La segunda es que, al no utilizar 'passphrase' (vacia), tenemos que estar seguros que la maquina servidor (maestra) desde donde nos vamos a conectar a los demas servidores, debe de ser segura. Tenemos que tener un cuidado extra con esta maquina, ya que si alguien indeseado consigue acceder a la misma como 'root', obtendra a su vez acceso (sin necesidad de clave) a todos los demas servidores de nuestra red. Para aumentar la seguridad del sistema, y si no necesitamos acceso 'root', podemos crear un usuario de sistema con privilegios restringidos, el cual podra ser utilizado para acceder a los demas servidores.
Una vez que hemos generado nuestra clave privada y publica en nuestro servidor principal (el que tendra acceso al resto de nuestras maquinas), tenemos que copiar el contenido del fichero /home/ralf/.ssh/id_rsa.pub (clave publica) a el fichero ~/.ssh/authorized_keys del usuario que va a tener acceso sin clave. Esto se debe de hacer en todas las maquinas a las que queremos tener acceso.
El contenido de ~/.ssh/authorized_keys en las diferentes maquinas se puede actualizar, por ejemplo, de la siguiente manera:
[ralf@servidor1]# scp /home/ralf/.ssh/id_rsa.pub ralf@servidor2:~/
[ralf@servidor1]#$ ssh ralf@servidor2
[ralf@servidor2]#$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
Despues de hacer esto, podremos conectarnos desde 'servidor1' a 'servidor2', como el usuario 'ralf' y sin clave, de la siguiente manera:
[ralf@servidor1]# ssh ralf@servidor2
Last login: Thu Sep 28 17:00:17 2006
 
[ralf@servido2]# 
Este procedimiento lo tenemos que repetir en todos los servidores a los que deseemos acceder sin clave desde la maquina 'servidor1'.
Para mejorar todavia mas la seguridad, podemos actualizar en todos nuestros servidores los ficheros /etc/hosts.allow y /etc/hosts.deny con la IP o el nombre completo de el 'servidor1' (servidor maestro/principal). Estas son las lineas que deberiamos de añadir o actualizar si ya existen:
En /etc/hosts.allow:
sshd: IP o hostname de 'servidor1'
 
Y en /etc/hosts.deny:
sshd: ALL
Con todo lo que hemos hecho hasta ahora, podremos ejecutar comandos remotamente en 'servidor2' desde 'servidor1' sin necesidad de claves. El formato seria el siguiente:
[user@servidor1]# ssh user@servidor2 'comando a ejecutar en servidor2'


CRON

Para los que no lo saben, cron es un administrador de procesos en segundo plano que ejecuta trabajos a intervalos regulares. Cron se utiliza para automatizar tareas que hay que realizar periodicamente. Los procesos que deben ejecutarse y la hora en la que deben hacerlo se especifican en el archivo crontab del usuario que ejecutara los procesos.
Para editar este fichero podemos utilizar nuestro editor favorito. Para ello tenemos que tener la variable de entorno EDITOR definida y usar crontab -e para editar nuestro crontab. Un ejemplo usando el editor emacs:
[ralf@servidor1]# export EDITOR=/usr/bin/emacs
[ralf@servidor1]# crontab -e
En el fichero crontab se define una linea por tarea/trabajo a ejecutar y el formato de la misma es el siguiente:
 ------------- minutos (0 - 59)
 | ----------- horas (0 - 23)
 | | --------- dia del mes (1 - 31)
 | | | ------- mes (1 - 12)
 | | | | ----- dia de la semana (0 - 6) (domingo=0, lunes=1, ... sabado=6)
 | | | | |
 * * * * * comando a ejecutar
 
 
* significa todos los valores validos
/ permite definir una repeticion
- permite definir un rango
, permite definir varios valores
Las lineas que comienzan con '#' se consideran comentarios. Podemos utilizar la linea MAILTO="usuario@ejemplo.com" al comienzo para que cron nos mande un mensaje cuando se ejecute un trabajo. Un ejemplo nos ayudara a entender todo esto mejor. Listamos el contenido de nuestro crontab despues de haberlo actualizado con crontab -e:
[ralf@servidor1]# crontab -l
 
MAILTO="usuario@ejemplo.com"
 
# Generar estadisticas web todos los dias a las 12:01 y als 23:01 
1 12,23 * * * /usr/local/bin/webalizer -c /etc/webalizer.conf
 
# Limpiar copias de seguridad de la base de datos (guardar ultima
# semana). Ejecutar trabajo de lunes a viernes a la 01:01
01 01 * * 1-5 for files in `/usr/bin/find /backups/pgsql/ -mmin +10000`; do rm -f $files; done
 
# Ejecutar 'mi_script.sh' un minuto pasado la hora en punto, cada dos horas.
01 */2 * * * /usr/local/bin/mi_script.sh 
En fin las posibilidades son muchas. Podeis usar vuestra imaginacion.

AT

at tambien se puede usar para ejecutar, solamente una vez, un trabajo a una determinada hora. Al contrario de cron que ejecuta de forma periodica hasta que no definamos lo contrario en el crontab del usuario.
Podemos definir los comandos a ejecutar o bien por la entrada estandar o en un fichero. El formato en uno u otro caso seria, at hora:minuto o at -f fichero hora:minuto. Un ejemplo nos aclarara las cosas. (^D significa que pulsamos las teclas Ctrl + D). Estos dos ejemplos hacen lo mismo (arrancan de nuevo la maquina) aunque se definen de manera distinta.:
[ralf@servidor1]# at 12.12.2006 21:30
> reboot
> ^D
 
[ralf@servidor1]# cat /tmp/at_reboot
reboot
 
[ralf@servidor1]#  at -f /tmp/at_reboot 12.12.2006 21:30
Para ver y borrar los trabajos definidos se pueden usar los comandos at -l y at -r 'ID del trabajo a borrar'

Combinando SSH, cron y at

El uso combinado de SSH sin clave y cron/at es una tecnica usada muchisimo por administradores de sistemas Unix/Linux con responsabilidad de muchas maquinas/servidores. Es una manera facil y eficaz de recoger informacion o ejecutar un trabajo en muchas maquinas de manera rapida. Vamos a poner un par de ejemplos para ver como podemos hacer esto.
Estos ejemplo necesitan acceso como root para funcionar, lo mas facil es actualizar el fichero ~/.ssh/authorized_keys de 'root' en las maquinas a acceder, con nuestra clave publica. Otra alternativa seria usar sudo.
En este ejemplo vamos a arrancar de nuevo todas las maquinas de nuestra subred 10.1.1.0/24 para que arranquen con el nuevo kernel que hemos instalado. El trabajo lo vamos a ejecutar mañana a las 23:00 horas.:
[ralf@servidor1]# at 23:00 tomorrow
>for ip in `seq 1 254`; do ssh root@10.1.1.${ip} '/sbin/shutdown -r now'; done
>^D
job 3 at 2006-10-05 23:00
 
[ralf@servidor1]#  at -l
3       2006-10-05 23:00 a ralf
En este otro ejemplo vamos a recoger los datos de uso de disco de todos los directorios /var de nuestros servidores, en nuestra subred 10.1.1.0/24. Esta lista la ordenaremos de mayor a menor uso, la grabaremos en /tmp/uso_var.txt y el trabajo lo ejecutaremos todos los dias a las 03:00:
[ralf@servidor1]# export EDITOR=/usr/bin/emacs
[ralf@servidor1]# crontab -e
 
Actualizamos y grabamos crontab con estas dos lineas:
 
# Uso de /var en 10.1.1.0/24
00 03 * * * for ip in `seq 1 254`; do echo -n 10.1.1.${ip}: ;ssh
root@10.1.1.${ip} '/usr/bin/du -sk /var '; done | sort -r +2 > /tmp/uso_var.txt
 

Supongo que os podreis hacer una idea de las posibilidades infinitas de automatizacion que tenemos con lo que hemos explicado y la ayuda indispensable que da a los administradores de sistemas Unix/Linux. En fin, espero que este articulo os ayude un poco mas a tener control de vuestros sistemas, esto es todo por hoy.

Consejos sobre los logs en Alfresco

Como muchos ya sabréis, Alfresco utiliza Log4j para los logs. Log4j es una herramienta Open Source para gestionar logs y permite a programadores y administradores controlar lo que ocurre en la aplicación de forma granular y a diferentes niveles de detalle.
Controlar cómo funcionan los logs en Alfresco es la mejor forma de conocer como funciona el sistema tanto para administradores como programadores y poder detectar/solucionar problemas en una instalación.
Se configura mediante un fichero de texto llamado log4j.properties que se encuentra dentro de alfresco.warconcretamente en el caso de Tomcat en ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes. En este fichero se especifica qué queremos que registre el log y cómo queremos que lo muestre (mayor o menor detalle). También es donde se establece el nombre del fichero de log (alfresco.log) y los ficheros de log anteriores a los que le añade fecha (alfresco.log.YYYY-MM-DD). Estos ficheros de logs generados los encontraremos en la raíz del directorio donde hemos instalado Alfresco también conocido como ${ALFRESCO_HOME}, ojo, ni esta variable ni ${TOMCAT_HOME} existen salvo que se declaren, se usa para indicar el directorio raíz de instalación de Alfresco y de Tomcat respectivamente.
Vamos a ver como cambiar la ubicación del fichero de log de Alfresco. Copiamos el fichero log4j.properties al directorio extension con otro nombre, por ejemplo custom-log4j.properties:
?
# cp ${TOMCAT_HOME}/webapps/alfresco/WEB-INF/classes/log4j.properties ${TOMCAT_HOME}/tomcat/shared/classes/alfresco/extension/custom-log4j.properties
Este cambio nos permitirá tener siempre la misma configuración de logs independientemente de que actualicemos Alfresco y despleguemos un nuevo alfresco.war donde se sobreescribiría la configuración personalizada si la hacemos dentro del war desplegado.
Editamos el fichero custom-log4j.properties y localizamos la línea:
?
log4j.appender.File.File=alfresco.log
para especificar la siguiente:
?
log4j.appender.File.File=/var/log/alfresco/alfresco.log
Como veis, este ejemplo está orientado a un sistema Linux o Unix, hay que tener en cuenta que si queréis poner los logs como he indicado hay que crear el directorio /var/log/alfresco y darle los permisos necesarios para que el usuario con el que se ejecuta Alfresco pueda escribir. También podríais poner los logs en alf_data/logs y así tener todo más centralizado. Para Windows habría que cambiar la ruta absoluta en el siguiente formato, por ejemplo “D:\logs\alfresco\alfresco.log”. Una recomendación de índole general para cualquier aplicativo y sus logs es disponer de una partición independiente encargado de almacenar estos ficheros (generalmente/var/log), de forma que si nos quedamos sin espacio en disco tanto en la aplicación como en los logs, no afecte al funcionamiento y podamos detectarlo de forma anticipada ya sea chequeando manualmente o con un sistema de monitorización, evidentemente también podemos poner una partición dedicada a los logs de Alfresco. Recuerda hacer backup de los logs regularmente.
Para entender mejor la sintaxis y opciones que encontramos en el fichero de configuración os recomiendo leeresta entrada en la Wikipedia. Destacaría el parámetro log4j.appender.File que especifica la rotación diaria del fichero de log y log4j.appender.File.File que permite indicar el nombre y path del fichero de log.
En cuanto a los niveles de detalle es importante conocer que existen los siguientes (de menos a mas detalle): OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE y ALL. Así que hay que tener cuidado con tener DEBUG, TRACE o ALL en un sistema en producción, salvo que sea necesario para solucionar un problema. Aquí puedes ver más información al respecto.
Si usáis un servidor de aplicaciones Tomcat, también es recomendable cambiar la ubicación del fichero de logs de Tomcat (o cualquier otro servidor de aplicaciones soportado), aquí vemos como cambiar el sitio donde se almacena el fichero catalina.out:
Editamos el fichero ${TOMCAT_HOME}/bin/catalina.sh, localizamos las líneas:
?
if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="$CATALINA_BASE"/logs/catalina.out
fi
Y cambiamos la ruta de CATALINA_OUT por la ruta deseada:
?
if [ -z "$CATALINA_OUT" ] ; then
CATALINA_OUT="/var/log/alfresco/catalina.out"
fi
Para que los cambios anteriores surtan efecto hay que reiniciar el servidor de aplicaciones. Una vez reiniciado ya veremos los ficheros creados en el directorio correspondiente.
Todo lo que hemos visto anteriormente se puede hacer de una forma más sencilla accediendo al servidor conjconsole mediante RMI y sin tener que reiniciar el servidor. En Alfresco Enterprise 3.4 ya está activado el acceso remoto. Aquí expliqué como acceder por jconsole a Alfresco.
Como vemos en la siguiente captura de pantalla, en la sección MBeans podemos encontrar un grupo llamado “log4j” y desplegado podemos ver todas sus opciones.
Concretamente en la captura anterior vemos los “Attributes” del bean “File“, y ahí podemos cambiar las opciones como por ejemplo “file”, el fichero y ruta de log. Una vez cambiado a nuestro gusto, para que tenga efecto vamos a “Operations“, hacemos clic en “activateOptions” y listo.
Por ejemplo, los logs de Webdav por defecto están configurados como detalle tipo “ERROR”, si queremos hacer un análisis más exhaustivo podríamos localizar el bean “org.alfresco.webdav.protocol” y desplegamos el menú “Attributes” y hacemos clic en “priority“, doble clic en “ERROR” para editarlo y lo cambiamos por “DEBUG” (sin comillas), a continuación guardamos simplemente pulsando la tecla “Enter” y ya tendríamos configurado el nivel de log del componente de turno. Fácil ¿no?
Para terminar quiero mencionar este pequeño desarrollo que ha realizado Tjarda Peelen – @tpeelen que permite ver los logs en la propia interfaz de la aplicación. Puede ser útil.
También se podría usar Log4mongo u otras aplicaciones para presentar logs vía web, pero eso ya es otra historia.
¿Algún consejo más? ¡Cualquier comentario es bienvenido!