tecnoquia

El efecto 2038

Ya queda un poco lejano el efecto 2000, pero afortunadamente para nuestras espectativas de trabajo se acerca el efecto 2038. Este futuro efecto está causado por la longitud del espacio reservado para almacenar timestamps en POSIX (time_t es un entero de 32 bits con signo) que cuenta el número de segundos transcurridos desde el 1/Ene/1970 a las 00:00:00 y alcanza su valor máximo (19/Ene/2038 a las 03:14:07), comenzando de nuevo la cuenta por el 1/Ene/1970. En arquitecturas de 64bits, time_t usa un entero con signo, pero de 64bits, que aplaza el problema durante unos cuantos millones de años, y claro, si el estándar POSIX ha funcionado bien durante todos estos años, tampoco íbamos a modificarlo para corregir este inconveniente, y por supuesto, tampoco es necesario montar sistemas que sabemos en el año 2038 tendrán problemas con la hora: Es deseable que los administradores Unix comencemos a migrar nuestros sistemas de 32 a 64 bits, por el llamado efecto 2038.
Una vez se dispone de una plataforma 64bits, es deseable usar una ver- sión Java de 64bits. La versión de 32bits de Java en Linux, tiene la gran limitación de permitir asignar hasta 3GB de RAM para la máquina virtual, y de ellos, sólo podremos darle a nuestra aplicación 2GB, porque el restante lo necesita la Runtime de Java para alojar el recolector de basura, heap, PermGen, etc. Esto que parece mucho, en realidad conforme van subiendo las conexiones a nuestro servidor se convierte en un inconveniente, porque la única forma que tenemos de mejorar el tiempo de respuesta y la cantidad de threads es aumentando la asignación de memoria RAM a la máquina virtual. Las distintas librerías y frameworks que actualmente necesitan las aplicaciones Java hacen que 2GB de RAM sea poco a largo plazo, y claro, no está recomendado si vamos a poner en marcha un sistema con la previsión de que esté funcionando después del año 2038.

La imagen la he sacado del album de simpologist en flickr

MultiPath para una cabina HP MSA

Si queremos configurar una cabina SAN HP MSA con Device Mapper Multipath sobre un sistema Debian, Ubuntu o Gentoo, podremos usar el siguiente fichero de configuración /etc/multipath.conf

blacklist {
   devnode "^cciss!c[0-9]d[0-9]*(p[0-9]*)?"
}
defaults {
   user_friendly_names yes
}
devices {
   device {
      vendor  "HP*"
      product  "MSA2312fc"
      getuid_callout "/lib/udev/scsi_id -g -u  -s /block/%n"
      hardware_handler "0"
      path_selector "round-robin 0"
      prio  alua
      #path_checker alua
      #prio_callout     "/sbin/mpath_prio_alua /dev/%n"
      path_grouping_policy group_by_prio
      failback  immediate
      rr_weight  uniform
      no_path_retry 18
      rr_min_io  100
      path_checker tur
   }
}
multipaths {
   multipath {
      wwid                   3600c0ff000da437942ece24c01000000 
      alias                  LUN1_MSA
   }
   multipath {
      wwid                   3600c0ff000da44502b1aec4c01000000
      alias                  LUN2_MSA
   }
}

Apache: Reescribir todo HTTP a HTTPS

A menudo ponemos en marcha VirtualHosts en nuestro servidor Apache, que más tarde decidimos securizar con HTTPS por cualquier razón, aunque las más habituales son la recomendación de nuestro auditor de seguridad, o la configuración de servicios autenticados con Login y Password. Esto siempre sucede después de haber publicitado la URL de nuestro servicio, y ya no tenemos control de qué URLs y bookmarks apuntan a nuestro servidor. Si se decide cerrar el puerto HTTP en nuestro servidor, los usuarios que accedan al servicio se encontrarán un error 404 y pensarán que la página ya no existe. Quizás sea más práctico configurar nuestro servidor para que reescriba todas las URLs en HTTP a HTTPS con mod_rewrite mediante el siguiente bloque:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

PhPKI

Casi todas las organizaciones tienen la necesidad de gestionar sus propios certificados autofirmados para implantar servicios OpenSSL. Hasta ahora siempre había recomendado usar los servicios de Certificación de Windows, por la comodidad que ofrecían: Una pequeña aplicación Web, desde la cual cualquiera puede solicitar un certificado de servidor, de cliente, VPN, etc. Además nos mantiene una pequeña base de datos con los certificados emitidos, y desde la interfaz web podemos renovarlos, volver a descargarlos y revocarlos.

Hacer esto mismo con OpenSSL delante de una consola Linux, no resulta tan intuitivo para nada, y por eso siempre he recomendado usar Windows para esta labor. Con OpenSSL siempre terminamos buscando en Internet cómo solicitar un nuevo certificado, que nunca es la misma página que usamos para configurar nuestra primera CA, y desgraciadamente acabamos configurando una nueva CA con un nuevo certificado raíz, que tendremos que volver a distribuir entre los clientes.

No hace mucho, encontré una pequeña aplicación Web OpenSource llamada PhPKI que nos permite olvidarnos de OpenSSL en la consola Linux, y hacer lo mismo pero desde la ventana de nuestro navegador. Esta aplicación simplemente es un Wrapper sobre OpenSSL y se instala con sólo descomprimir el TGZ en el directorio de nuestro servidor Web. La infraestrucutra PKI de nuestra entidad de certificación se mantiene en un directorio separado de la Web y toda la aplicación se configura mediente un fichero config.php. El código PHP es muy sencillito y se puede retocar y acondicionar muy facilmente. Ahora recomiendo usar esta herramienta :).

La imagen la he sacado del album de thierry en flickr

Optimizar las conexiones a MySQL

Si monitorizamos nuestro servidor MySQL recién instalado, podemos comprobar con el paso de las horas cómo se van amontonando conexiones en estado "Sleep" durante horas. Si nuestro servidor de base de datos empieza a recibir muchas conexiones será cuestión de tiempo que empiece a denegarlas.
El problema de que las conexiones quedén ahí sin cerrar los encontramos en la configuración de nuestros Apaches y en el propio MySQL.

En nuestros Apaches debemos revisar /etc/php.ini para configurar las conexiones persistentes a MySQL
```
mysql.allow_persistent = Off
mysql.max_persistent = 20
```
De esta forma le decimos a Apache que no se quede ahí con conexiones persistentes: Conecte y cierre.
En MySQL editar /etc/mysql/my.cnf y en la sección de [mysqld] añadir
```
wait_timeout = 60
```
El valor por defecto es 1 dia (expresado en segundos), y es el tiempo que tarda MySQL en matar sesiones, esperando a que se cierren. Tendremos que reiniciar el servicio para que se apliquen los cambios.

Para consultar el valor de las variables de TimeOut de nuestro MySQL debemos entrar en la consola mysql y ejecutar:

show global variables like '%time%';

Para fijar un valor en caliente:

set global wait_timeout=30;

La imagen la he sacado del album de mjsonline en flickr

Mirrors de Ubuntu

Durante este año he comprobado cómo cada vez más, Ubuntu Server es un estupendo candidato para instalar en servidores. La gran ventaja que nos ofrece es poder disponer de versiones de paquetes mucho más modernas que las que encontramos en RedHat Enterprise Linux (Oracle Unbreakable Linux, CentOs) o en Debian, y disponer de actualizaciones de seguridad gratuitas. También supone una ventaja el uso de paquetes DEB fáciles de recompilar para personalizar las opciones que necesitemos.
El uso de Debian o Ubuntu en servidores, nos obliga a disponer de conexión hacia de Internet para poder acceder a los reposiotorios de paquetes DEB. Esto no siempre es posible dependiendo de la topología de la red, y quizás nos convenga disponer de nuestro propio repositorio local de paquetes si queremos evitar permitir la conexión hacia Internet.
Para configurarlo realizaremos los siguientes pasos:

Instalar el paquete debmirror y apache2:
```
apt-get install debmirror apache2 rsync
```
Crear los directorios donde dejaremos nuestra réplica
```
mkdir /var/www/mirror/ubuntu/
```

Crear nuestro propio script para realizar la sincronización en /var/www/mirror/mirror-ubuntu.sh con el siguiente contenido:

#!/bin/bash
#

if [ "$1" = "" ]
then
 echo "ERROR: Debes pasar el nombre de la distribucion (ej: karmic,lucid...)" >&2
 exit 2
fi

# Mirror de 32bits
debmirror --ignore-release-gpg  -a i386 \
 -s main,restricted,universe,multiverse \
 -h cc.archive.ubuntu.com \
 -d $1,$1-security,$1-updates,$1-proposed,$1-backports \
 -r /ubuntu --progress -e http /var/www/mirror/ubuntu

# Mirror de 64bits
debmirror --ignore-release-gpg  -a amb64 \
 -s main,restricted,universe,multiverse \
 -h cc.archive.ubuntu.com \
 -d $1,$1-security,$1-updates,$1-proposed,$1-backports \
 -r /ubuntu --progress -e http /var/www/mirror/ubuntu

El script recibirá como argumento el nombre de la distribución: lucid, karmic, etc.

Preparar nuestro anillo de claves PGP, mediante:

apt-key exportall \
| gpg --no-default-keyring --keyring trustedkeys.gpg --import

Lanzar la sincronización y descarga de paquetes a nuestro directorio local:
```
cd /var/www/mirror
nohup bash mirror-ubuntu.sh karmic &
```

Una vez se hayan descargado todos los paquetes de la distribución de la que queremos mantener la réplica, configuraremos nuestros clientes apt, editando el fichero /etc/apt/sources.list y modificando la ruta del repositorio de paquetes:

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic universe

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-updates universe

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security main restricted
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security main restricted

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security multiverse
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security multiverse

deb http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security universe
deb-src http://IP_SERVIDOR_REPLICA/ubuntu/ karmic-security universe

Sería conveniente que ejecutemos periódicamente el script para mantener sincronizada nuestra réplica local.

La imagen la he sacado del album de Tobyotter en flickr

La catequesis

Hoy he estado hablando con mi ahijado ("el piripi") que debería hacer la comunión, si todo va bien, el próximo Mayo. Me ha dicho que está preparado, que enseguida empieza la catequesis y ya se sabe la oración del "Gloria" (quizás la más corta de todas), pero afirma que "Jesucristo era el hermano de Angel Cristo". La respuesta que me ha dado a la pregunta de qué es la Fe, ha sido:

"La Fe es lo que va antes de la Ge"

Creo que debo de empezar a ir a misa con este chaval, en plan intensivo.