Archivo de la categoría: General

Domotica Low Cost con Raspberry PI

En esta ocasión me gustaría desviarme un poco de la temática principal de este blog para hablaros de un proyecto que he emprendido y del cual estoy bastante conforme con su funcionamiento, aunque a decir verdad, la utilidad es un tanto limitada.

HARDWARE

En primer lugar, el servidor bien, gracias.  El pequeño y robusto portátil Siemens con aproximadamente diez años de antiguedad sigue funcionando como el primer día, con incluso unos grados menos de temperatura y sin apenas mantenimiento. Sin embargo ahora toca hablar de otro pequeño proyecto que llevé a cabo hace unas semanas y que os voy a detallar a continuación… La Raspberry PI

RBPI

Como sabéis, la Raspberry Pi es  un mini ordenador con procesador ARM 700Mhz que tan sólo vale 30€. Como tal, es accesible al bolsillo de todos y cuenta con unas características muy interesantes.

La placa programable de bajo nivel que contiene llamó mi atención desde el primer momento. Mis nociones en electrónica eran limitadas, así que tuve que tirar de google para al menos aclarar ciertos conceptos básicos y descubrir qué posiblidades tenía. De lo primero que me cercioré gracias a la red de redes era la existencia de los puertos GPIO. Puertos de entrada-salida que pueden ser controlados por el usuario… vamos… que puedo aplicar 0 ó 1 cuando me plazca. También, claro está, puedo leer en qué estado se encuentran los mismos en el caso de interesarme.

Me regalaron la Raspberry PI en un hackaton y no le había prestado mucha atención por falta de tiempo y tampoco tenía claro realmente qué tipo de proyecto podía crear con ella. No tenía intención ninguna de usarlo como MediaCenter teniendo una SmartTV y mucho menos como sistema de escritorio… más que nada por la ausencia de monitor. ¿Servidor? ¿Otro? ¿Realmente me iba a poner a probar como servidor otro dispositivo y escribir sobre ello? Sí y no. Ya os daréis cuenta porqué.

Es entonces cuando nació la idea de poder controlar partes básicas de mi casa por medio de estos puertos. Pero antes de nada hablemos un poco de las peculiaridades de los mismos. En primer lugar, cuando el estado del puerto es 1, se aplica un voltaje de 3.3 voltios, cuando el 0, obviamente, ninguno, A ver cómo hacemos para que se lleven bien 3.3V DC con unos bonitos 220V AC que circulan por mi casa.

Antes de entrar en materia, quise hacer unas pequeñas pruebas y compré un Kit con las cosas básicas:

  • Protoboard
  • LEDs
  • Cables
  • Resistencias

Los LEDs eran de varios colores y no pude sucumbir a la tentación de hacer un bonito semáforo. Como la placa de la Raspberry no está protegida, tuve que tener especial cuidado al elegir las resistencias y tiré por lo alto aunque los LEDs no brillen en demasía. El lenguage de programación elegido para este caso es Python y tengo que decir que me ha sorprendido su potencia y facilidad.

La distro elegida para esta causa fue, naturalmente, Raspbian, la cual es la más fiel a Debian y además cuenta ya con el entorno de desarrollo Python instalado. Tan sólo tuve que instalar unas librerías para controlar los GPIO y listo. Como comentaba anteriormente, hice mis primeras pruebas con los LEDs y aunque llevo muchos años trabajando en el mundo de la informática, a mí me sigue todavía llamando la atención cómo podía hacer parpadear LEDs a mi antojo, no sé… llamadme romántico.

RELÉS

Los relés eran una parte básica del proyecto. Necesitaba algo puramente mecánico que dejara pasar la electricidad ante cualquier evento. Hay un sin fin de relés disponibles con varios rangos de entrada y salida, pero a decir verdad, eran todos muy limitados y ninguno cumplía con mis premisas. Algunos sí se adaptaban a mis necesidades, pero como bien dice el título del presente blog, quería algo Low Cost.

Después de plantearme construir algún tipo de circuito manual para manejar tales rangos, no sé cómo fui a parar a la página de un simpático americano más bien rellenito que me dio a conocer unas de los aparatos que acabaría radicalmente con mi dolor de cabeza.

SOLID STATE RELAY

Parecía un producto caído del cielo. Ya ni siquiera no era mecánico, que es maravilloso, sino que además manejaba rangos de entrada DC de 3 a 32V… y no os lo perdáis, el rango de salida  era AC de 24 a 380V con un máximo de 25A. En cuestión, este el producto que adquirí:

SSR-25 DA

Aunque hay un sin fin de marcas y modelos, finalmente me decidí como os he comentado por este en cuestión ya que aguanta más amperaje y por lo que pude ver, FOTEK es una marca “consagradísima” de electrónica de Taiwan. 🙂

Antes de entrar en materia, primero tenía que saber qué partes de la casa podía controlar y cómo. Mi morada no es nada del otro mundo… de hecho es pequeña y, bueno, en teoría eso me favorecía a la hora de los relés usados. Dispongo de un salón con cocina integrada, baño y tan sólo una habitación. También cuento con una terraza que dispone a su vez de iluminación.

El siguiente paso es sencillo… ¿dónde puedo colocar la Raspberry, los relés y el cableado? Pues en el único sitio donde se encuentra todo centralizado… en el cuadro eléctrico. Sí, a mi también me tembló el pulso cuando pensé en colocar allí un mini ordenador de 30€ con la bonita responsabilidad de salvaguardar la iluminación de mi casa.

Como ya he comentado, hice una pruebas básicas con Python controlando los leds y  los nuevos  relés para comprobar que efectivamente funcionaban observando sus estados . Lo siguiente era estudiar cómo estaba diseñada la instalación eléctrica y ver qué posibilidades tenía. Unos de los fusibles controlaba las luces del salón y de la cocina, recordad, integrada. El siguiente controlaba mi habitación y, maldición, también el baño. No era partidario de incluir esta fase dentro del proyecto, pero no tenía otro remedio.

Otro de los fusibles daba al traste con la energía de los enchufes. Pensaba yo, ufano, que serían los aquellos localizados en el salón y que habría otro extra para aquellos colocados en  la habitación. Pero no, cortaba la energía de todo lo enchufado excepto los enchufes que requirieran más potencia como lavadora, horno y frigorífico; ya que estos contaban con sus propios fusibles.

Para aquellos más avispados, atentos a la siguiente explicación. Como sabéis, la Raspberry cuenta con su puerto HDMI  y poder usar así un monitor, pero claro está que donde radica su versatilidad es en poder conectar por VNC y por SSH sin necesidad de tal armatoste. ¿Qué pasa si corto la energía de los enchufes? Tendría que conectarlos manualmente en el cuadro eléctrico o llevar el router a algún enchufe no afectado para recuperar la conexión con mi RBPI.

Mi lugar de residencia en una pequeña isla del Mediterráneo, y como tal, cálida como es, todas las casas cuentan con unos paneles solares en los tejados para generar agua caliente. El problema es que en invierno, a veces el sol no es suficiente y contamos con un interruptor en el pasillo para calentar el agua usando la energía eléctrica. Os cuento esto porque de ese interruptor, en vez de llegar como de costumbre el cable marrón de FASE, llegaban los dos, FASE y NEUTRO. Es así como fabriqué un enchufe de la nada y fuera de peligro y apagones. Al tener en router en modo repetidor, tampoco me hacía falta que llegase ningún cable de teléfono. El router repite la señal wifi de un hotspot de pago cercano y así me aseguro de que mi raspberry no pierde internet nunca.

Colocando la RBPI y la protoboard en la compuerta del cuadro eléctrico.

Colocando la RBPI y la protoboard en la compuerta del cuadro eléctrico.

Una vez decidido qué partes tenía la posibilidad de controlar, llegó el momento de montar el sistema con RBPI y relés en el cuadro electrico. Mi intención era que una vez todo montado, tuviera la posibilidad de cerrar de nuevo el armario, por lo que tuve que medir los espacios que tenía y poner las piezas en sitios concretos.

En la imagen publicada podéis ver en principio dónde coloqué la RBPI y la protoboard. Hay dos grupos de tres cables que provienen de los GPIO. Tres de ellos para los tres relés, y los otros tres para alimentar tres Leds que usaré como monitor de temperatura. Dado que el cuadro estará cerrado la mayor parte del tiempo, es posible que la temperatura suba mucho debido a que el aire de dentro no se renueva. Quiero encontrar una solución a eso, pero hasta entonces, un pequeño ventilador en el procesador bajaba la temperatura hasta los 38º. Es por eso que cuento con los Leds en forma de semáforo. Con un script en Bash y ejecutado cada minuto, visualmente puedo hacerme a la idea del calor que está pasando el sistema. Además, ahora he colocado los LEds en la esquina para poder así ver el color de los mismos con el armario cerrado.

  • < 38º – 42º VERDE
  • 42º – 47º VERDE-AMARILLO
  • 48º – 52º AMARILLO – ROJO
  • > 52 ROJO

Otro de los problemas que tuve a la hora de montar el sistema en el cuadro eléctrico fue la fuente de alimentación. La que yo tenía era tan sólo de 700mA y no era suficiente para mover Raspbian (SO), el dongle WIFI y una cámara que tenía pensado poner para monitorizar la casa en mi ausencia. Luego tuve la gran idea de comprar otra cámara y poder así alternar entre ver mi cuarto y en salón cuando más me plazca.

Es por eso que adquirí por Amazon una USB Hub compatible con Raspberry y alimentado por su propia fuente de 2A. Eso se tornaba también en un problema, ya que no sabía donde colocar dos fuentes de alimentación en un espacio tan reducido como el cuadro eléctrico. Y no, alimentar la Raspberry por usb usando el Hub no funciona ya que el flujo de intensidad fluctúa y la hace comportarse de forma inestable.

Diseño completo antes de acoplar la compuerta al cuadro eléctrico.

Diseño completo antes de acoplar la compuerta al cuadro eléctrico.

Así es como quedó el diseño preliminar antes de acoplarlo al cuadro eléctrico, aunque he hecho algunas pequeñas modificaciones que ya veréis en el vídeo. Como veis he conectado tan solo una masa de la entrada DC de la raspberry en serie al igual que la FASE en la salida AC. Los cables restantes van directamente conectados al cuadro electrico.

Fui consciente del peligro que entrama que todo la intensidad de corriente para por esos pequeños cables. De los relés no tengo que preocuparme, ya que aguantan un máximo de 25A. De los cables para alimentar luces, tampoco era problema, puesto que con toda la iluminación conectada, no llega tirando por lo alto a 400W. Pero de los enchufes tengo que tener especial cuidado, porque conectando el tostador + estufa + secador podríamos llegar a los 20A fácilmente y los cables no están preparados para semejante intensidad. Como se puede observar, los cables que uso, aun siendo FASE y NEUTRO, uso los dos para evitarme como he comentado, calentamientos innecesarios. Aunque sí es verdad que tengo mucho cuidado a la hora de enchufar cosas.

De todas formas, ahora que voy a contratar mi propio internet, creo que voy a tener que buscar otro uso al tercer relé y así de paso me  quito la preocupación de ver ardiendo el sistema entero por sobrecarga.

Así quedó el sistema una vez acoplado todo. Os aseguro que cierra perfectamente 😉

IMG_20130715_232538

 SOFTWARE

Sí, muy bonito, la puerta cierra perfectamente… pero ahora qué. Hagámoslo, pues, funcionar con algunas líneas de código. Mi meta era clara, quería hacer un programilla elegante y simple para mis propósitos. Aunque la aplicación en sí no va a ser utilizada por otros usuarios, quise aplicar un férreo control de validaciones y por supuesto, que admita en el caso de que los haya, nuevos relés para otra futura instalación. No os penséis una obra de arte, aunque en mi trabajo veo mucho código, no me considero un programador, aunque nunca es tarde si la dicha es buena.

Como comenté anteriormente, opté por Python para realizar la aplicación “Domo” ya que el entorno está instalado en la distribución Raspbian para RBP y verdaderamente es un lujo trabajar con él. Poco después de preparar el entorno, me sentía más cómodo programando en un editor con alguna ayuda integrada.

Me instalé para ello  PyScripter Portable disponible dentro de Portable Python y para modificar directamente los archivos de la Raspberry tiré, lógicamente, del magnífico WinSCP con una pequeña ayudita que hará las delicias de muchos… En lugar de tirar del editor por defecto, instalé aparte el Sublime Text 2 y lo definí como editor predeterminado del WInSCP. Una verdadera maravilla.

Mi idea era editar directamente los archivos en el editor con SublimeText, que en sí corrige varios cosas, ya que en Python hay que tener especial cuidado porque todo funciona a través de tabulaciones. Si en tiempo de ejecución ocurrían problemas que no sabía a primera vista interpretar, tiraba del PyScripter para detectar los fallos más fácilmente.

Empecemos destripando el código:


#!/usr/bin/env python
#
# Nombre: Domotica
# Lenguaje: Python

# Importo las librerias para manejar los GPIO

from time import sleep
import RPi.GPIO as GPIO
import sys

#Funciones

############################################
# VALIDO ARGUMENTOS ########################
############################################

# Recojo el numero de argumentos que recibe la aplicacion.

def parametres(p):

blink = False

if (p < 5 and p > 2):
 print "Missing arguments"
 sys.exit()

if (p > 5):
 print "Too many arguments"
 sys.exit()

if (p == 1):
 print "Domo has the followings values"
 read()
 sys.exit()

# Es una puta chapuza. Pero despues de las anteriores
validaciones, esta ultima quiere decir que el usuario
quiere invocar el parpadeo de la casa.

if (p != 2):
 blink = True

return blink

Desde el principio quería que la aplicación aceptara argumentos. Me parecía mucho más cómodo que crear un menú con diferentes opciones y de lo que se trataba era de accionar rápidamente cualquiera de los relés. Usé para ellos el atributo argv del objeto sys. Pueden pasar tantos argumentos como quieras siendo almacenados en un array.

Los argumentos de entrada son muy simples. Tan sólo introduzco 0 ó 1 para determinar el estado de los relés. Ahora comentaré porqué acepto más argumentos que los ya comentados.  Como veis, puedo aceptar más de un argumento debido a una propiedad que aún estoy intentando integrar para hacer parpadear las luces de la casa a mi antojo. Mi intención no es crear una casa de esas navideñas, sino que simule presencia en mi casa, ya que cuando vuelvo a la madre patria por vacaciones lo hago por un largo periodo de tiempo y nunca está demás tomar precauciones.

Tengo que madurar aún la idea, y voy a quitar esas líneas innecesarias que afean un poco el código. Prefiero hacer otro script que invoque a este programa para manejar la simulación ya que es algo que tan sólo usaré en días de largas ausencias.

##############################
# VALIDA LOS ESTADOS #########
##############################
# Valido si el estado introducido por el usuario es 0 o 1.
def StateValidation(states):

for elements in states:

if elements != "0" and elements != "1":
 print "Value " + elements + " is incorrect"
 sys.exit()

if len(states) != n:
 print "Max number of states is " + str(n)
 print "Input states by user: " + str(len(states))
 sys.exit()

return states

Esta función no tiene ninguna complicación. Tan sólo me aseguro que no cometa el error de introducir un estado que no sea 0 ó 1 y, obviamente, no intentar encender o apagar partes de la casa que no existen.

##################
# DO THE JOB ########
##################

def Action(states, parts, blink, interval = None, times = None):

 GPIO.setwarnings(False)
 if blink == False:

 x=open("/usr/local/bin/logs", "w")

for i in range(0, n):

 x.write(states[i])
 GPIO.setup(parts[i], GPIO.OUT)
 GPIO.output(parts[i],int(states[i]))

x.close

 else:

for i in range(int(times)):

print i

GPIO.setup(parts[i], GPIO.OUT)

if int(states[0]) == True:
 GPIO.output(17, 1)
 sleep(float(interval))
 GPIO.output(17, 0)

if int(states[1]) == True:
 GPIO.output(27, 1)
 sleep(float(interval))
 GPIO.output(27, 0)

 if int(states[2]) == True:
 GPIO.output(22, 1)
 sleep(float(interval))
 GPIO.output(22, 0)

 Action("111", parts, False)

####################
# READ FILE##########
####################

def read():

 x = open("/usr/local/bin/logs", "r")
 print x.read()
 x.close

Las líneas anteriores tampoco tienen complicación. Es básicamente donde se realizan las acciones que invoco desde el Main que veremos más tarde. En primer lugar me aseguro que el usuario no tenga intención de hacer parpadear la casa y simplemente me dispongo a apagar o encender las partes deseadas.

Antes de nada abro un fichero plano para guardar cómo quedarán los estados después de la ejecución. A continuación, simplemente con un simple FOR, recorro tantas partes como haya definido y se aplica el resultado. Si añado más relés a la vivienda, es una parte del código que no se debe tocar, puesto que la variable “n” almacena el número de relés de los que dispongo.

Por favor, ignorar las líneas referentes al parpadeo. Las dejo si por casualidad sirven de ayuda, pero semejantes líneas merecen arder en el infierno para siempre. Para terminar, defino la función que leerá el fichero que contiene el último estado de los relés. Será llamada si ejecutamos el programa sin argumentos.


###################################
 # MAIN ############################
 ###################################

def main():
 pass

if __name__ == '__main__':
 main()

room = 17
 plugs = 22
 hall = 27

parts = [hall, room, plugs]

# How many rooms are available in the house
 n = len(parts)
 # How many arguments input by the user.
 p = len(sys.argv)
 #GPIO ports
 GPIO.setmode(GPIO.BCM)

blink = parametres(p)

states = StateValidation(sys.argv[1])

if blink == True:

Action(states, parts, blink, sys.argv[3], sys.argv[4])

else:

Action(states, parts, blink)

El cuerpo MAIN tampoco puede ser más simple. Si ignoramos la comprobación que hago  para el dichoso parpadeo, no hago más que definir en un array las partes de la casa y el número de GPIO que tienen asignado.

Las restantes líneas contienen la llamada a la función “Action” y que puedo llamar de diferentes maneras depende, cómo no, de el dichoso parpadeo.  Simplemente añadía a la función el número de parpadeos y cuánto tiempo en segundos había entre ellos.

Hasta aquí la pequeña criatura que ilumina mis momentos de tiniebla. Insisto en que las cosas se pueden hacer mucho mejor y estoy abierto a toda crítica constructiva que se precie. Al fin y al cabo y como he comentado, ya no ejerzo la programación y tan sólo la tengo como hobbie.

FRONT-END

Supongamos que llego a casa después de un arduo y sinuoso día de trabajo. Debido al calor sofocante he bebido cantidades ingentes de agua y requiero vaciar la vejiga y no es plan de orinar a oscuras. Pues queda muy bien la pantallita negra para fardar con los colegas, sin embargo es de agradecer contar con una interfaz donde poder apagar y encender fácilmente las luces. Si a eso le añades unas camaras conectadas a la RBPI, la fabulosa idea empieza a tomar forma.

Insisto que el único usuario soy yo, pero ya lo dice el refrán… “las cosas bien hechas, bien parecen”. Sí he realizado bastante diseño web y he toqueteado muchas cosas, pero juro que odio con todas mis fuerzas todo lo relativo a HMTL, CSS y la madre que los paseó a todos. Aún así me armé de valor para realizar una simple interfaz donde pudiera visualizar las imágenes de la habitación y el salón y además unos botones muy monos para manejarlas.

Me compré dos cámaras muy simples Logitech c130 que funcionaban sin la necesidad de instalar ningún driver e instalé el software “motion” que aunque no es del todo fácil, pero con la ayuda de internet y una tarde tienes lo básico para hacerlo funcionar.

Aunque tampoco es lo más elegante, usando PHP tienes la intrucción “exec” donde puedes ejecutar cualquier comando en la máquina remota. Me venía de perlas para mi propósito, sin embargo había una cosa con la que no había planeado. El uso de un enlace, sea un link o un botón, conlleva que la página web se recargue. No era un problema muy grande, pero quería evitar que con cada pulsación el usuario tuviera que esperar a que las imágenes se generaran otra vez.

Tuve algunos problemas de ancho de banda con los usb que solventé bajando la calidad de las imágenes y ya por fin soy capaz de visualizar las dos cámaras sin problemas, pero con un retraso de unos cuatro segundos. Motion también te ofrece la posibilidad que ejecutar cualquier comando sea cual sea el evento. Por ejemplo, puedo hacer parpadear las luces si detecta movimiento e incluso hacer sonar por los altavoces una alarma y ahuyentar así a los cacos.

Volviendo a la interfaz web y evitar así que la página recargue, me centré en el uso de AJAX y con una función para cada relé me las apañé para poder encender y apagar con sólo apretar el botón. Fácil, sencillo y puedes visualizar en la cámara sin cortes si la acción ha dado resultado o no.

He aquí la página web.

Interfaz Web

Interfaz Web

Pasando el cursor por las imágenes de la cámara, se mostrará unas flechas que te permiten visualizar la otra cámara. Pedí por DX un servomotor y será el paso siguiente del proyecto junto con unos altavoces para no sólo hacer sonar alarmas, sino también como un equipo decente de sonido mientras hago las labores del hogar.

El servomotor me permite con una solo cámara hacerla girar los grados que desee y poder visualizar incluso el baño. Los controles se añadirían en la interfaz web y es a día de hoy el siguiente paso y que documentaré tan pronto como lo instale. Obviamente perdería las prestaciones de “detector de movimiento”, pero creo que vale la pena.

Lamentablemente no os puedo dar la url de la interfaz web porque quiero vivir tranquilo sin tener que sufrir decenas de apagones diarios. He creado también un simple script para levantar y desactivar la interfaz cuando me plazca dejando tan sólo el servidor SSH como método primario.

En definitiva el proyecto puede crecer mucho, pero siendo honesto no tiene mucha utilidad. A todo mortal nos gusta pulsar el interruptor para que luz se encienda y no tener que ir con el teléfono pulsando botones todo el tiempo. Además, aunque a día de hoy la Raspberry me está respondiendo perfectamente, el hecho de que un dispositivo de 30€ sea el que mantenga la luz de mi casa es cuanto menos una locura. Aunque he sido lo suficientemente cuerdo para dejar fuera de la ecuación al frigorifico y demás electrodomésticos por si acaso ocurre algo en mi ausencia.

Bienvenidos sois todos de darme nuevas ideas y, por favor, corregirme si en algo me he equivocado o se puede hacer mucho mejor en lo referente al código publicado, ya que de la interfaz web ni me atrevo. Por último, os dejo un vídeo de demostración para que veáis el sistema funcionando in situ.

Anuncios

Suma y sigue

Han pasado muchas cosas desde la última vez que escribí aquí acerca de mi particular servidor. Afortunadamente a nivel de hardware el equipo se encuentran en perfectas condiciones, más bien hubo un cambió logístico significativo.

Como sabéis, el ordenador se encontraba en un piso particular que tenemos alquilado una serie de amigos y yo, sin embargo, por cuestiones económicas, el mantenimiento de internet se hizo insostenible y, claro… ya me diréis qué hacemos con un servidor sin estar conectado a la red de redes.

Hay que analizar por partes los pros y contras de este tipo de decisiones. La principal limitación es cláramente la imposibilidad de aprovechar las ventajas que nos daba el almacenamiento de datos de todo tipo.  Sin embargo, dado la edad avanzada del portátil, esa sería una carga que ya nunca tendría que soportar.

Dado que en mi domicilio particular cuenta también con una conexión con IP fija, no había más remedio que trasladar el servidor a mi casa. Así, si surge algún problema, ese desplazamiento que me ahorro. Lo primero que hice fue, de nuevo, rediseñar toda la estructura de directorios y eliminar los usuarios que ya no eran necesarios. Por lo tanto, eliminé uno de los discos duros externos y por supuesto la webcam, que de nada servía cuando no había nada interesante que ver. Obviamente descarté el HD de 200GB y me quedé con el gordo, que para eso son míos, y estudiaré la opción de donar el pequeño.

Una de las cosas principales que hay que realizar cuando hay un cambio como este, es volver a configurar las IPs de destino. Recordad que el servidor actúa como DNS público, por lo tanto, además de hacer una mínima modificación en mi proveedor de dominio, tendría que reconfigurar de nuevo mi servidor DNS para que los cambios surgieran efecto cuanto antes. Y ahora que tengo VirtualHost se vuelve una tarea tediosa. No vuelvo a cambiar el servidor de sitio.

Dado que nuestro álbum particular se alimenta del directorio de fotos y que yo sólo no puedo retroalimentar continuamente, tuve que crear una miniaplicación en PHP para permitir subir las fotos comprimidas y que por si solas se almacenaran en el álbum con sus respectivas fechas. De esta forma, yo era informado por mail y con otro script, generaría de nuevo el álbum con las nuevas fotos. Destacar que podría haber generado el álbum directamente cuando un usuario sube alguna foto, sin embargo es este proceso el que hace subir más la temperatura, por lo tanto prefiero tenerlo controlado. Si por algún casual tres usuarios subieran fotos a la vez, habría tres procesos generando el mismo álbum y prefiero no correr el riesgo. Para  información de los usuarios, actualmente uso  JALBUM, incluido en los repositorios Debian y Ubuntu. Usa JAVA y se puede ejecutar perfectamente desde consola. Una bonita aplicación gratis y apta a todos los públicos. Por supuesto, para aquellos a los que lo negro les de miedo (me refiero al terminal), posee también una interfaz gráfica la mar de sencilla.

Atrás quedaron los tiempos en los que tenía sólo una preocupación en la cabeza. Lo he automatizado todo tanto que no tengo que preocuparme casi en absoluto del mantenimiento. Llego incluso a arrepentirme de haber mudado el blog a wordpress dudando, lo reconozco, de mi pequeño  y su fiabilidad.

De lo que no estoy nada conforme es con el ruido. Con el tiempo y las horas de funcionamiento el ventilador se encuentra la mayor parte del tiempo funcionando y aunque se encuentra metido en un armario por las noches es difícil conciliar el sueño en ocasiones. Lamentablemente al ser un modelo muy antiguo, la aplicación sensors tan sólo encuentra los módulos para la temperatura de la CPU no pudiendo controlarse de esta forma la velocidad de los ventiladores. Un día con tiempo buscaré soluciones de sistema entrada – salida básica.

La backup la realiza todos los días a las 2:00 AM y actualmente la veo bastante fiable. El destino sigue siendo un pendrive de 1GB que alberga las bases de datos; los .conf de las aplicaciones y la totalidad de las mismas; todos mis scripts y el contenido de las páginas web comprimidas.  Genero un log y lo hago visible via web por si no tuviera modo de conectarme a la terminal:

http://gomezbecerra25.com/copia

Como medida de seguridad extra, también vuelco el contenido al disco duro externo para no correr riesgos con un pendrive y por supuesto, realizando una imagen del disco duro cada final de mes para poder poseer una base de restauración más rápida.

En definitiva, que teniendo como tengo un portátil casi sin usar mucho más nuevo, casi prefiero que algún día el actual diga basta y pueda renovar el HW por completo porque a nivel de SW, nadie me hará caer del burro.

Me mudo

Efectivamente me he mudado a wordpress por la simple razón de que me apetece compartir mucho más mis experiencias y soy consciente que la indexación que google pueda realizar a mi hosting casero no será la misma que aquí.

Para los usuarios nuevos que puedan leerme ahora, no hay más que leer las antiguas entradas para ponerse al día en todas las cuestiones. Mi servidor web sigue intacto y mi blog es legible igualmente desde su antiguo dominio

Blog de gomezbecerra25.com

Por lo tanto, aunque ya no será lo mismo, seguiré transmitiendo la bonita experiencia de mantener un servidor funcionando en un ordenador portátil. No será lo mismo porque ahora la conexión se realizará a quién sabe dónde se encuentren los servidores de wordpress y no al mismísimo portátil. Sin embargo siempre os quedará el antiguo link para comprobar que la cosa sigue en pie.

Etiquetado

8 Meses a pleno rendimiento.

Justamente hoy hace ocho meses que puse en marcha el servidor. Parece mentira que aquel viejo portátil que tenía en el altillo del armario me haya dado tanta felicidad. Aunque como mínimo quería esperar un año, me siento con toda libertad para asegurar que un portátil puede funcionar como servidor perfectamente. Primeramente quiero añadir que no hay que confundir las funciones que desempeña mi portátil, con la descripción que tenemos a rasgos generales de un servidor.

Naturalmente que un portátil no podrá hacer la misión que realizan los grandes servidores corporativos con sus aplicaciones y sus enormes cargas de trabajo que son capaces de soportar. Actualmente en mi trabajo tengo la suerte de conectarme diariamente a WorkStation con 32Gb de RAM y aún así veo como en muchas ocasiones, les cuesta mover ciertas aplicaciones que utilizan a la vez cientos de usuarios.

Por lo tanto, contemos con que nuestro servidor  desempeña tareas livianas y que a lo sumo, es el servidor de webcam es el que en ocasiones consume algo de memoria. Sin embargo, lo que realmente queremos constatar aquí es el desgaste que le puede a ocasionar a un Laptop el estar 24 horas encendido durante 8 meses.  Si realizo un ‘uptime’, desgraciadamente no puedo ver 5760 horas encendido, más que nada porque en un par de ocasiones he necesitado reiniciar por diferentes motivos.

Puedo decir también antes de finalizar, que a lo máximo que se ha visto sometido el portátil ha sido el foro phpBB3, el streaming de vídeo a un Pc cliente y el ya comentado servidor de la WebCam. Poca cosa en comparación con lo que he visto soportar a varias máquinas, pero que al menos esta labor la realiza a las mil maravillas. Sin contar con ciertas tareas que se encuentran en el crontab como las copias de seguridad y diferentes script que ejecuto diariamente.

En definitiva… sí, usad el portátil como queráis, están de sobradamente preparados para soportar cualquier tipo de función… Eso sí, tampoco pasarse y plantarle el Apache TomCat con 50 usuarios porque entonces sí se puede acortar seriamente el rendimiento.

Etiquetado

Un portátil como servidor :: Comienzos con phpBB

COMIENZOS CON PHPBBX

Si buscamos por google algo referente a servidores web en un ordenador portátil nos encontraremos varias entradas. De todas las que he consultado, no deja de ser consultas y varias respuestas dispersadas sin mucho sentido y sin una opinión clara. Es más, muchas de las personas que respondían, claramente aludían a opiniones personales, ya que que ninguno de ellos tenía montado un servidor web en un laptop.

Quería tan sólo desmontar algunos de los tópicos que existen y, por supuesto, dar validez a otros muchos que sí son ciertos. Sin embargo, me gustaría empezar desde el principio y situarme varios años atrás hasta explicar exactamente el proceso y cómo está funcionando el servidor en estos momentos.

Antes de comenzar, para aquellos que tiene conocimientos más avanzados del tema, además de leer esta entrada, recomendaría encarecidamente el completo análisis deDaniel Clemente, el único que ha vivido una experiencia parecida, o al menos ha querido compartirla. A mi parecer es muy bueno, quizás un poco complicado, pero él lo ha querido así. Un 10 para él.

Supongo que como todo hijo de vecino, todo el mundo comienza con un hosting alquilado, y en el peor de los casos gratuitos llenos de publicidad y esclavo de un dominio. En mi caso fue así. Afortunadamente poseo un gran número de amigos, que por las circunstancias que sean están muchos de ellos dispersados por el ancho mundo, desde diferentes partes de la península, hasta Alemania y en estos momentos también en Buenos Aires.

Empecé montando en un hosting de forogratis.es un foro phpbb2. En realidad no lo monté yo, simplemente me di de alta y por arte de magia la base de datos quedaba montanda y listo para administrar. Fueron unos comienzos bonitos y el foro llegó incluso a los 40 usuarios. Aparte de la pandilla, pues se iban aficionando amigos de amigos, novias, novios… en fin…

¿Qué ocurrió? Simplemente que soy un poco inconformista y hay infinidad de cosas que las pienso y las doy por imposible, pero con el paso del tiempo poco a poco las empiezo a digerir. Comencé a introducirme cada vez más en el tema de phpbb3, que en ese momento estaban apareciendo las primeras betas y me pareció muy interesante. Sin embargo era consciente de que el foro al que pertenecía y esclavo del dominio forogratis.es  (el cual recomiendo para empezar) tenía fecha de caducidad. No tengo nada en contra de la publicidad, puesto que es un medio necesario para que muchas webs sobrevivan, sin embargo los dichosos banners ya no los soportaba más.

Llegaba la hora de tener un hosting propio, no podía aguantar más. Como la cosa no estaba para tirar cohetes, comencé comprando Gomezbecerra25.com y por tan sólo unos 7€ al año ya era dueño de un dominio. Muchos de vosotros os diréis que era una ganga, pero recordad que no alquilo ningún tipo de espacio ni disco duro que se precie, tan sólo dispongo de 5MB que el proveedor te facilita por cortesía.

Obviamente con este espacio no puedo hacer nada parecido a phpbb3, donde en tan sólo un mes la base de datos puede llegar a pesar 10MB, por lo tanto debía esperar hasta el ansiado día. Ni tenía disponibilidad económica, ni me sentía bien haciendo una recolecta entre todo para tener un hosting, de hecho, todo el mundo estaba a gusto en el foro de aquel entonces.

Como premio de consolación, lo único que pude hacer era redirigir la dirección gomezbecerra25.com al foro antiguo, sin embargo con el tiempo me di cuenta que el único que tecleaba en el navegador dicha URL era yo, por lo tanto, de nada sirvió… mi gozo en un pozo.

Con el tiempo empecé  a descubrir hosting gratis, que sí, que los hay a patadas, pero esteera gratis de verdad, es decir, carecía por completo de publicidad. Estuve unos días estudiando la posibilidad y lo veía factible. Podía conservar el dominio que adquirí y redirigirlo mediante sus DNS a sus máquinas. Era perfecto, mi propio dominio, los 250MB eran más que suficientes y un panel de control de lo más completo. No tardé ni un ápice. Aprovechando que nadie entraba en antiguo foro por la dirección de gomezbecerra25.com, redireccioné para que apuntase lo antes posible al nuevo hosting.

Me apresuré para subir todos los archivos y aunque me costó, conseguí dar de alta en la base de datos MySQL  los usuarios correctamente. Voilá!  Después de unos cuantos clicks, tenía un foro PHPBB3 totalmente operativo. Uno de los grandes inconvenientes de tener tu foro en dominios ajenos, es que no te facilitan una copia de la base de datos, por lo que un foro con más de dos años de antigüedad, quedaba reducido a cenizas. Por un lado no me vino del todo mal, puesto que había un pupurrí de temas y posts que una limpia era realmente necesaria.

Paulatinamente mis amigos y amigos de amigos se iban registrando y aunque tenía ciertas quejas, fue una cálida bienvenida. Las quejas eran simplemente por la infinidad de opciones que el Panel de Usuarios poseía. Una vez que el entorno era familiar, el foro comenzó a crecer y actualmente ya es un adulto.

De este hosting saco varias cosas en claro. Dan mucho por muy poco (coño, es gratis),  el panel de control es muy completo, nada que envidiar a los de pago y por supuesto puedo hacer copias de seguridad de mi base de datos. Como grandes incovenientes tiene la NO posibilidad de crear más de una base de datos. Supongo que sera una forma de que te des de alta en la cuenta premium (pagando, obviamente). Sin embargo era feliz, no me importaba puesto que no tenía pensado montar nada además de mi foro.

No obstante, y como es común en este tipo de cosas, había un pero pequeño que poco a poco ibra creciendo a pasos agigantados. El servidor se caía constantemente. La cosa empezó una vez a la semana y se convirtió en una costumbre casi todos los días. Era bastante frustrante observar como la mayoría de las tardes el host no respondía y tardaba incluso horas en volver a estar disponible. Esa serie de cosas me hizo empezar a carburar.

Mis maquinaciones no dejaban de ser meras quimeras. Sin embargo poco a poco empecé a plantearme el montar mi propio servidor, mi propia máquina para alojar el foro y qué se yo. Como era de esperar, tenía que empezar a examinar los pros y los contras… contras que eran básicamente monetarios.

Antes de comenzar la aventura, quería introducíos en ciertos detalles. Si fuera mi propia casa donde decido montar el servidor, no habría problema, no tendría preocupaciones de tipo económicas y usaría la ADSL de mi casa para dar el soporte necesario, total, apenas notaría tráfico puesto que sería la velocidad de subida la que se vería un poco comprometida. Sin embargo el cuartel general quería que fuese otro lugar… un lugar que sirve habitualmente de reunión a todos mis amigos, incluido yo. Un piso pequeño, pero con lo suficiente para pasar buenos ratos y que tiene mucho que ver con el nombre de dominio.

Antes de que el proyecto tomara forma, en el piso tan sólo existía un PC con unas pobres características; un Pentium II 350Mghz con 128Mb de RAM, una auténtica cafetera con tan solo 8Gb de HD que era capaz de mover un Windows XP Pro… obviamente una versión fabricada con el software nLite. También teníamos una conexión “prestada” mediante Wifi que daba su utilidad. Obviamente, para colocar la primera piedra, uno de los prerequisitos más básicos, era sustituir la conexión por otra más estable, y sobre todo, por cable… qué es eso de planear un servidor web con una conexión Wifi.

Después de varios episodios que no tienen relevancia ninguna, por fin teníamos una conexión digna y el primer desembolso serio que se realizaba en el piso entre todos. Tenía sentido… el que no lo podía disfrutar estando allí, lo disfrutaba conectándose al foro. Debo decir que me costó bastante decidirme por la conexión y el proveedor. En mi casa particular dispongo de YACOM, no había tenido problemas y era una seria candidata, sin embargo no me preocupaba la velocidad de bajada, sino yo andaba buscando cuál de ellas me proporcionaba la mejor velocidad de subida. Recordad que dicha velocidad es la usada para enviar los resultados a todos los usuarios, y mi servidor iba a estar continuamente enviando información.

Finalmente me decidí por la conexión de YACOM de 10MB/512KB. Me resultaba muy golosa los 20MB ya que me proporcionaba 1MB de subida, pero se nos iba de precio y para cargas de quizás 7 usuarios a la vez en los mejores casos no la iba a necesitar. Finalmente con 32€ Iva incluido tengo 10MB y llamadas nacionales gratis por VozIP, por lo que me ahorro, a su vez, el pagar las cuotas a telefónica.

Para esos entonces el PC cliente (aquel Pentium II) fue sustiudo por un bonito Pentium IV a 2.8Ghz que hacía las delicias de todos los inquilinos permitiendo también ser usado para la visualización de películas. Este Pc estaba enchufado a la tele (y aún sigue) y permitía sesiones de cine interesantes, incluso compramos un buen equipo de sonido y repartimos los altavoces por cada esquina.

Este tipo de cosas me daban cada vez más ideas. El PC cliente tenía tan solo 40GB de HD, insuficiente si comenzamos a almacenar películas, series, música y demás. Aparte, al ser un PC al alcance de todos y con Windows, los formateos eran casi semanales… nada se podía hacer ante el anidamiento de virus que ese PC contenía. Estos incovenientes me hicieron ver que, aparte de servidor web, el futuro PC podría también funcionar como servidor de archivos, haciendo streaming al pc cliente que lo reproduciría por televisión. Era perfecto!

Manos a la obra. Me hice con un bonito PC, un AMD athlon XP 2400…  muchos de vosotros pensaréis que qué tiene que ver todo esto con el portátil…  paciencia. Ya tenía la torre en mi poder lista para preparle en un par de días un servidor web y un servidor de archivos.

Uno de los problemas que tuve fue la elección de un disco duro. Finalmente y después de penar mucho, decidí “donar” el mío personal de 200GB y comprarme yo uno más grande. Pues no estaba mal, aproximadamente 5GB de Web y el resto para datos.

¿Qué sistema operativo elijo? Difícil decisión. Si fuera un maestro en UNIX, obviamente eligiría una máquina Solaris… pero no lo soy, y lo que es peor, mis contactos con linux en aquella época eran escasos.  Tuve mis tentaciones, pero finalmente en mi cabeza estaba la idea de un windows 2003. Antes de que muchos de vosotros echen rayos por la boca ya os explicaré el  porqué.

Otra de mis ideas (grandes ideas)  fue que a su vez el servidor también mostrase imágenes en tiempo real desde una cámara web conectada al servidor. Esa era una de las razones de peso que me hacían elegir S.S.O.O Windows, ya que los programas disponibles para estos menesteres, me parecían más fácil de instalar y  de configurar. Sumándolo, por supuesto, mi experiencia durante años en administrar W2003 Server.

Decía Twain que un hombre con una idea nueva es un loco hasta que la idea triunfa. Todas las noches, antes de dormirme, siempre me quedaba pensando en cómo sería la administración, posibles maneras de accesos, permisos, etc… Por supuesto no era mi primera vez, en mi trabajo lo hacía constantemente… sin embargo lo consideraba diferente… realmente hacía esto por hobby, le puse una ilusión bárbara.

Aún me recuerdo compartiendo mi idea con un amigo… me escuchaba atentamente hasta que pronuncié la palabra “windows”.. y ahora doy gracias por no haber instalado un sistema operativo ocupando recursos totalmente innecesarios…Básicamente puedo decir que me tentó y por supuesto me animó.

Ya estaba claro… iba a poner un servidor LINUX. Es estable (muy estable), liviano, modificable y la administración remota es perfecta. Me introduje muy a fondo en el tema… tanto que ahora mi vida es muy diferente. Me pasó 8h al día trabajando con servidores UNIX, sería un delito haber puesto Windows en mi servidor.

Estuve en los foros durante dos o tres días informándome cuál era la mejor distribución para funcionar como servidor. Casi todos los usuarios estaban de acuerdo en usar o Debian – Ubuntu – Red Hat. Éste último lo descarto por no ser del todo gratis. Ubuntu me gusta (es Debian), pero no quiero para nada facilidades en entorno gráfico, ya que la administración remota iba a ser por consola. Ya estaba la decisión tomada, iba a instalar Debian… me gustaba la facilidad del apt-get como gestor de paquetes.

La instalé en mi portátil para familiarizarme con el S.O. Así estuve durante unos meses y conseguí verdaderamente convertirme en un usuario semi-avanzado. Me estudié a conciencia su infraestructura y todo su funcionamiento hasta tal punto de arrepentirme en cada línea que leía de no haberme adentrado más en este fantástico sistema.

Así llegó el día indicado y me puse a instalar el servidor en el AMD ATHLON que os comenté. En unas horas ya tenía arrancado el servidor web y el servidor de archivos usando Apache2 y Samba respectivamente. A su vez instalé ciertos programas que ya resumiré en otras entradas. Sin embargo lo básico ya estaba listo para funcionar.

Una vez el servidor funcionando en el piso, configuré ciertos parámetros Samba y me fui rápidamente al Pc Cliente (Windows XP)… perfecto, los vídeos y la música la reproducían perfectamente. Tocó el turno instantes después de poner en marcha el phpmyadmin para hacer funcionar el foro Phpbb3 que ya tenía funcionando en un hots ajeno. Por supuesto, apache2 no faltó tampoco. Configuré de forma apropiada los archivos de configuración de apache y en unos pocos minutos ya tenía la web andando.

Copié los archivos del foro a mi nuevo servidor y restauré las bases de datos. A la primera, funcionaba todo sin problemas y desde el PC cliente se leían todos los archivos compartidos por Samba. De esta forma, si el PC cliente muere, explota, etc, la información no se verá comprometida en ningún momento, ya que los datos se encuentran en el servidor.

Así pasaron varios meses, no tuve ningún problema que no se pudiera solventar en minutos, todo iba a las mil maravillas. Sin embargo había un tremendo inconveniente:Consumo – Ruido – Calor.

El servidor hacía un ruido exagerado, quizás cualquier noche de charla no se inmutaba uno del run-run, pero aquello parecía un martirio chino cuando te encontrabas solo. Cambié los ventiladores por algunos más silenciosos, pero teniendo en cuenta que tenía que tirar de viejos utensilios, lo único que conseguí era bajar pequeños decibelios y ganar algunos grados de temperatura.

Verdaderamente tampoco me ayudaba que aquello fuera un AMD Athlon. Era inconcedible tener el PC a 72º con una carga de procesados de 1%. ¿Qué pasaría cuando aumentase su rendimiento? Lógicamente, también me preocupaba el consumo de luz que generaría el servidor. Entre unas cosas y otras podría llegar a los 70W. 24h encendido, 30 días al mes era un posible motivo de alarma, ya que los consumos de un piso que la mayoría del tiempo está vacío, eran hasta entonces muy bajos.

COMIENZOS CON UN PORTÁTIL

Es justo en este momento, donde empiezo a plantearme seriamente usar un portátil como servidor. En aquel entonces reconozco que sólo veía contras, pero a lo largo de los días, cuando todo era digerido, empezaba a transformar los contras en ventajas. Recuerdo en una de aquellas madrugadas se me ocurrió probar un portátil Siemens que tenía prácticamente sin usar. Lo encendí y hacía un ruido prácticamente nulo. Me puse a pensar que con una buena ventilación no tendría problemas de temperatura. Primera prueba superada.

La segunda era algo más complicada. Era la migración. Tendría que traspasar toda la información del AMD al disco duro del portátil y configurar todo de nuevo. Con el poco tiempo del que dispongo era un bache en el camino, más que nada porque ello implicaba desplazamiento hasta el lugar donde se encuentra el servidor. Se me ocurrió un idea que no tarde en llevarla a cabo. Podría adaptar mi disco duro IDE introduciéndolo en los famosos adaptadores USB. De esa forma, Debian arrancaría como si estuviera en la máquina origen. Obviamente esa teoría hacía aguas por todos lados, ya que para empezar, el arranque estaba montado como hda, y al pasar IDE a USB, se convertiría el sda. De todos modos lo probé para quedarme tranquilo y efectivamente tenía razón. Prueba no superada.

Por lo tanto me convencí a mí mismo para realizar a mano la copia y dejar que el disco duro que poseía el portátil (80GB) fuera el encargado de arrancar y dejar al externo (antes interno) de 200GB para otros menesteres. Poco después pude comprobar que el proceso de copiar todos las aplicaciones podía ser automático con el comando “dpkg –get-selections > paquetes”. Éste me creaba un archivo paquetes que contenía la lista de programas que tenía instalado. Una vez copiado ese archivo a la máquina destino, tan sólo tenía que ejecutar un dpkg –set-selections < paquetes y en un abrir y cerrar de ojos (un poquito más), ya tenía instalado todas las aplicaciones en mi nueva máquina de un plumazo. En lo relativo a SAMBA y APACHE2, me copié a mano los archivos de configuración .CONF y reinicié los demonios. Segunda pruena superada.

Antes de seguir, me gustaría hacer mella de nuevo en las temperaturas y consumos. Desde luego la cosa mejoró mucho, acompañado naturalmente en el procesador, que era menor y al ser un portátil, estaban diseñados para no calentarse en exceso. Mi Servidor es un Siemens con un procesador Pentium M a 2000Mhz, pero la CPU realmente está funcionando a uns 900Mhz. El consumo se encuentra alrededor de los 15-40W si sumamos todos sus componentes. Una diferencia abismal comparado con el ciclo de reloj del anterior AMD. Sin duda he salido ganando. Rara vez mi el procesador pasa de 50º C. Otra de las mejoras de ser un equipo portátil, es que el ventilador en muchas ocasiones está apagado, silencio absoluto, y el ciclo de reloj suele oscilar dependiendo del consumo del procesador, que se encuentra el 90% de las ocasiones al 1%.

Cuando disponía de la torre, otras de los grandes obstáculos que me e ncontraba era la ausencia de monitor. Por supuesto que para un buen administrador eso no es ningún impedimento, sin embargo es algo que a veces se agradece si surgen problemas relativo al SSH y por si alguna vez queremos actualizar el sistema. Acabo de caer en que también tengo teclado… en qué estaría pensando para no haberme migrado antes! Y ratón!!

Ya ha pasado mucho tiempo, quizás no el suficiente para hacer un análisis completo sobre el rendimiento del Laptop. Pero aproximadamente lleva tres meses y sinceramente tenía la impresión de que no iba a aguantar mucho; no temía que se quemara, pero sí que la temperatura del micro fuera aumentando paulatinamente con el tiempo. Aún así, acudo cada dos semanas a despejar los orificions de ventilación puesto que el polvo es compañero inseparable y aún no me ha subido nunca de 50º C, una vez que actualicé el sistema. Aunque no es motivo de alarma, tengo diseñado un script que me alerte si la temperatura sube a más de 60º. Hasta hoy sigo sin ningún aviso.

Mucha de las cosas que veía por internet y que quería probar eran los rumores de que la batería podía salir ardiendo :D. Yo no sé cómo eran los portátiles de antaño, pero los de hoy en día, cuando el ordenador detecta que la batería está totalmente cargada corta el circuito. De esta forma la batería no está “sufriendo” y además, en el caso de falta de suministro eléctrico, el ordenador seguirá encendido. De nada vale puesto que no habría internet, pero nos evitamos rearrancarlo de nuevo. Obviamente, si ese proceso se repite muchas veces, ya podemos despedirnos de la batería, ya que acortamos enormemente su ciclo de vida.

Otro de los pequeño inconvenientes que primero se me ocurrieron cuando empecé a maquinar la idea del portátil, era que no podía instalar discos duros a mi antojo. En poco tiempo el disco duro de 200GB se quedará pequeño (si no lo es ya) y generalmente, los que llegan a mis manos son de pequeños tamaño. Con esto quiero decir que ojalá adquiera un HD de 1TB y adiós a mis problemas, sin embargo actualmente me tengo que conformar con HD’s de 200, 120, 80GB. Muchos de vosotros pensaréis que dispongo de las cajas para convertirlo en USB, pero no es plan de gastarme 20€ cada vez que adquiera un HD. Pero seguramente se me vaya la olla y el próximo HD que pase por nuestro piso será de 1TB seguro.

Para alargar la vida de los discos duros, se me ocurrió buscar alguna utilidad para detener el motor de giro del disco, de esa forma, ponerse en movimiento una vez que se requiera su uso. La encontré rápidamente, se llamaba hdparm, y con su opción -Spodías definir un valor numérico que indicaría los segundos que deben transcurrir sin uso, para que el motor del disco se detenga. Quizás lo habréis supuesto, pero mi servidor actualmente tiene dos discos duros. Uno, original para el portátil de 80GB y otro, externo de 200GB, justo el que se encontraba de forma interna en la torre. Cuando el PC cliente accede mediante SAMBA al servidor se encontrará tres carpetas:

  • Audio
  • Video
  • Imágenes

No hay que ser muy listo para presuponer que la carpeta Vídeo será la más guerrillera en forma de bytes. Por lo que se me ocurrió montar todo el contenido del disco de 200GB (sdb1 – ext3) a la carpeta Vídeo. El audio y las imágenes se hará cargo el disco de 80gb, a no ser que de repente alguien traiga la discografía completa de los Rolling Stones a 320kbps. Dado que rara vez el disco externo está haciendo streaming de películas, he indicado con hdparm que el disco se pare a los 55 segundos. Antes de hacer esto, me daba escalofíos tocar la caja que alberga al disco duro. Aun siendo un material frío, estaba siempre caliente. No era una temperatura extrema, sin embargo quise tomar medidas cuanto antes. Gracias a esta última medida, os puedo asegurar que da gusto poner la mano… frío como el hielo. Este ajuste también lo he hecho para el disco que alberga el sistema, el de 80GB, pero creo que por lógica nunca deja de estar en uso. Controlo de forma exhaustiva su temperatura y se encuentra normalmente a unos 43º C.

En resumidas cuentas, no he tenido ningún problema con él. Lo cuido como un niño pequeño, sí, pero con el paso del tiempo iré centrándome menos en él y realmente se verá cómo funciona en condiciones extremas. Verdaderamente temo la llegada del verano, puesto que en nuestra fachada y techo el sol pega directamente. Se pueden alcanzar perfectamente allí dentro los 35 º C. Todo esto me ha hecho montar proyectos de todo tipo como Joomla, Drupal, Phpbb3, WordPress y todo tipo de herramiento php. Es impresionante la libertad que se adquiere al tener tu propio servidor, realmente empiezo a ver un fastidio esos paneles que los hosting nos facilitan cuando adquirimos un dominio.

Seguidamente, en este mismo blog, os iré contando las modificaciones, mejoras o, por supuesto, inconvenientes que el Sevidor me pueda suponer. Aunque si estáis leyendo esto, imagino que no habrá ningún problema. Siento muchísimo la cantidad de información dada. No podía dejarme nada en el tintero, y lo que he dejado, lo reservo para sucesivas entradas.

Etiquetado