COMOs

Configurar ownCloud 2.0 en Dreamhost

ownCloud

Hablamos de ownCloud cuando el proyecto nació, hace casi dos años. Lo hemos usado desde entonces, pero lo teníamos a medio gas desde que realizamos la última migración de servidor, hace unos tres meses. Lo cierto es que en este tiempo el proyecto ha madurado muchísimo y vale la pena no olvidarse de él cuando pensamos en estrategias para recuperar la autonomía en una Red donde la centralización impera y el los defensores del cloud computing vuelven una y otra vez con la misma matraca.

Ahora hemos arreglado la situación. Esto ni siquiera merece ser llamado un cómo, es más un pequeño detalle. Instalar ownCloud es fácil, requiere Apache, MySQL y PHP. No se puede más fácil, vamos. Sin embargo, la versión 2.0 daba algún problema con la autenticación http para webdav en nuestro hosting. La interfaz web es preciosa y funciona de maravilla, pero el webdav no acababa de ir.

Para lograrlo tan sólo hay que editar el archivo .htaccess de ownCloud y añadirle estas líneas:


<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>

Dos minutos que lejos de ser dos minutos de odio pasarán enseguida y te dejarán la aplicación funcionando perfectamente desde cualquier entorno de escritorio que tenga soporte DAV integrado de serie (tanto Gnome como KDE lo tienen).

Categorías: 
Etiquetas: 

COMO mostrar información adicional del autor de un nodo en Drupal

En un blog, sobre todo si en él escribe más de un autor pero no sólo en esos casos, es importante que se sepa quién escribe cada post. Esto lo hacemos mostrando selectivamente una breve información sobre el autor del post en concreto, no sólo su nombre, sino algo más (contexto del autor: trayectoria, biografía, a qué se dedica, ...).

En Drupal es común que esto se aborde mediante la creación de un bloque usando Views, que luego incluye la info relativa al autor de cada post.

Esto tiene dos problemas.

  • Uno técnico. El bloque aparecerá vacío cuando en vistas que no sean de un único nodo. Por ejemplo, en la página principal. «Pues indicamos que no aparezca en <front> y santas pascuas», estará pensando alguno. Parece sencillo pero tenemos tantas vistas en las que no queremos ese bloque (archivos, páginas de usuario, cualquier View de tipo página que muestre contenido agregado o especial, ... y podríamos seguir) que nunca estaremos seguros de haberlo filtrado bien.
  • Otro de usabilidad. Pero no importa, for the sake of the argument, vamos a considerar que la primera vía fuera una buena solución técnica. En ese caso tenemos tres posibilidades: colocar el bloque justo antes del post, antes incluso del título del mismo. Colocarlo debajo del contenido principal o colocarlo en la sidebar, preferiblemente arriba del todo, en una ubicación preferente. Las tres son malas opciones: sobre el post porque da la mayor importancia de la página no al contenido de la misma sino al autor (en la mayoría de ocasiones no será lo que deseemos), bajo el contenido porque para ver ese bloque habrá que pasar primero por todos los comentarios que haya al mismo. Pueden ser muchos comentarios, y el bloque se perderá sin ser visto. Sobre la barra lateral es una situación intermedia, pero aún mejorable, pues más allá del nombre del autor, quizá el lector no quiere saber más de él antes de terminar el post y saber si el autor del mismo propone ideas interesantes. En ese caso, mejor aprovechar la barra lateral con los tradicionales botones de suscripción, mucho más importantes.

Entonces, ¿cuál es la ubicación idónea de esta información adicional sobre el autor de un nodo y cómo lo mostramos?

La ubicación
Lo idóneo es bajo el contenido del post y antes de los comentarios. En ese momento el lector ya ha leído el artículo y está preparado para recibir información adicional sobre el autor que le servirá para saber si buscar más ideas de este autor o descartarlo, o para contextualizar alguna afirmación arriesgada que el mismo haya podido hacer durante el artículo. Sólo después, con todo el contexto, el lector pasa a ver aportes de otros usuarios en comentarios. Evitamos distraerlo antes de que finalice su lectura, que es lo hacíamos poniendo esta información más arriba en la página.

La solución: cómo mostramos esta info
En Drupal 7 tenemos la ventaja de toda la flexibilidad que nos da el módulo Field, que ahora es parte del core y nos permite añadir campos con información adicional a casi cualquier aspecto que se nos ocurra.

  1. En nuestro caso, añadiremos un campo adicional al perfil del usuario, con un nombre descriptivo, algo como bio y le decimos a Drupal que será un campo tipo Texto Largo con un elemento de control del tipo Área de texto (varias filas). El breadcrumb para añadir este campo al perfil del usuario es: Inicio » Administración » Configuración » Personas » Opciones de la cuenta, y ahí seleccionamos la pestaña Gestionar campos. La URL relativa es /admin/config/people/accounts/fields.
  2. Una vez hemos añadido el campo, empezamos el cacharreo de verdad. Si queremos que este campo se muestre en todos los tipos de contenido, necesitaremos editar el archivo node.tpl.php de nuestra plantilla. Si, por el contrario, queremos que sólo afecte a un tipo de contenido editamos, o lo creamos si no existiera, el correspondiente archivo node--TIPODECONTENIDO.tpl.php, sustituyendo (obviamente) «TIPODECONTENIDO» por el nombre máquina de tu tipo de contenido. (Lo más común es que se trate de node--article.tpl.php.)
  3. En ese archivo, justo debajo del render del contenido del post y antes de renderizar los comentarios añadimos estas líneas, asumiendo que el campo recién creado para la info del autor se llame bio:

    <div class="autor-bio">
    <?php print $user_picture; ?>
    <?php
    $autor = user_load($node->uid);
    print ($autor->field_bio['und'][0]['value'])>
    ?>
    </div>

    Estas líneas mostrarán una foto del autor del nodo y, adicionalmente, la información sobre él.

Un ejemplo del resultado lo tenemos en cualquier post del blog de Cartograf, pero aquí enseñamos una demostración:

Sobre el autor en Drupal 7

Es posible que necesites vaciar la cache de tu Drupal para percibir los cambios y, claro, aún tendrás pendiente estilar bio la clase que hemos asignado a la capa, para que se vea verdaderamente bonito.

El resultado será exactamente el que queríamos, y exactamente el que da la información al visitante en el momento en que mejor le sirve. Y este post lo dejo aquí porque, ciertamente, estaba cansado ya de ver cómo la única solución que encuentras por ahí es la del bloque, muy simple y rápida pero también un tanto cutre. Así que ya que cociné ésta en un rato, la dejo aquí para la posteridad y para ahorrar sudores a todo aquel que necesite hacer algo similar.

Categorías: 
Etiquetas: 

Cómo instalar MailPress en WordPress Multi-site

Gestionar la suscripción por correo de nuestros blogs aporta siempre un valor añadido a aquellos con quienes interactuamos a través de nuestra modesta ventana al mundo.

Una de las opciones más utilizadas para gestionar este tipo de suscripciones es FeedBurner: funciona rápidamente y es sencillo de usar. Sin embargo, lo barato sale caro: al usar FeedBurner estamos externalizando nuestra presencia y una pieza importante de información muy valiosa (las direcciones de correo de personas). FeedBurner fue comprada por Google, el mayor vendedor de anuncios del mundo (aten cabos). Y, por si fuera poco, es una trampa a medio plazo para la gestión de nuestros suscriptores, motivo por el cual abandoné su uso en los albores de 2008.

Tanto si usamos Drupal como WordPress, existen módulos que nos permiten gestionar las suscripciones por correo internamente, sin salir de nuestro CMS y sin problema alguno: plug and play.

MailPress

Este artículo se centra en WordPress y MailPress, cuya instalación es laboriosa pero sencilla (caché de Google, la fuente da error). En el caso de WordPress Multi-Site, MailPress no funciona de inmediato. Se trata de un módulo muy potente, de los más utilizados para esta labor, pero se atasca antes de echar a andar.

¿Qué sucede? El problema real es que MailPress, en el momento de su activación para toda la red de blogs, sólo crea las tablas que necesita para funcionar... en el blog principal de la red, e ignora a los demás. En este caso, una vez activado para la red, el plugin podrá ser activado para cualquier blog, a voluntad de su administrador, que podrá añadir el widget de suscripción a cualquier parte de la web. Este widget, sin embargo, dará error cuando alguien intente suscribirse. A pesar de eso, el mail con el hash de confirmación se enviará al usuario, pero al no existir una base de datos en la cual almacenar esa petición, hacer click devuelve al potencial suscriptor un error del tipo Error #5 - Unknown User. De cajón: no hay tabla ni info almacenada, así que el sistema te responde que esa petición que tú quieres confirmar no existió jamás :D

Ahora vamos a ver cómo lo arreglamos, para poder gestionar directamente el newsletter de nuestro WordPress Multi-site sin depender de un proveedor externo. Requiere un poco de tinkering, pero nada complicado.

  1. Antes de nada, aunque confiemos en que no vamos a romper nada, lo que debemos hacer es una copia de seguridad de la base de datos. Usa el gestor que prefieras, si no te ves muy suelto con MySQL, puedes usar phpMyAdmin.
  2. MailPress crea tres tablas principales. Asumiendo que todas las tablas tengan un prefijo wp_, las tres tablas principales son wp_mailpress_mails, wp_mailpress_mailmeta, y wp_mailpress_users. Podemos usar el mismo gestor utilizado para respaldar nuestra base de datos para ver qué tablas adicionales ha creado MailPress, variará en función de los AddOns que hayamos activado.
  3. Hay quien propone soluciones un tanto complejas que supuestamente funcionan [sic, tiene erratas así que no sé cómo lo hizo para que le funcionara]. La realidad es que toda vez que al menos un blog de la red (el principal), lo más fácil es copiar las tablas creadas para ese blog, algo que hacemos ¡a partir del punto siguiente!.
  4. Buscamos en el menú de administrador de la Red los ID de los blogs para los que queremos activar MailPress, es un número y asumiendo el prefijo anterior como global (wp_) y que queramos activar MailPress en un blog con ID = 2, necesitaríamos crear como mínimo las tablas wp_2_mailpress_mails, wp_2_mailpress_mailmeta, y wp_2_mailpress_users. Se ve claro el patrón, ¿no? Si hemos activado alguna función útil como las métricas de suscriptores o la gestión de rebotes seguramente tendremos que crear alguna tabla más (wp_2_mailpress_stats, y wp_2_mailpress_usermeta). Remito al punto 2 para verificar exactamente qué tablas estamos necesitando.
  5. Una vez sepamos el ID del blog que nos da problemas y las tablas que nos hacen falta, seleccionamos la base de datos en cuestión y ejecutamos una query que deberá tener la siguiente pinta:
    CREATE TABLE wp_2_mailpress_mails LIKE wp_mailpress_mails;
    CREATE TABLE wp_2_mailpress_users LIKE wp_mailpress_users;
    CREATE TABLE wp_2_mailpress_mailmeta LIKE wp_mailpress_mailmeta;

    Esto creará en nuestra base de datos unas tablas idénticas a las que ya están funcionando correctamente para el blog matriz, pero vinculadas al blog con ID = 2 de nuestra red.
  6. Si necesitamos activar MailPress en más blogs de nuestra red, modificamos la query para adaptarla al ID de ese blog.
  7. Y con esto tendremos lista para nuestro WordPress Multi-Site una herramienta fantástica y potente que por algún motivo no se activa bien en este tipo de instalación.

Los beneficios son rápidos e importantes: nos gusta la Red, nos gusta pero no podemos caer en el empujón fácil hacia infraestructura ajena, porque de esa carrera surjen rentas de posición que serán usadas en nuestra contra.

¿Queremos una Red que merezca tal nombre? No una nube para todos, sino millones de nubes pequeñitas. Pasito a pasito hacia la autonomía tecnológica, ¿o no es para eso que usamos un CMS en software libre?

Categorías: 
Etiquetas: 

Cómo modificar los metadatos de un archivo PDF con Pdftk en Linux

Aunque no es algo que necesitemos hacer con demasiada frecuencia, puede darse el caso de que necesitemos modificar los metadatos de un archivo PDF con nuestro Linux. En este caso de querer editar los metadatos, no nos servirá el habitual PDFedit, ya que éste no puede editarlos. Por contra, recurriremos al maravilloso PDF Toolkit o pdftk.

Los pasos son:

  1. Instalar, si no lo tenemos ya, el pdfk desde nuestros repositorios. En distribuciones de la familia de Debian será suficiente con el habitual # apt-get install pdftk.
  2. Componer un pequeño archivo de texto en el que introducimos los metadatos básicos que queremos meter en nuestro PDF. Con un editor tipo Gedit creamos un archivo que tenga la siguiente pinta:

    InfoKey: Title
    InfoValue: La neutralidad de la Red
    InfoKey: Subject
    InfoValue: Por qué es una pésima idea acabar con la neutralidad de la Red
    InfoKey: Keywords
    InfoValue: Sociotecnología, Internet, Neutralidad de la Red, Economía
    InfoKey: Author
    InfoValue: Jose Alcántara
    InfoKey: Creator
    InfoValue: TeX
    InfoKey: Producer
    InfoValue: pdftk
    InfoKey: CreationDate
    InfoValue: D:20101023140009
    NumberOfPages: 116

    Es deseable, claro, que adaptéis los valores de los parámetros a lo que necesitéis realmente ;)

  3. Suponiendo que nuestro pdf se llame «neutralidad.pdf», que el archivo con los metadatos se llame «metadatos.txt» y ambos estén en el mismo directorio, abrimos una terminal de comandos y nos movemos hasta el directorio que contiene nuestros dos archivos. Una vez ahí ejecutamos $ pdftk neutralidad.pdf update_info metadatos.txt output neutralidad-con-metadatos.pdf, que nos generará un nuevo documento con nombre «neutralidad-con-metadatos.pdf».

Y esto es todo, la info básica la saque de Lagotzki.de, y sólo he sacado el grano para ponerlo en español.

Categorías: 
Etiquetas: 

Cómo conseguir buena integración de Thunderbird en Gnome

Thunderbird

Una de las cosas que me sorprenden es que a estas alturas la integración de Thunderbird en Gnome sea, por defecto, tan mejorable. Este post viene a dejar por escrito cómo integrar mejor nuestro Thunderbird con el escritorio Gnome. En realidad no es algo nuevo, tan sólo algo que quiero dejar por aquí para cuando me haga falta, algo que en su día no hice.

El asunto es que Thunderbird te avisa cuando tienes nuevo correo y demás, pero lo hace con su propio formato de avisos. ¿No sería mejor que usara el mismo tipo de globitos de notificación que usan el resto de nuestras aplicaciones? Vamos a ello:

  1. libnotify-bin. Instalamos esta librería, que estará posiblemente en nuestros repositorios (así es en el caso de Ubuntu, revísalo para tu distro).
  2. Gnome Integration. Es una extensión para Thunderbird que es la encargada de entenderse con libnotify-bin. Configuramos un poco y ya tenemos nuestros avisos de notificación estándard

Ahora bien, podemos hacer más. ¿No es molesto tener Evolution en el applet del panel si vamos a usar Thunderbird? Vamos a solucionar eso también.

  1. Necesitamos crear un archivo en /usr/share/applications/thunderbird.desktop. En lugar de hacerlo a pelo usamos el siguiente comando, que nos lo crea y nos hace una configuración básica:
    $ sudo touch /usr/share/applications/thunderbird.desktop
  2. Abrimos el archivo recién creado con gedit:
    $ sudo gedit /usr/share/applications/thunderbird.desktop
    para verificar que el contenido del archivo tiene, en sus primeras líneas, lo siguiente:
    [Desktop Entry]
    Encoding=UTF-8
    Name=Mozilla Thunderbird Mail/News
    Comment=Read/Write Mail/News with Mozilla Thunderbird
    GenericName=Mail Client
    Exec=thunderbird %u
    Terminal=false
    X-MultipleArgs=false
    Type=Application
    Icon=thunderbird
    Categories=Application;Network;Email;
    MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;
    StartupWMClass=Thunderbird-bin
    StartupNotify=true
  3. Si todo está en orden, ahora creamos el siguiente archivo de nuevo con touch:
    sudo touch /usr/share/indicators/messages/applications/thunderbird
    y lo abrimos con sudo gedit /usr/share/indicators/messages/applications/thunderbird para añadirle la siguiente línea apuntando al archivo que creamos justo antes:
    /usr/share/applications/thunderbird.desktop
  4. Opcionalmente, podemos eliminar el archivo /usr/share/indicators/messages/applications/evolution, para que no nos aparezca en ese menú.

Y esto es todo. La próxima vez que iniciemos sesión y abramos Thunderbird, éste será un suave guante en la mano (algo me dice que sería más apropiado decir pie) de nuestro Gnome.

[Actualización (2011-02-23 @ 17:07): Gracias a Amador, en los comentarios, nos enteramos que Instalando libnotify-mozilla se soluciona todo de forma sencilla.]

Categorías: 

Cómo configurar tarjeta gráfica Intel GMA 500 en Ubuntu Maverick

[Actualización (2010-12-02): No deberías comprar NUNCA el Asus Eee PC 1201HA si piensas usar Ubuntu. (Quizá no deberías comprarlo, así en general.) Si ya tienes este ordenador y no te puedes deshacer de él y necesitas configurar un Linux en él, aquí abajo encontrarás cómo configurar la tarjeta gráfica bajo Ubuntu.]

Tengo un nuevo portátil pequeñito, un Asus Eee Pc 1201HA. Aunque su potencia sea limitada, es fantástico porque es pequeñito (12.1") y su batería dura unas 8 horas, que no está nada mal.

Ubuntu

Sin embargo, hay un problemita básico que tuve que afrontar nada más instalarle la última Ubuntu: la tarjeta gráfica, una Intel GMA 500, no se había configurado adecuadamente.

Para lograrlo encontramos la info en el wiki de Ubuntu, ejecutamos en una terminal:

$ sudo add-apt-repository ppa:gma500/ppa && sudo apt-get update && sudo apt-get install poulsbo-driver-2d poulsbo-driver-3d poulsbo-config

Al reiniciar debería funcionar correctamente, al menos en Ubuntu 10.10 (Maverick).

Si tenéis algún problema, podéis instalar drivers alternativos a Poulsbo, como el driver fbdev. Siguiendo unas instrucciones también disponibles en la wiki de Ubuntu.

El rendimiento es mejor en el primer caso (driver Poulsbo) que en el segundo (driver fbdev). En todo caso, a disfrutarlo :)

Categorías: 
Etiquetas: 

Problema con escáner Epson en Ubuntu Maverick

Hay un bug que hace que los escáneres de la serie Perfection de Epson dejen de funcionar al actualizar a Ubuntu Maverick. Lo habitual es que el escáner esté funcionando normalmente, pero que al actualizar a Ubuntu 10.10, pese a que el escaner aún será reconocido por Sane, lo más probable es que dé «Fallo al escanear».

¿Cómo se soluciona? El bug está en el driver de la serie Perfection que hay en la librería sane-epson2, así que lo que haremos será:

  1. Editar el archivo /etc/sane.d/dll.conf. Típicamente ejecutando $ sudo gedit /etc/sane.d/dll.conf desde una consola.
  2. Hay dos líneas con la siguiente pinta:

    #epson
    epson2

    Lo cual significa que la librería epson2 está en uso y la epson está desactivada.

  3. Activamos la librería epson quitando la almohadilla y desactivamos la epson2 poniéndole una almohadilla. Debe quedar así:

    epson
    #epson2

  4. Reiniciamos el programa que usemos habitualmente para escanear, y listos.

El retorno de un clásico, el de los COMOs de baja tecnología.

Categorías: 
Etiquetas: 

Páginas

Suscribirse a RSS - COMOs
Todos los derechos revocados.