Blog de Franco Catrin

En la configuración por omisión de Ubuntu Gutsy (7.10) no está disponible el paquete vmware-server que estuvo hasta Feisty (7.04). Pero se puede cambiar esta configuración para instalarlo fácilmente en dos pasos:

• Ir al menú Sistema -> Administración -> Origenes del software -> Software de otros proveedores y activar el repositorio “partner”
• Instalar vmware-server con el comandosudo apt-get install vmware-server

Esperar la descarga y aplicar sal a gusto.

---

Hay gente que prefiere hacer todo por linea de comandos. Para habilitar el repositorio por linea de comandos en vez de usar la interfaz gráfica se deben realizar los siguientes pasos:

Abrir la lista de repositorios con un editor de texto:

sudo gedit /etc/apt/sources.list

Descomentar (quitando el signo #) o agregar la linea:

deb http://archive.canonical.com/ubuntu gutsy partner

Grabar y luego actualizar la lista de repositorios cargada:

sudo apt-get update

Cuando trato de conectarme a un servidor ssh usando Ubuntu Feisty se queda unos segundos “pensando” y después de eso se establece la conexión normalmente. Habilitando el “verbose” de ssh encontré lo siguiente:

fcatrin@desktop:~$ ssh -v serverdeprueba.com
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to serverdeprueba.com [ipdeprueba] port 22.
debug1: Connection established.
debug1: identity file /home/fcatrin/.ssh/identity type -1
debug1: identity file /home/fcatrin/.ssh/id_rsa type -1
debug1: identity file /home/fcatrin/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug1: Miscellaneous failure
No credentials cache found
debug1: Miscellaneous failure
No credentials cache found

Las ultimas cuatro lineas se demoraron bastante en aparecer, una rápida búsqueda en google me indica que esos mensajes los arroja la autenticación con kerberos, y además encuentro que esa autenticación se demora si no hay un servidor kerberos disponible. Como yo no uso kerberos, y además creo que soy parte de la mayoría, simplemente deshabilité ese modulo en /etc/ssh/ssh_config.

Donde dice:

GSSAPIAuthentication yes

Lo cambié por:

GSSAPIAuthentication no

Y ahora el ssh se conecta inmediatamente, como siempre debió haber sido.

Esta semana he estado trabajando con unas aplicaciones antiguas que requieren Java 1.3 por la versión del Application Server que están utilizando. Java 1.3 es bastante antiguo y depende de algunas bibliotecas igual de antiguas, piensen en esos tiempos en que no se usaba UTF-8 por omisión en Linux.

Tal como esperaba, no lo pude ejecutar directamente en Ubuntu Feisty, trate de darle algunas pistas al sistema, como el clásico LD_ASSUME_KERNEL pero tampoco tuve éxito. Al final, el procedimiento era bastante sencillo, pero bien podría haber perdido mucho más tiempo en esto. Estoy seguro de que alguien más agradecerá este tip (Hi Aldrin!)

Se necesitan 4 sencillos pasos:

Paso 1: Descargar Java 1.3 desde el sitio de Sun

• Ir a http://java.sun.com/products/archive/
• Seleccionar J2SDK 1.3 o J2RE 1.3 segun se necesite. Yo me fui por J2SDK 1.3.1_20

Paso 2: Cambiar los permisos y ejecutar el archivo .BIN para aceptar la licencia y descomprimir el archivo. Recomiendo hacer esto en el directorio /opt

cd /opt
chmod 755 ELARCHIVO.BIN
./ELARCHIVO.BIN

En mi caso, esto generó el directorio /opt/jdk1.3.1_20

Paso 3: Instalar libstdc++ compatible con esta version de Java. Ojo que el numero de version podria cambiar, lo importante es que sea 2.x

apt-get install libstdc++2.10-glibc2.2

Paso 4: Crear un link simbólico para que el binario de java pueda encontrar la biblioteca libstdc++ que espera. Ojo que las versiones pueden cambiar

cd /usr/lib
sudo ln -s /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2

Con eso ya podrán ejecutar java, pero seguramente tendrán problemas por el soporte multilenguaje, entonces antes de ejecutar java asegurense de ejecutar

export LANG=en_US

Resultado final:

fcatrin@shaman:~$ /opt/jdk_1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Pasos opcionales pero convenientes
Con esos pasos podrán ejecutar java directamente con /opt/jdk_1.3.1_20/bin/java, pero es muy engorroso. Personalmente uso un método que me simplifica el problema de rutas y versiones de java. Todas las versiones de java instaladas las hago vivir en /opt. En ese directorio creo un enlace simbólico apuntando al nombre real del java instalado. Tengo algo asi:

java13 -> jdk1.3.1_20
java14 -> j2sdk1.4.2_02
java -> java14

Para crear uno de esos enlaces aplico:

cd /opt
ln -s jdk1.3.1_20 java13

De esta forma, java13 siempre sera /opt/java13 independiente del java instalado, y el java por omisión siempre sera /opt/java, y si lo deseo lo puedo cambiar para que apunte a java14 o java 13 depende de qué java quiero tener por omisión. En mi .bashrc dice :

export JAVA_HOME=/opt/java
export PATH=$JAVA_HOME/bin:$PATH

Con eso tengo lo suficiente para que cualquier aplicación java que ejecute utilice el java por omisión (1.4 en este caso). Para el caso de java13 me cree un script /usr/local/bin/java13 que dice:

export JAVA_HOME=/opt/java13
export PATH=$JAVA_HOME/bin:$PATH
export LANG=en_US

Entonces cuando requiero java 1.3 simplemente ejecuto source java13 y listo. De esta forma:

fcatrin@shaman:~$ java -version
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
fcatrin@shaman:~$ source java13
fcatrin@shaman:~$ java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Una de las cosas que notaba desde hace un tiempo atrás es que Xorg estaba funcionando mas lento. Tenia sospechas de que se trataba de un problema con xcompmgr, o bien había algún tipo de regresión en el driver al cambiar desde 6.9 a 7.0. Se notaba especialmente al hacer scrolling, o al mover las ventanas.

Con una rápida búsqueda en una de las listas de correo relacionadas con X, me entere de que había un problema en la configuración de MTRR, de fácil solución y vaya que mejora el rendimiento! Que bueno que no haya sido el xcompmgr porque aun no me pego el salto a Xgl y uno se acostumbra a las sombritas.

Se que esto aplica a mi chip de video (intel), así que si lo quieren probar, haganlo bajo su propio riesgo, pero por lo que entiendo no podría pasar nada mas allá de un simple cuelgue.

El chip de video tiene un área de memoria asignada, esto lo pueden ver con lspci -v, revisando las características del “adaptador gráfico”.  Por ejemplo

lspci -v
[...]
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
Subsystem: Hewlett-Packard Company Device 30d5
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f0400000 (32-bit, non-prefetchable) [size=512K]
I/O ports at 3000 [size=8]
Memory at 98000000 (32-bit, prefetchable) [size=128M]
Memory at f0480000 (32-bit, non-prefetchable) [size=256K]
Capabilities: <access denied>
Kernel modules: intelfb
[...]


Supongamos que como en este caso, la base de memoria de video es 0×98000000, y el tamaño es de 128MB (0×8000000), entonces se debe hacer lo siguiente :

echo "base=0x98000000 size=0x8000000 type=write-combining" >| /proc/mtrr

Si sale algún error, seguramente es porque tienen uno de los parámetros malos, pueden ver el detalle ejecutando

dmesg | tail

Pueden ver el resultado final con

cat /proc/mtrr

Para que entiendan el problema, a través de MTRR se puede cambiar la forma en que esta manejada la memoria, por ejemplo si es cacheable o no, o bien en el caso de memoria AGP indica si se habilita el modo write-combining que es mucho mas rápido.

(no puedo mostrar lo que sale en mi notebook porque ahora estoy en un curso de Microsoft, cof cof.. sobre migración de aplicaciones 32-bit a 64-bits, de todas formas esta bastante interesante y entretenido).

Durante los últimos días he estado viajando harto a Santiago, no he podido usar mucho mi computador, ni menos habia tenido tiempo de escribir un poco. Hoy volvi a viña, durara solo 5 días pero algo es algo. Sin darme cuenta creo que escribir este blog se ha convertido en una especie de necesidad, no se si eso sera sano o no
Aprovecho de saludar a “mi amiga virtual” que hoy esta de cumpleaños… si si, me acordé pero no en el momento en que debía acordarme.. desde este rincón : FELIZ CUMPLEAÑOS!

Charla en DUOC

El jueves pasado estuve en Duoc sede Antonio Varas realizando un remake de la charla “Nueva generación de gráficos en Linux”. No habia mucha gente, pero de todas formas lo pase muy bien, al principio un poco nervioso como siempre, pero salio todo bien.

Hay dos cosas que me han llamado la atención últimamente, una es que ya no es necesario hablar sobre qué es Linux, la mayoría entiende un poco de que se trata, y es normal que en la audiencia haya gente que tiene bastante experiencia en el tema. Otra cosa que me llama la atención es que en el publico vayan apareciendo mujeres de a poco, en esta ocasión especial incluso había una niña de 16 años. Estuve conversando un poco con ella antes de comenzar y se veía bastante entusiasmada con lo que había visto en el par de días de charlas.

La organización me regalo una camarita web, aun no la configuro, pero JCI ya publico la forma de configurar la webcam , debería ser cosa de seguir sus instrucciones.

UPDATE: ya hay algunas fotos de las charlas Linux en DuocUC

Linux, irDA y obex

Cambie mi celular por un Sony-Ericsson K300. Esta serie es nueva, y el K300 viene siendo de la linea baja de la serie. Aun asi el aparato es mucho mejor que mi fiel Nokia 6225, lo unico que no me gustó fue la cámara fotográfica, sin duda la del nokia era superior.

JCI me enseño a usar obexftp, y me hice un sencillo script para sincronizar el contenido de una carpeta con el contenido de la galería de fotos. De esta forma es super fácil transferir los archivos del celular al notebook utilizando Linux, incluso mas fácil que en windows, solo me basta acercar el teléfono y el script hace todo, incluso aplicar algunos filtros que mejoran algo las fotos del sony ericsson.

Abajo incluyo el script, no les va a servir tal como esta, hay que personalizarlo. Las partes claves son la variable DIR que debe apuntar a la carpeta del teléfono que contiene las fotos, obexrename.sh es un sencillo script que modifica el nombre de las fotos para que queden mas fáciles de manejar, y el ciclo de convert no es necesario si tienes una buena camara como la del nokia.

Como verán, el script es super sencillo, y siguiendo la misma lógica se puede hacer que elimine las fotos que ya se encuentran en el directorio actual.

obexsync.sh

#!/bin/sh

# directorio del telefono (version ingles)
DIR=Pictures/camera_semc
OBEXFILES=`obexftp -i -c $DIR -l`
FILES=`echo "$OBEXFILES" | grep file | cut -d""" -f2`

# solo dejar los archivos que no se encuentran localmente
for FILE in $FILES
do
# obexrename es un script propio para transformar el nombre
LOCALFILE=`obexrename.sh $FILE`
if [ ! -f $LOCALFILE ]; then
OLDFILES=$NEWFILES
NEWFILES="$OLDFILES $FILE"
fi
done

# obtener los archivos desde el telefono
if [ ! -z "$NEWFILES" ]; then
obexftp -i -c $DIR -g $NEWFILES
fi

# filtrar las fotos si la camara no es muy buena
mkdir -p backup

for FILE in $NEWFILES
do
LOCALFILE=`obexrename.sh $FILE`
echo "Converting... $LOCALFILE"
convert $FILE -despeckle  -enhance -monitor $LOCALFILE
mv $FILE backup/$FILE
done

echo "sync ok"

El script obexrenane.sh dependera si necesitas o no transformar los nombres, en mi caso los nombres de archivo son del tipo foto-000(1).jpg, foto-000(32).jpg etc, y los transformo en foto-000-001.jpg, foto-000-032.jpg etc. Voy separando las colecciones de foto como foto-000, foto-001, etc.

obexrename.sh

#!/bin/sh

NAME=`echo $1 | cut -d "(" -f1`
NUM=`echo $1 | cut -d"(" -f2 | cut -d")" -f1`

if [ $NUM -lt 10 ]; then
NUM="00$NUM"
elif [ $NUM -lt 100 ]; then
NUM="0$NUM"
fi

echo $NAME-$NUM

Escuchando : Transatlantic – Duel with the Devil (el tema pa bueno!)

Prácticamente no falta nada para el Sexto Encuentro Nacional de Linux que este año se realizará en la Universidad Arturo Prat de Iquique. Si bien no tengo lista mi charla 100%, al menos ya tengo funcionando las demos mínimas que pienso mostrar.

El titulo de mi charla no dice mucho : “Nueva generación de gráficos en Linux”. Lo que tratare de hacer es mostrar lo que se esta haciendo en el área gráfica de Linux, tanto en el lado del xserver (composite, EXA, Xgl) como en las bibliotecas gráficas (cairo), mostrando algunos ejemplos que ya están funcionando.

German y Alvaro tienen la idea de hacer un track de charlas alternativas, será algo asi como un bonus track enfocado a publico mas especialista, charlas que de otra forma no hubiesen sido seleccionadas para el Encuentro, pero que si son interesantes para los mas avanzados. Esperamos que se nos unan otros secuaces como Max y Daniel Serpell.

Mañana parto a Iquique y por lo visto nos encontraremos con un grupo grande en el aeropuerto. Estos encuentros son una gran oportunidad para compartir con amigos que uno no ve muy seguido pero que tienen muchos intereses en común.

Tips de SSH (Túnel TCP)

Alejandro da unos tips para usar un tunnel de X por ssh de forma bastante cómoda. En palabras simples, solo basta tener una conexión ssh para poder ejecutar aplicaciones gráficas en forma remota y segura. Básicamente lo que hace ssh es crear una especia de proxy en el equipo remoto, que redirige el trafico de X a través de la conexión ssh hasta el servidor X local. Una pequeña observación al tip es que el primer paso (xhost +) no es necesario, ya que la conexión que llegara por X aparecerá como efectuada desde el equipo local :

xserver local - ssh cliente - ssh servidor - x remoto (ssh) - aplicación

El servidor ssh automáticamente setea la variable DISPLAY para que apunte al extremo “x remoto (ssh)”, usualmente DISPLAY=:10.0 (11, 12, 13, etc).

No solo se pueden usar conexiones a X por tunel, sino que cualquier conexión TCP, esto permite que con solo tener acceso ssh podamos acceder a cualquier recurso desde la red remota, como si fuera local.

Supongamos que tenemos un servidor de correo en la red remota, que solamente se puede acceder al interior de esa red. El servidor se llama correo.localdomain, y atiende IMAP por el puerto 143. Entonces por ssh se puede establecer la siguiente conexión:

ssh -L143:correo.localdomain:143 servidorssh

Esto creara un tunel desde el puerto 143/tcp local hacia el puerto 143/tcp en correo.localdomain a través de la conexión ssh con el “servidorssh”.

Luego si configuramos localmente nuestro cliente de correo para que los recupere desde localhost:143, la conexión se realizara a traves de ssh con el servidor correo.localdomain:143.