Archivo del Autor de Deigote

Mandato PS con salida “personalizada”

Una opción del mandato ps de los sistemas operativos tipo Unix que no suele estar muy bien documentada y que en mi opinión es tremendamente útil es la que permite personalizar la salida del mandato para que muestre la información que te interesa de cada proceso.

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 :D ).

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'

Svn y Apache: 403 Forbidden PROPFIND (client denied by server configuration)

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- :D ).

Idioma por defecto en Liferay

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 :lol: ).

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 :D . 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.

Obtener las extensiones de fichero existentes en un directorio

Una mini-receta rápida para obtener, de forma recursiva, todas las extensiones de fichero que existan a partir de un directorio dado:

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.