Upgrade a WP2.3.1

He actualizado mi blog a WordPress 2.3.1.

Siempre me ha dado bastante pereza actualizarlo, porque aunque no sea complicado (hasta ahora solia seguir este procedimiento), no es del todo sencillo: copiar la version actual, eliminar los ficheros de la version anterior y sustituirlos por la version nueva (para no perder todos los cambios que habia hecho yo y ficheros nuevos que he añadido a mano).

Hace poco descubri otro metodo que parece ser mucho mas sencillo!: Usar Subversion. Aqui esta el procedimiento correspondiente. Se hace con un comando:

$ svn sw http://svn.automattic.com/wordpress/tags/VERSION/ .

Obviamente, este metodo hace que actualizar sea tan sencillo que uno ya no se puede resistir. Ayer prepare mi instalacion para poder hacerlo con este metodo (viene explicado como hacerlo en el mismo link). Ahora, a ver cuando sale la siguiente release de WordPress… Estoy anxioso por actualizar mi blog otra vez con svn.

Homenaje a vcon03 :-)

Poca gente lo entendera, pero da igual…

Blog de Iván López: Los viejos tiempos…

Redistribuir los PV links de un VG (HP-UX) — Update

Respecto al post anterior sobre como redistribuir los PV links de un VG sobre los distinctos caminos a los discos, agradezco el comentario de RuBiCK apuntando a la opción -s del comando pvchange:

NAME
   pvchange - change characteristics and access path of a physical volume
   in an LVM volume group

SYNOPSIS
...
   /usr/sbin/pvchange [-A autobackup] -s pv_path
...
     -s  Immediately begin accessing the associated
         physical volume named by pv_path.
...

Usando este comando no es necesario quitar y reañadir los PV links al VG. Ademas de ser mas seguro, tambien se reduce considerablemente el script, quedando asi:

#!/usr/bin/ksh
# Distribuye los PV links sobre las controladoras
set -o nounset

VG=$1
I=0
for PV in $(
   vgdisplay -v $VG | grep "PV Name" |
   grep -v "Alternate Link" | awk '{ print $3 }' )
do

   LISTA_LINKS=$( pvdisplay $PV | grep "PV Name" | awk '{ print $3 }' | sort )
   NUM_LINKS=$( echo $LISTA_LINKS | wc -w )

   NEW=$(( I % NUM_LINKS + 1 ))
   PRI=$( echo $LISTA_LINKS | awk "{ print \$${NEW} }" )

   pvchange -A n -s $PRI
   (( I = I + 1 ))

done
vgcfgbackup $VG

Gracias RuBiCK por la contribución .

Redistribuir los PV links de un VG (HP-UX)

Inspirado por el post de RuBiCK sobre como extender un VG con todos los PV links alternates de cada PV, se me occurrio hacer un script para distribuir todos los PV links sobre los distinctos caminos a los discos (es decir sobre las posibles controladoras). Esto no aplica si estamos usando un drivers que balancea el acceso a los discos y no hace uso de los pv links (por ejemplo Powerpath).

Por ejemplo, un VG de 3 PVs. Cada PV se ve por 4 caminos, por las controladoras c4, c6, c8 y c10.

Posiblemente, el primary path de los 3 PVs sea por la c4, mientras que los demas caminos estan en standby. Aun que no sea comparable a Powerpath, es mas interesante distribuir las I/O sobre todos los caminos posibles. Para esto, podemos redistribuir los primary path sobre los caminos posibles.

Por ejemplo: PV1 por la c4, PV2 por la c6 y PV3 por la c8 (y seguiriamos asi con los demas discos…)

Para hacerlo en caliente, lo que hace el script es quitar los caminos que no seran el primario y reañadirlos (en el orden correcto):

# pvdisplay /dev/dsk/c4t0d4
--- Physical volumes ---
PV Name                     /dev/dsk/c4t0d4
PV Name                     /dev/dsk/c6t0d4     Alternate Link
PV Name                     /dev/dsk/c8t0d4     Alternate Link
PV Name                     /dev/dsk/c10t0d4    Alternate Link

# vgreduce -A n $VG /dev/dsk/c8t0d4 /dev/dsk/c10t0d4 /dev/dsk/c4t0d4

# vgextend -A n $VG /dev/dsk/c8t0d4 /dev/dsk/c10t0d4 /dev/dsk/c4t0d4

# pvdisplay /dev/dsk/c6t0d4
--- Physical volumes ---
PV Name                     /dev/dsk/c6t0d4
PV Name                     /dev/dsk/c8t0d4     Alternate Link
PV Name                     /dev/dsk/c10t0d4    Alternate Link
PV Name                     /dev/dsk/c4t0d4     Alternate Link

He hecho el siguiente script para hacer el trabajo automaticamente con todos los discos de un VG:

#!/usr/bin/ksh
# Distribuye los PV links sobre las controladoras
set -o nounset

# bucle para cada primary link:
VG=$1
FILE=$( mktemp )
J=0
for PV in $(
   vgdisplay -v $VG | grep "PV Name" |
   grep -v "Alternate Link" | awk '{ print $3 }' )
do
   (( J = J + 1 ))
   I=1

   LISTA_LINKS=$( pvdisplay $PV | grep "PV Name" | awk '{ print $3 }' | sort )
   NUM_LINKS=$( echo $LISTA_LINKS | wc -w )

   for LINK in $( pvdisplay $PV | grep "PV Name" | awk '{ print $3 }' )
   do
      (( N = ( I + J ) % NUM_LINKS + 1 ))
      echo $PV $( echo $LINK | tr "t" "/" | cut -d/ -f 4 ) $LINK $I $N
      (( I = I + 1 ))
   done
done | sort -k 5 > $FILE

for PV in $(
   vgdisplay -v $VG | grep "PV Name" |
   grep -v "Alternate Link" | awk '{ print $3 }' )
do

   # Lista de links
   set -- $( grep $PV" " $FILE | awk '{ print $3 }' )

   PRIMARY=$1
   shift
   ALTERNATES=$*

   # esta bien el futur primary? (sino saltamos)
   pvdisplay $PRIMARY >/dev/null 2>&1 || continue

   vgreduce -A n $VG $ALTERNATES
   vgextend -A n $VG $ALTERNATES

done
vgcfgbackup $VG
rm $FILE

Acceso remoto a ficheros…

En mi trabajo apunto un monton de cosas cada dia, comandos, trucos,… porque recordarlo todo seria imposible. Tambien creo que apuntarlo hacer que lo recuerde, y si no, al menos recuerdo haberlo apuntado, con lo que suele ser mas facil encontrarlo cuando lo necesite. Son mis “chuletas”; forman mi repositorio de chuletas.

La cuestion es ?donde poner estas chuletas? Si las tengo en el trabajo, desde casa no tendria acceso. Y vice-versa. Por lo que hasta hace poco las tenia replicadas entre un equipo de casa y uno del trabajo (ambos linux), por medio de un script basado en rsync (y un par de tuneles ssh) y del socorrido cron para automatizarlo todo. La verdad es que estaba bien montado, con una sincronizacion “2-way”, es decir que si actualizaba algo durante el dia en el trabajo, al llegar a casa ya estaba en mi repositorio de casa. Y si actualizaba algo en casa, el dia siguiente ya lo tenia en el trabajo. No me tenia que preocupar. Tambien me valia de backup.

El problema es que ahora ya no me vale esta solucion… Asi que me puse a buscar otra, que se pueda usar a traves de un proxy web (en general es la unica salida al exterior que solemos tener en desde la empresa). Tambien intento evitar cosas raras como tuneles TCP a traves de proxy, porque prefiero una solucion estandar que no necesite que instale nada (o muy poco).

De momento he encontrado 2 formas muy interesantes de conectarme a traves de un proxy corporativo a mis ficheros de casa.

La primera es mediante WebDAV: basicamente es como montar una unidad compartida por HTTPS (web-share):

Web-based Distributed Authoring and Versioning: …The protocol’s aim was to make the Web a readable and writable medium, in line with Tim Berners-Lee’s original vision. It provides functionality to create, change and move documents on a remote server (typically a web server or “web share”)…

Montar un WebDAV es algo muy sencillo con Apache2. Basta con activar los modulos dav y dav_fs con a2enmod y configurar unas pocas lineas en el .conf del virtual host correspondiente. Sobre este punto, los siguientes links aportan la informacion mas que necesaria para configurar WebDAV con Apache2:
# HOW-TO: Red Hat 9 – Apache 2 – WebDAV
# No pain no gain » Howto enable WebDAV in Apache

Respecto al tema de seguridad de acceso y a la privacidad de los datos transferidos, no me preocupo porque he activado SSL en mi apache y por lo tanto el trafico entre ambos extremos esta cifrado.

Con esto que logramos: poder abrir el directorio WebDAV desde XP con el explorer, para abrir, modificar, borrar ficheros:

Lo malo de esto es que las modificaciones que se hacen en el directorio compartido por WebDAV (en el servidor) se hacen con el usuario del apache (www-data en Debian). Esto no mola mucho. Incluso si se pueden definir directorios por cada usuarios que pueda entrar, al final en la maquina todos pertenecen al www-data. En mi caso, como tambien entro en la maquina en local (ssh, samba,…) no me vale tener los ficheros con el usuario del apache. Para remediar esto, se puede hacer un cron (que se lance como root) para cambiar el propietario/grupo y los permisos de los ficheros cada x tiempo. (No es muy limpio, pero por lo visto no hay otra solucion que se haya desarrollado).

Por lo tanto, con un directorio WebDAV, uno puede tener acceso desde el trabajo a un repositorio de ficheros que tenga compartido desde su casa. (Lo he probado con XP solo).

Mientras estaba montando esto del WebDAV, encontre un script php muy interesante, tambien relacionado con el tema del acceso remoto (por http(s)): smbwebclient.php. La instalacion del script no presenta dificultad (teniendo un apache con soporte para php). Una vez instalado, el script permite navegar por la red Microsoft (o Samba) en la que este el servidor web (en mi caso la red Samba de mi casa). Si solo tenemos una maquina, el servidor Web, supongamos que hemos compartido por samba algunos directorios, pues con abrir con un navegador la pagina del smbwebclient, podremos navegar por estos directorio. El script gestiona la autenticacion en la red (pide el usuario del workgroup/dominio para acceder a los shares). Si tenemos toda una red Samba, podemos acceder a toda ella mediante smbwebclient simplemente por Web.

En la web oficial hay una demo que permite probarlo:

Con smbwebclient tambien es recomendable usar SSL, para que tanto la autenticacion como el trafico de datos este cifrado.

Mientras WebDAV permitia una navegacion del directorio compartido integrada en XP, en el caso de smbwebclient la navegacion se hace con el navegador (puede ser mas portable, independientemente del SO, y sin necesidad de ningun cliente WebDAV). Por otra parte, smbwebclient permite acceder a mas cosas que WebDAV (toda la red Samba), y deja los ficheros con el usuario que toca, no el www-data.

Son realmente dos soluciones muy interesantes para poder acceder a nuestros ficheros en remoto a traves de http(s).

Ahora, respecto al tema de la sincronizacion bidireccional, encontre una herramienta, Super Flexible File Synchronizer, que permite sincronizar ficheros entre dos directorios, y soporta multiples protocolos (smb, ftp, sftp…) pero el que mas me interesaria en este caso es que soporta WebDAV! (esto todavia no lo he probado, pero en breve lo hare!).

Por lo tanto, creo que me quedare con ambas soluciones de acceso remoto, poniendo mi repositorio de chuletas en el WebDAV, con un cron que me fije el propietario y los permisos regularmente. En el trabajo configurare el Super Flexible File Synchronizer para sincronizar las chuletas (2way) con el WebDAV. Para acceder al resto de ficheros, bien desde el trabajo, o desde donde sea, podre tambien usar smbwebclient.

(Vaya ladrillo acabo de escribir… Enhorabuena a quien me haya leido hasta el final!).

Filtrado por MAC para la Fonera

Tengo una Fonera (con firmware de Fon, pero con acceso SSH) y estaba un poco mosqueado de que no tuviera filtrado por MAC de la gente que puede conectarse a la red “privada” (MyPlace).

Pues con estas lineas se puede habilitar el filtrado por MAC. En mi caso, lo pongo en modo whitelist, es decir que pongo la mac de los equipos que autorizo a conectarse. Tambien se puede poner en modo blacklist, es decir poner la mac de los equipos que no dejamos conectar.

Ejecutando estas lineas funciona:

# To flush the list of MAC addresses:
iwpriv ath1 maccmd 3

# To make the list a whitelist (1) / blacklist (2):
iwpriv ath1 maccmd 1

# Add some MACs to the list:

# Equipo 1
iwpriv ath1 addmac xx:xx:xx:xx:xx:xx

# Equipo 2
iwpriv ath1 addmac yy:yy:yy:yy:yy:yy

Para que se haga efectivo en cada reinicio de la Fonera, he puesto estas lineas en el /etc/init.d/S45firewall.

(Saque los comandos iwpriv de MadWifi.org.)

[scriptlet] 4 columnas de 20 caracteres

Este pequeño scriptlet imprime una lista (de item de menos de 20 caracteres) en 4 columnas:

LISTA_IMP="a b c d e f"

I=0
for IMP in $LISTA_IMP
do
   (( I = I + 1 ))
   printf "%-20s" $IMP
   if [ $I -eq 4 ]
   then
      I=0
      echo
   fi
done
echo

Me suena que existe algun binario que hace esto, pero no recuerdo cual…

Solaris pkgadm tool

Estaba buscando hoy un gestor de paquetes tipo APT para HP-UX. Es decir, algo que permita bajar paquetes directamente de Internet, resolver y bajar dependencias y actualizar versiones obsoletas de paquetes.

Al final no encontre lo que buscaba, pero encontre algo parecido para Solaris (no lo he probado todavia): Solaris pkgadm tool.

Apache2, SSL y WordPress

Estos ultimos dias he añadido soporte SSL a mi servidor web (apache2 en Debian). La verdad es que, gracias a estos dos enlaces, ha resultado muy facil:

* Setting up an SSL server with Apache2
* Apache2-SSL-Certificate for Ubuntu Feisty / Debian: How to install this missing script to get the SSL certificates up (porque el primer link hace referencia a un script que ya no viene en Debian o Ubuntu).

Una vez configurado el virtualhost con SSL, he añadido el plugin Admin-SSL a mi blog para redireccionar la web de administracion sobre SSL.

Realmente, el usar SSL no es para proteger mi web de administracion del blog (aunque no viene mal ), sino para algo mas, pero eso lo contare en otro post .

µTorrent en Linux (III): Tuning TCP/IP

En este nuevo post de mi serie sobre µTorrent en Linux, hablaré de los parametros de kernel que he modificado en mi maquina para intentar optimizar el tema de conexiones.

La verdad es que he cojido estos parametros de algun manual sobre como tunear un servidor para tener un buen rendimiento cuando asume muchas conexiones, lo cual deberia servir en nuestro caso.

Estas lineas se introducen en el fichero /etc/sysctl.conf y para cargarlas usamos el comando: sysctl -p. Ahi van los parametros, con comentarios:

# Enable fast recycling of TIME-WAIT sockets status

net.ipv4.tcp_tw_recycle=1

# tcp_fin_timeout is the time to hold a socket in state
# FIN-WAIT-2 when the socket is closed at the server.

net.ipv4.tcp_fin_timeout=30

# One of the problems found in servers with many simultaneous TCP
# connections is the large number of connections that are open but unused.
# TCP has a keepalive function that probes these connections and
# drops them after tcp_keepalive_time

net.ipv4.tcp_keepalive_time=1800

# max OS send buffer size (wmem) and receive buffer size (rmem)
# for queues on all protocols (8388608=8MB)

net.core.wmem_max=8388608
net.core.rmem_max=8388608

# In addition, you should also use the following commands for send and receive
# buffers. They specify three values: minimum size, initial size, and maximum
# size. The third value must be the same as or less than the value of
# wmem_max and rmem_max.

net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608

# When the server is heavily loaded or has many clients with bad connections
# with high latency, it can result in an increase in half-open connections.
# This is very common for Web servers, especially when there are many dial-up
# users. These half-open connections are stored in the backlog connections
# queue. You should set this value to at least 4096 (the default is 1024).

net.ipv4.tcp_max_syn_backlog=4096

# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1

Lo cierto es que no tengo datos para comparar si va mejor asi, pero el caso es que a mi me va de fabula!