El día de hoy necesitaba realizar algunas pruebas con Linux en un equipo de bajo perfil.  Primero probé con Fluxbox como manejador de ventanas pero me pareció poco elaborado para el tipo de usuario que lo iba a utilizar.  En otras ocasiones había utilizado XFCE con buenos resultados, sin embargo quería probar algo que consumiera aún menos recursos.

Así fue como finalmente llegué a probar LXDE con muy buenos resultados hasta ahora.  Es mas simple que XFCE pero es lo mínimo que necesitaba.

Para simplificar su uso decidí instalarle un dock y se me ocurrió probar nuevamente a Docky, antes parte de Gnome-do.  Esta aplicación es muy interesante, especialmente por su integración con la segunda, sin embargo no acostumbra a ser de mi preferencia por la forma como agrupa los íconos de las instancias abiertas de la misma aplicación, aumentando el número de clics necesarios y obligando a utilizar frecuentemente el clic derecho que en mi netbook me resulta un tanto incómodo (problemas de diseño de Dell).

El problema surge en este momento ya que Docky requiere de la instalación de un composite manager que LXDE no trae por defecto y Compiz es demasiado pesado para las limitaciones de hardware que tenía.  Así que encontré la existencia de Xcompmgr el cual es mucho mas liviano y cumple su tarea.

Procedimientos de instalación.

Instalación de Docky.

$ sudo aptitude install docky

Adicionalmente es aconsejable instalar también Gnome-do ya que agrega una funcionalidad interesante que agiliza el trabajo en el escritorio.

$ sudo aptitude install gnome-do gnome-do-docklets gnome-do-plugins

Instalación de Xcompmgr.

$ sudo aptitude install xcompmgr

Finalmente es necesario indicarle a LXDE que debe utilizar al Xcompmgr como su composite manager.  Para hacer esto es necesario realizar el siguiente paso.

$ sudo vi /etc/xdg/lxsession/Mint/autostart

(agregar)
@xcompmgr

Enlaces.

• Xcompmgr en el Wiki de ArchLinux.
  http://wiki.archlinux.org/index.php/Xcompmgr

Generalmente no es necesario ni conveniente que los servidores ejecuten, menos automáticamente, un servidor de ventanas por básicamente dos razones: aumentan la probabilidad de problemas de seguridad y el mayor consumo de recursos (procesamiento y memoria RAM).

Como se ha visto anteriormente, es posible realizar esto de múltiples maneras según la distribución de GNU/Linux que se utilice.  Para este caso, Debian, se plantea el desactivar el inicio automático del GDM.

Procedimiento.

Desactivar el inicio automático.

# update-rc.d -f gdm remove

Reemplace el gdm por el administrador de login que utilice como xdm o kdm si no utiliza GNOME.

Iniciar manualmente el sistema de ventanas.

En cualquier momento es posible iniciar manualmente el sistema de ventanas mediante la ejecución del siguiente comando.

$ startx

Esta ejecución no realiza ningún tipo de cambios en la configuración así que este inicio será temporal, la próxima vez que se reinicie el servidor lo hará nuevamente en modo texto.

Activar el inicio automático.

Si se desea revertir el cambio en la configuración y permitir que el login grafico y el sistema de ventanas se inicien automáticamente ejecute el siguiente comando.

# update-rc.d -f gdm defaults

Nuevamente, ajuste el nombre del administrador de login según el administrador de ventanas que utilice.

Enlaces.

• Man page of update-rc.d.
  http://www.unix.com/man-page/Linux/8/update-rc.d/

No había notado la necesidad de instalar las fuentes complementarias en GNU/Linux hasta que me dí cuenta que el contenido de mi blog no se estaba viendo bien desde mi netbook con el sistema operativo recién instalado.  En él utilizo bastante la fuente Courier New para el código fuente, los comandos del shell y la salida estándar.  Esta no estaba apareciendo de ancho constante sino que aparecía de manera muy similar al resto del texto.

La solución por supuesto fue instalar las fuentes adicionales (MS Core Fonts) y el contenido del blog empezó a aparecer correctamente.

Instalación del paquete de fuentes.

Para hacer esto es necesario que se encuentre activo el componente Universe de los repositorios.

$ sudo aptitude install msttcorefonts

Regenerar el caché de las fuentes.

$ sudo fc-cache -fv

Después de instalar OpenSim 0.7 el paso siguiente es verificar su funcionamiento.  Para esto se probaron los siguientes 4 visores compatibles con Second Life/OpenSim.

1. Second Life Client (1.23.5.136262).
2. Second Life Client (2.1.0.207030).
3. SnowGlobe (2.0.2.3576).
4. Hippo OpenSim Viewer (0.6.3).

Second Life Client v1	Second Life Client v2
SnowGlobe v2	Hippo OpenSim Viewer v0.6

Instalación y ejecución.

Todos, a excepción del Hippo, para instalarse deben simplemente descomprimirse en el directorio donde residirán finalmente.  Por el contrario, cuando se descomprime Hippo se obtiene un instalador, el cual al ejecutarse pregunta a través de diálogos la ubicación final donde se instalará el visor.

De manera similar, todos, a excepción de Hippo, se ejecutan de la siguiente manera.

$ ./<visor> -loginuri http://<host>:<port>

Donde <visor> es el archivo ejecutable (secondlife o snowglobe), <host> es el nombre o dirección IP del servidor de OpenSim y <port> es el puerto donde se está ejecutando el servicio (9000 por defecto).

Nuevamente Hippo se diferencia del resto ya que incluye desde su interfaz grafica (Edit > Preferences > Grids) la capacidad de administrar las grids a las cuales se va a realizar conexiones.

Hippo OpenSim Viewer, grid configuration

Conclusiones.

En una revisión rápida se encuentran las siguientes conclusiones.

• Aparentemente Second Life Client v1 y Hippo OpenSim Client se encuentran basados sobre la versión del software base, mientras que les sucede lo mismo al Second Life Client v2 y al SnowGlobe.
• Los clientes Second Life Client v2 y SnowGlobe presentan problemas para descargar y manipular el skin del avatar, así que en su defecto muestran una nube o un huevito (en gráficos con calidad menor).
• Debe tenerse en cuenta que la prueba se realizó desde un portátil con una tarjeta gráfica de muy bajo perfil (Intel 965) y que con una mejor configuración de hardware los resultados pueden variar.

Enlaces.

• Second Life Viewer.
  http://secondlife.com/support/downloads/
• SnowGlobe.
  http://snowglobeproject.org/
• Hippo OpenSim Viewer.
  http://mjm-labs.com/viewer/
• Connect to OpenSim.
  http://opensimulator.org/wiki/Configuration#Connecting_to_OpenSim

OpenSimulator es un servidor de aplicaciones 3D que puede ser utilizado para crear ambientes o mundos virtuales los cuales pueden ser accedidos a través de una variedad de clientes y  protocolos. Permite realizar los desarrollos con las tecnologías mas habituales gracias a un diseño flexible, fácilmente extendible mediante módulos cargables para crear con ellos configuraciones completamente personalizadas.  Este software se licencia bajo la BSD License, lo que permite que sea incluído en paquetes de código abierto o comerciales.   Por defecto, OpenSimulator puede simular un entorno virtual de Second Life™ (incluyendo la compatibilidad con su cliente). Otros ambientes, protocolos y características pueden ser soportadas mediante módulos añadidos.

Tomado de http://opensimulator.org/.

Instalar Mono.

# pacman -S mono unzip

# mono --version

Mono JIT compiler version 2.6.7 (tarball Sun Jul 25 19:50:39 CEST 2010)
Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
TLS:           __thread
GC:            Included Boehm (with typed GC and Parallel Mark)
SIGSEGV:       altstack
Notifications: epoll
Architecture:  amd64
Disabled:      none

# vi /etc/rc.conf

DAEMONS=(... mono)

Crear usuario opensim.

# /usr/sbin/useradd -m -g users -s /bin/bash -c “OpenSimulator” opensim

# passwd -l opensim

Instalar OpenSim.

# wget http://dist.opensimulator.org/opensim-0.7-bin.tar.gz

# tar zxvf opensim-0.7-bin.tar.gz

# mv opensim-0.7-bin /home/opensim/0.7

# chown -R opensim:users /home/opensim/0.7

# ln -s /home/opensim/0.7 /opt/opensim

Iniciar OpenSim.

# su -c /opt/opensim/bin/opensim-ode.sh opensim

Configurar OpenSim por primera vez.

=====================================
We are now going to ask a couple of questions about your region.

You can press ‘enter’ without typing anything to use the default

the default is displayed between [ ]: brackets.
=====================================

New region name []: Playing Region
Region UUID [18d5fc00-1452-4876-bb46-6f75c06387a6]:
Region Location [1000,1000]:
Internal IP address [0.0.0.0]:
Internal port [9000]:
Allow alternate ports [False]:
External host name [SYSTEMIP]:

Your region is not part of an estate.
Do you wish to join an existing estate? [no]:
New estate name [My Estate]: Playing Estate

The current estate has no owner set.
Estate owner first name [Test]: Master
Estate owner last name [User]: Player
Password: testing
Email []:

Enlaces.

• Open Simulator.
  http://opensimulator.org/
  • Descargar.
    http://opensimulator.org/wiki/Download
  • Archivos de la distribución.
    http://dist.opensimulator.org/
• Running OpenSim for first time.
  http://opensimulator.org/wiki/Configuration#Running_OpenSim_for_the_first_time
• Instalación OpenSimulator 0.7 RC2.
  http://www.marlonj.com/blog/2010/07/pulsar-project-instalacion-opensimulator-0-7-rc-2/
• Mono, ArchLinux.
  http://wiki.archlinux.org/index.php/Mono

Una de las características interesantes de ArchLinux es que la instalación básica incluye únicamente los paquetes realmente necesarios para su funcionamiento inicial, siendo responsabilidad del administrador instalar los demás paquetes que se requieran.  Esto es muy importante ya que, a diferencia de otras distribuciones, se disminuye el tiempo de instalación, el consumo de recursos y se reducen los riesgos de seguridad.

ArchLinux inclusive no incluye por defecto el servicio de SSH el cual debe ser instalado manualmente.  En ese artículo se describe el proceso de instalación y configuración del servicio de SSH en ArchLinux.

Instalación.

# pacman -S openssh

Configuración.

Configuración del cliente.

# vi /etc/ssh/ssh_config

Port 22
Protocol 2
HashKnownHosts yes
StrictHostKeyChecking ask

Configuración del servidor.

# vi /etc/ssh/sshd_config

Port 22
Protocol 2
LoginGraceTime 2m
PermitRootLogin no

Configuración del servicio.

Configurar el inicio automático con el sistema operativo.

# vi /etc/rc.conf

DAEMONS=(... sshd)

Iniciarlo, detenerlo o reiniciarlo manualmente.

# /etc/rc.d/sshd {start|stop|restart}

Permitir el acceso al servicio desde otros equipos.

# vi /etc/hosts.allow

sshd: 192.168.1.

Enlaces.

• Servicio de SSH, ArchLinux.
  http://wiki.archlinux.org/index.php/SSH

$ sudo aptitude install build-essential

ArchLinux.

# pacman -S base-devel

ArchLinux es una distribución que me sigue pareciendo interesante, especialmente por su rapidez y transparencia en términos de los paquetes que instala: únicamente los solicitados.  Por ahora es la distribución que estoy utilizando para hacer las pruebas y experimentos que se me ocurren, a excepción del proyecto de Grid que requiere explícitamente utilizar nodos con Scientific Linux.

Aparentemente esta distribución no se encuentra basada en ninguna otra que haya utilizado anteriormente, esto trae para mi un agradable obstáculo ya que desconozco como realizar la mayoría de los procedimientos habituales como cambiar el hostname, activar sudo o actualizar sus paquetes entre muchas otras cosas.  Así que todo es nuevo y todo debe ser explorado y experimentado lo que me hace evocar recuerdos de hace mas de 10 años cuando cuando me iniciaba en el uso de Linux.

En este artículo se describe como realizar la configuración de una dirección IP dinámica gracias a DHCP y su contraparte estática, la cual tiene un detalle muy pequeño pero importante con su puerta de enlace.

Procedimiento.

Configuración de la IP dinámica.

# vi /etc/rc.conf

eth0=”dhcp”
INTERFACES=(eth0)

Configuración de una IP estática.

# vi /etc/rc.conf

eth0=”eth0 192.168.1.222 netmask 255.255.255.0 broadcast 192.168.1.255”
INTERFACES=(eth0)
gateway=”default gw 192.168.1.1”
ROUTES=(gateway)

Nótese que se removió el símbolo (!) de la variable gateway en la asignación de ROUTES, si esto no se realiza, el enrrutador por defecto no será agregado a las rutas estáticas definidas al inicio del sistema operativo.

Para hacer unas pruebas esta tarde necesito un proxy que haga caché sobre los datos descargados; inicialmente iba a instalar Squid sobre un Scientific Linux pero decidí hacerlo sobre ArchLinux, con el cual estoy jugando desde el día de ayer.  Leyendo la documentación del wiki de ArchLinux, que por cierto es muy buena, encontré que hacen referencia a Polipo, un software similar en funciones a Squid pero con mayores limitaciones y destinado a servidores con muy pocos usuarios.  Ese es mi caso, así que procedí a instalarlo en una máquina virtual con VirtualBox y 512MB de RAM.  Espero que aguante.

Instalación de los paquetes.

Desafortunadamente lo paquetes de Polipo no están disponibles en los repositorios, sin embargo estos pueden ser creados utilizando una facilidad interesante del sistema operativo.

Los siguientes pasos deben realizarse como un usuario sin privilegios.

Descargar la versión mas reciente de los archivos (sección de files) de Polipo de la siguiente ubicación.

http://aur.archlinux.org/packages.php?ID=14579

$ wget http://aur.archlinux.org/packages/polipo/polipo/PKGBUILD

$ wget http://aur.archlinux.org/packages/polipo/polipo/polipo.install

$ wget http://aur.archlinux.org/packages/polipo/polipo/polipo

Generar el paquete.

$ makepkg -s

Instalar el paquete recién generado.

$ sudo pacman -u polipo-1.0.4.1-1-x86_64.pkg.tar.xz

Configuración de Polipo.

Crear un archivo básico de configuración a partir de la plantilla.

$ sudo cp /etc/polipo/config-sample /etc/polipo/config

Permitir las conexiones externas, además de localhost.

$ sudo vi /etc/polipo/config

proxyAddress = “0.0.0.0″

Si se desea permitir el uso del caché por equipos diferentes del mismo (localhost)  es necesario especificar las redes autorizadas en la siguiente variable del mismo archivo config.  Nótese que, a diferencia del ejemplo en el mismo archivo, fue necesario remover las comillas dobles que encerraban las direcciones de red.

allowedClients = 127.0.0.1, 10.0.0.0/16, 192.168.1.0/24

Actualizar el archivo de inicio de Polipo.  Nótese en el script que por razones de seguridad se utilizará al usuario nobody para ejecutar el servicio.

$ sudo cp /etc/rc.d/polipo /etc/rc.d/polipo.orig

$ sudo vi /etc/rc.d/polipo

#!/bin/bash
. /etc/rc.conf
. /etc/rc.d/functions
DAEMON=polipo
ARGS="daemonise=true pidFile=/var/run/$DAEMON/$DAEMON.pid"
PID=`pidof -o %PPID /usr/bin/$DAEMON`
case $1 in
    start)
        stat_busy "Starting $DAEMON"
        rm /var/run/$DAEMON/$DAEMON.pid 2> /dev/null
        install -d /var/run/$DAEMON
        ## /usr/bin/$DAEMON $ARGS >/dev/null 2>&1
        sudo -u nobody /usr/bin/$DAEMON $ARGS >/dev/null 2>&1
        if [[ $? != 0 ]]; then
            stat_fail
        else
            add_daemon $DAEMON
            stat_done
        fi
    ;;
    stop)
        stat_busy "Stopping $DAEMON"
        kill $PID >/dev/null 2>&1
        if [[ $? != 0 ]]; then
            stat_fail
        else
            rm_daemon $DAEMON
            stat_done
        fi
    ;;
    purge)
        stat_busy "Purging polipo"
        [[ ! -d /var/run/polipo ]] && mkdir /var/run/polipo
        if ! ck_daemon polipo; then
            kill -USR1 $DAEMON >/dev/null 2>&1 || stat_die $?
            sleep 1
            /usr/bin/$DAEMON -x $ARGS >/dev/null 2>&1 || stat_die $?
            kill -USR2 $PID >/dev/null 2>&1 || stat_die $?
            stat_done
        else
            /usr/bin/$DAEMON -x $ARGS >/dev/null 2>&1 || stat_die $?
            stat_done
        fi
    ;;
    restart)
        $0 stop
        sleep 1
        $0 start
    ;;
    *)
        echo "usage: $0 {start|stop|restart|purge}"
    ;;
esac

Ajustes al sistema operativo.

Crear un proceso cron para purgar el servicio.

$ sudo vi /etc/cron.weekly/polipo

#!/bin/sh
/etc/rc.d/polipo purge >/dev/null 2>&1

$ sudo chmod +x /etc/cron.weekly/polipo

Crear las rutas necesarias para los archivos del proxy.

$ sudo touch /var/log/polipo

$ sudo chown nobody:nobody /var/log/polipo

$ sudo mkdir /var/run/polipo

$ sudo chown nobody:nobody /var/run/polipo

$ sudo mkdir /var/cache/polipo

$ sudo chown nobody:nobody /var/cache/polipo

Configurar el inicio automático de Polipo con el sistema operativo.

$ sudo vi /etc/rc.conf

DAEMONS=(syslog-ng network netfs polipo crond)

Prueba del caché.

Configure el proxy de Firefox o de cualquier otro cliente y acceda a los recursos que desee, estos deberán almacenarse en el caché por lo cual futuros accesos (recuerde limpiar el caché local de ser necesario para hacer mas confiable la prueba) deberían ser más rápidos.  Como ubicación del servidor de caché utilice la IP del servidor donde se instaló Polipo y el puerto -por defecto- 8123.

Enlaces.

• Polipo - a caching web proxy.
  http://www.pps.jussieu.fr/~jch/software/polipo/
• Polipo en ArchLinux.
  http://wiki.archlinux.org/index.php/Polipo

Después de instalar ArchLinux su hostname es, si no fue modificado durante el proceso de instalación, myhost el cual no dice mucho de la destinación del servidor.  A continuación se presentan los breves pasos necesarios para configurar adecuadamente el hostname del servidor.

Configurar el hostname.

# vi /etc/rc.conf

HOSTNAME=”cache.jorgeivanmeza.com“

Actualizar el archivo de hosts para que refleje los cambios del nuevo nombre.  En mi caso la dirección se obtiene por DHCP así que asocio el hostname a la dirección local, si fuera estática sería conveniente hacerlo a esta.

# vi /etc/hosts

127.0.0.1     cache.jorgeivanmeza.com cache localhost.localdomain localhost

Reiniciar el servidor para que los cambios sean tenidos en cuenta.

# reboot

Enalces.

• Configuring the network con ArchLinux.
  http://wiki.archlinux.org/index.php/Configuring_Network#Set_the_hostname