Me resisto a pensar que la anunciada desaparición de Google Reader puede significar en modo alguno que los feeds RSS están tocados de muerte. Google Reader es ahora un buen lector de feeds, pero no siempre ha sido así (¡hasta finales de 2007 ni siquiera integraba un buscador!) y sobrevivíamos. Por otro lado, sin los lectores de feeds estamos abocados a compartirlo todo y estar al tanto de los temas que nos interesan a través de las redes sociales o volviendo a las listas de correo… Y, sinceramente, no veo nada claro que (sobre todo los usuarios técnicos) nos resignemos a ello. Y no, por favor, no. Twitter tampoco sirve para estar al día de casi nada de forma seria.

Si estás conmigo y buscas un sustituto lo más parecido a Google Reader los “gurús”, “expertos” (y, si, también alguna persona maja y corriente ) ya han hecho listas y valoraciones y casi todos coinciden en que los mejores reemplazos son feedly o The Old Reader. No hay consenso claro por ninguno de ellos, así que seguramente cualquiera de ambos sea una buena elección. Una segunda opción sería cambiar a un lector de escritorio. De estos los hay a patadas pero ya imaginarás que no son la mejor opción cuando lees tus feeds a ratos desde diferentes ubicaciones. Más si además usas un dispositivo móvil. Puesto que la lectura por RSS es algo propio de usuarios medios y/o avanzados no creo que se trate de una buena opción…

Pero si dispones de un servidor web visible en internet y algo de tiempo para dedicarle, tienes una tercera posibilidad: montarte tu propio lector auto-hospedado y no volver a depender de nadie. En este caso, también parece haber dos opciones bastante claras: Tiny Tiny RSS y Selfoss. Yo me he decidido por el primero. Selfoss tiene un aspecto más moderno pero en el escaso tiempo que he dedicado a evaluarlos me ha parecido que Tiny Tiny es más ligero y potente.

La instalación de Tiny Tiny RSS (tt-rss en adelante) es muy sencilla (como la de la gran mayoría de aplicaciones LAMP) pero no tanto como alguna de las más populares nos tienen acostumbrados

¿Buscas una aplicación adaptada a la pantalla de 4 pulgadas de tú móvil? Casi no te hace falta. tt-rss viene con un plugin que lo adapta perfectamente con sólo activarlo:

O una aplicación web que se instala por separado:

Si buscas una aplicación nativa para android, tienes esta del propio autor (con una versión gratuita de evaluación) que luce así:

Existe, también, un fork gratuito de la anterior.

En cuanto a funcionalidades, tt-rss tiene todo lo que usabas con Google Reader y más gracias a sus funcionalidades base (perfiles de usuario, etiquetado, marcación y búsquedas, filtros…) y a una amplia colección de plugins, muchos de los cuales están soportados y vienen “de serie” con la aplicación. Otros puedes instalarlos de forma individual descargándotelos desde el foro o la wiki que mantiene el autor.

Y si buscas características sociales, aparte de los plugins que te permiten compartir entradas de forma directa en las principales redes sociales (Facebook, Google+, Twitter, Identi.ca…) tienes uno que te permite “linkar” instancias de diferentes usuarios para compartir recomendaciones o la posibilidad de obtener un feed público de cualquiera de las categorías que lees o, incluso, de una selección hecha de forma manual o mediante un filtrado automático.

Total que, a lo mejor, Google nos ha hecho un favor chapando su Reader. A mi, al menos, parece que así ha sido

Como ya habíamos hablado por aquí, uno de los parámetros críticos en un servidor Apache es MaxClients, el número máximo de conexiones que es capaz de manejar simultaneamente. Es crítico porque cada tarea de Apache consume una determinada cantidad de memoria y si la suma de la memoria que consumen todos de forma simultanea es mayor que la memoria RAM que la máquina tiene libre comenzará a hacer swapping a disco y, si esta situación se mantiene, corremos un riesgo importante de que se nos quede virtualmente congelada. Una instalación de Apache por defecto toma un valor de 150 para este parámetro y esto es una verdadera burrada para casi cualquier servidor web con menos de 1 Gbytes (o incluso con bastante mas) que use contenidos dinámicos medianamente pesados.

Hace bien poco, buscando por ahí algún enlace para profundizar un poco más en estos temas, me encontré con este artículo de una empresa de hosting donde te proponen un script para ajustar el valor más adecuado a tus necesidades. Había dos cosas que no me gustaban en él script propuesto. Por un lado, tomaban el valor más conservador, es decir, el resultante de dividir la memoria libre entre lo que ocupa el proceso de Apache mayor. En segundo lugar, hacen el cálculo de la memoria libre sin tener en cuenta la que está ocupada por cache o buffers y que podría liberarse en caso de necesidad. Yo le he hecho algunos cambios para salvar ambos puntos y dejarlo un poco más bonito e informativo y me ha salido esto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#!/bin/bash
clear
 
# Primero analizamos los procesos de apache funcionando actualmente
LISTA=`ps -aylC apache2 |grep apache2 |awk '{print $8'} |sort -n`
 
echo "Lista ordenada de la memoria, en bytes, ocupada por los procesos de Apache corriendo en este momento:"
COUNT=0
SUMA=0
for ITEM in $LISTA
do
        COUNT=`expr $COUNT + 1`
        SUMA=`expr $SUMA + $ITEM`
        echo "$COUNT -> $ITEM"
        if [ $COUNT -eq 1 ]
        then
                MENOR=$ITEM
        fi
done
 
MAYOR=$ITEM
MEDIA=`expr $SUMA / $COUNT`
 
# Pasamos las cantidades a Kbytes
MENOR=`expr $MENOR / 1024`
MAYOR=`expr $MAYOR / 1024`
MEDIA=`expr $MEDIA / 1024`
 
echo "El proceso de Apache más grande ocupa" $MAYOR "Kbytes y el menor" $MENOR "Kbytes"
echo "La media de la memoria ocupada por un proceso es de $MEDIA Kbytes"
 
echo "Detenemos Apache..."
apache2ctl graceful-stop > /dev/null
 
# Limpiamos los caches y buffers del servidor
sync
echo 3 > /proc/sys/vm/drop_caches
 
# Calculamos la memoria libre del sistema
FREEMEM=`free -m |head -n 2 |tail -n 1 |awk '{free=($4); print free}'`
echo "La memoria libre del servidor, después de liberar cache y buffers, es de $FREEMEM Kbytes"
 
echo "Arrancamos Apache de nuevo..."
apache2ctl start > /dev/null
 
echo "MaxClients debería de estar entre" `expr $FREEMEM / $MAYOR` "y" `expr $FREEMEM / $MENOR`
echo "Usando el valor medio de la memoria ocupada, un valor recomendable de MaxClients sería de" `expr $FREEMEM / $MEDIA`

El script de aquí arriba imprime una lista de la memoria ocupada por todos procesos de Apache activos en el momento de ejecutarlo. Luego toma el mayor, el menor y la media de todos ellos y calcula la memoria libre del sistema. Para ello, antes detiene Apache (con un graceful-stop para no fastidiar a nadie que esté viendo nuestra web en ese momento) y libera los buffers y caches de memoria. Por último, arranca de nuevo Apache y nos da como salida dos valores: una horquilla entre el valor que debería de tomar MaxClient usando el menor y el mayor valor de los procesos tomados en la instantánea anterior y un valor recomendado que sale de usar el valor medio de todos ellos.

Evidentemente no se trata de algo matemático. Como es lógico, ejecutado en diferentes momentos obtendremos valores distintos ya que ni la RAM que usa nuestro servidor es inmutable ni el tamaño de los procesos de Apache es siempre el mismo ni siguen la misma distribución. Pero para darnos una primera idea del valor con el que tenemos que empezar a jugar creo que es bastante válido. Ya me contáis.

NOTA: En algunas instantáneas el valor de memoria ocupado por el proceso más pequeño de Apache puede ser cero, seguramente porque o está creándose o está destruyéndose en ese momento. En ese caso el valor de la horquilla pierde uno de sus extremos. Sería muy fácil modificar el script para que en ese caso tome el segundo valor y divida por un elemento menos, pero ocurre en tan pocas ocasiones que no creo que merezca la pena hacerlo. Al menos no hoy

La instalación más sencilla (y, me atrevería a decir, más frecuente que he tenido que realizar) que suele hacerse con Cacti es aquella que se se usa para monitorizar los recursos de un único host (típicamente un servidor dedicado o VPS en una empresa de hosting) en el que el propio Cacti se encuentra instalado de forma local.

Cacti necesita para funcionar un servidor web (apache2, por ejemplo) con php, una base de datos de mysql-server, las rrdtools y snmp (cliente y agente). Seguramente tendremos ya instalados apache2 y mysql-server y, si no, añade los paquetes apache2, php5 y mysql-server al comando siguiente:

1

sudo apt-get install cacti snmp snmpd rrdtool

Durante la instalación se nos pedirá si queremos configurar de forma automática la base de datos que necesita cacti (en caso afirmativo, se nos pedirá la contraseña de root de mysql-server para crear dicha base de datos y un usuario de acceso a la misma) y el servidor web que usaremos (apache2 en nuestro caso).

Una vez concluida la instalación podremos acceder a Cacti con la URL http://ip_o_nombre_del_servidor/cacti. En el primer acceso se ejecutará un asistente en el que se nos pedirá aceptar la licencia de uso, decidiremos el tipo de instalación (nueva o actualización de una versión anterior) y se realizará un chequeo de dependencias:

Una vez cumplimentado esto se nos redirecciona a la ventana de login. El usuario inicial es admin y su password la misma. Inmediatamente después de realizar el primer login se nos forzará a cambiar esta password, así que tenla pensada de antemano

Cacti está ya funcionando y recogiendo datos de forma automática del servidor en el que se encuentra instalado. Si lo dejamos unos minutos para que le de tiempo a recoger algunos y pulsamos sobre la solapa de gráficos (arriba a la izquierda) veremos que ya tenemos gráficas (no tan completas como estas que llevan ya más de 24 horas, claro) de carga de la CPU, ocupación de memoria, número de procesos y número de usuarios conectados.

Para monitorizar el tráfico de red es preciso “tirar” de snmp. Lo primero que tenemos que hacer es configurar el daemon de snmp para que Cacti pueda leer de él. Para ello editamos el fichero /etc/snmp/snmpd.conf y quitamos el comentario que deshabilita la siguiente línea:

1

rocommunity public localhost

Reiniciamos el servicio (sudo service snmpd restart) y volvemos a Cacti para configurar la nueva gráfica. Para ello entramos en la opción Devices del menú de la izquierda, pulsamos sobre la entrada de localhost (la única que tendremos) y, en la ficha resultante, editamos el campo destacado en la imagen de aquí abajo (el correspondiente a la versión de SNMP que aparecerá como Not in Use) y luego pulsamos el botón de Save. Si todo ha salido bien y Cacti es capaz de contactar con el demonio SNMP de nuestro equipo, arriba a la izquierda aparecerán las líneas de información que también puedes ver resaltadas en este gráfico:

En la parte inferior de esta misma ficha de datos, en el bloque de “Associated Data Queries” debería de aparecer ahora una línea etiquetada como “SNMP – Interface Statistics” (a la derecha de “Add Data Query”). La seleccionamos, pulsamos el botón de Add y, a continuación, el de Save.

Bien, ahora volvemos a la parte superior de la página y pulsamos en el enlace de “Create Graphs for this Host”. En la página que nos aparece marcamos los interfaces de red cuyo tráfico queremos monitorizar y, ya que estamos, las unidades de disco cuya ocupación queremos controlar (eth0 y sda1, respectivamente, en el ejemplo aquí abajo). Bajo las líneas correspondientes a los interfaces de red tenemos, como puedes ver, un selector que nos permite elegir entre diferentes tipos de gráficos. A mi particularmente la que aparece por defecto (In/Out bits) es la que me parece más cómoda pero, ya sabéis, para gustos…

Pulsamos Create y listo. Los datos se empezarán a tomar inmediatamente y, a los pocos minutos, si volvemos a entrar en la solapa de Gráficos tendremos ya las primeras muestras disponibles. Después de 24 horas tus nuevas gráficas de tráfico de red y de ocupación de disco lucirán como estas:

El siguiente gráfico que añadiremos será el de activida de lectura y escritura en discos, muy interesante sobre todo para monitorizar la actividad de nuestro disco de swap y detectar si la máquina está corta de memoria. También es el que más “trabajo” nos va a dar para ponerlo en marcha, así que atención.

Lo primero que necesitas es descargarte y descomprimir este fichero (extraído de este hilo del foro de Cacti que es de donde he sacado las instrucciones que te voy a contar) donde encontraras dos archivos con extensión XML. El que se llama net-snmp_devio.xml tienes que copiarlo al directorio /usr/share/cacti/site/resource/snmp_queries/ de la máquina. El otro, llamado cacti_data_query_ucdnet_device_io.xml, tienes que importarlo desde la opción “Import Template” que aparece en el menú de la izquierda.

Si el resultado es correcto veremos algo como esto:

Ahora volvemos a la opción de Devices, volvemos a seleccionar localhost y en la parte inferior, en el mismo bloque de “Associated Data Queries”. ahora nos aparecerá una nueva línea etiquetada como “ucd/net – Device I/O” que debemos de seleccionar y, luego, pulsar el botón de Add y salvar los cambios.

Volvemos a pulsar ahora en el enlace de “Create Graphs for this Host” y en el nuevo bloque que nos aparece seleccionamos las líneas correspondientes a los discos cuya actividad queremos seguir. En el ejemplo de aquí abajo se han seleccionado sda1 (la partición donde reside el sistema) y sdb (el disco de swap).

Cambiamos al pie del bloque el tipo de gráfico si así lo deseamos y pulsamos el botón de Create. Listo:

Y para terminar, un pantallazo con todos los gráficos de monitorización que tenemos ahora en nuestro servidor tras configurar sus dimensiones para que puedan verse cómodamente con un sólo vistazo (pulsa sobre él para verlo ampliado):

Y otra receta simplota de comandos útiles para hacer modificaciones sencillas a un vídeo. Cuando queremos rotar un vídeo (ya sabéis, aquello de que habéis cogido la cámara en vertical y ahora cada vez que queréis ver al niño hacer sus monerías cogéis tortícolis) podemos usar mencoder. El comando base es el siguiente:

1

mencoder -vf rotate=1 -oac copy -ovc lavc original.avi -o resultado.avi

El tipo de rotación se selecciona con el argumento -vf rotate=1. El anterior gira el vídeo 90 grados en el sentido de las agujas del reloj, mientras que si lo sustituimos por -vf rotate=2 lo hará en sentido antihorario. Mediante el argumento -oac copy definimos como se trasladará el audio del vídeo y con -ovc lavc especificamos el tipo de codec que usaremos en el vídeo final. Podemos ver las opciones disponibles que tenemos en nuestro sistema mediante el siguiente comando:

1

mencoder -oac help -ovc help

La opción copy siempre está disponible pero no funcionará con el argumento -ovc (¡si copiamos el original no rotamos!) y algunas de las opciones disponibles puede que nos obliguen a especificar parámetros adicionales (bitrate, fixed_quant, pass, etc.).

Por último, original.avi es el nombre del vídeo a rotar y con el argumento -o resultado.avi definimos como se llamará el vídeo resultante.

Si queremos instalar xampp en Chakra Linux nos encontramos con que esta distribución sólo está disponible ya para 64 bits mientras que xampp se distribuye en forma de script sólo para sistemas de 32 bits. La solución pasa, sencillamente, por instalar unas librerías de compatibilidad y listo. Manos a la obra, pues. En un primer paso sustituimos las gcc-libs por las gcc-libs-multilib:

1

sudo pacman -S gcc-libs-multilib

Luego, tenemos dos opciones, descargar e instalar xampp siguiendo sus instrucciones como haríamos normalmente o usar el paquete ccr disponible (aunque ligeramente desactualizado):

1

ccr -S xampp

En cualquiera de ambos casos, xampp se instalará en el directorio acostumbrado (/opt/lampp) y responderá a los comandos y opciones habituales.

NOTA: Siempre que he realizado operaciones de este tipo y he instalado versiones de librerías de 32 bits en distribuciones de 64 (concretamente en Ubuntu y Fedora) luego, en algún momento, he tenido problemas de dependencias no resueltas a la hora de realizar alguna instalación y/o actualización. Aunque de momento no he tenido ningún problema similar con Chakra no llevo suficiente tiempo con esta distribucion como para asegurar que esto esté mejor resuelto.

memcached es uno de los sistemas de caché para servidores web más usado. Usa una zona de la memoria RAM del servidor web de tamaño configurable como caché y funciona bien tanto en sitios pequeños y discretos como en grandes sistemas con múltiples servidores. Facebook, Twitter o Youtube, por ejemplo, usan este sistema de cacheado. El 85% de los 20 sitios con más tráfico de Internet lo usan, en realidad. Nada mejor, pues, para estrenar una pequeña sección acerca de sistemas y extensiones de cacheado para apache ¿no?

Partimos para la instalación de una Debian en la que ya tenemos un servidor web apache y la versión 5 de php (paquetes apache2 y php5). Para instalar memcached en una Debian he tenido que recurrir a usar “paquetería” de wheezy (testing) porque parece que hay algún problema de dependencias en la versión estable (squeeze) y la librería de extensión para trabajar con PHP no compilaba correctamente. Así que manos a la obra. El primer paso es instalar el servidor de memcached:

1

apt-get install memcached

El servicio se instala, como es habitual, en el directorio /etc/init.d y responde a los argumentos start, stop, restart, force-reload y status. En el directorio /usr/share/memcached/scripts existe un script llamado start-memcached que es el encargado de realizar el inicio automático y que toma la configuración del archivo memcached.conf en el directorio /etc. Dentro de este fichero de configuración una de las opciones más interesantes es la que dice a memcached cuanta RAM va a usar como caché. Por defecto son 64M, pero en sistemas con muy poca RAM tal vez nos convenga bajarlo. Mi VPS tiene sólo 512M de RAM y yo he bajado esos 64M a la mitad. Para ello basta con cambiar la línea -m 64 por -m 32 y reiniciar el servicio.

Otra de las opciones interesantes en ese archivo de configuración es la posibilidad de habilitar un archivo de logs que, por defecto, viene deshabilitado. Para ello basta con quitar el comentario a una de las dos opciones que aparecen el el fichero según el nivel de detalle que queramos: -v o -vv. El log se grabará en el fichero /var/log/memcached.log. Esto también es configurable modificando la línea que aparece en el mismo fichero. Y no olvides que para que la opción tome efecto haz de reiniciar de nuevo el servicio de memcached.

El segundo paso sería instalar la extensión de memcached para PHP. Para ello tenemos que instalar los siguientes paquetes:

1

apt-get install php-pear php5-dev php5-memcached libmemcached10 libmemcached-dev libmemcachedutil2 libhashkit2 libhashkit-dev

Y, a continuación, ejecutar lo siguiente:

1

pecl install memcached

Si todo sale bien, al final del proceso se nos mostrará un mensaje similar a este:

La librería debería de haberse creado en el directorio de extensiones de php que se indica al final del proceso y que puedes ver en la imagen anterior (/usr/lib/php5/20100525+lfs) y ya sólo nos resta hacerle caso al mensaje final y añadir la línea extension=memcached.so al final de nuestro fichero php.ini que debería de estar en el directorio /etc/php5/apache2. Reiniciamos apache y, si ejecutamos la función phpinfo veremos una nueva sección:

Para ver información acerca de como está funcionando nuestra cache tenemos un par de opciones más atractivas que inspeccionar el fichero de log que hemos mencionado antes. Una de ellas es usar el script memcached-tools que encontraremos en el directorio /usr/share/memcached/scripts/.

1

/usr/share/memcached/scripts/memcached-tool 127.0.0.1:11211

El comando anterior muestra información sobre el estado del servicio memcached que hemos instalado en nuestra máquina. Añadiendo al final el argumento stats nos mostrará estadísticas de uso y con el argumento dump realizará un volcado del contenido de la caché por pantalla.

La segunda opción que tenemos es bajarnos de aquí un script hecho en perl y llamado memcache-top. Tienes distintos argumentos para modificar la salida que puedes consultar en la web desde la que te has bajado el script. En la imagen siguiente se muestra con las opciones --cumulative y --commands

Y ya sólo nos queda habilitar el uso de memcached desde wordpress. Para ello usaremos Memcached Object Cache que, aunque aparece como cualquier otro en el repositorio de plugins de wordpress, en realidad precisa de una sencilla instalación manual para que funcione. Bajamos el archivo, lo descomprimimos y copiamos el archivo object-cache.php en el directorio wp-content de nuestra instancia de wordpress.

phpSysInfo es un script escrito en PHP que muestra información acerca del sistema en el que corre. Es bastante ligero y extensible mediante la programación de plugins. Tienes una demo real bastante completa aquí, mucha información en las páginas del proyecto en sourceforge y hasta un cliente para tu android.

Las instalación es tan sencilla como descomprimir y copiar los ficheros del proyecto en un virtual host de tu apache, renombrar el ejemplo del archivo de configuración (de phpsysinfo.ini.new a phpsysinfo.ini) y editarlo siguiendo las indicaciones de los comentarios que lo acompañan.

Una de las primeras cosas que un administrador de sistemas (de “los de verdad”, no de los que trabajan con Windows, que a esos no les sirve de nada ) se plantea instalarse en su android es, si o si, un emulador de terminal. ConnectBot admite conexiones ssh y telnet (o locales contra el propio android donde está instalado). Ocupa muy poca memoria (apenas 650KBytes con los datos de conexión de varias máquinas) y aprovecha muy bien la pantalla tanto en vertical como en apaisado. Ambas cosas son indispensables para quién, como yo, tiene un terminal barato de gama baja. Es capaz de mantener varias sesiones abiertas de forma simultanea con diferentes máquinas y soporta copy/paste. Además, es software libre y los fuentes están disponibles en Google Code.

• ConnectBot en Google Play
• ConnectBot en Google Code

Me gusta la línea de comandos, ya lo sabéis. Pero no se me caen los anillos por decir que hay dos tipos de configuraciones que evito hacer “a pelo” siempre que puedo por complicadas y tediosas: las de iptables y las de Asterisk. Para cualquiera de ambas prefiero utilizar algún tipo de herramienta que automatice y simplifique la tarea desde un interface gráfico guiado. En el caso de Asterisk, el panorama ha cambiado muchísimo en los últimos cuatro años. Por aquel entonces Trixbox era la reina absoluta e indiscutible y AsteriskNOW una prometedora aspirante pero, a mi juicio, demasiado verde para llevarla a una instalación en producción. ¿Cómo está esto ahora?

A la hora de plantear hoy en día una instalación cómoda con Asterisk existen cuatro opciones bastante interesantes a considerar y Trixbox es, a pesar de su veteranía, la última que yo escogería. Todas ellas están basadas en la rama 5.x de CentOS y usan FreePBX (o un fork de este, en el caso de Trixbox) como interface para la configuración. Vamos a echarles un vistazo rápido a cada una de ellas:

Trixbox

Como ya adelantaba, la antaño bien valorada Trixbox no es ahora ni una sombra de lo que era. Hace casi dos años que la version comunitaria no se actualiza (posee una versión Pro de pago que tampoco parece estar mucho mejor atendida) y la impresión tras la instalación es nefasta: problemas de dependencias al actualizar los cerca de 199 Mbytes de paquetes obsoletos, ninguna indicación clara acerca del usuario/password de administración inicial (maint/admin, por si google trae a alguién aquí buscándo esto ) y versiones muy, muy obsoletas de Asterisk y de Dahdi (la librería de drivers para tarjetas Digium VoIP que sustituyó hace algunos años a Zaptel). Como también adelantaba, desde hace años no usa ya freePBX como GUI de configuración de Asterisk, sino un fork de esta que, intuyo, llevará al menos los mismos dos años sin actualizar que su última distro. Lo dicho: no te deja buen sabor de boca como para usarla en un sistema en producción.

AsteriskNOW

AsteriskNOW ha mejorado mucho durante estos años. Ya de entrada ha abandonado su planteamiento inicial basado en el sistema de gestión de paquetes rpath + conary y ahora es ya una distro mucho más asequible basada en CentOS. Durante la instalación inicial realiza una actualización automática de forma que tras el primer arranque no hay ningún paquete desactualizado. En la parte negativa, el menú principal en javascirpt no parece estar bien resuelto como puedes ver en el pantallazo de aquí arriba y tiene toda la pinta de que a alguien se le ha olvidado meter unas hojas de estilo en la última compilación de la distro, puesto que se trata del aspecto normal y sin ninguna personalización de FreePBX (como veremos más adelante). El correcto, según se ve en sus tutoriales, debería de ser así:

Sorprende, además, que siendo la distribución “oficial” de Digium no sea la que tenga las versiones más actualizadas de Dahdi y libpri, los dos pilares fundamentales de Asterisk.

FreePBX Distro

Las Distribución propia de FreePBX tiene un aspecto inmejorable: una instalación limpia y fácil tras la cual apenas hay que actualizar 138kbytes y lo que parece ser un estupendo soporte tras ella: viene con las versiones más actuales de Dahdi y de libpri (por supuesto también de Asterisk y de FreePBX), y en las dos semanas que he estado haciendo pruebas con ella ha lanzado una nueva versión estable (la 1.812) y una beta (la 1.1004). Por decir algo negativo de ella, se echa de menos el panel de operadora que viene de serie con Trixbox. Su propuesta es usar iSymphony, un módulo externo para FreePBX con una versión reducida gratuita pero que hay que instalar de forma adicional.

Elastix

Si te gustan las cosas minimalistas, ciertamente esta no es tu opción. Ahora bien, si tienes un jefe impresionable por las primeras apariencias y quieres ganártelo, ni lo dudes. Elastix va más alla de ser un mero servidor VoIP destinado a hacer de centralita: es un completo centro de comunicaciones con servidor de correo imap, servicio de webmail, servidor de fax, mensajería instantanea, etc. Su problema, a mi juicio, es que en ningún momento de la instalación básica se te permite elegir que servicios quieres y cuales no y, o bien cargas con todos, o te toca posteriormente parar servicios, desinstalar paquetes, etc. La última versión, la 2.3.0, es de hace apenas un mes pero tras la instalación inicial es preciso hacer una actualización que “pesa” cerca de 250Mbytes.

NOTA: para ver las versiones que tienes instaladas de asterisk, dahdi y libpri puedes usar los siguientes comandos (el último sólo funciona en un Linux basado en paquetes rpm como es CentOS):

1
2
3

asterisk -v
dahdi_cfg -vv
rpm -qa | grep libpri

Hace algo más de dos años que la gente de KDE anunció un proyecto llamado ownCloud, un sistema de copia y sincronización de archivos “en la nube” basado en un servicio LAMP en la parte del servidor y el uso de csync en la parte del cliente. El resultado es que cualquiera pueda montarse su propio servicio de sincronización de ficheros similar a Dropbox o SugarSync, pero sin restricciones de espacio y/o tráfico (más allá de lo que le permita su propio servidor o su servicio de hosting) y sin plantearse dilemas de privacidad. El desarrollo ha sido muy rápido (hace dos meses que vió la luz la versión 3 del servidor y la 1 del principal cliente) y realmente, merece la pena probarlo y echarle un vistazo.

El aspecto realmente “potente” de ownCloud es montar tu propio servicio, pero si no tienes medios o prefieres empezar por evaluar si te gusta de forma sencilla, puedes hacerlo a través de algún proveedor externo, que ya los hay. Existen servicios de pago y otros que, al igual que Dropbox y similares, ofrecen una modalidad de entrada gratuita y opciones adicionales por las que hay que pagar (freemiun que lo llaman por ahí). Owncube ofrece cinco Gbytes de espacio gratuito y GetFreeCloud, ofrece seis. Yo te aconsejo que empieces por Owncube puesto que ha actualizado ya su versión a la 3.0.2 y hasta la anterior, la 3.0.1 que es la usada en GetFreeCloud, existen un par de vulnerabilidades que pueden aprovecharse fácilmente a través de Metasploit. (Ver ACTUALIZACIÓN (y II))

Crear una cuenta en cualquiera de ambos servicios es fácil: nombre, contraseña, correo electrónico y listo. Sólo con eso ya tienes un servicio de almacenamiento con un cómodo interfaz web.

Pero si realmente le quieres sacar partido a la sincronización automática de archivos entre tu equipo y el servidor y/o entre distintos equipos, necesitas instalarte un software cliente. En el anterior enlace tienes los binarios disponibles para Windows y las principales distribuciones de Linux. Los de Mac y Android (Ver ACTUALIZACIÓN) aún están en fase de desarrollo y no están disponibles. Para distribuciones “marginales” de Linux tienes los fuentes y detalladas instrucciones de compilación, aunque imagino que la mayoría de ellas tendrán ya listos paquetes más o menos oficiales. Yo estoy usando Chakra en estos momentos (y muy contento, ya os hablaré de ello en otra ocasión) y el pkgbuild correspondiente está disponible aquí.

Una vez instalado tenemos un icono disponible en la bandeja del sistema con un menú contextual bien sencillo: La opción de Configurar nos permite cambiar los datos de conexión con el servidor de sincronización y la opción de Add Folder nos permite añadir un nuevo directorio al servicio. Luego tenemos una entrada por cada directorio que se está sincronizando que nos abre directamente el administrador de archivos por defecto en dicho directorio local y la opción de cerrar el servicio (Quit). Si pulsamos con el botón izquierdo sobre el icono, en lugar de este menú se nos abrirá una ventana con información sobre el estado de sincronización de los directorios y la posibilidad de elmininarlos (del servicio, no de borrarlos), añadir nuevos, parar temporalmente el servicio en uno de ellos o volver a reanudarlo, etc.

En la funcionalidad de “añadir directorios” es donde, quizás, se aprecia mejor la diferencia en la filosofía de uso frente a Dropbox que, tal vez, es su competidor más popular. Aquí no existe un único directorio de sincronización sino que los añadimos de forma individual aunque estos se encuentre en diferentes sitios de nuestro sistema de archivos. En Dropbox solemos resolver este asunto (al menos desde Linux) mediante enlaces simbólicos pero este método es bastante más flexible y cómodo. Además, podemos realizar la sincronización de un directorio en particular no sólo contra el servidor que hemos configurado “en la nube” sino contra otro directorio local o contra cualquier otra URL donde, lógicamente, debemos de tener acceso de escritura. Esto nos abre 1001 posibilidades de salvaguarda de nuestros datos.

Volviendo al interfaz web, este tiene algunos “complementos” bastante útiles que podemos apreciar en el menú de enlaces a la izquierda: bookmarks, calendarios, contactos y dos entradas llamadas Música y Galería donde, automáticamente y de forma similar a como hace Android, se recopilan entradas a este tipo de archivos independientemente del directorio donde se encuentren. Ah, y en la opción de música tenemos un reproductor y todo

No he encontrado forma de sincronizar el calendario o los bookmarks con otros servicios externos y los contactos deberían de poder sincronizarse con los de GMail a través de una opción existente en el menú de Ajustes (la rueda dentada que aparece en la parte inferior izquierda) pero no he logrado hacer que funcione.

Para los amigos de la línea de comando, existe un cliente de administración opcional para la consola llamado owncloud-admin. Los ficheros de configuración, al menos en mi distribución, se guardan en el directorio $HOME/.local/share/data/ownCloud/ Allí nos llevaremos la desagradable sorpresa de que el usuario y la contraseña de nuestro servidor de sincronización se guardan en claro dentro del fichero owncloud.cfg. En la instalación del cliente se nos pregunta si queremos que esta no se guarde y se nos pregunte en cada arranque pero, vaya, sería deseable una mayor integración con kwallet, el servicio de gestión de contraseñas propio de KDE.

Está claro que el desarrollo tiene aún muchos detalles por pulir y mejorar. He tenido problemas durante las pruebas con supuestos desajustes horarios entre cliente y servidor (que se han solucionado eliminando el servicio de sincronización y volviéndolo a crear, luego se trata de otra cosa…) y echo de menos que sincronice el contenido de enlaces simbólicos en el equipo local (cosa que no hace). Se echan de menos, además, opciones disponibles en Dropbox desde hace tiempo (como, por ejemplo, la recuperación de versiones anteriores de un archivo). También sería deseable que, ya puestos, pudiéramos sincronizar distintas carpetas contra diferentes servidores de owncloud. Y, desde luego, los clientes móviles deberían de estar disponibles pronto si quieren que el servicio entre a competir con los grandes. Pero de entrada, y a mi juicio, tiene muchas posibilidades y se trata del primer servicio de este tipo verdaderamente libre (y no como Ubuntu One). OpenSuse está particularmente involucrado en sacarlo adelante, asi que esperemos que seguirá evolucionando de forma rápida.

Pronto y en otra entrada, contaremos como puedes montarte tu propio servicio servidor de owncloud.

ACTUALIZACIÓN: Uppps! A los pocos minutos de escribir esto me entero de que ya está disponible el cliente para Android.

ACTUALIZACIÓN (y II): En getfreecloud.com han actualizado ya a la versión 3.03 de la versión servidor de owncloud, así que ya no hay problemas de vulnerabilidades conocidas.