Autenticación en Apache: básica y PAM

apache El servidor web Apache puede acompañarse de distintos módulos para proporcionar diferentes modelos de autenticación. Hoy vamos a echarle un vistazo a la configuración básica de dos de los más utilizados y sencillotes. Vamos allá.

La primera forma que veremos es la más simple. Usamos para ello el módulo de autenticación básica que viene instalada “de serie” con cualquier Apache. La configuración que tenemos que añadir en el fichero de definición del Virtual Host a proteger podría ser algo así:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthUserFile "/etc/apache2/claves/passwd.txt"
     AuthName "Palabra de paso"
     AuthType Basic
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

La información a personalizar está marcada en negritas. En Directory escribimos el directorio a proteger, que puede ser el raíz de nuestro Virtual Host o un directorio interior a este. En AuthUserFile ponemos el fichero que guardará la información de usuarios y contraseñas que debería de estar, como en este ejemplo, en un directorio que no sea visitable desde nuestro Apache. Ahora comentaremos la forma de generarlo. Por último, en AutnName personalizamos el mensaje que aparecerá en la ventana del navegador que nos pedirá la contraseña. Existen otras directivas adicionales o modificaciones a estas útiles para personalizar el acceso: AuthGroupFile, Require user, Require group, etc. Ya sabéis: Google es vuestro amigo 😉

El fichero de contraseñas se genera mediante la utilidad htpasswd. Su sintaxis es bien sencilla. Para añadir un nuevo usuario al fichero operamos así:

# htpasswd /etc/apache2/claves/passwd.txt carolina
New password:
Re-type new password:
Adding password for user carolina

Para crear el fichero de contraseñas con la introducción del primer usuario tenemos que añadir la opción -c (create) al comando anterior. Si por error la seguimos usando al incorporar nuevos usuarios borraremos todos los anteriores, así que cuidado con esto. Las contraseñas, como podemos ver a continuación, no se guardan en claro. Lo que se almacena es el resultado de aplicar una función hash.

josemaria:rOUetcAKYaliE
carolina:hmO6V4bM8KLdw
alberto:9RjyKKYK.xyhk

Para denegar el acceso a algún usuario basta con que borremos la línea correspondiente al mismo. No es necesario que le pidamos a Apache que vuelva a leer su configuración (/etc/init.d/apache2 reload) cada vez que hagamos algún cambio en este fichero de contraseñas, pero si lo es después de hacer los cambios en el fichero de definición del Virtual Host.

autenticación en apache La principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear una instancia Apache con SSL.

El segundo método que vamos a tocar usa PAM, el propio sistema de autenticación de la máquina donde está instalado nuestro servidor de Apache. Si ya tenemos alguna herramienta de gestión de usuarios y contraseñas en la misma este sistema nos ahora el engorro de tener que generar otro tipo de usuario. En caso contrario no ganamos mucho en este sentido y seguimos teniendo el problema de que las contraseñas viajan en claro con el agravante adicional de que ahora se trata de usuarios de la máquina… así que ya sabéis: o configuráis ssl o usáis el truco que comentamos el otro día por aquí para deshabilitar la conexión remota.

Usaremos para ello el módulo mod_auth_pam y lo primero que tenemos que hacer es instalarlo:

# sudo apt-get install libapache2-mod-auth-pam

En el fichero de configuración del Virtual Host tendríamos que incluir algo así:

<Directory "/var/www/privado">
     AuthType Basic
     AuthName "Palabra de paso"
     AuthPAM_Enabled On
     AuthBasicAuthoritative Off
     AuthUserFile /dev/null
     Require user josemaria gemma fernando araceli
</code>

Si en este caso la directiva usada fuese Require valid-user se permitiría el acceso a cualquier usuario con cuenta en la máquina. Ah, y no olvides hacer un reload de apache después de este cambio.

Sólo nos quedan un par de pasos. Primero, añadir el usuario www-data (el que usa apache) al grupo shadow para que pueda verificar las contraseñas:

usermod -a -G shadow www-data

Y dos, hacer un enlace como el que sigue. Ignoro la causa, pero el motivo de que esto sea necesario es debido a que apache (en los binarios de Debian y Ubuntu, al menos) pretende leer del archivo /etc/pam.d/http mientras que el módulo de autenticación ha creado el archvo /etc/pam.d/apache2. El módulo auth_pam hace años que no está soportado e imagino que esto tiene algo que ver, pero no lo se a ciencia cierta. Simplemente lo leí por ahí...

ln -s /etc/pam.d/apache2 /etc/pam.d/httpd

Y con esto está todo listo. No lo he probado nunca pero también he leído que la autenticación se hace contra el directorio activo si Apache está instalado en una máquina windows configurada en un dominio. Existe también un módulo para autenticar contra un ldap (mod_auth_ldap) que si que he probado y que ya veremos otro día 😉

Instalar un servidor de correo IMAP en Linux

correo Hoy vamos a dejar por aquí un paso a paso para montar un servidor de correo de la forma más sencilla posible y con acceso a través de IMAP y de webmail. Partimos, para ello, de un servidor Debian recien instalado y disponemos de un dominio y de un servicio desde el que gestionar los registros de nuestro DNS. Para la instalación usaremos Postfix como SMTP, Dovecot como servidor IMAP y Squirrel como servicio de Webmail.

Lo primero que debemos de hacer es planificar los nombres que necesitamos dar de alta en el DNS para hacerlo cuanto antes y dar tiempo a que se propaguen. Realmente un único registro A y otro MX nos valdrían ya que todo va a funcionar en la misma máquina, pero por aquello de que quede bonito y pensando en futuros cambios en los que el servicio crezca y necesitemos usar máquinas diferentes para cada cosa, deberíamos de crear un registro A diferente para cada uno de los servicios. Algo así:

smtp IN A 99.99.99.99
mail IN A 99.99.99.99
webmail IN A 99.99.99.99
@ IN MX 10 mail.midominio.com

Donde, lógicamente, hemos de cambiar midominio.com por el nombre de dominio que vamos a usar y 99.99.99.99 por la IP de nuestra máquina.

En segundo lugar debemos de instalar los paquetes que necesitamos. Dejaremos el webmail para el final y nos centraremos en el resto. Para ponerlo en funcionamiento necesitamos instalar, además de postfix y dovecot, los paquetes necesarios para realizar la autenticación mediante el protocolo SASL:

# apt-get install postfix-tls libsasl2-2 sasl2-bin libsasl2-modules dovecot-imapd

El archivo de configuración principal de postfix es /etc/postfix/main.cf. Lo siguiente que tenemos que hacer es editarlo y añadir las siguientes líneas a su contenido:

smtpd_sasl_local_domain = $myhostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
home_mailbox = Maildir/

En la primera línea debemos de sustituir la cadena en negritas por el dominio cuyo correo queremos recibir. El resto de los parámetros determinan el tipo de autenticación que vamos a realizar, el servicio que se encargará de la autenticación (dovecot en este caso) y las restricciones de acceso más comunes al servidor. Tienes información detallada de todas ellas en este enlace.

Con el parámetro home_mailbox, muy importante, indicamos a Postfix que queremos usar el formato de correo Maildir y que la ubicación de las carpetas donde se almacenará este será un directorio denominado Maildir en el raiz del directorio home de cada usuario. Si no lo especificamos así, el correo se almacenará en un único fichero con el nombre de la cuenta de cada usuario y bajo el directorio /var/mail.

Una de las operaciones que se realiza durante la instalación de Dovecot es crear la estructura necesaria para albergar los buzones de correo en el directorio /etc/skel que es el que sirve de plantilla para generar el home de los nuevos usuarios. Eso quiere decir que los usuarios que tengamos previamente creados antes de hacer esta instalación no dispondrán de dichos directorios y, por tanto, no funcionaran correctamente. Para remedir esto tenemos que copiar manualmente dicha estructura. Supongamos que queremos copiar la estructura de buzones al usuario josemaria, ya creado antes de esta instalación. La operación sería la siguiente:

# cp -r /etc/skel/Maildir /home/josemaria
# chown -R josemaria:josemaria /home/josemaria/Maildir
# chmod -R 700 /home/josemaria/Maildir

La configuración de dovecot la realizamos en el fichero /etc/dovecot/dovecot.conf. Así como el archivo de configuración de postfix es sencillito y asequible (apenas tiene 20 líneas), el de dovecot es un engendro de más de 1000 líneas. Casi todas son comentarios, si, pero aun así asusta bastante…

Los dos primeros cambios son para determinar el protocolo que vamos a usar y habilitar la autenticación mediante texto plano. Busca las siguientes líneas y asegúrate de que no están comentadas y de que sus valores son estos:

protocols = imap
disable_plaintext_auth = no

El siguiente cambio va encaminado a configurar el identificador único que usaremos para cada email. Para que exista compatibilidad con algunos de los clientes de Microsoft es necesario que se defina de esta forma:

pop3_uidl_format = %08Xu%08Xv

Y ya sólo nos resta por definir los parámetros relativos al mecanismo de autenticación que hemos elegido. Lo hacemos con el siguiente bloque:

auth default {
	mechanisms = plain login
	passdb pam {
	}
	userdb passwd {
	}
	socket listen {
		client {
			path = /var/spool/postfix/private/auth
			mode = 0660
			user = postfix
			group = postfix
		}
	}
}

Ahora necesitamos hacer unas pequeñas modificaciones para permitir la comunicación entre postfix y sasl. Puesto que el daemon de postix se ejecuta mediante chroot en el directorio /var/spool/postfix, crearemos un enlace allí al que podrá acceder el daemon de sasl:

# mkdir -p /var/spool/postfix/var/run/saslauthd
# rm -r /var/run/saslauthd/
# ln -s /var/spool/postfix/var/run/saslauthd /var/run
# chgrp sasl /var/spool/postfix/var/run/saslauthd
# adduser postfix sasl

Y, finalmente, debemos de reiniciar los tres servicios involucrados para que lean los cambios hechos en sus respectivas configuraciones:

#/etc/init.d/saslauthd restart
#/etc/init.d/postfix restart
#/etc/init.d/dovecot restart

Para quién la autenticación mediante usuario y contraseña con texto plano se le quede corta, puede echarle un vistazo a este tutorial donde explican como realizarla mediante TLS.

Vamos ahora con la instalación de Squirrel Mail que es mucho más sencilla. Para ello necesitamos instalar apache, php y el propio squirrel:

# apt-get install apache2 libapache2-mod-php5 php5-cli php5-common php5-cgi squirrelmail

En el directorio /etc/squirrelmail tenemos un archivo llamado apache.conf con la configuración necesaria para crear la instancia de apache que nos permitirá acceder a Squirrel. Debemos de editarlo para modificar los datos correspondientes al Virtual Host que queremos crear:

<VirtualHost *:80>
	DocumentRoot /usr/share/squirrelmail
	ServerName webmail.<strong>midominio.com</strong>
</VirtualHost>

Luego creamos un enlace a este archivo en el directorio sites-availables de apache:

# ln -s /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrelmail

Y, por último, habilitamos el sitio y pedimos a Apache que vuelva a recargar su configuración:

#  a2ensite squirrelmail
# /etc/init.d/apache2 reload

La configuración de squirrel se realiza a través de un sencillo programa en modo consola que permite seleccionar, desde el idioma por defecto o el icono de la página de login, hasta la ubicación de carpetas por defecto o los plugins disponibles. Dicho programa se lanza con el siguiente comando:

# /usr/sbin/squirrelmail-configure

Con esto tenemos nuestro servidor de correo perfectamente operativo. Para crear una nueva cuenta de correo basta con que creemos un nuevo usuario en la máquina. Si creamos una cuenta llamada paquito, automaticamente se creará un buzón de correo para paquito@midominio.com cuyos mensajes se almacenaran en un directorio llamado Maildir que colgará del home de nuestro nuevo usuario.

Un par de ajustes finales. Si nuestra máquina permite el acceso por ssh y sólo queremos dar acceso de correo pero no permitir que estos usuarios accedan a la consola de la misma, lo mejor es que creemos un grupo con los usuarios que tendrán acceso de ssh y lo indiquemos así. Además, recordad que la autenticación de las cuentas de correo la estamos haciendo en texto plano, con lo cual cualquiera podría “escucharlas” y disponer de una cuenta de acceso a nuestra máquina. Podríamos, por ejemplo, tener un grupo llamado ssh_permitido al que pertenecerían los usuarios con permiso de acceso e indicarlo en el fichero /etc/ssh/sshd_config con la siguiente directiva:

AllowGroups ssh_permitido

Otro posible “extra” sería permitir que los usuarios con cuenta de correo pudieran modificar sus contraseñas a través de la web. En Unixcraft nos cuentan como hacer un script PHP para permitirlo.

ACTUALIZACIÓN: Los que necesiten gestionar el correo de más de un dominio pueden continuar por aquí. Y si quieres configurar un sistema antispam basado en greylisting échale un vistazo a esto.

Thunderbird, Lightning & Google Calendar

thunderbird Hace ya muchos años que uso Thunderbird como cliente de correo electrónico y Google Calendar como gestor de citas y eventos, pero como muchos de los que hemos echado los dientes con el Outlook siempre he echado de menos un calendario integrado en el cliente de correo electrónico y ni Evolution ni Kmail despiertan mis simpatías. Además, el recordatorio gratuito por SMS de Google Calendar es, hoy por hoy, insustituible. Ahora podemos tener lo mejor de ambos mundos gracias a dos extensiones disponibles para thunderbird: Lightning y Provider for Google Calendar.

Una vez instaladas ambas Lightning proporciona un calendario integrado perfectamente con Thunderbird y Provider for Google Calendar la sincronización con uno o varios calendarios creados previamente en Google Calendar. Partiendo de que ya has instalado ambas extensiones y tienes ese (o esos) calendario creado en el sistema de Google, configurar la sincronización entre ambos es tan sencillo como seguir estos pasos:

entrando en lightning1. Una vez instalado lightning tendremos disponibles dos pequeños iconos en la parte superior derecha de nuestro thunderbird y bajo la caja de filtros de búsquedas. Pulsamos el primero de ellos para entrar en la vista de calendario y esta se nos abrirá en otra solapa. El atajo de teclado es Ctrl+May+C y la opción de menú se encuentra bajo el nuevo item etiquetado como “Events and Tasks”.

creando un nuevo calendario en lightning2. Ya dentro de la vista de calendario, creamos uno nuevo pulsando con el botón derecho del ratón sobre el panel izquierdo y eligiendo la opción de “New Calendar”.

3. A continuación se nos abre una sencilla ventana de diálogo en la que debemos de elegir si el nuevo calendario que queremos crear se almacenará en local o estará ubicado en la red. Elegimos la segunda opción y pulsamos Intro.

creando un nuevo calendario en lightning 2

tomando datos de google calendar 1 4. En el siguiente diálogo se nos pedirá la ubicación en la red de dicho calendario, así que necesitamos que google calendar nos proporcione esos datos. Lo abrimos, elegimos el calendario que queremos sincronizar con Lightning y, pulsando sobre el pequeño icono a su derecha, escogemos la opción de “Configuración de Calendario”.

tomando datos de google calendar 25. Ya en la página de “Configuración del calendario”, nos vamos al apartado de dirección de calendario y pulsando con el botón derecho sobre el botón de XML elegimos la opción de “Copiar dirección de enlace”.

6. Volvemos a thunderbird-lightning y en el diálogo siguiente elegimos el formato de Google Calendar y en la caja de Localización copiamos la dirección que hemos obtenido en Google Calendar. Al pulsar siguiente, y si es el primer calendario que sincronizamos, se nos pedirá usuario y contraseña para validar la conexión con los servicios de Google.

creando un nuevo calendario en lightning 3

7. Y ya casi estamos. Finalmente elegimos un nombre y un color distintivo para los eventos de nuestro calendario (muy útil si, como yo, separas los eventos por categorías en diferentes calendarios) y pulsamos el botón de Siguiente.

creando un nuevo calendario en lightning 4

El resultado final, una vez repetida la operación con todos nuestros calendarios, debería de mostrarnos algo así:

Lightning & Thunderbird

La sincronización desde ambos extremos es perfecta e, incluso, tareas como la configuración de avisos por SMS procedentes de Google se pueden realizar perfectamante desde el propio Thunderbird:

Configurando avisos por SMS desde Thunderbird

ATENCIÓN: Google está haciendo cambios en su API y la versión 24 de Thunderbird con la 2.6 de Lightning ha dejado de funcionar. Te lo explican todo muy bien aquí, así como una solución temporal (usando versiones beta de ambos productos) por si no puedes esperar a la siguiente versión en la que prometen subsanarlo.
ACTUALIZACIÓN: Al parecer se trataba de un problema que sólo tenía la versión 24.0.1 de Thunderbird para Linux y que está corregido ya si la usas junto con la versión 2.6.1 de Lightning.

Chuletillas (y XXII) – Montar un servicio FTP sobre un directorio local

chuleta Mi servicio de hosting me proporciona casi 1000 Gbytes de espacio en disco (750 de base más algunos extras por referencias) de los que estoy usando unos 800 Mbytes y cerca de 120 GBytes de transferencia diaria de la que apenas aprovecho un par ¿Por qué no usar estos recursos extra para hacer backups incrementales de mis datos locales? Yo uso para este fin un sencillo script que usa rdiff-backup el cual me permite conexión con una máquina remota a través de ssh, pero no de ftp. Y mi hosting no me da conexión por ssh. Una solución sencilla a esto podría ser montar mi servidor ftp sobre un directorio local usando FUSE y, a partir de ahí, usar mi script de la forma habitual.

Para seguir esta chuletilla necesitas tener instalado curlftpfs, una utilidad que permite el uso de curl sobre FUSE disponible entre los paquetes estables tanto de Fedora como de Ubuntu y de Debian. Una vez instalado, sólo debes de ejecutar lo siguiente con privilegios de root:

# curlftpfs -o allow_other ftp://user:pass@ftp.server.com /mnt/ftp

Donde user y pass son los datos de tu cuenta de ftp, ftp.server.com el nombre de tu servidor ftp y /mnt/ftp el directorio local donde quieres montarlo. Fácil ¿verdad? Bueno, vamos a mejorarlo un poco…

Si queremos que el montaje se realice de forma más cómoda, sólo tenemos que incluir esta línea en nuestro fichero /etc/fstab:

curlftpfs#user:pass@ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

El directorio no se montará de forma automática en el arranque del sistema como el resto de las unidades (gracias al parámetro noauto) pero a partir de ahora montarlo y desmontarlo será tan fácil como ejecutar mount /mnt/ftp o umount /mnt/ftp respectivamente.

Por último, si nos preocupa que el usuario y la contraseña de nuestra cuenta de ftp sea visible dentro de un archivo legible por todos los usuarios del sistema (o, también, visualizando la lista de procesos en ejecución) podemos guardar estos datos en un fichero llamado .netrc dentro del directorio del usuario root. El formato del fichero sería este:

machine ftp.server.com
login user
password pass

Y ahora la línea en nuestro fichero fstab quedaría así

curlftpfs#ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

Dos apuntes finales. Recuerda que tus datos viajarán en claro a través de la red, así que si guardas información especialmente sensible procura cifrarla antes y trata de usar en todo momento la línea de comandos para acceder a esta nueva unidad. La utilidades gráficas no son eficientes para este tipo de accesos.

Chuletillas (y XXI) – Convertir nombres de fichero a UTF-8

chuleta Cuando se trabaja con diferentes versiones de sistemas operativos y pasas grandes bloques de fichero con frecuencia de uno a otro te sueles encontrar a menudo con un problema: las conversiones entre distintos juegos de caracteres. Uno de los casos más molestos es cuando copias árboles de directorios de windows a GNU/Linux y te encuentras con que los carácteres especiales (eñes, vocales acentuadas, etc.) no se han copiado correctamente impidiéndote, incluso, manipular dichos ficheros y directorios desde determinados programas. La herramienta convmv, disponible en la “paquetería” por defecto de las principales distribuciones, nos proporciona una forma rápida y cómoda para solucionar este problema.

convmv ofrece la posibilidad de convertir entre prácticamente cualquier juego de caracteres. La sintaxis para pasar de ficheros creados en un sistema windows al formato correcto en la mayoría de los Linux que ya usan UTF-8 por defecto es el siguiente:

convmv --notest -r -f cp1252 -t utf-8 /mnt/datos/windows/*

Esto realizaría los cambios de forma de forma recursiva (-r) en todos los archivos a partir del directorio /mnt/datos/windows. El formato origen (-f) es el cp1252 y el final (-t) utf-8. Si eliminamos el argumento --notest la herramienta nos hará una simulación por pantalla de los cambios a realizar para que comprobemos previamente si estamos escogiendo correctamente los formatos de origen y destino.

Sobreviviendo a Twitter

spam mediante DM en twitter Twitter logoNo recuerdo (y tal vez no haya precedentes) la última vez que un servicio de Internet ha creado en torno suyo un ecosistema tan diverso de aplicaciones y servicios como está ocurriendo con Twitter. Existen clientes para todos los gustos y plataformas, utilidades, juegos, chorradas de todo tipo… Tal vez el repositorio más completo sea el de oneforty pero basta con que hagas una sencilla búsqueda en google para encontrarte con miles de listas de supuestas “imprescindibles”.

Twitfilter valora con un índice a nuestros followers Pero que el uso de twitter corre también el riesgo de convertirse en un verdadero coñazo es algo más que evidente. Por un lado empiezan a proliferar bots y herramientas que permiten la automatización de seguimientos y respuestas automáticas (twittermass, twollow, assetize, socialtoo, hummingbird2…) haciendo un uso “legítimo” del sistema. En segundo lugar, la seguridad no ha sido nunca una de las prioridades de este servicio (¿podríamos relacionar de forma directa el éxito de algo en este mundillo con su escaso interés por la seguridad?) y ya no es raro recibir algún mensaje de spam procedente, incluso, de la cuenta de algún conocido real y a través de mensajes directos a través de los múltiples agujeros que se le encuentran de forma periódica. En tercer lugar, pero no menos importante, contamos con la práctica común de tantos y tantos “amigos”, conocidos y otro tipo de contactos que por diversas razones queremos mantener en nuestra listas pero que no siempre atinan (atinamos) con, digamos, una adecuada frecuencia (e interés) en la actualización de sus estados.

Twitstat permite identificar a los bots en Twitter Desgraciadamente al otro lado, el que nos permitiría controlar de alguna forma esta actividad, sigue habiendo pocas cosas interesantes. Pero haberlas, haylas. Una de ellas nos la proporciona Twitstat, un sencillo cliente para móviles que dispone de una utilidad que permite identificar a los bots que nos siguen en función de sus hábitos y suscripciones. Para usarlo no necesitas crear una cuenta adicional y puedes hacer login con tu identificador y contraseña de twitter. En este mismo sentido contamos con twittfilter que hace una valoración individual de nuestros contactos y, mucho más práctico para los que cuentan con cientos de seguidores, tweetblocker que los ordena en cinco categorías (A, B, C, D y F ¿qué diablos les ocurre con la letra E?) en función de las probabilidades de que sean bots o spammers y bloquearlos a todos con unos pocos golpes de ratón.

Tweetblocker categoriza nuestros followers en twitter

En otro segmento tenemos a muuter una utilidad que nos permite “silenciar” a un contacto durante un determinado periodo de tiempo (todos nos ponemos pesaditos con algún tema de vez en cuando ¿verdad?) o filtrar todos los twitts que recibimos en función de determinadas palabras clave. Esta segunda funcionalidad está aún en fase beta y no funciona del todo correctamente, pero promete. Lo realmente bonito de muuter es que se trata de un filtro totalmente independiente y que nos va a permitir seguir usando nuestros clientes favoritos y poder disfrutar de estos filtros. Por cierto: que no se me enfade nadie que el pantallazo de aquí abajo es puramente experimental 🙂

Montaje con los dos tipos de filtros que muuter nos permite

Pero en este terreno, si hay una utilidad que brilla con luz propia es Filltr, un cliente web (prometen un futuro cliente de escritorio) que a través de una inteligente combinación de prioridades directamente aplicadas a los usuarios y filtros aplicados en base a listas blancas y listas negras te permite personalizar de forma perfecta que es lo que quieres ver (y de quién) en tu timeline de twitter.

Montaje con los filtros disponibles en Filttr, el cliente de twitter perfecto

Imagino que tendremos que ver muchas más cosas en este campo en los próximos tiempos (Stoptweet, por ejemplo, es un servicio que aún no he podido probar por estar en fase beta bajo invitación). El planteamiento del servicio es, en cualquier caso, tan frágil e inseguro que mucho me temo que en el futuro se convertirá en algo similar al correo electrónico: lo usaremos por sus ventajas a pesar de sus incontables (e irresolubles) inconvenientes…

WPA Cracker

opinion Un cluster de 400 ordenadores para auditar la seguridad de una clave WPA en 10 minutos por 34$ (17$ si sólo queremos usar la mitad) mediante un ataque por fuerza bruta, la única posibilidad factible por el momento contra este sistema. Todo lo que necesitas, aparte de pagarles, es el ESSID de la red que quieres auditar, una captura de tráfico lo suficientemente grande (unos 10 Mbytes, indican en su FAQ) y una dirección de correo donde enviarte los resultados. Eso si, recuerda que se trata de una auditoria y que nadie te garantiza un resultado positivo.

WPA Cracker

Dropbox

Dropbox Icon Me he llevado un par de meses probando Ubuntu One pero, a pesar de que desde que escribí esto ha mejorado bastante, al final he decidido abandonarlo y buscar alguna alternativa. La principal causa ha sido la excesiva dependencia de la distribución de Canonical. El cliente web es universal, si, pero no es tan cómodo como la sincronización transparente y automática de archivos y carpetas que se consigue con el cliente de escritorio. Y este sólo está disponible para Ubuntu 9.04 y posteriores. Tocaba, pues, mirar alternativas. Y la mejor, sin duda, es Dropbox.

Dropbox hace todo lo que contaba en la antes mencionada entrada sobre Ubuntu One pero más y mejor: tiene cliente web, cliente de escritorio multiplataforma, no depende de la distribución de GNU/Linux que usemos y se puede usar perfectamente tanto con Gnome, como con KDE (aunque usando nautilus) o, incluso, instalarlo en un Linux sin entorno gráfico. También se pueden compartir directorios y la cuenta gratuita permite 2 Gbytes de almacenamiento (hasta tres cinco si invitamos a unos cuantos amigos al servicio). Eso si, una parte del código que usa es propietario, pero ya comentamos que con Ubuntu One pasa lo mismo.

Cliente de escritorio de Dropbox en KDE4

Entre los extras que Dropbox proporciona y que no ofrece Ubuntu One están la posibilidad de recuperar ficheros borrados o versiones anteriores de los mismos. Eso si, estas dos opciones sólo están disponibles desde el interfaz web pero, aún así, son un lujo para una aplicación como esta:

Recuperar archivos borrados en Dropbox
Recuperar versiones anteriores en Dropbox

Y para quien los 2 (o 5) Gbytes se le queden chicos, existen planes de pago, que te permiten extender la capacidad disponible hasta 100 Gbytes, pero a mi juicio son demasiado caros y, salvo excepciones, no les veo mucho sentido salvo que lo que quieras no sea una solución de sincronización de archivos de trabajo entre distintas máquinas sino una herramienta de backup online. Y, para esto, existen otras posibilidades.

ACTUALIZACI?N: Se me olvidaba comentar que, al menos para quien trabaje desde GNU/Linux (imagino que en windows funcionaría también pero no lo he probado) la mejor forma de trabajar es creando enlaces a los directorios o documentos que queremos sincronizar dentro de la carpeta de Dropbox. La sincronización funciona así perfectamente y nos evita tener que reorganizar la estructura de nuestro disco.

Kopete se integra con Skype

Kopete y Skype integradosicono de Skype Una de las últimas versiones de Kopete, el cliente de mensajería instantánea que KDE trae por defecto, añade una pequeña sorpresa que se me ha pasado totalmente desapercibida hasta ahora: su integración con Skype. Kopete no usa directamente el protocolo de Skype ni permite el alta de cuentas de este sistema de forma directa, sino que integra la información de una cuenta de Skype abierta y autenticada mediante su propio cliente nativo y sirve como intermediario entre nosotros y dicho cliente, creándonos la ilusión de tener un único programa de mensajería. Más aún si, además de realizar esta integración, “escondemos” el icono de Skype de forma que no aparezca en nuestra bandeja del sistema.

Kopete nos permitirá, a partir de ahora, la clasificación de los contactos de Skype en grupos (cosa que, inexplicablemente, no ha permitido nunca el cliente original), la inclusión de dichos contactos en meta-contactos (que engloban en una sola las cuentas de diferentes sistemas de mensajería de la misma persona) y derivará todos los eventos generados por Skype al nuevo centralizador de notificaciones incorporado en KDE4.

Kopete y Skype integrados

La verdad es que las últimas versiones de Skype para Linux han dejado mucho que desear y presentan frecuentes problemas con el audio y el video. La reciente versión 2.1, aunque mejor integrada, sigue sin solventar del todo estos problemas. Pero, por desgracia, se trata del cliente VoIP más extendido y por el momento no hay más remedio que “pasar por el aro”, así que esperemos que, aparte de mejoras externas como esta, el señor Andreessen (desde hace sólo unos días su nuevo accionista mayoritario) tenga la intención de cambiar el enfoque y nos permita disfrutar un poco mejor de esta popular herramienta.

Probando Ubuntu One

logo de canonical Llevo ya unos días probando Ubuntu One, el servicio propietario a través del cual Canonical pretende introducirse en esto del Cloud Computing al tiempo que le da un valor añadido a su distribución de Linux e incluso, si tiene la suficiente aceptación, le proporcionará una fuente de ingresos.

Ubuntu One se presenta como un servicio de almacenamiento remoto, sincronización y compartición de archivos con dos modalidades: una gratuita que ofrece hasta 2 GBytes de espacio y otra de pago que, por 10$ al mes, amplía esta cuota hasta 10 Gbytes. El servicio está disponible, por el momento, sólo mediante beta cerrada a través de invitaciones, tiene aún algunos bugs importantes y ha despertado críticas en muchos sectores ya que, mientras que el cliente de escritorio está escrito en python y su código si es libre, la parte que corre en servidor (en los servidores EC2 de Amazon, concretamente) es propietaria.

Una vez que disponemos de una cuenta, el acceso al servicio de Ubuntu One se puede hacer de dos formas: mediante una aplicación web o mediante un cliente de escritorio. Este último, que es quién realmente le proporciona un carácter difererenciador al servicio, sólo puede utilizarse por el momento desde la versión 9.04 de Ubuntu.

El cliente web no tiene nada de especial y se parece mucho a cualquier otro interfaz FTP vía web. El acceso se hace siempre vía https y la autenticación mediante una cuenta de launchpad. Podeis ver un pantallazo aquí abajo:

Cliente web de Ubuntu One

Compartiendo carpetas con el cliente web de Ubuntu One Tal vez lo único a destacar de este cliente es que tenemos una opción disponible en el panel derecho a través del cual podemos compartir cualquier directorio tanto en modo de sólo lectura como de lectura y escritura. Cuando invitamos a alguien basta con escribir su dirección de email y el destinatario recibirá en su buzón de correo una invitación con todas las instrucciones necesarias. El enlace recibido por correo nos llevará a un formulario de aceptación y el invitado deberá de disponer de su propia cuenta de Launchpad o, en su defecto, se le invitará a crear una nueva.

Pero, como decíamos antes, la verdadera gracia del servicio está en el cliente de escritorio. Las instrucciones para su instalación están aquí y son bien sencillas. La primera vez que ejecutemos el cliente en nuestra máquina asociará esta a nuestra cuenta de Ubuntu One. Podemos tener tantas máquinas asociadas a una cuenta como queramos (y los archivos compartidos se sincronizaran en todas ellas) pero, por lógica, cada cuenta de usuario en una misma máquina sólo podrá estar asociada a una cuenta de Ubuntu One. Esto es debido a que el servicio lo que hace es crear físicamente un directorio en nuestro home que es sobre el que se realizará la sincronización:

Cliente de escritorio de Ubuntu One

Icono del Sistem Tray de Ubuntu One El cliente coloca un icono en la bandeja del sistema desde el que podemos activar o desactivar la sincronización de archivos, abrir los directorios sincronizados, lanzar el cliente web, etc. No lo he probado en KDE así que no se que tal se integra por allí. En Gnome la integración es total. Aparte del icono y del botón de conexión y desconexión que, como veis en el pantallazo de aquí arriba, nos aparece en Nautilus, en el menú contextual también se incluye una nueva opción etiquetada como “Share on Ubuntu One” que nos permite compartir las carpertas con quien queramos simplemente introduciendo su dirección de correo electrónico al igual que hacíamos con el cliente web.

Compartiendo carpetas con el cliente de escritorio de Ubuntu One Si alguien tiene curiosidad por comenzar a probarlo por si mismo y no quiere esperar la invitación de Canonical que me deje un comentario con la dirección de correo electrónico donde quiere recibir la invitación: si os invito a compartir uno de mis directorios os dejará, además, crear vuestra propia cuenta. Pero recordad que el cliente de escritorio sólo funciona con Ubuntu 9.04 y que no se, siquiera, si funcionaría con Kubuntu 9.04 o Xubuntu 9.04. Si lo probáis en alguno de estos sistemas decídmelo y así salgo de dudas.

El servicio que presta Ubuntu One no es nuevo. dropbox, box.net, wuala, humyo o mozy, por decir algunos, ofrecen una funcionalidad similar desde hace tiempo. Algunos de ellos incluso con clientes específicos para GNU/Linux. La baza de Canonical, imagino, será presentarlo ya instalado y disponible para su uso como una característica de base en futuras versiones de sus plataformas proporcionandolo como un valor añadido. Veremos.