Permitir Ficheros grandes – Upload Onwcloud

Hace poco me he montado un owncloud casero y me dió algunos problemas, a la hora de poder hacer upload de los ficheros con un tamaño grande, del orden de Gb.
Revisando información en castellano, no he encontrado referencias claras, por eso dejo aquí los cambios que he necesitado. Básicamente son 2…..

1.- Tamaño máximo de subida.

Estos parámetros se pueden cambiar en el php.ini de la maquina, pero no tendrán valor ya que son sobrescritos por el «.htaccess» del owncloud, por lo que se deben modificar en el directorio web del owncloud.

Ej. Para 2Gb

php_value upload_max_filesize 2G
php_value post_max_size 2G

2.- Tiempo máximo de ejecución. (Esta es la parte menos documentada.)

Además de esto, cuanto mayor es el fichero más tiempo de ejecución necesita el cgi para hacer el upload, por lo que debemos aumentar el tiempo de ejecución o obtendremos un «Internal server error«, ya que la subida se corta. Sigue subiendo pero ya no lo almacenamos en el fichero temporal, el cual deja de crecer llegado ese punto.
Esto se puede revisar viendo crecer el fichero en «/tmp» o donde se almacene.
Estos valor los he cambiado directamente en php.ini
Dejándolos en 1h (Por defecto los tenia en 60s):

max_execution_time = 3600
max_input_time = 3600

Con estos cambios tenemos la subida de ficheros grandes solucionada.
Además de esto, he cambiado la forma por defecto de loguear de ownclud.
En el fichero:

..../owncloud/config/config.php

Definimos:

  'log_type' => 'owncloud',
  'logfile' => '/var/log/owncloud.log',
  'loglevel' => '2',
  'logdateformat' => 'F d, Y H:i:s',

Nota: También se puede tirar contra syslog y por supuesto hay varios levels de logg, en la documentación esta indicado.

Temperatura – Raspberry

Siempre había tenido la «falsa» sensación de que la raspberry no debía calentarse mucho. Como siempre llaga la hora de despertar.
Tras varias tomas aleatorias ví que la temperatura era mas menos de unos 60ºC sin tener nada de carga de trabajo.

root@RASP1:~# /opt/vc/bin/vcgencmd measure_temp
temp=60.5'C

Así que para tener una opinión mas formada he decidido tomar un muestreo cada hora, durante una semana. Al final indicare como los he obtenido, aunque no tiene misterio.

Gráficas:
21 / 22 Agosto 2014

   
23 / 24 Agosto 2014

   
25 / 26 Agosto 2014

   
27 / 28 Agosto 2014

   
Se puede ver que la temperatura media es de unos 60ºC y que hay picos de las 10h a las 12h los cuales tienen su explicación… , ya que es el momento en que el sol incide sobre las raspberry por la ventana. Los días que recuerdo tapar la luz no existen estos picos.
Por otro lado he colocado un ventilador el cual puedo encender o parar con un interruptor.  Tras dejar un día completo el ventilador funcionando la caída de temperatura es muy alta…

29 / 30 Agosto 2014 ( Ventilador ON )

   
La caída es de unos 20ºC (33%) aproximadamente. Es así como debería estar siempre.
Con estas pruebas la opción mas evidente es dejar funcionando el ventilador pero tiene un problema…..
El «sonido» más bien «ruido«, es sumamente molesto…. Ahora estoy pensando en como aislar un poco la raspberry , para atenuar lo suficiente el ruido…. caja de cartón, corcho….. Ya iré probando.

Raspberry con Ventilador y disipadores.

Para tomar las medidas he usado los siguientes mini scripts, por llamarlos algo…

En el cron de root:

#Toma Datos Control Temperatura
00 * * * * /usr/local/scripts/control_temperatura/temperaturas.sh
15 00 * * * /usr/local/scripts/control_temperatura/genera_grafica.sh
30 00 * * * rm /usr/local/scripts/control_temperatura/datos_temp.txt

temperaturas.sh

#!/bin/bash
PATH_TRAB=/usr/local/scripts/control_temperatura
if [ ! -f $PATH_TRAB/datos_temp.txt ]; then
echo "#Hora Temperatura">>$PATH_TRAB/datos_temp.txt
fi
HORA=`date +%H`
TM=`/opt/vc/bin/vcgencmd measure_temp`
TEMPERATURA=`echo ${TM:5:-2}`
echo $HORA $TEMPERATURA>>$PATH_TRAB/datos_temp.txt

genera_grafica.sh

#!/bin/bash
PATH_TRAB=/usr/local/scripts/control_temperatura
NOMBRE=grafica_`date +%d_%m_%Y`.jpg
sed -i 's/00\ /24\ /g' $PATH_TRAB/datos_temp.txt
cat $PATH_TRAB/script_plot.sh |gnuplot > `echo $PATH_TRAB/$NOMBRE`

script_plot.sh

set terminal jpeg #Formato de salida
set title "Grafica Temperatura" #Titulo
set xlabel "HORA" #Etiqueta eje x
set ylabel "TEMPERATURA" #Etiqueta eje y
set yrange [0:100] #Rango eje y
#Dibujo de la gráfica (columnas 1 y 2) tipo de línea 4 y ancho de línea 3:
plot '/usr/local/scripts/control_temperatura/datos_temp.txt' using 1:2 with linespoints linetype 4 linewidth 3 title "Temp"

Cuando tenga la chapucilla para el ruido lo colgaré.

Apagado disco USB – RaspBerry

Publicación original: 19.07.2014

Tengo una raspberry conectada 24/7, en la cual tengo conectado un disco usb que uso muy poco (motivo por el que nunca se me había planteado la necesidad de poder «apagarlo» automáticamente). Hasta ahora montaba y desmontaba el disco según necesidades.

Es posible que para un proyecto futuro, me interese tener el/los disco/s montados siempre y que el SO los apague según el tiempo de inactividad.
Un compañero me comento el uso y me he puesto a mirar HDPARM

Nota:

Simplemente a modo de recordatorio, buscando info sobre el tema he visto que podemos saber si ha existido actividad en el disco consultando el fichero:

/sys/block/sda/stat

Cuando se realizan operaciones sobre el disco el valor número cambia.

cat /sys/block/sda/stat | tr -dc "[:digit:]"

HDPARM

Con mi disco he tenido unos problemas, que detallare al final. Aunque el estado «unknown» que se ve a continuación, esta relacionado con mis problemas.

Ver el estado del disco:

root@RASP1:~# hdparm -C /dev/sda1
/dev/sda1:
drive state is: unknown
root@RASP1:~#

Si todo funciona correctamente el estado debe ser «active/idle, standby»….

Ver el tiempo tras el que pasaremos a inactividad «spin-down«

root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor se debe entender del siguiente modo:

• SI Permitimos el Spin-Down: Entre 1 y 127
• NO Permitimos el Spin-Down: Entre 128 y 254
• El valor de 255 : Desactiva la gestión de energía avanzada del disco duro.

Cuando permitimos el spin-down, el tiempo en segundos, se obtiene multiplicando por 5 el valor dado, así un valor de 120, serán 120*5 segundos….. 10 minutos

Estableciendo el valor:

Para esto editamos el fichero de configuración de hdparm:

/etc/hdparm.conf

Y al final añadimos: (Este punto no he conseguido que funcione con mi disco)

/dev/DISCO {
  spindown_time = Valor_deseado}

Tras esto es suficiente con dejar el demonio corriendo:

/etc/init.d/hdparm restart

NOTA: Problemas con mi disco

Las pruebas las estoy haciendo con un disco WD:

root@RASP1:~# hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD5000BEVT-11A03T0
Serial Number: WD-WX30A6957814
Firmware Revision: 01.01A01
...

En este disco no he podido definir el valor en el fichero de configuración, así como ver el estado del disco, ni forzar el «apagado» del disco

root@RASP1:~# hdparm -y /dev/sda
/dev/sda:
issuing standby command
HDIO_DRIVE_CMD(standby) failed: Invalid argument

Sin embargo el disco si para cuando establezco el valor via comando:

root@RASP1:~# hdparm -B 121 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x79 (121)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 121
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 121
root@RASP1:~#
root@RASP1:~#
root@RASP1:~# hdparm -B 120 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x78 (120)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 120
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor esta en uso hasta que el disco se desconecta de la corriente. Por lo que no es un problema para mi no poder, establecerlo de manera permanente.

Procesos en segundo plano – SIGHUP, NOHUP

Publicación original: 14.07.2014

Me parece interesante a modo de «chuleta» y/o recordatorio comentar un poco este tema…
Lo quiero separar en dos partes una sobre los procesos en segundo plano y otra sobre la señal SIGHUP.

• Procesos en segundo plano

Los procesos en segundo plano son aquellos que pese a estar en ejecución no tenemos la posibilidad de interactuar con ellos.

La manera de lanzar procesos en segundo plano es añadiendo al final & , de este modo el proceso quedará en ejecución pero liberará la shell, para poder seguir trabajando.

gandalf ~ # find / -name hola &
[1] 19968
gandalf ~ # ps -ef|grep find
...
[1]+  Hecho                   find / -name hola

Para poder interactuar con estos procesos necesitamos traerlos a primer plano y para realizar esta gestión tenemos los comandos jobs, bg y fg

Un ejemplo…. Lanzamos dos procesos en segundo plano:

gandalf ~ # while true; do echo "ab" > /dev/null; done &
[1] 20265
gandalf ~ # while true; do echo "a" > /dev/null; done &
[2] 20266

Visualizamos los procesos en segundo plano así como su estado:

gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Traemos uno de los procesos a primer plano y lo detenemos con Ctrl+Z

gandalf ~ # fg %1while true; do
echo "ab" > /dev/null;
done
^Z
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done

Al listar los procesos en segundo plano tenemos uno detenido y uno en ejecución.

gandalf ~ # jobs
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done
[2]-  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Volvemos a poner en ejecución en background el proceso que estaba detenido.

gandalf ~ # bg %1
[1]+ while true; do
echo "ab" > /dev/null;
done &
gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

También podemos matar un proceso en background determinado

kill %2

• SIGHUP / NOHUP

Cuando un proceso termina lanza una señal SIGHUP a los procesos que cuelgan de el, y estos reaccionan simplemente saliendo.
Esto es un problema cuando queremos dejar corriendo algún proceso en la shell en la que nos encontremos, ya que aun teniéndolos en background, al salir de la shell el proceso terminará.
Podemos evitar esto lanzado el proceso con NOHUP, lo cual hará que el proceso no «escuche» la señal SIGHUP de su proceso padre.
Para lanzar un proceso con NOHUP basta con (nohup «comando»), por ejemplo:

nohup ./script.sh arg1 arg2
nohup su - user -c "./script arg1 arg2"

Algo interesante, a tener en cuenta, es el tratamiento de la salida /entrada estandar, así como de la salida de error que hace nohup.

• Salida estandar –> Si no esta redirigida, se redirige a $HOME/nohup.out
• Entrada estandar –> SI no esta definida toma valor de «/dev/null»
• Salida de error –-> Si no está definida es redirigida a la salida estandar.

Cabio de Site y CMS..

Ha llegado el momento de realizar la migración que estaba preparando.
El blog estrena nueva cara y cambia de ubicación..

He migrado todo el contenido y las nuevas entradas serán publicadas en el nuevo site.

http://www.celtha.es/blog

A ver que tal la experiencia.