Apache con certificado emitido por CA propia

December 19th, 2009

En el artículo Apache con SSL se indican los pasos para crear un certificado y utilizarlo para habilitar el acceso cifrado por HTTPS al servidor Apache. El único inconveniente es que el usuario del contenido cifrado recibirá en su navegador una advertencia ya que el certificado no ha sido emitido por ninguna autoridad de certificación (CA) y, por tanto, no hay forma de verificar la autenticidad del sitio web.

Si se ha comprado el certificado a una autoridad de certificación, entonces el resto del contenido del artículo es igualmente válido y la CA garantizará la validez del certificado.

Si no se desea comprar un certificado se puede crear una CA propia para un entorno determinado siguiendo los siguientes pasos.

Creación de una autoridad de certificación (CA) raíz

En primer lugar se crea un directorio para todos los ficheros relacionados con la CA:

$ mkdir ~/ACME-CA

Se comprobará que el fichero /etc/ssl/openssl.cnf tiene en la variable dir el directorio creado.

A continuación se crea un certificado autofirmado para la CA. Para el nombre común (CN) se recomienda indicar algo como “Certificado raíz ACME”.

$ openssl req -config /etc/ssl/openssl.cnf -new -x509 -keyout newreq.pem \
-out newreq.pem -days 365

Si durante la creación del certificado se recibe el error “unable to write ‘random state’” puede que previamente se haya intentado ejecutar openssl como root y el fichero ~/.rnd no permita la escritura al usuario que ejecuta openssl. Si es así bastará con hacer propietario al usuario correspondiente.

Una vez ejecutada la orden se tendrán en el fichero newreq.pem la clave privada (parte RSA PRIVATE KEY) y el certificado (parte CERTIFICATE). Cada una de estas partes se guardará en un fichero distinto, la clave en ~/ACME-CA/private/cakey.pem y el certificado en ~/ACME-CA/cacert.pem. A continuación se puede eliminar newreq.pem.

Instalación del certificado de la CA raíz como certificado raíz de confianza

Se puede proporcionar acceso al certificado raíz publicándolo en http://sitio.tld/ssl/cacert.crt para que cualquier visitante pueda instalarlo en su navegador. Hay que tener en cuenta que si alguien presenta una web falsa, en lugar de la legítima, también podría proporcionar su propio certificado raíz falso desde dicha web.

El fichero a publicar debe contener exclusivamente el certificado, éste se obtiene así:

$ openssl x509 -in cacert.pem -out cacert.crt

Una vez disponible el certificado, un usuario podrá descargarlo e importarlo en la lista de certificados raíz de CA de confianza.

Preparación de la CA raíz

Antes de crear el certificado que se utilizará para el cifrado hay que comprobar que se disponga en ~/ACME-CA de los siguientes directorios

newcerts
private

y de los siguientes ficheros

index.txt
serial

El fichero index.txt deberá estar vacío y el serial contener únicamente la cadena “01″, sin las comillas, como siempre.

Creación del certificado del sitio

Ahora ya se puede crear un certificado emitido por la CA raíz propia y que será considerado válido por cualquier navegador que confíe en dicha CA raíz. Para ello se genera una clave privada y una solicitud de certificado en el fichero newreq.pem:

$ openssl req -config /etc/ssl/openssl.cnf -new -keyout newreq.pem \
-out newreq.pem -days 365

En este paso hay que proporcionar el nombre del sitio web (dominio sin protocolo ni directorios) para el que se genera el certificado en el campo “Nombre común” (CN), de lo contrario, los navegadores que accedan al sitio detectarán que el certificado no ha sido emitido para dicho sitio, aunque provenga de una CA raíz de confianza. Si lo que se desea es cifrar emails habrá que indicar la dirección de correo electrónico como nombre común.

Ahora se firma la solicitud con el certificado de la CA y se crea el certificado para el sitio. Habrá que proporcionar la clave del certificado cacert.pem.


$ openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything \
-out newcert.pem -infiles newreq.pem

Esta orden provocará la creación del certificado en el fichero newcert.pem y en el directorio newcerts con el nombre xx.pem, donde xx será el número indicado en el fichero serial. La clave privada se guarda en newreq.pem. Los ficheros serial e index.txt también son actualizados para reflejar la creación del certificado.

Instalación del certificado y la clave en Apache

Este paso ya corresponde con lo explicado en el artículo Apache con SSL, salvo que en esta ocasión se proporciona un fichero para la clave y otro para el certificado en vez de proporcionar ambos en un mismo fichero.

La clave utilizada por Apache no debe estar protegida por clave, por lo que hay que obtener una versión no segura de la calve generada:

$ openssl rsa -in newreq.pem -out wwwCLAVE-NO-SEGURA.pem

Este fichero deberá estar de alguna forma protegido contra accesos no deseados.

Ahora se copian los ficheros newcert.pem y wwwCLAVE-NO-SEGURA.pem a alguna ruta accesible por Apache y se configura para utilizarlos en el fichero de configuración de Apache correspondiente:


# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with `make certificate' under
# built time.
#SSLCertificateFile conf/ssl/ca.crt
SSLCertificateFile sitio.tld.cert.pem
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file.
#SSLCertificateKeyFile conf/ssl/ca.key.unsecure
SSLCertificateKeyFile wwwCLAVE-NO-SEGURA.pem

Un reinicio del servidor Apache y los navegadores que visiten el sitio detectarán que el certificado ha sido emitido por la CA raíz creada y, si confían en ella, admitirán el certificado como válido sin advertir al usuario sobre posibles riesgos.

$ sudo service apache2 restart

o

$ sudo /etc/init.d/apache2 restart

Si el servidor Apache falla al reiniciar puede que se deba a que no localiza el fichero de clave o el de certificado. Habrá que comprobar si la ruta proporcionada es válida y, si lo es, el contenido de los ficheros.

Referencias

SSL Certificates HOWTO

Crear interfaces virtuales para VirtualBox

November 23rd, 2009

Este procedimiento surge de la necesidad de crear interfaces virtuales para su uso por distintas máquinas virtuales de VirtualBox ejecutadas sobre un equipo anfitrión Kubuntu, pero es válido para cualquier otra situación en la que se necesiten crear interfaces virtuales en una máquina interconectados entre sí virtualmente.  En otras distribuciones debe bastar con sustituir los comandos de obtención de paquetes y poco más.

El procedimiento consiste en crear un interfaz bridge que sirva de conexión entre los interfaces virtuales y entre éstos y el resto de interfaces de la máquina. Para crear este tipo de interfaz se necesita instalar el paquete bridge-utils:

# apt-get install bridge-utils

También hará falta el paquete uml-utilities (no relacionado con diagramas UML, sino con User-Mode Linux):

# apt-get install uml-utilities

Puesto que en este caso se desea que estos interfaces estén disponibles siempre que se inicie la máquina se ha elaborado un conjunto de scripts que puedan configurarse para su ejecución al inicio del sistema y que capturan parte de la configuración de un fichero para facilitar la modificación del conjunto de interfaces virtuales deseados.

Hay un script principal pensado para aceptar los parámetros start y stop de modo que pueda configurarse como un servicio más y arranque automáticamente en los niveles de ejecución deseados y se detenga al salir de los mismos. Este será /etc/init.d/netbridges.

Dicho script utilizará a su vez otros cuatro destinados cada uno de ellos a una de las funciones para crear y eliminar los interfaces virtuales y habilitar y deshabilitar el encaminamiento de paquetes desde el interfaz bridge y sus interfaces con el resto de interfaces de la máquina para permitir a estos interfaces virtuales la comunicación con el exterior de la máquina anfitrión. Estos estarán situados en /usr/local/sbin y se llamarán addtap, deltap, nattap y unnattap respectivamente. Tanto addtap como deltap accederán al fichero /etc/local/network-bridges.conf para preparar la lista de interfaces virtuales a crear/eliminar, que estará formada por $NUMBER_OF_VM interfaces virtuales numerados desde $NB y por los interfaces separados por espacios indicados en $NAMED_TAPS.

/etc/local/network-bridges.conf

NUMBER_OF_VM=2
NB=1
NAMED_TAPS="tap_win"

Cada interfaz, a su vez, puede incluir comandos específicos de configuración en un fichero con el nombre tap<numero>.conf o <nombre>.conf situado en /etc/local/netbridges.d/:

/etc/local/netbridges.d/tap1.conf

ifconfig tap1 hw ether 00:ff:10:01:01:10

Los scripts son:

/etc/init.d/netbridges

#!/bin/sh -e                                         
### BEGIN INIT INFO                                  
# Provides:          netbridges                      
# Required-Start:    $network                        
# Required-Stop:     ifupdown $local_fs              
# Default-Start:     2                               
# Default-Stop:                                      
# Short-Description: Raise bridge network interfaces.
### END INIT INFO                                    

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"

[ -x /sbin/ifup ] || exit 0

. /lib/lsb/init-functions

case "$1" in
start)      
 log_action_begin_msg "Configuring network bridge interfaces"

 if [ "$VERBOSE" != no ]; then
 if addtap; then          
 log_action_end_msg $?
 else                     
 log_action_end_msg $?
 fi                       
 else                         
 if addtap >/dev/null 2>&1; then
 log_action_end_msg $?      
 else                           
 log_action_end_msg $?      
 fi                             
 fi                                 

 unnattap
 nattap  
 ;;      

stop)
 log_action_begin_msg "Removing NAT with network bridge interfaces"

 unnattap

 log_action_begin_msg "Removing network bridge interfaces"

 if deltap >/dev/null 2>&1; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi
 ;;

force-reload|restart)
 if $0 stop; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi

 if $0 start; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi

 ;;

*)
 echo "Usage: /etc/init.d/netbridges {start|stop|restart|force-reload}"
 exit 1
 ;;
esac

exit 0

/usr/local/sbin/addtap

#!/bin/sh                                          
# set PATH for the case we are called via sudo or su root

PATH=/sbin:/usr/sbin:/bin:/usr/bin
USER=usuario_virtualbox                          

NUMBER_OF_VM=2
NB=1          

$LOCAL_ERRORS=0

if [ -f /etc/local/network-bridges.conf ];
then                                      
 . /etc/local/network-bridges.conf       
fi                                        

# create the bridge
brctl addbr br0    

# create the taps and insert them into the bridge

while [ $NB -le $NUMBER_OF_VM ];
do
 tunctl -t tap$NB -u $USER
 `cat /etc/local/netbridges.d/tap$NB.conf`
 ip link set up dev tap$NB
 brctl addif br0 tap$NB
 if ifconfig tap$NB; then
 echo Tun interface created: tap$NB
 else
 LOCAL_ERRORS=`expr $LOCAL_ERRORS + 1`
 fi
 NB=`expr $NB + 1`
 done

for TAP_NAME in $NAMED_TAPS; do
 tunctl -t $TAP_NAME -u $USER
 `cat /etc/local/netbridges.d/$TAP_NAME.conf`
 ip link set up dev $TAP_NAME
 brctl addif br0 $TAP_NAME
 if ifconfig $TAP_NAME; then
 echo Tun interface created: $TAP_NAME
 else
 LOCAL_ERRORS=`expr $LOCAL_ERRORS + 1`
 fi
done

# set the IP address and routing
ip link set up dev br0
ip addr add 10.1.1.1/24 dev br0
ip route add 10.1.1.0/24 dev br0 2> /dev/null

echo $LOCAL_ERRORS

/usr/local/sbin/deltap

#!/bin/sh
# set PATH for the case we are called via sudo or su root

PATH=/sbin:/usr/sbin:/bin:/usr/bin
USER=usuario_virtualbox

NUMBER_OF_VM=2
NB=1

if [ -f /etc/local/network-bridges.conf ];
then
 . /etc/local/network-bridges.conf
fi

# remove the taps and extract them from the bridge

while [ $NB -le $NUMBER_OF_VM ];
do
 sudo brctl delif br0 tap$NB
 tunctl -d tap$NB
 NB=`expr $NB + 1`
 echo Tun interface deleted: tap$NB
done

for TAP_NAME in $NAMED_TAPS; do
 sudo brctl delif br0 $TAP_NAME
 tunctl -d $TAP_NAME
 echo Tun interface deleted: $TAP_NAME
done

# remove the bridge
ip link set down dev br0
brctl delbr br0

/usr/local/sbin/nattap

#!/bin/bash

INTIF="br0"
EXTIF="wlan0"
echo 1 > /proc/sys/net/ipv4/ip_forward

# clear existing iptable rules, set a default policy
iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
#iptables -P FORWARD DROP
iptables -P FORWARD ACCEPT
iptables -F FORWARD
iptables -t nat -F

# set forwarding and nat rules
iptables -A FORWARD -i $EXTIF -o $INTIF -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

# enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/ip_dynaddr

/usr/local/sbin/unnattap

# remove NAT rule
iptables -t nat -F
# disable forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

Bueno, pues eso es todo, los scripts podrían estar un poco mejor hechos, sobre todo con más información tomada del fichero de configuración, pero como base sirven.

Compilar un módulo del kernel

November 23rd, 2009

En ocasiones se necesita compilar un módulo del kernel de Linux a partir de sus fuentes. Para ello hay que utilizar las cabeceras y, ocasionalmente, los ficheros fuente del propio núcleo y hacer un make indicando la ruta hacia las fuentes del núcleo o incluyendo el código fuente del módulo en el lugar apropiado dentro de dichas fuentes.

En el caso que se detalla las fuentes del módulo se encontraban dentro de la estructura completa de las fuentes del núcleo. El módulo en cuestión era el rt61pci situado en el directorio drivers/net/wireless/rt2×00/ . Para compilarlo sin tener que compilar todo el núcleo hay que preparar las fuentes del núcleo para la compilación de un módulo externo y después indicar qué módulo se quiere compilar:

$ make modules_prepare
$ make M=drivers/net/wireless/rt2x00 modules

Y listo, en unos minutos se obtiene compilado el módulo requerido sin tener que compilar todo el núcleo.

De ext3 a ext2

November 21st, 2009

Para hacer lo posible por alargar la vida de mi memoria USB, decidí pasar sus particiones ext3 a ext2 para deshacerme del “Journal” y sus numerosas escrituras. No estoy seguro de que esto sea efectivo, pero tampoco veo razón por la que pueda ser perjudicial, así que busqué y encontré este artículo de Enrique Barbeito García donde se describen los principales pasos.

Básicamente lo único que hay que hacer es desmontar la partición si está montada e indicar que el sistema de ficheros de dicha partición ya no debe tener “Journal”, que es la diferencia entre un sistema de ficheros ext3 y uno ext2. Esto se hace con el comando ‘tune2fs’.

# tune2fs-O ^has_journal /dev/sdc4

Con esta orden se elimina el “Journal” y se puede montar la partición como ext2, aunque para ello hay que indicarlo explícitamente.

# mount -t ext2 /dev/sdc4 /media/sdc4

Para que no haya que indicar explícitamente el tipo de sistema de ficheros hay que actualizar la información del núcleo sobre esta partición, para lo que se utiliza el comando ‘partprobe’, así el “Notificador de dispositivos” será capaz también de montar la partición sin tener que reiniciar ni retirar el dispositivo USB.

# partprobe /dev/sdc

Distinguir sesión local de sesión por SSH

September 8th, 2009

En uno de mis equipos cargo al inicio de sesión pulseaudio, pero también se intentaba cargarlo cuando iniciaba sesión por SSH, fallando la carga del programa aunque continuando el inicio de sesión sin ninguna consecuencia.

A pesar de que no molestaba el intento de carga de pulseaudio, sí que me molestaba a la vista ver un error al iniciar sesión en mi flamante Linux, así que busqué y encontré esta precisa referencia cuyo contenido reproduzco por si las moscas.

http://blog.rodrigorega.es/distinguir-una-sesion-local-de-una-remota-en-linux/

Me he encontrado con la necesidad de programar un pequeño script en bash para el servidor Linux de un cliente. Dicho script estaba funcionando correctemente en la máquina local pero no así cuando se realizaba una conexión remota.

Ante esto era preciso encontrar alguna manera de discernir entre las conexiones locales y remontas para realizar configuraciones diferentes para cada una.

La solución, sencilla y un tanto ingeniosa, pasó por utilizar variables de entorno para hacer la distinción entre conexión local y remota:

1.if [[ -z "$REMOTEHOST" &&  -z "$SSH_CLIENT" ]]; then
2.echo "Cliente conectado en local";
3.else
4.echo "Cliente conectado en remoto";
5.fi

Se comprueba que no existan las variables de entorno $REMOTEHOST ni $SSH_CLIENT, la primera está presente en conexiones telnet y la segunda en conexiones SSH. Si no existe ninguna de ellas la conexión es local, si existe alguna de ellas la conexión es remota.

Me he encontrado con la necesidad de programar un pequeño script en bash para el servidor Linux de un cliente. Dicho script estaba funcionando correctemente en la máquina local pero no así cuando se realizaba una conexión remota.

Ante esto era preciso encontrar alguna manera de discernir entre las conexiones locales y remontas para realizar configuraciones diferentes para cada una.

La solución, sencilla y un tanto ingeniosa, pasó por utilizar variables de entorno para hacer la distinción entre conexión local y remota:

1.if [[ -z "$REMOTEHOST" &&  -z "$SSH_CLIENT" ]]; then
2.echo "Cliente conectado en local";
3.else
4.echo "Cliente conectado en remoto";
5.fi

Se comprueba que no existan las variables de entorno $REMOTEHOST ni $SSH_CLIENT, la primera está presente en conexiones telnet y la segunda en conexiones SSH. Si no existe ninguna de ellas la conexión es local, si existe alguna de ellas la conexión es remota.

Instalación de módem HSDPA K3520 de Huawei en Linux

August 4th, 2009

Los pasos descritos corresponden a la instalación para Kubuntu 64 bits. Aunque exceptuando la descarga de los paquetes debería ser similar en el resto de distribuciones y plataformas.

El primer paso es descargar los paquetes desde http://forge.betavine.net allí, con toda probabilidad, aparecerá como proyecto más descargado el Vodafone Mobile Connect Card driver. En el caso de Ubuntu AMD64 hay que descargar los paquetes ozerocdoff, usb-modeswitch y vodafone-mobile-connect.

Estos paquetes habrá que instalarlos en el orden que se han nombrado, pero antes hay que satisfacer las dependencias que tienen de otros paquetes.

En la instalación de la que surge este artículo se encontraron problemas con la versión de los paquetes ya instalados, pues en la máquina donde se instaló se había intentado instalar trac y las versiones de python no eran las del repositorio. Así que hubo que reinstalar las versiones oficiales para poder descargar el resto de paquetes necesarios sin problemas.

$ sudo aptitude --purge install python-gnomecanvas

Ahora se puede continuar con la instalación de ozerocdoff.

$ sudo dpkg -i ozerocdoff_0.4_amd64.deb

Se continua con las dependencias del paquete vodafone-mobile-connect.

$ sudo apt-get install python-crypto python-gnome2 python-sqlite python-twisted python-tz
$ sudo apt-get install python-gnome2-extras

En el equipo donde se realizó la instalación no se pudo instalar python-gnome2-extras y también se necesitó forzar la actualización de algunos paquetes a la versión oficial para poder instalarlo.

$ sudo aptitude --purge install python-gnome2-extras libgdl-1-0 libgtkspell0 python-gnome2-desktop

Y se termina con la instalación de usb-modeswitch y vodafone-mobile-connect.

$ sudo dpkg -i usb-modeswitch_0.9.7_amd64.deb
$ sudo dpkg -i vodafone-mobile-connect_2.10.01-1_all.deb

Ahora debería estar todo preparado para conectar el módem  y ejecutar la aplicación de conexión.

$ vodafone-mobile-connect-card-driver-for-linux

La aplicación de conexión requiere introducir los datos de conexión que para Vodafone España son los siguientes:

Usuario: vodafone
Contraseña: vodafone
Modo de autenticación: Predefinido
Host APN: ac.vodafone.es
Usar DNS estáticos
DNS primario: 212.73.32.3
DNS secundario: 212.73.32.67

Referencias:

http://usrweblog.wordpress.com/2008/09/22/instalar-modem-3g-huawei-k3520-en-kubuntu/
http://www.grupobonatel.com/modem-usb-vodafone-en-linux-mobile-connect/#more-537

Instalación de REM 1.2.2 sobre wine

July 4th, 2009

La Universidad de Sevilla hace disponible de forma gratuita (aunque rellenando un formulario) el programa REM 1.2.2 (REquirement Management) que permite documentar y realizar matrices de trazabilidad de requisitos, objetivos, actores, etc.

El problema es que la aplicación sólo está disponible para plataformas Windows, por lo que hay que utilizar wine para poder ejecutarlo en Linux.

Por tanto, lo primero es instalar wine si no está ya instalado:

$ sudo apt-get install wine

Instalación

Una vez descargado el fichero comprimido zip de REM lo primero es descomprimirlo:

$ mkdir rem_1.2.2
$ cd rem_1.2.2
$ unzip ~/REM_1_2_2.zip
$ wine SETUP.EXE

Para ejecutar el instalador se requiere la librería del motor JET 4.0, sin ella la instalación no podrá realizarse y terminará sin éxito. Para instalar esta y otras librerías se puede utilizar la herramienta winetricks que automatiza la instalación de múltiples librerías, evitando tener que buscarlas e instalarlas manualmente.

Así que se descarga la aplicación winetricks, se instala la libería JET 4.0 y se repite la instalación de REM 1.2.2.

$ wget http://www.kegel.com/wine/winetricks
$ sh winetricks jet40
$ wine SETUP.EXE

Ahora la instalación deberá completarse con éxito. No hay que olvidar editar el fichero “C:\Archivos de Programa\REM 1.2.2\xml\default\REM_TraceImage.xsl” y eliminar el último caracter del mismo. La ruta para localizar el fichero será así: ~/.wine/drive_c/Archivos de programa/REM 1.2.2/xml/default.

Ejecución

Para lanzar el programa se ejecuta la siguiente orden desde un terminal:

$ wine ~/.wine/drive_c/Archivos\ de\ programa/REM\ 1.2.2/bin/REM_1_2_2.exe

Si aún faltan librerías wine informará sobre los errores producidos durante la ejecución incluyendo el nombre de las librerías no encontradas si éste es el problema:

err:module:import_dll Library MFC42.DLL (which is needed by L"Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe") not found                                                                          
err:module:import_dll Library MSVCP60.dll (which is needed by L"Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe") not found                                                                        
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe" failed, status c0000135

Estos errores advierten la imposibilidad de cargar las librerías MFC42.DLL y MSVCP60.dll, lo que provoca el cierre del programa. Para instalar las librerías se recurre de nuevo a winetricks y se lanza de nuevo el programa:

$ sh winetricks vcrun6
$ sh winetricks mfc42
$ wine ~/.wine/drive_c/Archivos\ de\ programa/REM\ 1.2.2/bin/REM_1_2_2.exe

Y con eso aparece la ventana del programa.

Contenido HTML

Aunque el programa arranque necesita hacer uso de las librerías de Internet Explorer para representar el contenido HTML generado por la herramienta. Para ello se instala Internet Explorer 6 mediante winetricks y el motor gecko para representación de contenido HTML.

$ sh winetricks ie6 gecko

Con esto no fue suficiente, así que la herramienta funciona pero los resultados no se ven.

¿Sugerencias?

Gracias al comentario de Juan se resuelve el último problema en la ejecución de REM instalando las librerías XML necesarias mediante el siguiente comando:

$ sh winetricks msxml3

Por fin, no se necesita más utilizar una máquina virtual con Windows para poder ejecutar REM.

Nueva actualización. Es posible que al ejecutar

$ sh winetricks ie6

se obtenga el error “The download location information is damaged”. Este problema se ha arreglado estableciendo en winecfg el tipo de unidad para la unidad Z:. Los pasos son ejecutar winecfg, ir a la pestaña de “Unidades”, pulsar el botón “Mostrar avanzado”, seleccionar la unidad Z: y establecer el tipo a “Disco duro local”. Una vez hecho esto la ejecución de la instalación de ie6 volvió a fallar de la misma forma, pero al repetir el intento funcionó, tal como se advertía que podía ocurrir en la siguiente referencia:

http://appdb.winehq.org/objectManager.php?sClass=version&iId=469&iTestingId=34487

Instalación de Trac en Dreamhost

May 18th, 2009

Lo conseguí, después de varias sesiones de intentos fallidos, he configurado un servidor Trac en Dreamhost y, de alguna manera, lo he puesto en funcionamiento. A continuación describo el procedimiento resultante.

Referencias:

Requisitos

En primer lugar se asegura el cumplimiento de los requisitos indicado en el documento para la instalación de Trac en Dreamhost mediante dreamy-trac. Estos pasos no deben ser así necesariamente, pero hacerlo de este modo simplifica las cosas:

  1. Crear un dominio nuevo para el servidor Trac y asociarlo a una cuenta de usuario nueva.
    Supóngase el dominio miservidortrac.org y la cuenta de usuario miusuariotrac.
  2. Configurar la cuenta de usuario miusuariotrac con acceso shell.
  3. Crear desde el apartado Subversión de la categoría Goodies del menú de Dreamhost un repositorio SVN. El ID de proyecto del repositorio será mirepositoriosvn, se indicará al menos el usuario miusuariotrac con una contraseña y el resto de usuarios que deseemos. Si no se quiere más que uno habrá que eliminar el resto de líneas de usuarios. Opcionalmente se marca ls casilla “DAV Autoversioning”.
  4. Comprobar que el dominio miservidortrac.org es propiedad del usuario miusuariotrac y que tiene FastCGI activado.

Instalación automática con dreamy-trac

A continuación se obtiene el script de instalación y se inicia la instalación de todos los paquetes necesarios:

$ ssh miusuariotrac@mihost.dreamhost.com
[mihost]$ cd dreamy-trac
[mihost]$ ./configure.sh source
[mihost]$ source ~/.bash_profile
[mihost]$ ./install.sh
[mihost]$ chmod +x create_trac_project

A continuación se hicieron necesarios dos retoques en el fichero ~/dreamy-trac/create_trac_project:

PKG_DIR=/home/miusuariotrac
TRAC_PROJECTS_DIR=miservidortrac.org
htdocs_location = /chrome/common/

Ahora se ejecuta create_trac_project:

[mihost]$ cd ~
[mihost]$ ln -s share .
[mihost]$ dreamy-trac/create_trac_project

Los datos que se proporcionaran al instalador serán los siguientes:

  • Repositorio SVN: mirepositoriosvn
  • Proyecto Trac: miproyectotrac
  • Nombre del proyecto Trac: Mi Proyecto Trac
  • Ruta de la raíz: /home/miusuariotrac/miservidortrac.org
  • Usuario administrador: miusuariotrac

Para comenzar la ejecución de Trac lanzamos el servidor propio con nohup para que siga disponible cuando cerremos la sesión SSH.

[mihost]$ nohup tracd --port 8000 /home/miusuariotrac/miservidortrac.org/miproyectotrac &

Para comprobar si funciona se consulta http://miservidortrac.org:8000/ si todo va bien aparecerá un enlace hacia “Mi Proyecto Trac” que lleva hasta la página de inicio del sitio del proyecto. Si la página del proyecto se ve sin estilos ni imágenes habrá que hacer ciertas reparaciones:

[mihost]$ cp -rf dreamy-trac/trac/trac/htdocs/* miservidortrac.org/miproyectotrac/htdocs/

Además se modifica miservidortrac.org/miproyectotrac/conf/trac.ini:

htdocs_location = http://miservidortrac.org/miproyectotrac/htdocs/

Apache con SSL

March 19th, 2009

Para habilitar HTTPS sobre una instalación de Apache 2.2 hay, en primer lugar, que obtener los paquetes que proporcionan la S, que son openssl y ssl-cert.

# apt-get install openssl ssl-cert

A continuación se ejecuta la siguiente orden que pedirá los datos que deben introducirse en el certificado y generará éste. Para el valor nombre se espera que se proporcione la dirección del sitio (sin la cabecera de protocolo, sólo el nombre del dominio):

# openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl-cert/sitio.apache.pem -keyout /etc/apache2/ssl-cert/sitio.apache.pem

Es conveniente restringir el acceso al contenido del fichero, ya que contiene la clave privada que se utilizará para el cifrado.

# chmod 600 /etc/apache2/ssl-cert/sitio.apache.pem

A continuación se configura Apache para el uso de SSL con el certificado generado. Pata ello lo primero es revisar el contenido de /etc/apache2/ports.conf para comprobar que Apache incluye el puerto 443 entre sus puertos de escucha.

Listen 443

Habilitar el módulo ssl

# a2enmod ssl

Si sólo se quiere aplicar a ciertos sitios se crea un VirtualHost para el puerto seguro

<VirtualHost sitio:443>

incluyendo lo siguiente dentro de la sección VirtualHost

SSLEngine on
SSLCertificateFile /etc/apache2/ssl-cert/sitio.apache.pem

Si además sólo se quiere permitir el acceso por HTTPS se crea el sitio virtual para HTTP y se redirige al correcto mediante uno de los siguientes métodos:

<VirtualHost sitio:80># Método 1
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

# Método 2
#    RewriteEngine On
#    RewriteCond %{SERVER_PORT} !^443$
#    RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [L,R]
</VirtualHost>

Ahora se reinicia Apache

# /etc/init.d/apache2 restart

Si falla la redirección y en el reinicio de Apache da un error

Could not reliably determine the server’s fully qualified domain name

habrá que proporcionar el nombre del servidor en la sección principal de la configuración (httpd.conf)

Servername    nombre.servidor.tld

Referencias:

  • http://www.debianadmin.com/install-and-configure-apache2-with-php5-and-ssl-support-in-debian-etch.html
  • http://albertoliva.com/index.php/2007/01/24/redirigir-el-puerto-http-al-https-en-apache/

Instalar el entorno “GNOME Desktop Environment” en CentOS 5 Server

March 15th, 2009

Pues eso, cómo instalar el escritorio Gnome sobre una instalación de CentOS 5 Server (sin entorno gráfico).

Primero se actualiza el sistema y, si es el caso, se configura el teclado en español, ya que es más intuitivo cuando al pulsar la tecla del ‘-’ sale un ‘-’ en vez de un ‘/’ de los teclados americanos:

# yum update
# echo KEYBOARDTYPE=”pc” > /etc/sysconfig/keyboard
# echo KEYTABLE=”es” >> /etc/sysconfig/keyboard
# mkdir -p /lib/kbd/keymaps/i386/qwerty
# cp /lib/kbd/keymaps/i386/qwerty/es* /lib/kbd/keymaps/i386/qwerty
# yum install kbd

Ahora se instala el servidor X:

# yum install "X Window System"

A continuación el escritorio Gnome:

# yum install "GNOME Desktop Environment"

Esta instalación falla por una dependencia incumplida para el paquete nautilus-sendto con el siguiente error:

Error: Missing Dependency: libgaim.so.0 is needed by package nautilus-sendto

Lo que hay que hacer es forzar la instalación del paquete ya que en su construcción no se han definido las dependencias correctas, gaim ha sido sustituido por pidgim:

# wget http://mirror.centos.org/centos/5/os/i386/CentOS/nautilus-sendto-0.7-5.fc6.i386.rpm
# rpm -Uvh --nodeps nautilus-sendto-0.7-5.fc6.i386.rpm

(Literalmente obtenido de: http://blog.franciscomedina.net/2008/02/error-missing-dependency-libgaimso0-is-needed-by-package-nautilus-sendto/)

Ahora se repite la instalación del Gnome:

# yum install "GNOME Desktop Environment"

Y listo. Ya se puede iniciar el escritorio Gnome

# startx

y configurar el inicio del sistema en el nivel de ejecución 5 para que cargue el gestor de sesiones de Gnome al iniciar el sistema:

# cp /etc/inittab /etc/inittab3
# cat /etc/inittab3 | sed "s/id:3:initdefault/id:5:initdefault/" > /etc/inittab