sábado, 31 de diciembre de 2011

Cuando las empresas pierden su alma (Strands Fitness echa el cierre)

Ayer, día 30 de diciembre de 2011 fue un día triste para una comunidad de usuarios. Strands Fitness echó el cierre definitivo. Para los que no tuvieron la suerte de conocerla, se trataba de una red social orientada al mundo del deporte y quizás más concretamente al mundo del atletismo. Podías llevar un registro de tus entrenamientos (correr, bici, nadar, gimnasio,...), crear rutas a través de google maps, sacar estadísticas de muy distintos tipos, marcarte objetivos tanto de entrenamiento como de peso, ... y todo ello con el aliciente de ser una red social donde todo puedes (o no) compartirlo con tus amigos. Una plataforma muy útil para todos los amantes del deporte ya sean profesionales o simples aficionados como yo.

Sin embargo, en mi humilde opinión creo que también fue un día triste para el mundo de los emprendedores y las startups y en este post voy a exponer mis razones.

El origen de Strands Fitness nació de la mano de Vicent Gozalbes (@vigosan), un apasionado del mundo de la programación Web y del atletismo popular. Una combinación de lo más apropiada para crear en solitario mientrenamiento.com. Cito textualmente del blog de Strands:

mientrenamiento.com surge de la necesidad de registrar y llevar un control diario de los entrenamientos de atletismo realizados. Además, nos permite llevar la cuenta de los kilómetros realizados con cada par de zapatillas y la posibilidad de crear y compartir rutas de entrenamientos entre amigos. 
Ahora todos podemos encontrar muchísimas aplicaciones para nuestros smartphones que te trazan la ruta mientras vas corriendo, pero os hablo de 2008, y por aquellos entonces, trazar tu ruta de entrenamiento a través de google maps, medir las distancias y poder saber en qué kilómetro exacto cogías tus tiempos parciales era toda una pasada, al menos lo era para mí y mis amigos. Por supuesto existían dispositivos como Garmin, pero para aficionados como nosotros, lo único que necesitabas era conexión a internet y un simple reloj para medir tu tiempo.

Abel Antón y Vicent Gonzalbes
Mientrenamiento.com fue comprado por Strands y Vicent Gonzalbes fue puesto al frente del proyecto. Pasó al dominio www.strands.com e incluso contaron con grandes atletas como Abel Antón, Marta Domínguez, ... para promocionarlo. Más tarde llegaron las aplicaciones para dispositivos móviles iPhone,Android, ... las cuales estaban geniales porque cerraban el círculo. Ya no había que meter los datos a mano, sino pulsar un botón al salir a correr y todo quedaba registrado en tu perfil. El proyecto apuntaba bastante alto. Sin embargo, desde mi humilde opinión, aquí empezó el desalme del proyecto.

Strands relegó al proyecto al subdominio fitness.strands.com y cuando entrabas en www.strands.com te encontrabas 3 secciones: un recomendador de productos(recommender.strands.com), una parte de finzanzas (money.strands.com) y, por supuesto, Strands Fitness. 3 plataformas que desde mi punto de vista nada tienen que ver las unas con las otras, salvo que eran de Strands. Parece que la necesidad de monetización del proyecto cobró más importancia, y el alma del proyecto, el objetivo por el que nació mientrenamiento.com, el cual se recoge la cita de más arriba, fue quedando poco a poco en un segundo plano.

Estoy convencido de que a la comunidad de usuarios de Strands Fitness poco le importaban las otras dos secciones, y estoy más convencido aún de que les bastaba con la plataforma que cumplía su objetivo inicial, incluso podrían admitir anuncios, pagar algo más por la app móvil o recibir promociones de productos relacionados con el atletismo. En definitiva, estoy seguro de que aceptarían un pequeño sacrificio con tal de mantenerla abierta.

Con esto no digo que desde Strands no lo hayan intentado lo suficiente o hayan hecho sus sacrificios para intentar seguir adelante con el proyecto. Sinceramente, lo desconozco. Me gustaría hablar con Vincent Gonzalbes para conocer su experiencia desde dentro. Es comprensible que, siendo una empresa, existe para ganar dinero. Lo que quiero decir es que en algún momento perdieron de vista el objetivo por el que nació Strands Fitness o mientrenamiento.com, su alma. Y cuando una empresa pierde su alma se converte en sólo un negocio, y ya cualquier cosa vale.


Feliz año 2012 a todos.

viernes, 4 de noviembre de 2011

Evitar timeout de sesiones SSH en Centos, Red Hat y Fedora

A veces estamos trabajando a través de SSH, dejamos de usar la sesión durante unos minutos y al volver a ella nos encontramos que la sesión ya no funciona. Al estar la sesión inactiva, el timeout ha expirado y tenemos que volver a iniciar sesión.

Por supuesto, se trata de un mecanismo de seguridad que viene activado por defecto en los servidores SSH de Centos, Red Hat y Fedora. A través de este mecanismo se previene que alguien le pueda dar un mal uso a una sesión SSH que otro usuario haya dejado abierta sin querer en algún ordenador. En Debian y Ubuntu la configuración por defecto no activa este mecanismo.

Sin embargo, en determinadas situaciones esto es especialmente molesto, sobre todo cuando estamos trabajando con varias ventanas o aplicaciones y entre ellas se encuentra una sesión SSH que usamos sólo de vez en cuando. Tenemos que estar continuamente abriendo consolas SSH y si encima teníamos abiertas varias sesiones a la vez, cosa muy habitual por otra parte, entonces los pensamientos (o gritos en los más expresivos) maldiciendo al servidor o al árbol genealógico de los creadores del SSH se multiplican.

Como ya he comentado, la sesión expira debido a la falta de actividad o intercambio de datos entre el cliente y el servidor. Algunos solucionan este problema dejando abierto algún comando que continuamente intercambie datos, como por ejemplo el comando top o watch. Sin embargo, si olvidas dejar ese comando antes de dejar de usar la consola te encontrarás una bonita sesión expirada al volver a usarla. :p

La solución en el caso de que esto suponga un problema es bien sencilla. Basta con configurar dos parámetros en el servidor SSH. En concreto se trata de los parámetros ClientAliveInterval y ClientAliveCountMax. El primer parámetro establece el tiempo en el que, en caso de estar la conexión SSH inactiva, el servidor SSH enviará una petición al cliente para comprobar si sigue existiendo la conexión, o en otras palabras, para comprobar si el cliente sigue "vivo". El segundo parámetro indica cuantas peticiones con el fin anterior sin respuesta se van a permitir como máximo antes de dar por finalizada la conexión.

Dicho de otro modo, configurando adecuadamente los parámetros anteriores, el servidor SSH en caso de encontrarse una sesión inactiva, enviará peticiones al cliente para comprobar que la conexión sigue existiendo y no cerrará la sesión SSH a menos que realmente la conexión se pierda.

Estos parámetros se configuran en /etc/ssh/sshd_config y una configuración típica es:

ClientAliveInterval 10
ClientAliveCountMax 3

Lo que quiere decir esta configuración es que en las sesiones inactivas el servidor comprobará que la conexión sigue activa cada 10 segundos y si es así no cerrará la sesión. En el caso de que realmente se interrumpa la comunicación entre el servidor y el cliente, el servidor la dará por "muerta" a los 3 intentos fallidos, es decir, en 30 segundos (10x3).

Como decía, en el fichero sshd_config por defecto de Centos, Red Hat y Fedora no vienen estos valores (o vienen comentados) y el valor por defecto de ClientAliveInterval es 0. Por tanto, eso significa que no se van a realizar las comprobaciones anteriores y de ahí que nuestra sesión caduque al poco tiempo de dejar de usarla.

Por último, comentar que realmente sólo es estrictamente necesario el parámetro ClientAliveInterval ya que el valor por defecto de ClientAliveCountMax es precisamente 3. Sin embargo, no está de más ponerlo.

Espero que os sea de utilidad.
;-)

lunes, 3 de enero de 2011

Recuperar archivos borrados en Linux

Hay veces en las que borramos archivos accidentalmente. Normalmente tenemos la papelera de reciclaje como red de protección para no perder definitivamente esos archivos, pero a veces borramos con shift+supr o desde consola (rm -f ....) y de esa forma los ficheros no van a la papelera. ¿Qué hacemos en este caso?

Lo primero es conservar la calma, hay muchas posibilidades de que recuperemos dichos archivos o al menos gran parte de ellos.

Cuanto antes debemos dejar de utilizar la partición en la que hemos eliminado los archivos. Cualquier escritura posterior a la eliminación de esos archivos podría escribir donde antes estaban nuestros archivos, lo que nos impediría recuperarlos.


Si es la partición raíz, tendremos que apagar y posteriormente arrancar con un livecd o montar nuestro disco desde otro ordenador. Si es otra partición, como por ejemplo la /home, únicamente tendremos que desmontarla. Para poder desmontar la partición primero tenemos que dejar de utilizarla. En el caso de la /home, implica para las X Windows (gdm,kdm,... según el caso) . Para ello pulsamos ctrl+alt+F1 y entramos en una consola como root. Después escribimos,

/etc/init.d/gdm stop
umount /home

Ahora es cuando realmente empieza la tarea de recuperación. Tenemos diversas opciones como extundelete, magicrescue, foremost,... Mi consejo es que primero lo intentes con extundelete, ya que recupera incluso el sistema de directorios borrado. Si extundelete no nos recupera los ficheros deseados, habría que meterse en un análisis en profundidad del disco con magicrescue y/o foremost.
 

extundelete

 

Esta opción sólo te vale si tu sistema de ficheros es ext3 o ext4. Puedes descargarlo desde su página oficial. También puedes ir directamente al área de descargas.

Una vez descargado, descomprimimos el tar.bz2

tar -xjvf extundelete-0.2.0.tar.bz2

Para instalarlo necesitarás tener instalado los paquetes e2fslibs-dev y build-essential. Si necesitas instalarlos, puedes usar el siguiente comando (en Debian y Ubuntu):

aptitude install e2fslibs-dev build-essential

A continuación hay que compilar e instalar extundelete. Para ello:

cd extundelete-0.2.0
./configure
make

Ahora puedes ejecutar el comando extundelete que se ha generado en el directorio src

src/extundelete --help

Si quieres instalarlo para poder ejecutarlo como cualquier otro comando del sistema, es decir, escribiendo extundelete desde cualquier directorio, deberás ejecutar make install aunque no es necesario.

Puedes usar la opción --restore-file si tienes claro el fichero que has perdido, pero si son varios ficheros o es un directorio, creo que lo más cómodo es ejecutar lo siguiente:

src/extundelete /dev/sda2 --restore-all

donde /dev/sda2 es la partición donde se encuentran los ficheros eliminados.

Los ficheros recuperados se guardan en un directorio dentro del directorio actual llamado RECOVERED_FILES. Tan sólo tienes que entrar en ese directorio y ver si tus ficheros perdidos se encuentran entre los recuperados.

magicrescue


Este programa escanea byte a byte la partición deseada en busca de patrones de ficheros o, como dicen en su página, bytes mágicos. Los patrones o recetas son ficheros que están en un directorio, típicamente en /usr/share/magicrescue/recipes/ y son los siguientes:
  • avi
  • canon-cr2
  • elf
  • flac
  • gimp-xcf
  • gpl
  • gzip
  • jpeg-exif
  • jpeg-jfif
  • mp3-id3v1
  • mp3-id3v2
  • msoffice
  • nikon-raw
  • perl
  • png
  • ppm
  • zip
De esta forma, podemos indicarle al programa que busque sólo ciertos tipos de ficheros.

magicrescue lo podemos encontrar en los repositorios de muchas distribuciones linux. Por ejemplo, para instalarlo en Debian o Ubuntu basta ejecutar lo siguiente:

aptitude install magicrescue

Para lanzar una búsqueda debemos ejecutar:

magicrescue -d DESTINO_FICHEROS_RECUPERADOS -r /usr/share/magicrescue/recipes/RECETA DISPOSITIVO

Por ejemplo, si hemos perdido nuestras fotos de algún viaje, podemos indicarle la receta jpeg-exif, que es el formato en que suelen guardar las fotos las cámaras digitales:

magicrescue -d /root/recuperados -r /usr/share/magicrescue/recipes/jpeg-exif /dev/sda2

También podemos indicarle varias recetas repitiendo el parámetro -r, o indicarle todas las recetas disponibles si en lugar de un fichero de recetas concreto indicamos el directorio de recetas.

Este programa no recupera los directorios ni nombres de fichero originales, por lo que una vez ejecutada la instrucción de recuperación, tendremos que buscar nuestros ficheros en el directorio donde hemos almacenado los ficheros recuperados.

 

foremost

 

Es similar a magicrescue, pero trae recetas diferentes. Podemos descargarlo de su página oficial, pero al igual que magicrescue, podemos encontrarlo en los repositorios de muchas distribuciones linux. Por ejemplo, para instalarlo en Debian o Ubuntu:

aptitude install foremost

La sintaxis es similar a magicrescue aunque en lugar de trabajar con recetas, trabaja con tipos de archivos. Las opciones son:
  • jpg
  • gif
  • png
  • bmp
  • avi
  • exe
  • mpg
  • wav
  • riff
  • wmv
  • mov
  • pdf
  • ole
  • doc
  • zip
  • rar
  • htm
  • cpp

    foremost -o DESTINO_FICHEROS_RECUPERADOS -t TIPOS_SEPARADOS_POR_COMA -i DISPOSITIVO

    Por ejemplo, si queremos buscar imágenes jpg y png:

    foremost -o /root/recuperados -t jpg,png -i /dev/sda2

    Al igual que magicrescue tampoco recupera directorios ni nombres de ficheros.

    No volverá a ocurrir

     

    Por supuesto, llegados a este punto ya nos habremos repetido mil veces que esto no me puede volver a ocurrir, que tengo que hacer más copias,... A continuación expongo una serie de buenas prácticas que nos pueden ayudar a evitar este tipo de desastres:

    • Forzar a que los comandos peligrosos como rm, mv y cp pidan confirmación. Para ello tenemos que añadir en el .bashrc de los usuarios que utilicemos lo siguiente:
    alias rm='rm -i'
    alias cp='cp -i' 
    alias mv='mv -i' 
    • Nunca hacer borrados del tipo rm -rf * : normalmente esto lo hacemos para vaciar el contenido de un directorio y para ello previamente hemos hecho un cd DIRECTORIO , pero hay veces que o bien el ese cd no lo hemos hecho adecuadamente o simplemente no lo hemos hecho y con las prisas borramos lo que no deberíamos. Una alternativa a ese rm peligroso es hacer el borrado desde un directorio superior o con rutas absolutas, de forma que el wildcard no sea tan generico. Por ejemplo:
    rm -rf DIRECTORIO/*

    • Y no menos importante, pensar dos veces antes de pulsar Intro en los comandos peligrosos.

    Y por supuesto, tener backups más o menos actualizados de nuestra información sensible por si las buenas prácticas anteriores no han evitado el desastre.

    Espero que este post te haya sido de utilidad y que, si has borrado accidentalmente algún fichero importante, ahora puedas respirar tranquilo.

    ;-)

    sábado, 1 de enero de 2011

    Feliz año nuevo

    Con el primer post de 2011 me gustaría desear a todo el mundo un feliz 2011 y que, en cualquier caso, sea mejor que el 2010. Os dejo un popular villancico en su versión más metal: