Seguro que hay formas más elegantes de hacerlo (incluso puede que esté soportado nativamente, Dios no lo quiera), pero para pasar de usar la versión 1.3.5 a la 1.2.0, los siguientes mandatos hicieron el truco:

$ cd /usr/local/bin/
$ for i in `ls ../Cellar/grails/1.3.5/bin/*`; do rm `basename $i`; done
$ for i in `ls ../Cellar/grails/1.2.0/bin/*`; ln -s $i `basename $i`; done

Muy rico :-).

Lamentablemente, al ser un iPhone traído allende los mares, está atado al operador AT&T, y además necesita ser activado, por lo que al final tuvimos que volver al jailbreak (ah, ironía, cómo te gusta repartir patadas en el culo ), ya que la activación y liberación sin hacer un jailbreak previo es, como poco, no trivial.

Hacerlo no es nada difícil una vez conoces los pasos, pero al ser un modelo antiguo, me costó bastantes prueba y error hasta dar con la fórmula. Básicamente hay que hacer tres cosas:

1. Obtener el software redsn0w (en mi caso usé la versión 0.92, el resto de instrucciones son para esta versión).
2. Obtener el firware 3.1.2 para iPhone Edge.
3. Usar redsn0w con el firmware 3.1.2 (iPhone1,1_3.1.2_7D11_Restore.ipsw).

La clave es no usar el firmware que tienes instalado, el 3.1.3 (iPhone1,1_3.1.3_7E18_Restore.ipsw), pues si lo haces obtienes un bonito mensaje: Unable to recognize specified IPWS. Una vez sabes esto, hacer el jailbreak, y liberar el iPhone es coser y cantar.

$ sudo equery belongs somefile
  File "/usr/bin/equery", line 271
    print pp.path(" /" + c[0])
           ^
SyntaxError: invalid syntax

Tras darle unas vueltas y no encontrar gran cosa en Internet Google , acabé pensando que podía tener que ver con el intérprete de python instalado. No estoy seguro de cómo llegué a esa conclusión, pero supongo que ayudaron el hecho de ver que equery está escrito en python, que mi sistema tenía instalados varios intérpretes (concretamente los más actuales de la versión 2 y 3 del mismo), y que otra máquina con Gentoo usaba otro intérprete y no sufría el problema.

Para resolverlo, lo primero es buscar pistas. Al trabajar con varias versiones, lo normal es que el ejecutable sea un enlace a la versión elegida. Así que fue cuestión de ver a dónde apuntaba dicho enlace y buscar el paquete involucrado.

$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 14 jul 14 12:21 /usr/bin/python -> python-wrapper
$ equery belongs /usr/bin/python-wrapper
[ Searching for file(s) /usr/bin/python-wrapper in *... ]
app-admin/eselect-python-20100321 (/usr/bin/python-wrapper)
$ equery files app-admin/eselect-python
[ Searching for packages matching app-admin/eselect-python... ]
* Contents of app-admin/eselect-python-20100321:
/etc/env.d/python/.keep_app-admin_eselect-python-0
/usr/bin/python-wrapper
/usr/share/eselect/modules/python.eselect

Parece que eselect es la herramienta que usa portage para decidir qué versión se usa cuando un paquete tiene varias instaladas. Por lo que se ve arriba, cada paquete instala sus propios módulos para informar a eselect de qué versiones hay disponibles, etc. A partir de aquí, jugando un poco con el mandato eselect, encontrar la forma de cambiar la versión no es difícil:

$ eselect
Usage: eselect   
...
$ eselect python
Usage: eselect python  
...
$ eselect python list
Available Python interpreters:
  [1]   python2.6
  [2]   python3.1 *
$ sudo eselect python set python2.6

Y, efectivamente, eso resuelve el problema y equery vuelve a funcionar .

$ firefox
Could not find compatible GRE between version 1.9.1.8 and 1.9.1.8.


Parece que Firefox anda buscando una versión de GRE que esté entre la 1.9.1.8 y la… 1.9.1.8. Vamos, que tiene que ser la 1.9.1.8 . El siguiente paso lógico sería buscar el paquete gre, pero el resultado es algo desalentador :

$ equery list gre
[ Searching for package 'gre' in all categories among: ]
* installed packages
[I--] [  ] sys-apps/grep-2.5.4-r1 (0)
[I--] [  ] x11-proto/bigreqsproto-1.1.0 (0)


También podemos probar con eix, pero el resultado es aun peor (me lo ahorro por la longitud de la salida). Sin embargo, tras hacer una búsqueda en /etc (un buen lugar para empezar a buscar), vemos que al menos tiene ficheros de configuración:

$ sudo find /etc/ -name 'gre*'
/etc/gre.d


Para los que venimos de Debian, el siguiente paso es consultar una guía de comparación de mandatos de gestores de paquetes, un recurso útil que nos da el equivalente a un dpkg -S y buscar a qué paquete pertenece ese fichero:

$ equery belongs /etc/gre.d/
[ Searching for file(s) /etc/gre.d in *... ]
net-libs/xulrunner-bin-1.8.1.19 (/etc/gre.d)
net-libs/xulrunner-1.9.1.8 (/etc/gre.d)


Sabiendo que xulrunner es nuestro sospechoso, basta con ver qué versiones hay disponibles:

$ eix xulrunner
[I] net-libs/xulrunner
Available versions:
(1.8)    1.8.1.19
(1.9)    *1.9.0.11-r1 1.9.0.14 1.9.1.6 1.9.1.8 1.9.2-r5 ~1.9.2.2-r1
{+alsa custom-optimization dbus debug elibc_FreeBSD gnome ipv6 java libnotify python sqlite startup-notification system-sqlite wifi xinerama}
Installed versions:  1.9.2-r5(1.9)


Y comprobar que la versión que queremos es la 1.9.1.8, estando instalada la 1.9.2-r5. Para bajar de versión, nada más fácil que enmascarar la que está instalada y volver a emergerla:

$ sudo echo "=net-libs/xulrunner-1.9.2.3-r1" >> /etc/portage/package.mask
$ sudo emerge xulrunner
$ firefox


Problema resuelto, y oye, siendo el primero de este estilo al que me enfrento por mi cuenta, sienta bien .

La opción es -o, y acepta como argumentos una gran cantidad de posibilidades, que normalmente se encuentran descritas en la página del manual como standard format specifiers (o directamente no se encuentran ).

Un ejemplo de cómo lucen normalmente las órdenes de tipo ps que suelo lanzar en mis terminales:

$ ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args
USER       UID   PID  PPID  PGRP %CPU %MEM   RSS    VSZ    SZ TTY          ELAPSED START COMMAND
root         0  3434     1  3434  0.0  0.1   552   5404   464 ?        12-22:14:08 Feb23 /usr/sbin/sshd
root         0 14466  3434 14466  0.0  0.5  2572   8124   512 ?              36:04 12:13  \_ sshd: deigote [priv]
deigote   1000 14469 14466 14466  0.0  0.2  1440   8280   668 ?              36:01 12:13      \_ sshd: deigote@pts/2
deigote   1000 14470 14469 14470  0.0  0.6  3344   6548  2172 pts/2          36:01 12:13          \_ -bash
root         0 16310 14470 16310  0.1  0.2  1196   4292   472 pts/2          00:06 12:49              \_ su -
root         0 16311 16310 16311  0.0  0.3  1688   4740   364 pts/2          00:03 12:49                  \_ -su
root         0 16315 16311 16315  0.0  0.2   992   4148   580 pts/2          00:00 12:50                      \_ ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args

Y, de hecho, un par de alias que suelo tener siempre definidos, entre otros, son:

alias ps='ps fax -o user,uid,pid,ppid,pgrp,%cpu,%mem,rss,vsize,size,tname,etime,start_time,args'
alias psg='ps | head -n 1 && ps | grep'

If you are an english speaker that arrived here by Google or similar, I’ll just resume the solution to you: Don’t use fucking mod_evasive with mod_dav_svn. Hope that helps

Si, es un nombre críptico de pelotas narices, pero es el que me gustaría haber encontrado a mi al principio de esta mañana, cuando por alguna razón mi configuración para acceder Subversion desde Apache ha empezado a dejar de funcionar correctamente.

Tras volverme loco durante toda la mañana, he descubierto el problema: una pequeña “incompatibilidad” entre mod_dav_svn y mod_evasive, un módulo que se me ocurrió probar con el fin de evitar ataques de denegación de servicio, y que no quiero saber qué otros efectos secundarios puede haber causado (¿bots de los buscadores en la lista negra?).

La cuestión ha comenzado cuando esta mañana he realizado una serie de operaciones masivas de Subversion (un refactoring de estos “gordos”) y de pronto la cosa ha empezado a fallar. A partir de ahí, la cosa ha ido degenerando y ha comenzado a fallar siempre. Tras volverme loco, “reiniciar” el repositorio, tirar las peticiones por un tunel SSH para evitar posibles proxies intermedios, y otras soluciones infructuosas, he optado por probar directamente en el servidor, de forma local. Al principio ha funcionado, así que he optado por instalar mediante backports una versión más moderna de subversion, para ver si había alguna incompatibilidad en ese sentido. Con el tiempo, ha dejado de funcionar en local también, por lo que he reinstalado las versiones originales de Subversion, sin éxito. Como es lógico yo no entendía nada.

Los errores que obtenía en el cliente eran:

svn: PROPFIND of '/': 403 Forbidden

Mientras que en el log de apache aparecía un mensaje

client denied by server configuration: /opt/websites/virtual host docroot

Que era lo que realmente me tenía fuera de juego: ¿Qué pintaba el docroot del virtualhost en el error, si todas las peticiones estaban entrando al location /, el cual estaba configurado como un DAV?

¿Qué estaba pasando? Dado que un simple svn list hace bastantes operaciones, mod_evasive estaba tomándolo como un “ataque”, bloqueando al cliente durante un tiempo. Por eso la cosa ha ido degenerando hasta que no funcionaba nada. El mensaje de error con el dichoso docroot debe ocurrir porque cuando mod_evasive pone a un cliente en su lista negra, ésta ya no llega a entrar en el DAV, y se considera el acceso fallido como un acceso al docroot. ¿Solución? No usar mod_evasive en conjunto con mod_dav_svn, o buscar una configuración del primero que funcione bien con el segundo (yo, escarmentado como estoy, lo dejo para otro día -aka nunca- ).
]]> http://blog.deigote.com/2010/03/03/svn-y-apache-403-forbidden-propfind-client-denied-by-server-configuration/feed/ 4 http://blog.deigote.com/2010/01/28/idioma-por-defecto-en-liferay/ http://blog.deigote.com/2010/01/28/idioma-por-defecto-en-liferay/#comments Thu, 28 Jan 2010 09:56:34 +0000 Deigote http://blog.deigote.com/?p=454 Un detalle que se me olvidó en la pequeña guía para instalar Liferay que escribí el otro día es la selección del idioma por defecto, que aunque a simple vista no parece gran cosa, como dirían los americanos, es un poco tricky (Wordreference lo traduce como que tiene sus bemoles, genial ).

Igual que Liferay incluye un fichero con todas las propiedades relacionadas con funcionalidad, existe otro fichero, llamado system-ext.properties, que tiene las propiedades relacionadas con el sistema (codificación de los ficheros, zona horaria, lenguaje por defecto, etcétera). Este fichero puede extenderse creando el fichero system-ext.properties.

Visto esto, para poner el portal en lenguaje español por defecto, debería bastar con anotar en ese fichero las propiedades relativas al lenguaje que queremos (las rutas corresponden a las mostradas en la guía antes mencionada):

$ echo "# Liferay default language
user.country=ES
user.language=es" >> /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps/ROOT/WEB-INF/classes/portal-ext.properties

¿Fácil, verdad? Pues no funciona . Para ser más exactos, no funciona para las compañías que ya tengamos creadas en la base de datos que estemos usando, ya que al crearlas, Liferay lee estas propiedades y las asocia a la compañía directamente en la base de datos.

Si ya tenéis el portal creado y no queréis empezar de cero, no es un problema grave, ya que estos datos pueden modificarse. Para ello, arrancad el portal accediendo a la compañía que queráis (en la mayoría de instalaciones se suele usar sólo una, ya que la feature de compañías no está muy bien documentada), y navegad por el menú superior escogiendo las opciones Panel de control – Portal – Configuración – Preferencias de presentación para seleccionar el idioma y país que por defecto.

find directorio_raiz -type f -exec sh -c 'basename $0 | sed "s/.*\.//"' {} \; | sort | uniq

El truco viene del archipoderoso sed, que permite obtener las extensión de un fichero mediante la orden sed “s/.*\.//”, y funciona que yo sepa, para cualquier Unix con una shell compatible con sh y find, basename y sed instalados.

1. ¿Qué es Liferay?
2. Instalación básica
3. Usando Liferay con MySQL
4. Usando Liferay con Apache
5. Usuario por defecto y un par de ajustes más

¿Qué es Liferay?

Liferay es un gestor de portales web con una gran funcionalidad integrada (gestión de comunidades y usuarios, CMS, wiki, blogs, y mucho más), y a su vez es un contenedor de portlets, lo que le permite ser extendido de manera bastante rápida y flexible (siguiendo la especificación JSR 286: Portlet Specification 2.0). Además, cuenta con una versión Community cuyo uso es gratuito y cuyo código es libre.

Instalación básica

Descargamos la última versión Community con el usuario que arrancará Liferay (en mi caso www-data) en el sitio que queramos (yo he escogido /opt/websites/liferay.deigote.com como directorio base de la instalación):

$ su - www-data
$ cd /opt/websites/
$ wget 'http://sourceforge.net/projects/lportal/files/Liferay%20Portal/liferay-portal-tomcat-6.0-5.2.3.zip'
$ unzip liferay-portal-tomcat-6.0-5.2.3.zip
$ mv liferay-portal-5.2.3/ liferay.deigote.com

Si ahora arrancamos Liferay, podremos ver cómo nos informa en los log de que se usará una base de datos para testing (Hipersonic), y si navegamos por la web, podremos ver una serie de portlets a modo de demo:

$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/startup.sh
$ tail -f logs/catalina.out &
$ firefox http://localhost:8080

Este entorno de demo está bien para cacharrear un poco y ver cómo la gente de Liferay quiere vendernos sus capacidades para hacer un clon de Facebook (vienen instanciados portlets de chat, de muro, de añadir usuarios como amigo, de actividad reciente…), pero los datos no persisten, por lo que no podréis pasar de ahí. Además, Liferay viene por defecto con usa serie de portlets (en forma de plugins) preparados para hacer la demostración antes mencionada. Yo normalmente borro dichos portlets antes de continuar (de hecho, en mi caso borro todos los plugins excepto el de web-form-portlet, que es el único que encuentro útil):

$ rm -rf `ls /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps | grep -v ROOT | grep -v web-form-portlet`

Para la persistencia de los datos, tenemos que conectar Liferay con un viejo conocido .

Usando Liferay con MySQL

Para conectar Liferay con MySQL existen varias formas. De momento anotaré aquí la más sencilla (aunque para mi gusto un poco “fea”), puesto que no recuerdo exactamente cómo es la otra . Liferay incluye en su core un fichero de propiedades (portal.properties) que configuran prácticamente todos los componentes del portal, base de datos incluida. Ese fichero puede ser extendido mediante el fichero portal-ext.properties, que por defecto no existe. Así que escribimos en él la configuración de la base de datos:

$ echo "# Database connection
jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/liferay_database?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=mysql-user
jdbc.default.password=mysql-password" > /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps/ROOT/WEB-INF/classes/portal-ext.properties

A continuación nos conectamos al servidor de mysql (en mi caso, localhost) y creamos la base de datos y un usuario con permisos para la misma:

$ mysql -h localhost -u root -p
$ create database liferay_database
$ grant all privileges on liferay_database.* to "mysql-user"@"localhost" identified by "mysql-password";

Si en este momento arrancamos Liferay de nuevo, deberíamos ver algunos mensajes haciendo mención a la base de datos utilizada (MySQL), y otros que indican que se están creando las tablas..

Usando Liferay con Apache

Para usar Apache como servidor web, creamos un host virtual y lo conectamos al servidor de aplicaciones de Liferay (en mi caso Tomcat) usando un módulo de proxy. Podemos usar el módulo proxy_http, que funcionaría con cualquier servidor de aplicaciones, o el módulo proxy_ajp, específico de Apache, y que presenta algunas ventajas sobre http, aunque yo no las recuerde . Dado que Tomcat soporta AJP, será el que usemos. Dado que yo uso Debian, necesito activar el módulo de proxy_ajp y crear un host virtual que use dicho módulo:

$ su -
# a2enmod proxy_ajp
# nano /etc/apache2/sites-available/liferay.deigote.com
# a2ensite liferay.deigote.com
# /etc/init.d/apache2 restart
# exit

El contenido del fichero /etc/apache2/sites-available/liferay.deigote.com será el siguiente:

<VirtualHost *:80>
        ServerName liferay.deigote.com
        ServerAdmin webmaster@localhost
        ErrorLog /var/log/apache2/liferay.deigote.com_error.log
        LogLevel warn
        CustomLog /var/log/apache2/liferay.deigote.com_access.log combined
        # Proxy to Tomcat
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass / ajp://liferay.deigote.com:8009/
        ProxyPassReverse / ajp://liferay.deigote.com:8009/
</VirtualHost>

Antes de echar a andar con esta configuración, debemos añadir un par de líneas al fichero de propiedades de Liferay, ya que si no éste dará por hecho que estamos atacando al puerto 8080 (el puerto por defecto de Tomcat) y escribirá las URL’s con dicho puerto. Una vez realizado este paso, deberíamos poder acceder a Liferay a través del host virtual que hemos usado (siempre y cuando nuestro servidor DNS sepa resolver dicho host, claro):

$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/shutdown.sh
$ echo "
# Webserver configuration
web.server.http.port=80
web.server.https.port=443" >> /opt/websites/liferay.deigote.com/tomcat-6.0.18/webapps/ROOT/WEB-INF/classes/portal-ext.properties
$ /opt/websites/liferay.deigote.com/tomcat-6.0.18/bin/startup.sh
$ firefox http://liferay.deigote.com

Usuario por defecto y un par de ajustes más

Una vez estemos navegando por Liferay, podremos acceder usando el usuario test@liferay.com con la contraseña test, que es administrador de la comunidad por defecto (guest) Yo recomiendo un par de ajustes más:

• Cambiar la dirección de correo (y por tanto el login) y la contraseña del usuario administrador. Esto lo podéis hacer en el Panel de control, en el apartado de Usuarios.
• Modificar el host virtual de la comunidad por defecto (o la que vayáis a usar) para que coincida con el que estéis usando para acceder a través de Apache. Esto se puede hacer en el panel de control, en el apartado Communities – Guest – Manage pages – Settings – Virtual host, usando el campo Public virtual host. Esto permitirá que las URL’s del tipo http://virtual_host/web/nombre_de_la_comunidad/pagina pasen a ser http://virtual_host/pagina, lo cual es más cómodo. Por ejemplo, la URL de la página por defecto (home) en la comunidad por defecto (guest) en mi caso pasaría de http://liferay.deigote.com/web/guest/home a http://liferay.deigote.com/home

Una vez finalizados estos pasos, ya podemos empezar a trabajar con Liferay en un entorno de producción (a falta, por supuesto, de configuraciones y optimizaciones de Tomcat, Apache y MySQL que no vienen al caso ).

• Contestador: Bienvenido al servicio de atención al cliente de Filostros Asociados. Si desea hacer una consulta general sobre filostros, por favor, pulse 1. Si desea información sobre nuestros puntos de venta, por favor, pulse 2. Si desea consultar el estado de un pedido de filostros, por favor, pulse…
• Diego: Operador
• Contestador: Perdone, no hemos entendido su opción. Si desea hacer una consulta general sobre filostros, por favor, pulse 1…
• Diego: Quiero cambiar la dirección de entrega de mi pedido de filosotros, a ver si me podéis pasar con un operador
• Operador: Buenas tardes, le atiende Gloria Aleluya, ¿en qué puedo ayudarle?

Un amigo que trabajaba en atención al cliente de Vomistar Movistar me dijo hace unos cuantos años que en realidad casi siempre hay un operador que te redirije manualmente a la opción escogida, en caso de que sea por voz, y en caso de que sea por número, siempre hay alguien “vigilando”. Por lo visto tenía razón, pues este truco ya lo he usado con éxito unas cuantas veces.

]]> http://blog.deigote.com/2009/07/28/contestadores-automaticos-al-final-alguien-te-esta-escuchando/feed/ 9