Archivo del sitio

[OpenLDAP] Bitácora de instalación

He decidido recuperar mi blog técnico, y para comenzar su uso, he incluído una completa guía de instalación, configuración y personalización del servicio de directorio OpenLDAP bajo Debian GNU/Linux.

Espero poder contar con sus visitas y comentarios en esta nueva etapa de documentación en mi blog.

Gracias y allá nos vemos!

Linux Disks: Rescatando data de un disco de portátil VIT de las garras de la muerte

Mil disculpas por tener abandonado el blog!, ciertamente el no tener portátil y trabajar con portátil prestada, me limita en las cosas que podría y/o debería hacer en el equipo, además el trabajo, múltiples ocupaciones hacen imposible dedicarle mucho tiempo a escribir …

Pero sucedió algo … ;-)

Me encontraba usando una portátil VIT (modelo 2400), en vista que mi anterior portátil Thinkpad fue robada en diciembre pasado, con el equipo todo iba bien salvo algunas cosas:

  • Ligeros congelamientos en el mousepad
  • Keycodes disparados (visibles en el dmesg) sin haber presionado ninguna tecla especial
  • Algunos problemas con la red
  • Incompatibilidad con Debian Jessie e imposibilidad de usar un kernel liquorix con la tarjeta inalámbrica que trae.

Bueno, todo iba bien con el equipo, hasta que un día, de improviso y sin siquiera avisarlo el smartctl, el disco duro se congeló!, el equipo literalmente se congeló por completo, una larga espera y tuve que apagarlo forzado.

Al encender, veo que insólitamente el BIOS ni siquiera ve el disco!, es decir, el disco duro se ha “esfumado”, tratando de “dilucidar” tan extraño comportamiento de la BIOS (imaginándola tal vez desactualizada y jamás dudando de un disco duro SATA3 de menos de un mes de uso), decido probar suerte y meto un Live-USB de Debian Installer.

Pero, por si acaso, presiono “TAB” para editar la entrada del “Advanced Options > Rescue Mode” y escribo:

idebus=66 pci=routeirq

La primera opción, hace que el disco funcione como un IDE-66 (PATA-compatible) y la segunda opción cuestiona la decisión de asignación de IRQ de la tarjeta madre y decide que el kernel la haga por si mismo (esto me permite en algunas tarjetas madre “buggy”, como la que usan en VIT, detectar hardware con problemas).

Insólito!, el disco aparece en el dmesg!

[ 2377.833672] end_request: I/O error, dev sdb, sector 4007
[ 2377.833689] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833695] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833708] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833745] end_request: I/O error, dev sdb, sector 4007
[ 2377.833767] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833774] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833784] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833820] end_request: I/O error, dev sdb, sector 4007
[ 2414.775081] sd 9:0:0:0: [sdb] Unhandled error code
[ 2414.775083] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2414.775086] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 41 00 00 02 00

Ahora bien,eso realmente no significa mucho, el disco da problemas de montaje, sin embargo, el DRIVER_OK me causa sospechas, ¿y si el disco está bueno, pero la lógica de comunicación de la tarjeta madre está operando mal?, entonces apago el equipo y reinicio el sistema de rescate, pero esta vez con dos opciones más:

libata.force=noncq libata.atapi_passthru16=0 idebus=66

Con la primera opción, fuerzo la desactivación del NCQ, es un sistema de cola de comandos de 32bits que utilizan los discos SATA y SSD más modernos para comunicarse con la tarjeta madre, un error en la lectura de comandos por parte de la controladora ATA puede “simular” un fallo de hardware y desactivar el disco; por ende, desactivar el NCQ puede ayudar a la controladora SATA a entender al disco duro.

La segunda opción, me permite tratar al disco como si fuera un viejo IDE, desactivando el soporte a comandos de 16 bits.

Con estas dos opciones, mágicamente el disco duro ahora es perfectamente detectado, he montado un disco externo, rescaté los datos a dicho disco externo y listo!, datos del disco duro “dado por muerto” rescatados.

¿y qué pasará con la portátil?

Aunque pudiera desactivar el modo AHCI en el BIOS y funcionar en modo IDE y pudiera luego pasar estas opciones en el GRUB, ciertamente estas opciones hacen que el disco vaya a muchísima menos velocidad que en condiciones normales, cómo la única posible solución documentada es una actualización del BIOS que le permita actualizar la tabla APCI y corregir el bug NCQ de la controladora ATA; será mejor devolver el equipo ya que al ser un equipo VIT ensamblado en Venezuela con piezas chinas, es poco probable que el proveedor de piezas de VIT haya sacado alguna “actualización de seguridad” del BIOS VIT.

Si a alguno le quedó el disco como “desaparecido del BIOS” en una VIT y necesitan con urgencia sacar unos datos, les indico que esta es la solución de resurrección más idónea.

Si alguien sabe como “actualizar” el BIOS de una VIT, me avisa …

Actualización

Luego de “despertar” al disco con “idebus=66 libata.force=noncq” y apagar inmediatamente el equipo, EL EQUIPO ENCENDIÓ!, normalmente, salvo que al llegar al GRUB, por precaución agregué ámbas opciones (idebus=66, libata.force=noncq) y pude llegar al GNOME para sacar sin apuro y con más vigilancia (y con un entorno gráfico) algunas cosas que no había respaldado.

Happy Hacking!

[Linux] Instalación rápida de un DNS caché

Con el advenimiento de los problemas DNS o los fallos de resolución (el sábado pasado DNS1.CANTV.NET dejó de resolver por un par de horas), además como una buena práctica de gestión de tu plataforma, es importante contar con un servidor DNS caché.

En este caso, instalaremos dnsmasq, tanto para Debian como para Fedora/CentOS.

La razón de este artículo fue un compañero que me llamó presuroso, “tenemos problemas con el correo!, auxilio!, se está quedando represado y están fallando las resoluciones DNS”, rápidamente le envié mi guía de DNS caché y solventó su problema, ¿por qué no solventarle el problema a los demás?, aquí la publico.

DNSmasq es un servicio muy sencillo y fácil de configurar, con muchas guías disponibles, este simplemente es una más :)

Preámbulo

Un DNS caché es una herramienta que se encarga de hacer las consultas DNS contra servidores externos y almacenarlas el tiempo previsto por el REFRESH de la zona, así, nos ahorramos un montón de tráfico “hacia afuera” a preguntarle a DNS de Google o de CANTV (o el que sea tu ISP).

Para el trabajo utilizaremos una aplicación muy ligera, conocida como DNSmasq, acá las instrucciones para instalarlo.

Instalación

Para instalar en Debian GNU/Linux debemos ejecutar:

aptitude install dnsmasq

Para Fedora, debemos ejecutar:

yum install dnsmasq

Para CentOS, tenemos qué, previamente, añadir los repositorios EPEL para descargar de allí dnsmasq

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

Y luego si ejecutamos la instalación

yum install dnsmasq

Luego de esto, aseguraremos la instalación, para ello, debemos crear un usuario y grupo (por defecto, dnsmasq se instala y correo como root ó como nobody):

groupadd -r dnsmasq
useradd -r -g dnsmasq dnsmasq

A partir de acá, pasamos a configurar el servicio.

Configuración de DNSmasq

Primero, guardamos el archivo de configuración “original” (por si acaso!):

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

Y creamos uno con el siguiente contenido:

archivo: /etc/dnsmasq.conf
#
# Configuration file for dnsmasq acting as a caching nameserver.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
#
# Updated versions of this configuration file may be available at:
#
#   http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/
#
#
# Basic server configuration
#
listen-address=127.0.0.1
port=53
bind-interfaces
user=dnsmasq
group=dnsmasq
pid-file=/var/run/dnsmasq.pid
## Logging #
log-facility=/var/log/dnsmasq.log
log-queries
## Name resolution options #
domain-needed
bogus-priv
dns-forward-max=150
cache-size=1000
neg-ttl=3600
resolv-file=/etc/resolv.dnsmasq
no-poll

NOTA: si queremos evitar que dnsmasq lea las entradas del /etc/hosts simplemente agregamos “no-hosts” luego de “no-poll”.

Este archivo simplemente define un dnsmasq como “caching nameserver” con un tamaño de caché de 1000 entradas y un caché negativo (tiempo que se guarda una resolución NXDOMAIN como válida) de una hora.

Guardamos luego el archivo y le damos los privilegios necesarios:

chown dnsmasq.dnsmasq /etc/dnsmasq.conf
chmod 0640 /etc/dnsmasq.conf

Creando el resolv para DNSmasq

El archivo “/etc/resolv.conf” apunta al DNS que debería resolver nuestras direcciones, y este debe ser, obviamente, “127.0.0.1”, o sea, nuestro propio dnscaché.

archivo: /etc/resolv.conf
nameserver 127.0.0.1

Sin embargo, dnsmasq cuenta con su propio archivo, donde se definen los servidores DNS que consultará recursivamente por direcciones:

archivo: /etc/resolv.dnsmasq
nameserver 8.8.8.8 #DNS de GOOGLE, mi favorito
nameserver [Primer DNS de tu ISP]
nameserver [segundo DNS de tu ISP]

Gestionando el log

Hemos creado un log, para gestionar los mensajes de dnsmasq (y la opción “log-queries” creará una bitácora con todas las direcciones que nuestros “usuarios” consultan), pero este log no es el “oficial”, así que hay que incorporarlo al logrotate:

Creamos el archivo con el siguiente contenido:

archivo:  /etc/logrotate.d/dnsmasq

/var/log/dnsmasq.log {
monthly
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq
}

Y aplicamos la regla de logrotate ejecutando:

/usr/sbin/logrotate  /etc/logrotate.conf -f

Ya con esto, sólo nos hace falta, iniciar el servicio.

Arranque y parada

Para poder iniciar al arranque del sistema, en Debian ejecutan:

update-rc.d dnsmasq defaults

Y en Fedora/centOS:

chkconfig dnsmasq on

Para luego, iniciar el servicio con:

service dnsmasq start

Con lo cual ya está en operación tu caché de DNS, ¿por qué no probarlo?

Pruebas

Lo más ideal, es realizar una serie de consultas, para determinar su velocidad, para ello utilizamos la herramienta “dig”

Por ejemplo, una consulta sobre un dominio .gob.ve a google (8.8.8.8) le toma:

$ dig @8.8.8.8 -t A localhost.saren.gob.ve
;; Query time: 198 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Apr 26 03:06:12 2013
;; MSG SIZE rcvd: 56

Y a CANTV.NET

;; Query time: 105 msec
;; SERVER: 200.44.32.10#53(200.44.32.10)
;; WHEN: Fri Apr 26 03:39:59 2013
;; MSG SIZE rcvd: 56

Pero consultando 2 veces (una para que resuelva, la segunda ya responde desde caché) a nuestro servidor DNS:

$dig @127.0.0.1 -t A localhost.saren.gob.ve
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 26 03:42:29 2013
;; MSG SIZE rcvd: 56

Lo cual no solo es una mejora significativa en velocidad, sino una además, un ahorro notable de ancho de banda de resoluciones DNS innecesarias.

[Android] Actualizando HTC Desire en Linux (I)

Desde hace algún tiempo tengo un equipo HTC Desire (bravo) original de Digitel:

HTC Desire Bravo

HTC Desire (bravo)

Preámbulo y otras yerbas

El equipo ha sido fiel hasta donde más, le he comprado una batería de polímero extra-grande que me permite llevarlo encendido full-operativo por más de 2 días y le tengo una memoria microSD class6 SDHC para almacenamiento, fue uno de los primeros teléfonos en poseer un CPU ARM snapdragon de 1Ghz y a pesar de lo que digan, todavía le queda mucho por ofrecer.

Inicialmente viene con Android 2.2 Froyo, en el “boom” de los smartphones que vino después de Froyo (Samsung Galaxy S1, Motorola Milestone y Xperia Sony) pues HTC lanzó una carrera de teléfonos (entre ellos el HTC Hero y el HTC one) dejando abandonado en el camino a este guerrero, que jamás recibió actualización alguna vía OTA (Over-The-Air) de Android.

Ya he actualizado mi tablet Lenovo K1 hasta el cansancio (no he hecho un post, porque aún no he conocido a alguien *que no sea mi esposa* que tenga una Lenovo K1 en Venezuela); nunca me había atrevido a instalar algo más que no fueran actualizaciones al teléfono, mucha gente optó por abandonarlo, pero yo no!.

Actualizando desde GNU/Linux

En la mayoría de los casos la gente olvida que Android es Linux y mucha gente entusiasta de la plataforma desarrolla herramientas para interactuar con él solo para Windows, lo que dificulta mucho el realizar operaciones sobre él, sin embargo, este no es el caso.

¿Qué vamos a actualizar?

Hay 4 cosas que debemos actualizar antes de pensar en montarle una nueva ROM (versión modificada de Android) estas son:

* Radio: software que gestiona la comunicación con el radio del teléfono, la última versión mejora notablemente el consumo de energía en comunicaciones de datos 3G, además, es esta opción la que “libera las bandas” desbloqueando el teléfono para cualquier operadora (SIM-Lock).

* S-Off: Permite escribir en la ROM del equipo, desactivando las protecciones en la misma

* HBOOT: el sistema de arranque del HTC Boot, incluye el recovery y el fastboot (algo así como los modos de recuperación del teléfono, si algo llega a pasar mal, deberán entrar en modo “fastboot”).

* Root: root significa realmente “ganar SU”, es decir, ganar privilegios de super-usuario (como cualquier linux) por lo que ganas el control total sobre el equipo.

NOTA: Recuerda activar la depuración de USB (Ajustes -> Aplicaciones -> Desarrollo -> Depuración USB) y conectar el telefono al computador mediante su cable micro-USB.

Requerimientos:

Android Debug Bridge (ADB)

Hay muchas guías de cómo instalar ADB en Linux, yo simplemente me descargue la SDK de Android y luego colocando la carpeta “platform-tools” en el PATH, para así poder llamar a los comandos “adb” y “fastboot”.

Advertencia!

Este proceso es altamente técnico, pueden dejar el teléfono inservible (bricked, volverlo un ladrillo) o en un estado inconsistente, además, perderán TODOS los datos en él (recomiendo una aplicación como Titanium Backup y SMS backup&Restore para respaldar todos sus datos).

OJO!, no nos hacemos responsables en este blog por el daño o pérdida de equipos por impericia o mal uso de las herramientas, para conocer más, es mejor pasear un rato y leer por los foros de xda-developers.

- Actualizando la Radio

Para actualizar la radio he obtenido información de acá:

Foro: http://forum.xda-developers.com/showthread.php?t=687464
Y de este post: http://www.mofirouz.com/wordpress/2011/03/htc-desire-radios/

He extraído la información para descargar la última radio para mi HTC Desire (5.17.05.23)

He descargado este .zip y la he descomprimido (un archivo, llamado radio.img está dentro del teléfono)

http://www.mofirouz.com/ahp/?file=htcdesire/radios/32.56.00.32U_5.17.05.23.zip

* Conectamos vía USB el teléfono y reiniciamos en el bootloader:

adb reboot bootloader
* daemon not running. starting it now on port 5037
** daemon started successfully *

Revisamos que fastboot detecta nuestro teléfono:

fastboot devices
SH12GPL05338 fastboot

El valor inicial es el serial (n° de serie) del teléfono, que lo pueden verificar en una etiqueta que está detrás de la batería.

* Ejecutamos el proceso de volcado de la nueva radio:

fastboot flash radio /home/jesuslara/android/htc/32.56.00.32U_5.17.05.23/radio.img
sending ‘radio’ (26112 KB)…
OKAY [ 3.800s]
writing ‘radio’…
OKAY [ 29.446s]
finished. total time: 33.246s

Luego de finalizado el proceso, seleccionamos “POWER DOWN” (botones de volumen para navegar y POWER para seleccionar), apagamos el equipo y entramos “de nuevo” en modo fastboot (tecla BACK + tecla POWER juntas por 7 segundos hasta que se ponga la ventana en blanco).

Verificamos la versión de la radio: RADIO-5.17.05.23

Procedemos a cambiar el modo S-ON a S-OFF (posibilidad de escribir en la ROM del teléfono) con “revolutionary”.

- Permitiendo escribir la ROM (S-OFF)

* Se conectan a la siguiente página web: http://revolutionary.io/

En esta página, descargan la versión para Linux, es necesario que la descarguen de allí, ya que un asistente les generará el beta-key (una llave) que les permitirá ejecutar revolutionary.

Luego de descargada y generada la clave, es muy fácil, le dan privilegios de ejecución a revolutionary:

chmod +x revolutionary

Y lo ejecutan con el teléfono encendido y conectado al USB (recuerden la nota USB-Debugging activo):

* Verifiquen qué el teléfono está conectado:

adb devices
List of devices attached
SH12GPL05338 device

Al ejecutar:

./revolutionary
=============================================
| Revolutionary S-OFF & Recovery Tool 0.4pre4 |
=============================================
Brought to you by AlphaRev & unrEVOked.

Este procederá a apagar el S-ON del teléfono, te preguntará la beta-key y luego si deseas instalar ClockworkMod Recovery a lo que indicarás que si (necesario para instalar muchas otras cosas):

Do you want to download (Internet connection required) and flash ClockworkMod Recovery? [Y/n] Y
Downloading recovery for your phone (bravo)…
Downloading recovery for your phone (bravo)…Done.
Rebooting to fastboot…
Flashing recovery over fastboot…SUCCESS!

* Al finalizar, el teléfono quedará en fastboot e indicará arriba que tiene revolutionary y S-OFF, vamos a actualizar el HBOOT.

HTC-Desire-A8181-S-OFF-and-custom-recovery-installed

- Actualizando HBOOT

Para actualizar el HBOOT de nuestro HTC podemos hacer uso del listado de HBOOT disponble en la página web de AlphaRev: http://alpharev.nl/

Cada HBOOT distribuye el espacio de acuerdo a ciertos factores como disponibilidad de espacio para /system, caché o no caché y cantidad de espacio que queda para /data (datos internos de usuario); por ahora vamos a lanzar la actualización de HBOOT stock:

http://alpharev.nl/bravo_alphaspl.img

NOTA: revisen la ROM que deseen, algunas versiones de HBOOT (como CWM7) son necesarias para funcionar.

* Encendemos directamente en fastboot (botón “BACK” + botón “POWER” ó Volumen Arriba-Volumen Abajo-POWER, esperan 7 segundos y en la opción “FASTBOOT” presionan “POWER”).

* Ya en fastboot; ejecutamos:

fastboot flash hboot /home/jesuslara/android/htc/bravo_alphaspl.img
sending ‘hboot’ (512 KB)…
OKAY [ 0.089s]
writing ‘hboot’…
OKAY [ 0.137s]
finished. total time: 0.226s

* Reiniciamos el fastboot:

fastboot reboot-bootloader
rebooting into bootloader…
OKAY [ 0.162s]
finished. total time: 0.162s

* limpiamos la cache:

fastboot erase cache

Listo!, ya tenemos el equipo con HBOOT, ClockworkMod Recovery, S-OFF y Radio actualizada, ¿qué nos falta?, root y una buena ROM!.

- Rooting con S-OFF

Al contar con S-OFF y acceso vía ClockWorkMod al ROM del teléfono, ya podemos instalar superuser (http://downloads.androidsu.com/superuser/Superuser-3.0.7-efgh-signed.zip) en el teléfono, para ello simplemente descargamos superuser, lo copiamos a una memoria SD del teléfono y entramos en modo recovery del teléfono:

* Encender en recovery (Volumen Arriba-Volumen Abajo + POWER) esperar 7 segundos y con los botones de volumen seleccionar la opción RECOVERY y luego presionar POWER, entramos en modo recovery (que gracias al CWM Recovery se ve cómo esta imagen):

HTC-Desire-A8181-Revolutionary-CWM-v4.0.1.4

* Seleccionar “install zip from sdcard” (se puede usar el trackball central para navegar por el menú y hacer click)
* Seleccionar “choose zip from sdcard”
* Seleccionamos el archivo zip “Superuser-3.0.7-efgh-signed.zip”

Esperamos a que el proceso termine, presionamos botón “BACK” y luego “reboot system now”.

Y listo!, tenemos el teléfono desbloqueado, actualizada la radio, con root y con un recovery para instalar lo que necesitamos, ¿y qué necesitamos?, una BUENA ROM!, pero eso es parte de un segundo artículo!.

Happy Hacking!

Instalando y usando openvswitch en Debian GNU/Linux

Open VSwitch es un sistema de switch virtual, diseñado especificamente para habilitar automatización y despliegue de interfaces de red de manera programática, además soporta su distribución alrededor de múltiples servidores físicos, lo que lo hace ideal para la construcción de esquemas de redes virtuales para nubes.
OpenVSwitch es el esquema por defecto de gestión de redes de plataformas de virtualización con Citrix XenServer, openNebula y openStack y puede ser usado en KVM, Xen y Proxmox VE.

Open VSwitch

¿Por qué usar open VSwitch?

OpenVSwitch permite más capacidades que los módulos regulares del kernel Linux, aún cuando el Datapath está dentro del propio Kernel GNU/Linux, openVSwitch permite crear un “Soft Switch” en el hipervisor contando con características como QoS, LACP, etc; además, es el modo de gestión de redes virtuales en soluciones como OpenNebula, OpenStack y XenCenter (XCP).

Instalando open VSwitch

Para instalar openVSwitch en Debian Wheezy, realizaremos los siguientes pasos:

* Instalamos las dependencias:

apt-get install build-essential module-assistant

* Y los headers de nuestro kernel:

apt-get install linux-headers-`uname -r`

* removemos temporalmente los bridge-utils

apt-get remove --purge bridge-utils

* E instalamos el módulo para compilarlo en nuestro kernel:

apt-get install openvswitch-datapath-source

* Generamos el módulo para nuestro kernel:

module-assistant auto-install openvswitch-datapath

* Instalamos luego la compatibilidad con bridges linux

apt-get install openvswitch-brcompat openvswitch-common

* Completamos la instalación de openvswitch:

apt-get install openvswitch-switch

* Verificamos, que luego de instalado e iniciado, nos muestre la versión:

ovs-vsctl show
1dad3b56-0a78-4513-8480-be086ef042f7
ovs_version: "1.4.2"

Y Reiniciamos:

/etc/init.d/openvswitch-switch restart
[ ok ] ovs-brcompatd is not running.
[ ok ] Killing ovs-vswitchd (7353).
[ ok ] Killing ovsdb-server (7302).
[ ok ] Starting ovsdb-server.
[ ok ] Configuring Open vSwitch system IDs.
[ ok ] Starting ovs-vswitchd.

Con lo que ya tendremos openvswitch instalado en nuestro equipo.

Creando un bridge en Debian

Para crear un bridge contamos con tres formas, de la manera tradicional (en el archivo /etc/network/interfaces), con la herramienta tradicional bridge-utils o con los comandos propios de openvswitch.

Agregando una definición de bridge:

La definición de un bridge utilizando el archivo /etc/network/interfaces es igual a la forma tradicional, tomando en cuenta que todo bloque de definición debe empezar con la sentencia “allow-ovs” y el nombre de la interfaz, ejemplo:

auto br0
allow-ovs br0
iface br0 inet static

Además, cada puerto asociado a un bridge (por ejemplo) deben ser incorporados a ovs, ejemplo:

allow-hotplug eth0
allow-br0 eth0
iface eth0 inet manual

Donde “allow-${bridge}” representa el nombre del bridge padre.

Ejemplos:

* Un bridge autónomo:

auto br0
allow-ovs br0
iface br0 inet static
   address 172.16.20.1
   netmask 255.255.255.0
 # bridge info
   ovs_type OVSBridge
   ovs_ports eth0
   bridge-ports eth0
   bridge-maxwait 1

Fijese en la opción ovs_type, puede ser OVSBridge, OVSPort, OVSIntPort u OVSBond de acuerdo a lo que  deseamos construir, también fijese que podemos mezclar con opciones compatibles con kernel bridge sin problemas.

Luego de definido un bridge, podemos definir un puerto (interfaz añadida al bridge):

# eth0
allow-hotplug eth0
allow-br0 eth0
iface eth0 inet manual
   ovs_bridge br0
   ovs_type OVSPort

Al reiniciar las interfaces, podemos ver su incorporación a OVS:

ovs-vsctl show
1dad3b56-0a78-4513-8480-be086ef042f7
 Bridge "br0"
       Port "eth0"
               Interface "eth0"
       Port "br0"
               Interface "br0"
        type: internal
 ovs_version: "1.4.2"

Agregando una definición de bond

Construir un bond es semejante en forma a la construcción de un bridge, tomando en cuenta que debemos encender las interfaces esclavas y configurar la pertenencia del bond a un bridge.

Definimos el bond:

auto bond0
allow-br0 bond0
iface bond0 inet manual
   ovs_bridge br0
   ovs_type OVSBond
   ovs_bonds eth0 eth1
   ovs_options bond_mode=balance-tcp lacp=active
   bond-miimon 100

Definimos las esclavas del bond (para que estén activas cuando este se cree):

auto eth0
iface eth0 inet manual
  bond-master bond0
auto eth1
iface eth1 inet manual
  bond-master bond0

Y por último, el bridge que gestionará el bond:

auto br0
allow-ovs br0
iface br0 inet static
   address 172.16.20.1
   netmask 255.255.255.0
   ovs_type OVSBridge
   ovs_ports bond0

Usando los comandos OVS para construir un bridge

Podemos crear un bridge fácilmente utilizando el comando “ovs-vsctl” siguiendo los siguientes pasos:

ovs−vsctl add−br br0
ovs−vsctl add−port br0 eth0

Aunque, podemos hacer ambas operaciones en una sola línea:

ovs−vsctl add−br br0 −− add−port br0 eth0

Nota: El double dash (–) es un separador entre opciones y comandos.

Podemos ver la interfaz con el comando “ovs-vsctl show” o utilizar el comando tradicional “brctl show”

brctl show
bridge name                bridge id                       STP enabled                           interfaces
br0                               8000.f0def1919e43             no                                     eth0

Definiendo una VLAN en un bridge

Para crear un bridge asociado a una VLAN, agregamos una interfaz interna etiquetada con el número de la VLAN:

* Creamos el bridge:

ovs-vsctl add-br br0

* Incorporamos una interfaz interna, etiquetada con el número de la VLAN (ejemplo, VLAN10):

ovs-vsctl add-port br0 vlan10 tag=10 -- set interface vlan10 type=internal

* Configuramos la interfaz:

ifconfig vlan10 192.168.10.254 netmask 255.255.255.0

Y listo!.

QoS sobre una interfaz en openVSwitch

También podríamos crear una regla de QoS sobre el ancho de banda de las interfaces participantes en un bridge, por ejemplo; podríamos definir una regla para limitar el ancho de banda de la interfaz eth0 a 10Mbps:

* Limitamos la interfaz eth0 a un máximo de Kbps que puede enviar (10000=10Mbps).

ovs-vsctl set interface eth0 ingress_policing_rate=10000
ovs-vsctl set interface eth0 ingress_policing_burst=1000

* Podemos también hacerlo a través la opción qos de un puerto;

ovs-vsctl -- set port eth0 qos=@newqos -- --id=@newqos create qos type=linux-htb other-config:max-rate=5000000 queues=0=@q0 
-- --id=@q0 create queue other-config:max-rate=5000000

Conclusiones

Espero les haya servido esta guía como a mí, yo no soy muy dado al área de redes, pero desde que estoy experimentando con virtualización (Xen, XCP-XAPI, KVM) pues he aprendido mucho acerca del control y gestión automatizado de interfaces; espero les sea de provecho.

Happy Hacking!

Server, Desktop o Workstation: El punto de no-retorno de Linux

El día de ayer me encontraba actualizando mi equipo, quitando y poniendo cosas en su sitio, limpiando de cosas que no uso, aplicaciones instaladas “por prueba” o por trabajos anteriores y pensé ¿por qué no de una vez, separar mis dos actividades, trabajo y ocio, en entornos distintos?, aún cuando eso es del común de muchos, en mi caso el “dual boot” no era mi estilo.-

Hasta ayer.

Sobre Escritorios y Servidores

Los sistemas de escritorio suelen ser equipos de gama alta, donde la gente desea el mayor nivel de respuesta de las cosas que ha comprado (tarjetas de video de gama alta, microprocesadores Intel con sandybridge o AMD opteron, etc) y otra serie de cambios que describiremos brevemente.

En cambio, los servidores suelen ser equipos de diferente estructura, con más CPUS, mucho mayor poder de cómputo, donde la mayoría de la latencia del núcleo debe ser dedicada a servicios en segundo plano y a aplicaciones que mantienen una actividad constante sobre el equipo; donde rara vez habrá una interfaz de usuario y mucho menos una aplicación corriendo en el espacio de memoria de usuario.

En cambio, una estación de trabajo (Workstation) es una combinación de ambas cosas, es una computadora de escritorio donde tendremos entornos de programación, ambientes para probar modelos de virtualización (KVM, Virtualbox), donde el equilibrio entre servicios y aplicaciones es más que necesario.

El procesador:

A menos que estés en algún ambiente hostil (como la pista de maiquetía, que está hoy a 47 grados centígrados), el procesador debería mantener un CPUfreq en “performance”, para extraer el máximo a nuestro CPU, o en su defecto en “ondemand” pero con una tasa baja de actualizaciones de velocidad (para disminuir las subidas y bajadas de la frecuencia del CPU).

En el caso del CPUfreq “on demand”, el sampling factor (el factor con el que cambia la frecuencia del CPU) puede ser disminuida a un factor de 10:

echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

Esto hace que el reloj sea evaluado menos veces, haciendo que el CPU se mantenga complementa arriba en caso de estar ocupado y no bajará y subirá constantemente (como cuando el sampling_down_factor = 1).

(sleep 10 && echo -n 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold) &

En otro lado está el threshold, el nivel de carga de CPU necesaria para que la velocidad de reloj sea “elevada”, por defecto es 95 (95% de carga en el CPU), si disminuimos esto (ejemplo: 25%) con sólo un 25% de carga ya estará subiendo el CPU de velocidad.

NOTA: tomen en cuenta que aplicarle más carga al CPU consume más rápido la batería de los equipos portátiles.

Discos y Elevadores:

Linux es un núcleo que puede ser utilizado para diferentes cosas, desde televisores smartTV hasta enrutadores y access points, pasando por servidores y clusters, los “elevadores” es la forma como el kernel Linux gestiona la entrada/salida (I/O) de los datos y desde los discos.

El desarrollador Paolo Valente diseñó un I/O scheduler optimizado de manera agresiva para el trabajo intensivo de escritura en disci de las aplicaciones de escritorio; BFQ (Budget Fair Queueing) I/O scheduler, dicho trabajo no fué aceptado en el árbol general del núcleo Linux pues el código afectaba el desempeño del núcleo en otras áreas críticas como por ejemplo, su uso en servidores.

Pero dicho scheduler puede ser encontrado a manera de “parche” en algunas versiones de Linux, como por ejemplo Liquorix, Liquorix es una versión para Debian del Kernel Zen, un kernel con los parches y optimizaciones más importantes para su uso en desktops, equipos multimedia y alto desempeño para aplicaciones multimedia y juegos.

Luego de instalado el kernel Liquorix, podemos habilitar el scheduler BFQ agregando en el grub:

archivo: /etc/default/grub

GRUB_CMDLINE_LINUX=”numa=on acpi=force acpi_osi=linux apic lapic elevator=bfq”

Agregando “elevator=bfq” en la línea del núcleo, y generando de nuevo el arranque GRUB:

update-grub2

Podemos contar con un scheduler digno de un equipo de escritorio para juegos y multimedia.

Por el contrario, en equipos con hardware especializado para servidores, podemos encontrar el caso contrario, NO NECESITAMOS que el kernel gestione la organización, ordenamiento y agrupamiento de los datos que van a disco, esto es porque contamos con hardware especializado (controladoras SAS, SATA-RAID o SCSI) que puede gestionar correctamente los datos que son entregados “RAW” por el Sistema Operativo; en este caso, el elevador es completamente distinto:

elevator=noop

Con “elevator=noop” el núcleo delega en el hardware subyacente la gestión de almacenamiento en disco (imaginen un RAID-5 y el sistema operativo organiza la data que luego la controladora SAS vuelve a organizar para almacenarla en los stripes del RAID).

Núcleo Liquorix

El núcleo Liquorix es una variante para Debian del fuente del núcleo Zen, una versión del kernel Linux con la mayoría de los parches y optimizaciones para escritorios, sistemas multimedia y para juegos.

Aunque mucha gente lo desconoce, estos núcleos modificados suelen ayudar mucho a las portátiles al ahorro energético, puesto que el CPU “descansa” de procesar todo al delegar correctamente operaciones de video al GPU (debe estar habilitada la aceleración de video en el Xorg) o la gestión de dispositivos al northbridge.

Los servidores no están configurados para pensar en cosas como “ahorro de energía de la batería”, “aceleración de video”, “anti-flicker de la reproducción multimedia” o aceleración de audio con dolby 7.1; pero este tipo de núcleos para escritorio lo están, hay algunos RT (para aplicaciones multimedia, video y sonido).

Para instalar el kernel Liquorix (en la actualidad va por la versión 3.5) simplemente agregamos a nuestros repositorios:

#archivo: /etc/apt/sources.list.d/liquorix.list
deb http://liquorix.net/debian sid main

E instalamos:

aptitude install linux-headers-3.5.0-4.dmz.1-liquorix-amd64 linux-modules-3.5.0-4.dmz.1-liquorix-amd64 linux-headers-liquorix-amd64

La respuesta del CPU

Con Kolivas diseñó un CPU scheduler (gestor del trabajo de los CPU) completamente diferente y más sencillo que la heurística del CFS (Completely Fair Scheduler), este Scheduler es muy óptimo para aplicaciones que requieren acceso directo y multi-hilado al CPU, pero solo es eficiente cuando la cantidad de CPUS sea menor que 16 (¿han visto una portatil con 32 CPUs?); en este caso, el scheduler provee una extremadamente baja latencia y un algoritmo distribuido alrededor de un número fijo de CPUS (o Cores) y no alrededor de un algoritmo heurístico más complejo para determinar la carga de los CPUs.

Tal como BFQ, BFS (Brain-Fuck Scheduler: sugerente nombre, ¿no?) rompe con muchisimas cosas dentro del kernel Linux en su uso para servidores, así que no forma parte del mainline del Kernel, para poder utilizarlo hay que contar con un núcleo que contenga el parche BFS (como el kernel Liquorix).

Grandes bloques de memoria

La memoria de un sistema es gestionada en bloques, en términos generales (y en muchos sistemas operativos), cada bloque de memoria mide 4096bytes, en 1MB de memoria caben 256 bloques; cada bloque es conocido como una página de memoria; cada CPU tiene un “mapa” de páginas de memoria para saber dónde está almacenado qué cosa en cada momento.

Para que un sistema operativo pueda gestionar una gran cantidad de RAM (por encima de 2GB), se pueden hacer 2 cosas: o aumentar el número de páginas que puede almacenar un CPU (algo costoso, implica modificar el comportamiento del hardware) ó hacer las páginas más grandes; cuándo el CPU llena sus “mapas de páginas”, el Sistema Operativo (en este caso el kernel Linux) termina gestionando la memoria vía algoritmos de software, lo que pone a TODO el sistema en un estado “más lento”.

Transparent Huge Pages (THP) permite incrementar el tamaño de las páginas desde 2MB hasta 1GB y permite que las aplicaciones accedan más rápidamente a bloques grandes de memoria, que siguen gestionados por los mapas de memoria del CPU, logrando una mejora notable en el rendimiento general del sistema.

Para habilitar las THP simplemente agregamos al /etc/default/grub y generamos:

GRUB_CMDLINE_LINUX="numa=on acpi=force acpi_osi=linux apic lapic transparent_hugepages=always elevator=bfq

Modos de aceleración exclusivos

En el caso de dispositivos Sandybridge e IvyBridge (como los presentes con algunos CPUs iCore de Intel), hay configuraciones en el video que son exclusivas y que permiten aceleración por hardware, en el caso de Intel se pueden usar el modo UXA (el más nativo) o el más moderno SNA, para contar con aceleración SNA agregamos este archivo al Xorg (/usr/share/X11/xorg.conf.d/):

archivo: 20-device.conf
Section "Device"
    Identifier "Configured Video Device"
    Driver "intel"
    Option "AccelMethod" "SNA"
    Option "BackingStore" "True"
    Option "MonitorLayout" "CRT,LFP"
    Option "XvMC" "on"
    #intel
    Option "SwapbuffersWait" "false"
    Option "TearFree" "true"
EndSection

En algunos casos, la mejora del rendimiento (de contar con el chip requerido) es del 20%.

Conclusiones

Este es solo un conjunto simple de acciones que, aplicadas a un núcleo, podrían mejorar notablemente el performance general del equipo, con el “penalty” que no tendrías “vuelta atrás” para usar tu equipo como un “servidor” o una “estación de trabajo para programadores” (a menos que sean programadores que les guste mucho ver videos en youtube y jugar UrbanTerror); una de las características que ha hecho popular MacOSX está en tomar un núcleo BSD y reducirlo, optimizarlo y compilarlo para el hardware que ESPECIFICAMENTE han diseñado para dicho Sistema Operativo; considero que la cantidad de optimizaciones mayores para escritorio que hay en Linux hoy en día la hacen el blanco ideal para un conjunto de nuevas versiones de GNU/Linux optimizadas y personalizadas “por versión de hardware” y no solo por arquitectura, como se hace ahora.

¿Por qué no tomar un equipo como este, ejemplo, un Thinkpad E420 o uno X1, Sandybridge, Multi-core y reduces y optimizas el kernel para únicamente esta gama de equipos?, sé que es una inversión que empresa alguna realizaría en estos momentos, pero muchos proyectos podrían comenzar a hablar ya de “versiones por hardware”, Canaima podría tener versiones específicas para los equipos de Canaima Educativo.

Espero prontamente reducir y optimizar el kernel liquorix para una versión de hardware específica, pero eso ya será una próxima entrega.

Happy Hacking!

[postgreSQL] Una instalación de postgreSQL básica (¡pero mejor!)

PostgreSQL: Introducción

PostgreSQL es una de las grandes maravillas del software libre, robusto, potente, altamente funcional, distribuido en miles de formas posibles (greenplum=clusterizador masivo, postgres Plus=”imitador” de Oracle,deepgreen=granjas de datawarehousing con postgreSQL, etc) puede ser optimizado (como todo lo que es software libre) de maneras inimaginables para cada necesidad específica. Entonces, ¿por qué hay gente que denigra de él? …

El primer error que comete la gente, es pretender que un sistema tan necesario como la base de datos, sea utilizado “directamente” luego de su instalación; un detalle de distribuciones Linux como Debian, es no optimizar para ningún aspecto (ya que son meta-distribuciones genéricas sin una orientación específica).

Mientras Oracle saca libros de 900 páginas de cómo optimizar al máximo hardware, sistema de archivos, sistema operativo y la base de datos como tal, mucha gente piensa “migrar” a postgreSQL ejecutando un “aptitude install postgresql” y dejándolo así … nada más perdido y lejos de la realidad.

Acá, ejecutaremos una instalación que debería ser “básica”, la más básica, para un entorno pequeño de datos, para que sus sistemas “rindan”.

Preámbulo

Uno de los aspectos más importantes es que postgreSQL “no debería” compartir acceso a disco con el sistema operativo, esto es, si es posible que postgreSQL esté en una partición distinta a “root” (incluso un disco separado, de ser recomendable); por lo que la opción “instalar y usar” no debería ser para instalaciones en producción de postgreSQL 9.1.

Hay que tomar en cuenta que postgreSQL (como cualquier otra base de datos) debería ser optimizada posteriormente a su instalación de manera correcta, una de las optimizaciones más necesarias (pero que casi nadie sigue) es gestionar los espacios de datos y separarlos del tablespace pg_default (que gestiona la DB “postgres”, la DB de “information_schema” y demás información, por lo general en “/var/lib/postgresql/9.1/main”); además, ambos deberían estar separados de la partición raíz donde está el sistema operativo.

Las optimizaciones acá realizadas son de las más sencillas a nombrar para postgreSQL, se tomó una máquina virtual en Xen 4.1 en una portátil y se optimizó de lo más básico, para demostrar, que hasta en los cambios más sencillos, pueden afectar el “performance” de aplicaciones diseñadas con postgreSQL.

Preparación primaria

Si estamos instalando un servidor de datos, lo primero que debemos pensar es en separar el montaje de /var del resto del sistema, de hecho, si podemos incluso separar /var/log sería muy apropiado; también es bueno separar /tmp (más 1Gb es innecesario) ya que si no separamos /tmp, Debian GNU/Linux utilizará un tmpfs montado en RAM para gestionar /tmp (restándonos un poco de RAM para trabajar, además que postgreSQL no utiliza la partición /tmp).

Un esquema básico podría ser:

  • / (raiz) (Debian GNU/Linux no ocupa más de 5Gb en este modo)
  • /tmp (1Gb como máximo)
  • swap (Lo necesario, aunque no mayor a 2GB en sistemas con más de 4Gb de RAM)
  • /var (2~4GB ya que será un servidor en producción)

Y de resto, un volumen lógico (LVM) que podemos modificar de tamaño de acuerdo a nuestra necesidad.

Luego de instalado el sistema, procedemos a instalar PostgreSQL.

Instalación

La instalación de postgreSQL 9.1 en Debian GNU/Linux es bastante sencilla:

  • Instalamos postgreSQL 9.1 (pero así no se debería quedar):
    apt-get install postgresql-9.1

PostgreSQL por defecto, creará una carpeta de configuración en: /etc/postgresql/9.1/main/

Y creará un espacio de datos en: /var/lib/postgresql/9.1/main/

Que no utilizaremos para nuestra base de datos, ya que crearemos un espacio propio.

Configuración inicial

Siempre es recomendable dejar el usuario “postgres” (el super-usuario de PostgreSQL) como un usuario “para accesos de emergencia”, ya que este usuario tiene garantizado el acceso a todas partes(si eres root en el sistema), es recomendable que NINGUNA base de datos tenga como “owner” el usuario postgres (y evitar en lo posible utilizarlo como usuario de acceso desde sistemas, aunque esto, obviamente lo he visto más de una vez ocurrir hasta en sistemas web).

  • Creamos un super-usuario para nuestras necesidades, primero cambiamos al usuario postgres:
    su postgres
  • Creamos un usuario, que será nuestro “super-usuario” para “nuestros” accesos, evitando así el usuario postgres:
    createuser -sPl jesuslara
    
    -- ingresamos nuestra contraseña
    Enter password for new role: 
    Enter it again:
  • Ejecutamos la consola SQL de postgreSQL:
    psql
  • Garantizamos al usuario que creaste acceso irrestricto sobre el la DB postgres:
    psql (9.1.3)
    Type "help" for help.
    
    postgres=# grant all on database postgres to jesuslara;
    GRANT

Y salimos de la consola:

postgres=#\quit

Configuración de postgreSQL

  • Accedemos al directorio /etc/postgresql/9.1/main
    cd /etc/postgresql/9.1/main
  • Si vamos a acceder de manera remota a nuestro postgreSQL, agregamos la siguiente línea al archivo pg_hba.conf:
    # la forma es:
    # host -> database (all: todas las db) -> usuario (all: todos los usuarios) -> subnet (de nuestra red) -> modo de clave
    host    all     jesuslara       192.168.100.0/24        md5
  • Habilitamos el acceso remoto en nuestro postgreSQL:

archivo /etc/postgresql/9.1/main/postgresql.conf

listen_addresses = '*'

Optimización del archivo postgresql.conf

  • Y cambiamos algunas opciones básicas del archivo postgresql.conf:
    shared_buffers = 256MB

‘shared_buffers': Es la memoria de trabajo compartida para todo el servidor postgreSQL, fíjese que por defecto en Debian GNU/Linux la opción es 24MB (y el valor por defecto si comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de postgreSQL, es recomendable “al menos” el 25% de la RAM disponible (y jamás > 40%).

temp_buffers = 16MB

‘temp_buffers': La memoria temporal utilizada por cada sesión para las tablas temporarias y para apertura de tablas en cada sesión de cada base de datos, tome en cuenta que este valor dependerá obviamente de la cantidad de datos que carga cada sesión y dependerá muchísimo del sistema que se utiliza.

work_mem = 16MB

‘work_mem': uno de los valores más importantes y más despreciados, “work_mem” se refiere a la memoria temporal utilizada por cada sesión, para las operaciones de ordenamiento (ORDER BY) para las sesiones de diferenciación (GROUP … HAVING y DISTINCT) y para la gestión de hash (uniones HASH, indices HASH, hash_aggregations), si en nuestro sistema realizamos muchísimas consultas ordenadas, agrupadas, diferenciadas por cadenas, etc se crearán mucho de estos buffers de manera paralela, mientras más memoria asignemos, menos probabilidades hay que los ordenamientos y otras operaciones se hagan con archivos temporales en disco (más lentos que la memoria RAM).

max_stack_depth = 8MB

‘max_stack_depth': define el tamaño del espacio utilizado para cómputo de operaciones complejas, su valor está asociado al límite máximo que un usuario (en este caso, “postgres”) tiene derecho a reservar un stack, el valor soportado por nuestra distribución se determina con “ulimit -s”.

shared_preload_libraries = '$libdir/plpython2.so'

‘shared_preload_libraries': Permite cargar una librería específica cuando arranca el sistema, si utilizamos muchos procedimientos almacenados en un lenguaje específico (ej: python, perl, tcl, java, etc), es bueno pre-cargarla para que esté disponible cuando se utilice por primera vez. Nota: esta opción ralentiza un poco el reinicio del sistema.

bgwriter_delay = 500ms

‘bgwriter_delay': El background-writer es un proceso del servidor que se encarga de escribir a disco todos los “shared_buffers” modificados, este proceso conlleva una carga de I/O sobre el disco, su modificación permite o reducir el valor para evitar en lo más posible pérdidas de datos en equipos que pueden fallar, o su incremento permite reducir el I/O al disco duro en sistemas perfectamente protegidos.

Modificados estos parámetros básicos, vamos a modificar nuestro sistema operativo.

Optimización de Linux para postgreSQL

Una de las cosas que olvidamos “optimizar” (tunning) es nuestro sistema operativo GNU/Linux, con grupo de valores en el sysctl ya podemos ayudar “mucho” a nuestro postgreSQL.

  • Agregamos al archivo sysctl.conf

archivo: /etc/sysctl.conf

kernel.sem = 100 32000 100 128
kernel.shmall = 3279547
kernel.shmmax = 289128448
kernel.shmmni = 8192
fs.file-max = 287573
vm.dirty_bytes = 67108864
vm.dirty_background_bytes = 134217728

Nota: observe el valor de shmmax, la cantidad de “memoria máxima reservada para un shared_buffer” que puede crear una aplicación debe ser igual o mayor al valor del shared_buffer de postgreSQL, este valor está en bytes y es ~ 275MB.

La cantidad máxima de archivos que pueden abrirse en un sistema, dependerá obviamente del nivel de trabajo de la DB, durante una operación regular, la gente puede ejecutar “lsof | wc” para obtener la cantidad de archivos abiertos.

  • Y luego, las aplicamos:
    sysctl -p
    
    --
    kernel.sem = 100 32000 100 128
    kernel.shmall = 3279547
    kernel.shmmax = 289128448
    kernel.shmmni = 8192
    fs.file-max = 287573
    vm.dirty_bytes = 67108864
    vm.dirty_background_bytes = 134217728

Ya, con estos sencillos cambios, podemos reiniciar el postresql:

/etc/init.d/postgresql restart
Restarting PostgreSQL 9.1 database server: main.

Y estamos listos para crear una partición y tablespace para nuestra DB.

Creación del espacio de tablas

Creamos una partición del tamaño necesario para contener “al menos” nuestra base de datos (esta es una guía básica, no hablaremos de particiones adicionales para metadatos, para índices y demás).

Nota: en nuestro caso, la partición es /dev/xvdb1 y mide 10GB.

El “journal”, para quien no lo conoce, es la razón por la cual no existe software de “desfragmentación” en Linux, todos los sistemas operativos que lo soportan (ext3, ext4, jfs, reiserfs, xfs, zfs, etc) tienen servicios que se encargan de ordenar, desfragmentar y gestionar tanto la data como los metadatos (información acerca de los archivos y carpetas en sí), pero además, los journal cumplen otras funciones, entre ellas, recuperar desde sus logs la data que pudiera “haberse perdido” luego de un fallo de energía y/o de sistema.

En sistemas de base de datos, la data es contenida en uno o más (y diversos) tablespaces, espacios de tablas donde la data, metadata e índices es contenida, como es la base de datos la encargada de gestionar la posición de los datos en ellos, el Sistema Operativo no requiere la presencia de un journal, o al menos, de un journal más relajado y menos estricto.

Formateando la partición

  • Se formatea la partición (disco):
    mkfs.ext4 -E stride=32 -m 0 -O extents,uninit_bg,dir_index,filetype,has_journal,sparse_super /dev/xvdb1

Utilizamos ext4, porque en modo “writeback” tiene un mayor performance que XFS para almacenar los tablespaces y tiene menor propensión a fallos.

  • Habilita el journal en modo writeback:
    tune2fs -o journal_data_writeback /dev/xvdb1
  • Si simplemente desea eliminar el journal, ejecute:
    tune2fs -O ^has_journal /dev/xvdb1
  • Nota: utilice esta opción a su propio riesgo, recuerde que no tener un journal afecta de 2 modos:
  • La data no es colocada en orden en el disco, fragmentando el mismo
  • Ante un fallo de energía, el FS no podrá recuperar desde el journal las últimas actividades para recuperar esos datos.
  • Se ejecuta un chequeo de archivo básico:
    e2fsck -f /dev/xvdb1
  • Creamos la carpeta de postgresql:
    mkdir /srv/postgresql
  • Y luego se monta con las opciones que describiremos más abajo:
    mount -t ext4 /dev/xvdb1 /srv/postgresql -o  noatime,nouser_xattr,noacl,discard,nodelalloc,data=writeback,barrier=0,commit=300,nobh,i_version,inode_readahead_blks=64,errors=remount-ro

Las opciones son:

Opciones de FS Linux:

noatime

No guardar la información del timestamp del último acceso a los archivos, esta información no es necesaria ya que postgreSQL gestiona apropiadamente el acceso a los tablespaces.

nouser_xattr

Deshabilita el uso de atributos extendidos de usuario, esto es seguro en postgreSQL ya que la carpeta donde se guardan los tablespaces no requiere ninguno de esos atributos.

noacl

No utilizar atributos extendidos ni ACLs POSIX, no son necesarias ya que solamente postgreSQL tendrá acceso a los archivos en esta partición.

Opciones específicas de ext4:

nobh

ext4 asocia buffers de datos con las páginas de datos, esos bloques de cache proveen garantía de ordenamiento de los datos; “nobh” evita el uso de estos buffers de ordenamiento de datos (sólo activable con “data=writeback”).

data=writeback

No se preserva el ordenamiento de los datos, la data será escrita en el sistema de archivos solo después que la metadata ha sido guardada en el journal. Aunque hay personas que recomiendan desactivar el “journaling” del disco, esto no es recomendable pues, aunque postgreSQL gestiona correctamente los datos, los metadatos (información de los archivos y carpetas en el FS) es responsabilidad de mantenerla consistente el FS.

commit=seconds

Los datos y metadatos son escritos a disco cada “n” cantidad de segundos, el valor por defecto son 5 segundos (commit=0 es igual a dejar el valor por defecto), un valor más bajo puede mejorar la seguridad de los datos, un valor muy alto mejora el performance pero ante un fallo podría perderse datos.

barrier=0

Deshabilita el uso de barreras de escritura, las barreras de escritura fuerzan el uso de ordenamiento on-disk de los commits al journal, haciendo las caché de disco seguras de usar, pero un daño en el performance del disco.

inode_readahead_blks=n

Cantidad de inodes que el sistema de pre-lectura de ext4 lee al buffer caché, el valor por defecto de n es 32, pero un valor de 64 es normal para optimizar las lecturas.

discard

Permite decidir que realiza con los bloques que son liberados, por lo general ext4 ejecuta una operación de trim (limpieza), con esta opción, ellos simplemente son marcados como descartados, evitando la escritura innecesaria de bloques.

i_version

Permite indicar que los inodes serán de 64-bits, solo disponible si se está en un sistema a 64 bits.

  • Luego de montada de esta manera, lo fijamos en el /etc/fstab
# particion para postgresql
/dev/xvdb1 /srv/postgresql ext4 rw,noatime,errors=remount-ro,nouser_xattr,noacl,commit=300,barrier=0,i_version,nodelalloc,data=writeback,inode_readahead_blks=64,discard 0 0
  • Comprobamos:
    mount -a

Y ya estamos listos para crear el espacio de datos para nuestra DB!.

El espacio de tablas (tablespace)

Crearemos un simple espacio de tablas en nuestro optimizado sistema de archivos ext4 para contener nuestra base de datos:

  • cambiamos el propietario a la carpeta /srv/postgresql
    chown postgres.postgres /srv/postgresql
  • cambiamos al usuario “postgres” y abrimos la consola ‘psql':
    su postgres
    psql
  • En la consola, ejecutamos el comando para crear un espacio de tablas:
    postgres=# CREATE TABLESPACE db_sistema OWNER jesuslara LOCATION '/srv/postgresql';

Y listo!, ya tenemos un espacio de tablas disponible para crear bases de datos y optimizado!

Usando el espacio de datos optimizado

Para crear una DB que no esté asociada al espacio “por defecto” (pg_default) ejecutamos:

  • Crear una DB:
CREATE DATABASE sistema WITH ENCODING='UTF8' OWNER=jesuslara TEMPLATE=template0 TABLESPACE=db_sistema;

Y como verán, le pasamos el tablespace “db_sistema” que hemos creado anteriormente.

¿Alguna prueba de la eficiencia?

La configuración siguiente no se hizo en un sistema dedicado para tal, se realizó en una portátil, corriendo Xen 4.1 y en una VM con 1GB de RAM se instaló el postgreSQL con las opciones nombradas, sin embargo, es posible notar una mejora en el performance general de las consultas (y eso que son solamente optimizaciones básicas).

Para ello, creamos una DB adicional, de un sistema administrativo (migrado desde Oracle hasta postgreSQL) que un amigo amablemente me facilitó para esta prueba.

Para ello, se movieron algunas funciones de código “Visual Basic” a código PL/Python y PL/pgSQL y se creó una consulta semi-compleja, de unas 26 líneas de extensión, que unifica unas 6 tablas del sistema para calcular una simple pre-nómina (ivss, paro forzoso, caja de ahorros, faov, isrl, etc); hay que notar que en la versión “cliente-servidor” de la aplicación, la nómina de 13 mil empleados dura varias minutos hasta horas con múltiples conceptos; para nuestra versión “simplificada” (5 asignaciones y 3 deducciones y cálculo de salario integral); la consulta se ejecutó en: 33068ms Para 13674 registros.

Pero, lo mejor ocurre si lo ejecutas por segunda vez!, ya que los buffers de trabajo mantienen en cache las operaciones de hash_aggregate (necesarias para algunos de los cómputos de agregado realizados), la segunda ejecución fué: 3107 milisegundos (3 segundos)

¿13 mil cómputos de empleados en 3 segundos?, ¡Nada mal para ser una portátil!

Conclusiones

Estas optimizaciones no son ni la décima parte de las que podemos optimizar de postgreSQL, pero es un comienzo, esta guía surge de la necesidad de orientar a las personas, que creen que pueden poner un sistema en producción de un postgreSQL recién instalado, estas optimizaciones mínimas, que cualquiera puede seguir, son un ejemplo y un comienzo.

No se dejen engañar con esas personas que dicen que “postgreSQL no rinde como Oracle” y un largo etcétera de excusas baratas, si alguien en su sano juicio instala Oracle cambiando parámetros en el sysctl, modificando los valores de tunning del sistema operativo o del sistema de archivos, clusterizar al máximo e incluso hace cosas más “malandras” como generar índices “al vuelo” por aquellos DBA vagos que jamás piensan bien sus bases de datos; ¿por qué la gente no hace lo mismo con postgreSQL?, tal vez porque ser un DBA “certificado postgreSQL” es más difícil y hacer entender a la gente, cuando crean un sistema conectado a datos, que su principal preocupación no debería ser “si usar PHP o Python” sino ver de qué formas optimizarás el S.O, el sistema de archivos, las consultas, el planificador, el acceso a disco y la gestión de índices para lograr que te sea “inocuo” si la gente utiliza perl o Visual Basic como Front-End.

Al final, postgreSQL debe tener el mando de los datos de la aplicación, y aprender a “verdaderamente” instalarlo, es el primer paso!.

¡Happy Hacking!

[Trac] Instalando SCM Trac en Debian Wheezy y derivados (Ubuntu, Mint, Canaima)

Preámbulo

Un amigo me solicitó la bitácora de instalación de Trac en Debian Wheezy, había tenido algunos detalles utilizando Trac y postgreSQL 9, por lo que decidí publicarla para que más personas pudieran aprovecharla, sin embargo, como el Wiki de GNU de Venezuela no está operativo (donde estaba la versión Squeeze) entonces publicaré toda la guía por acá.

Instalación de Trac

Trac funciona en el modo “instancia”, cada instancia requiere de su propia base de datos y de su propia carpeta (instancia), pero comparten un único punto en el servidor web, aunque Trac utiliza por defecto sqlite para la base de datos, utilizaremos postgreSQL.

La instalación se realiza en una distribución Debian-based pero puede ser realizada en cualquier distribución GNU/Linux que posea python-setuptools y el comando easy_install (o pip).

Instalación de dependencias

  • Instalar las dependencias en Debian Wheezy (o distribución compatible con aptitude | apt-get):
aptitude install apache2 python2.7-setuptools python-genshi python-pybabel python-psycopg2 python2.7-psycopg2 libapache2-mod-wsgi python-babel babel-1.4.0 postgresql-8.4 subversion git mercurial bzr

Nota: si utiliza postgresql-9.1 con Trac < 0.12.2 tendrá que realizar una correción en el código fuente de Trac para poder crear instancias en schemas de postgreSQL 9.

Nota: Si se instala babel posterior a la instalación de Trac, deberá reinstalar trac y actualizar sus instancias.

  • Opcionalmente, podemos actualizar setuptools (requiere conexión a Internet)
easy_install -U setuptools

Instalación de Trac

  • Vía apt-get:
    apt-get install trac trac-bzr trac-git trac-graphviz trac-mercurial trac-odtexport trac-wikiprint
  • ó via easy_install:
easy_install Babel==0.9.5 Genshi==0.6
easy_install Trac
  • También podemos descargar el fuente e instalarlo manualmente:
    wget -c http://ftp.edgewall.com/pub/trac/Trac-0.12.2.tar.gz
    tar xvf Trac-0.12.2.tar.gz
    cd Trac-0.12.2
    python ./setup.py install

Nota: si deseamos instalar (o descargar) la versión de pruebas ejecutamos:

  • Usando easy_install:
easy_install Trac==dev
  • Descargando:
    svn co http://svn.edgewall.org/repos/trac/trunk trac
    cd trac
    python ./setup.py install

Por ultimo, luego de instalado, verificamos que tenemos la última versión:

trac-admin --version

Luego de instalado Trac, procedemos a configurar una instancia.

Configuración de una instancia

Preparación de la DB de postgreSQL

Agregar las siguientes líneas al archivo pg_hba.conf:

archivo: /etc/postgresql/{version}/main/pg_hba.conf

local tracdb tracuser password
host tracdb tracuser 127.0.0.1/32 md5
host tracdb tracuser [subnet]/24 md5
#para poder iniciar sesion en red:
host all all [subnet]/24 md5

Donde [subnet] se reemplaza por la subnet de la red local; ejemplo:

local tracdb tracuser password
host tracdb tracuser 127.0.0.1/32 md5
host tracdb tracuser 192.168.1.0/24 md5
#para poder iniciar sesion en red:
host all all 192.168.1.0/24 md5

Y en postgresql.conf modificamos:

listen_addresses = '*'

Nota: solo necesario si el postgreSQL y el Trac estarán en diferentes equipos.

  • Iniciar una consola y ejecutar:
su postgres
  • E iniciar una consola de postgreSQL:
    >psql
  • En la consola de postgreSQL, crear la DB:
  • Para crear una DB en > 8.4 ejecutar:
    CREATE DATABASE tracdb
      WITH ENCODING='UTF8'
           TEMPLATE=template0
           LC_COLLATE='C'
           LC_CTYPE='C'
           CONNECTION LIMIT=-1;
  • para 8.3 o inferior:
    CREATE DATABASE tracdb 
    WITH ENCODING='UTF8' 
    TEMPLATE=template0 
    LC_COLLATE 'C' 
    LC_CTYPE 'C';
  • Crear el usuario necesario para gestionar la DB:
create user tracuser password 'clavesecreta';
  • Y garantizar los permisos necesarios sobre la DB de trac:
    grant all on database tracdb to tracuser;
  • Salimos del postgresql:
postgres=# \q

Y reiniciamos el postgreSQL:

/etc/init.d/postgresql restart

Ya estamos listos para crear una instancia de Trac.

(Opcional) Preparación de Trac con postgreSQL 9.1

Nota: cambios iniciales para Trac 0.12 y postgreSQL 9.1

Si se intenta crear una instancia de Trac en postgreSQL 9.1 utilizando un schema personalizado (no “public”), Trac devolverá un error por un detalle en el uso de psycopg (la librería python para conectarse a Trac), dicho error se ve así:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/trac/admin/console.py", line 422, in do_initenv
    options=options)
  File "/usr/lib/python2.7/dist-packages/trac/env.py", line 213, in __init__
    self.create(options)
  File "/usr/lib/python2.7/dist-packages/trac/env.py", line 401, in create
    DatabaseManager(self).init_db()
  File "/usr/lib/python2.7/dist-packages/trac/db/api.py", line 146, in init_db
    connector.init_db(**args)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 98, in init_db
    params)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 87, in get_connection
    params)
  File "/usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py", line 212, in __init__
    cnx.cursor().execute('SET search_path TO %s', (self.schema,))
DataError: invalid value for parameter "search_path": "weyu"
DETAIL:  schema "weyu" does not exist

Es un error en el archivo /usr/lib/python2.7/dist-packages/trac/db/postgres_backend.py, dicho error ya está corregido en versiones posteriores de Trac y existe un patch para dicho archivo:

  • Parche que está en la incidencia #10406 de Trac:

 http://trac.edgewall.org/attachment/ticket/10406/10406-search-path-r10830.patch

Si desean hacer los cambios ustedes mismos, las líneas a cambiar son:

Línea 34:

34	 	    from psycopg2 import ProgrammingError as PGSchemaError <- eliminar esta
 	34	    from psycopg2 import DataError, ProgrammingError <- agregar esta

Línea 214:

214	 	        except PGSchemaError: <- eliminar esta
 	214	        except (DataError, ProgrammingError): <- agregar esta

Con esta correción podrán crear instancias en postgreSQL 9.1.

Creando un ambiente base (environment Trac)

  • Creamos el árbol de proyectos:
mkdir /srv/{repositorios,trac,proyectos} -p
  • Nos dirigimos a la carpeta de proyectos:
cd /srv/proyectos
  • Inicializamos la primera instancia de trac (se llamará documentacion)
trac-admin /srv/proyectos/documentacion initenv
  • Se inicia un script que realliza una serie de preguntas:
Project Name [My Project]> Documentacion GNU/Linux
  • Conexión a la DB:
Database connection string [sqlite:db/trac.db]>
  • forma del database connection string
    ''{database}://{usuario}:{contraseña}@{host}:{port}/{database}?schema={schema}''

Ejemplo:

postgres://tracuser:clavesecreta@localhost:5432/tracdb?schema=documentacion

Nota: de usar el schema “public”, simplemente no pasar la opcion schema: ejemplo:

postgres://tracuser:clavesecreta@localhost/tracdb
  • Si deseamos usar unix-sockets:

postgres://user:pass@/dbname?host=/path/to/unix/socket/dir&schema=schemaname

Ejemplo:

postgres://tracuser:clavesecreta@/tracdb?host=/var/run/postgresql/.s.PGSQL.5432/dir&schema=documentacion

— Al terminar la configuración de trac, podemos iniciar las pruebas:

  • ejecutamos:

tracd –port 8000 /srv/proyectos/documentacion

Y apuntamos nuestro navegador a:

 http://host:8000/documentacion

Luego de chequeado, procedemos a configurar nuestra instancia de Trac.

Configuración de Apache y Trac

Debemos crear un ambiente web (www) con WSGI del Trac para apache, para ello desplegamos en la carpeta web (/srv/trac/www’) el sitio web:

trac-admin /srv/proyectos/weyu deploy /srv/trac/www/

Creamos el virtualHost para multiples proyectos de trac, creamos un archivo en:

/etc/apache2/sites-availables/trac.site

<VirtualHost *:80>
# administrador del servidor
ServerAdmin jesuslara@DOMINIO
# nombre del vhost
ServerName proyectos.DOMINIO
# alias del servidor
ServerAlias trac.DOMINIO
DocumentRoot /srv/trac/www/htdocs/

        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

WSGIScriptAlias / /srv/trac/www/cgi-bin/trac.wsgi

    <Directory /srv/trac/www>
        WSGIApplicationGroup %{GLOBAL}
        SetEnv trac.env_parent_dir /srv/proyectos
        Order deny,allow
        Allow from all
    </Directory>

    ErrorLog /srv/trac/www/log/apache-error.log
    CustomLog /srv/trac/www/log/access.log combined

</VirtualHost>
  • Creamos el directorio para los logs de apache:
mkdir /srv/trac/www/log && chown www-data.www-data /srv/trac/www/ -R
  • Modificamos el archivo trac.wsgi /srv/trac/www/cgi-bin/trac.wsgi:

Este queda:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys
sys.stdout = sys.stderr

import os
import trac.db.postgres_backend
trac.db.postgres_backend.PostgreSQLConnection.poolable = False

os.environ['TRAC_ENV_PARENT_DIR'] = '/srv/proyectos/'

def application(environ, start_request):
    if not 'trac.env_parent_dir' in environ:
        environ.setdefault('trac.env_path', '/srv/proyectos/documentacion')
    if 'PYTHON_EGG_CACHE' in environ:
        os.environ['PYTHON_EGG_CACHE'] = environ['PYTHON_EGG_CACHE']
    elif 'trac.env_path' in environ:
        os.environ['PYTHON_EGG_CACHE'] = \
            os.path.join(environ['trac.env_path'], '.egg-cache')
    elif 'trac.env_parent_dir' in environ:
        os.environ['PYTHON_EGG_CACHE'] = \
            os.path.join(environ['trac.env_parent_dir'], '.egg-cache')
    from trac.web.main import dispatch_request
    return dispatch_request(environ, start_request)

Apache debe acceder al directorio de proyectos:

chown www-data.www-data /srv/proyectos -R
  • Y al directorio trac/htdocs:
chown www-data.www-data /srv/trac -R
  • Reiniciamos apache:
/etc/init.d/apache2 restart
  • Y ya podemos acceder a nuestra instancia vía la ruta del  virtualhost:

 http://host/documentacion

Quedando el directorio así:

.
|-- proyectos
|   `-- documentacion
|       |-- attachments
|       |-- conf
|       |-- htdocs
|       |-- log
|       |-- plugins
|       `-- templates
|-- repositorio
|   `-- documentacion
`-- trac
    `-- www
        |-- cgi-bin
        |-- htdocs
        |   |-- common
        |   |   |-- css
        |   |   |-- guide
        |   |   `-- js
        |   `-- site
        `-- log

(opcional) Configuración de múltiples ambientes (instancias)

Aunque se puede crear una base de datos para cada instancia, utilizaremos una única base de datos postgreSQL y schemas por cada instancia de Trac.

  • Inicializamos una nueva instancia:
trac-admin /srv/proyectos/lyx-book/ initenv
  • Configuramos la instancia:
Project Name [My Project]> Lyx Book

Database connection string [sqlite:db/trac.db]> postgres://tracuser:clavesecreta@localhost:5432/tracdb?schema=lyx
  • Propietario www-data a la carpeta del proyecto:
chown www-data.www-data /srv/proyectos -R
  • reiniciamos apache:
/etc/init.d/apache2 restart
  • Y ya podemos ver la nueva instancia en la lista de instancias:
  • al acceder al vhost, veremos la lista de instancias:

 http://host/

– Lista de instancias:

—————————————-

Available Projects

—————————————-

Autenticación inicial del Trac

La autenticación inicial se realizará vía htpasswd (en próximo artículo, agregaré la autenticación openldap).

  • Agregamos un usuario de sistema, para administrar el trac
useradd administrador
  • Creamos el archivo inicial para autenticar los usuarios con Trac
htpasswd -c /srv/trac/www/.htpasswd administrador
  • nota: inicialmente autenticamos con el usuario administrador, con la contraseña que le asignemos.
  • Y agregamos la entrada de autenticación al vhost del trac:
        <Location />
                AuthType Basic
                AuthName "Trac"
                AuthUserFile /srv/trac/www/.htpasswd
                Require valid-user
        </Location>
  • Luego, agregamos la info de autenticación via HTPASSWD al archivo de configuración de la instancia:
  • nota: el archivo de configuración de la instancia está en /srv/proyectos/{instancia}/conf/trac.ini, ejemplo:

archivo: /srv/proyectos/documentacion/conf/trac.ini

  • Agregamos la autenticación vía htpasswd:
[account-manager]
account_changes_notify_addresses =
password_file = /srv/trac/www/.htpasswd
password_format = htpasswd
password_store = HtPasswdStore
  • Le damos privilegios de TRAC_ADMIN al usuario administrador:
trac-admin /srv/proyectos/documentacion
  • Aparece la consola de la instancia de Trac:
-
Welcome to trac-admin 0.12.2
Interactive Trac administration console.
Copyright (C) 2003-2011 Edgewall Software

Type:  '?' or 'help' for help on commands.

Trac [/srv/proyectos/documentacion]>
  • Y en la consola ejecutamos el siguiente comando:
permission add administrador TRAC_ADMIN
  • Salimos de la consola:
>exit
  • Ejecutamos el upgrade de la instancia:
trac-admin /srv/proyectos/weyu upgrade
  • Y reiniciamos apache:
/etc/init.d/apache2 restart

Y ya podemos entrar al trac como el usuario administrador:

 http://host/documentacion/admin/

Ahora podemos personalizar ciertas opciones como incorporar plugins o agregar temas.

Incorporar un Tema a Trac

Para incorporar un tema a Trac, se debe primeramente incorporar el  http://trac-hacks.org/wiki/ThemeEnginePlugin Theme Engine Plugin

Instalación del Theme Engine Plugin

  • Descargamos el gestor de temas:
svn co http://trac-hacks.org/svn/themeengineplugin/0.11/ theme-engine
  • compilamos e instalamos:
cd theme-engine
python setup.py install
  • Habilitamos el theme engine plugin en el archivo conf/trac.ini
[components]
themeengine.* = enabled
  • Y reiniciamos el apache:
    /etc/init.d/apache2 restart

Ya podemos instalar un nuevo tema.

Instalar un Tema

  • Descargamos el tema que necesitamos:
svn co http://trac-hacks.org/svn/pydotorgtheme/0.11/ pydotorgtheme
  • Habilitamos el tema como plugin en el archivo conf/trac.ini
  • Se agregan a la sección ![components] del archivo trac.ini:
    pydotorgtheme.* = enabled
  • Habilitamos el tema en la sección ![theme] del archivo conf/trac.ini
[theme]
theme = PyDotOrg
  • Reiniciamos apache:
/etc/init.d/apache2 restart

Y ya contamos con un nuevo tema instalado.

Instalando un plugin de Trac

Para instalar un plugin de trac por la vía de la descarga, primero, ubicamos y descargamos la fuente;

  • Descargamos, el plugin de Mercurial
svn co http://svn.edgewall.com/repos/trac/plugins/0.12/mercurial-plugin
  • Nos movemos a la carpeta:
    cd mercurial-plugin
  • Ejecutamos la instalación del plugin:
python setup.py install
  • Y luego incorporamos dicho plugin al ‘conf/trac.ini’
[components]
tracext.hg.backend.*
  • Nota: podremos saber el nombre del componente a agregar en el archivo “setup.py > packages”.

Algunos plugins solicitarán actualizar (upgrade) de la instancia, para ello:

  • Ejecutamos en una cónsola:
trac-admin /srv/proyectos/documentacion upgrade
  • Y reiniciamos apache:
    /etc/init.d/apache2 restart

Configuración de repositorios

La configuración de repositorios (directorios donde se almacena código fuente versionado gracias a un VCS) depende de cada software de VCS utilizado, por defecto Trac gestiona Subversion, pero puede habilitarse para otros VCS.

Subversion

  • Instalamos subversion
aptitude install subversion libapache2-svn
  • Creamos la carpeta para el proyecto que deseamos versionar:
mkdir /srv/repositorio/proyecto-svn
  • Creamos el ambiente del proyecto SVN:
svnadmin create /srv/repositorio/proyecto-svn
  • Y le damos privilegio a apache para leerlo:
chown www-data.www-data /srv/repositorio -R
  • Entramos en el environment del trac:
trac-admin /srv/proyectos/documentacion
  • Agregamos el repositorio:
repository add proyecto-svn /srv/repositorio/proyecto-svn svn
  • nota: la sintaxis es: repository add {nombre} {ruta} {tipo}
  • Y ejecutamos la sincronización:
Trac> repository resync proyecto-svn 

Resyncing repository history for proyecto-svn ... 
0 revisions cached. 
Done.
  • Podemos ejecutar la resincronización de todos los repositorios existentes ejecutando:
repository resync '*'

Mercurial (Hg)

  • Instalamos el soporte a mercurial en nuestra distribución:
aptitude install mercurial
  • Descargamos el plugin
svn co http://svn.edgewall.com/repos/trac/plugins/0.12/mercurial-plugin
  • E instalamos el plugin de mercurial:
    cd mercurial-plugin
    python setup.py install
  • Configuramos el plugin de mercurial (hg) en el trac.ini
[components]
tracext.hg.backend.*
  • agregamos la configuración del plugin mercurial
    [hg]
    # -- Show revision number in addition to the changeset hash (defaults to yes)
    show_rev = yes
    # -- Changeset hash format
    node_format = short
  • Reiniciamos el environment de trac y apache:
trac-admin /srv/proyectos/documentacion upgrade && /etc/init.d/apache2 restart

Y ya tenemos configurado el soporte para Mercurial en Trac, ahora procedemos a agregar un repositorio:

  • Para agregar un repositorio Hg (Mercurial) creamos:
mkdir /srv/repositorio/hg/gnu
  • Nos movemos al directorio:
cd /srv/repositorio/hg/gnu/
  • Iniciamos Mercurial en la carpeta
    hg init
  • Y actualizamos:
    hg update
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
  • Entramos en el environment del trac:
trac-admin /srv/proyectos/documentacion
  • Agregamos el repositorio:
>repository add gnu-hg /srv/repositorio/hg/gnu hg
  • Y ejecutamos la re-sincronización:
    Trac [/srv/proyectos/documentacion]> repository resync gnu-hg
    Resyncing repository history for gnu... 
    0 revisions cached.
    Done.

GIT

Configurando Git

  • Instalamos lo necesario para git:
    aptitude install git git-core git-daemon-run
  • instalamos el plugin de GIT
    easy_install http://github.com/hvr/trac-git-plugin/tarball/master
  • Reiniciamos apache:
    /etc/init.d/apache2 restart
  • Agregamos la sección GIT al trac.ini
    [git]
    cached_repository = false
    persistent_cache = false
    shortrev_len = 7
    wiki_shortrev_len = 7
    git_bin = /usr/bin/git
    trac_user_rlookup = true
    use_committer_id = false
    use_committer_time = false
  • Y habilitamos el plugin (trac.ini)
    [components]
    tracext.git.* = enabled
  • Tambien agregamos la posibilidad de tener GIT post-commit hooks:
    [components]
    tracopt.ticket.commit_updater.committicketreferencemacro = enabled
    tracopt.ticket.commit_updater.committicketupdater = enabled
  • Y cambiamos esto (en el trac.ini):
    repository_sync_per_request = (default)

    — por esto:

    repository_sync_per_request =

Ya configurado GIT, creamos un repositorio.

Creación de un repositorio GIT

  • Creamos la carpeta:
mkdir /srv/repositorios/lyx-book
  • La convertimos en un repositorio git vacio:
    git --bare init
  • Nota: el directorio debe ser de tipo “bare”, ya que Trac debe tener acceso a los archivos de control (HEAD y config) de GIT y no solo el directorio .git/
  • Incorporamos los archivos necesarios, ejecutamos su adhesión al GIT:
    git add .
  • Ejecutamos el primer commit del repositorio:
    git commit -a -m 'first commit'
  • Verificamos su estado:
    git status
    # On branch master
    nothing to commit (working directory clean)
  • Cargamos la consola de la instancia:
    trac-admin /srv/proyectos/documentacion
    
    Welcome to trac-admin 0.12.2
    Interactive Trac administration console.
    Copyright (C) 2003-2011 Edgewall Software
    
    Type:  '?' or 'help' for help on commands.
    
    Trac [/srv/proyectos/documentacion]>
  • Incorporamos el repositorio:
repository add lyx-book /srv/repositorio/lyx-book git
  • Ejecutamos la sincronización:
    repository resync lyx-book

Conclusiones

Trac es una excelente herramienta  de SCM (Source Code Management) ya que combina Wiki, Gestión de incidencias (ticket, bug-tracking), gestión de código VCS y se le pueden incorporar plugins de terceros que incluyen desde un foro hasta un blog.

Xen 4 y Debian: corrigiendo algunos detalles

Instalar Xen 4.x en Debian GNU/Linux es bastante sencillo (el metapaquete xen-linux-system), ahora bien, configurar para hacer funcionar otras cosas es otra tarea distinta; por ejemplo, encontrarán que 6 cosas no  funcionan “a la primera” en Debian y deberá corregirlas para disfrutar al máximo de Xen 4.x:

1.- Habilitando XenAPI y accediendo con virt-manager

Virt-manager es la herramienta gráfica para libvirt (librería para acceso a servicios de virtualización, integra KVM, Qemu, Xen, LXC, openVZ y hasta VMWare) diseñada por la gente de Red Hat y que raya en lo infantil por su facilidad de uso para gestionar sistemas virtualizados, sin embargo, notaremos que luego de instalarlo, no podremos acceder a nuestro sistema Xen.

Para acceder con virt-manager (luego de instalado virt-manager y libvirt-bin) es activar el acceso por la API de Xen:

Editamos:

archivo: /etc/xen/xend-config.sxp

Y habilitamos http-server (en el puerto 8000, es el que usa libvirt), descomentamos (y ponemos en “yes”):

(xend-http-server yes)

Nota: si desean acceder desde cualquier equipo con libvirt (y no solo desde localhost), agregan esta línea:

(xend-address ”)

Posteriormente, debemos agregar al usuario con el que vamos a acceder al dominio Xen al grupo libvirt (ojo: esto como medida de seguridad para no acceder con el usuario root):

adduser jesuslara libvirt

E instalamos los paquetes necesarios para virt-manager y para que este nos interrogue por nuestra contraseña:

aptitude install virt-goodies ssh-askpass ssh-askpass-gnome

Listo!, ya podremos conectarnos a nuestro Xen vía un tunel remoto SSH (accedemos a “Archivo > Nueva Conexión  y seleccionamos Xen y modo “Tunel SSh Remoto”), usando nuestro usuario y nuestra contraseña.

2.- Creando VMs, configurando virt-manager

Una cosa que debemos configurar antes de empezar a crear máquinas con virt-manager, es indicarle en qué forma creamos los discos de las máquinas virtuales, esto se hace en el menú “Detalles” de la conexión al servidor Xen:

En esta ventana hay una pestaña que dice “almacenamiento”, donde podrán indicar si se crean volúmenes LVM, archivos de imagen en disco, etc

He creado 3 tipos de almacenamiento, un grupo de volúmenes LVM (para las máquinas virtuales), un espacio en disco (en /srv/xen) para aquellas máquinas que crearé usando archivos .img (imágenes qcow exportables) y una carpeta especial, donde he copiado los ISO de todos los sistemas operativos que utilizaré, así los podré usar rápidamente cada vez que quiera crear una nueva VM.

Ya con esto (Y la red), podrán crear máquinas virtuales.

3.- Creando VMs con HVM (virtualización completa) en virt-manager

Cuando intentan crear una VM HVM (que requiera virtualización completa, ejemplo, un Windows) con virt-manager, este emitirá un error de que no encuentra qemu-dm, esto es debido a que Xen utiliza una forma modificada de KVM y el ejecutable (aunque instalado, se llama “xen-qemu-dm-4.0″) no se encuentra en el lugar que espera virt-manager, esto se resuelve fácilmente con un enlace simbólico:

ln -s /usr/lib64/xen-4.0 /usr/lib64/xen

Y listo!, ya pueden crear máquinas usando HVM, fijense en este equipo freeBSD:

4.- virt-manager y “xm new” no funciona

“xm create” es la forma “usual” como creamos VMs en Xen, sin embargo, esto tiene un inconveniente, la VM es “creada” cada vez que se inicia y “destruida” (léase mejor, retirada de la lista de dominios administrados) del gestor de dominios Xen cada vez que se apaga, debido a esto, la VM no puede ser gestionada vía la XenAPI o vía gestores externos basados en libvirt (como virt-manager).

Este es un error heredado de Xen 3.x, cuando ejecutamos “xm new” aparece el siguiente error:

xm new -f test.cfg

Unexpected error: <type ‘exceptions.ImportError’>
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File “/usr/lib/xen-4.0/bin/xm”, line 8, in <module>
main.main(sys.argv)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3620, in main
_, rc = _run_cmd(cmd, cmd_name, args)
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 3644, in _run_cmd
return True, cmd(args)
File “<string>”, line 1, in <lambda>
File “/usr/lib/xen-4.0/lib/python/xen/xm/main.py”, line 1449, in xm_importcommand
cmd = __import__(command, globals(), locals(), ‘xen.xm’)
File “/usr/lib/xen-4.0/lib/python/xen/xm/new.py”, line 26, in <module>
from xen.xm.xenapi_create import *
File “/usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py”, line 22, in <module>
from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc

Esto es debido a la ausencia del módulo xmlproc de python, sin embargo, cuando intentamos instalarlo ocurre esto:

apt-get install python-xml
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
El paquete python-xml no está disponible, pero algún otro paquete hace referencia
a él. Esto puede significar que el paquete falta, está obsoleto o sólo se
encuentra disponible desde alguna otra fuente
E: El paquete «python-xml» no tiene un candidato para la instalación

El paquete ya no existe (porque fué reemplazado por python-lxml) y porque xmlproc ya no está en esa librería, sin embargo, como XMLproc es utilizado simplemente para validar el DTD de los archivos XML generados por xenAPI (y eso no es un “error fatal” que afecte la creación de la VM administrada) entonces;  para hacerlo funcionar, simplemente abrimos el archivo:

archivo : /usr/lib/xen-4.0/lib/python/xen/xm/xenapi_create.py

Y editamos la línea 22, comentándola:

#from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd

Cuando ejecutamos:

xm new -f test.cfg 
Using config file "./test.cfg".

Ahora veremos que la VM test está incorporada al administrador Xen permanentemente (permitiendo ser gestionada por la API vía xenapi o vía libvirt):

xm list
Name        ID  Mem    VCPUs    State Time(s)
Domain-0    0   2752   2        r----- 90.2
freebsd         512    1               0.0
test            256    1               0.0
winxp           1250   2               1358.4

Nótese que las VMs gestionadas por XenAPI no tienen ID si están apagadas, para encenderlas indicamos:

xm start test

Y veremos que la VM “test” se inicia, incluso podemos gestionarla vía libvirt (ej: virt-manager):

Nota: ¿y cómo editamos un domU administrado?, si contamos con el archivo cfg, entonces simplemente eliminamos el dominio:

xm delete test

Y lo volvemos a incorporar con xm new.

Si no contamos con el archivo cfg (porque tal vez lo creó otra herramienta) entonces debemos editar el dominio en “/var/lib/xend/domains/”, recuerde, sin embargo, que este archivo tiene la forma “SXP” (un parser a XML hecho en perl para sablotron, que permite persistencia de objetos en un pseudo-lenguaje de marcado), como esta:

(domain
(domid 3)
(vcpus_params ((cap 0) (weight 256)))
(PV_args ‘root=/dev/xvda2 ro ip=:127.0.255.255::::eth0:dhcp ‘)
(PV_bootloader )
(cpus (()))
(memory_sharing 0)
(superpages 0)
(VCPUs_live 1)
(actions_after_crash restart)
(uuid 6257207b-6831-ddcd-a21d-010a5fb77070)
(PV_ramdisk /boot/initrd.img-3.2.0-0.bpo.2-amd64)

5.- Mi VM Windows es lenta, ¿cómo hago?

Una de las razones por las cuáles la gente usa VMWare, es qué, como toda herramienta privativa, accede a información confidencial a la cual no acceden empresas dedicadas al software libre, esto es, VMWare “inyecta” drivers Windows WHQL para que el acceso a red, disco y video de la máquina virtual sea más rápido, sin embargo, desde 2011 eso es posible en Xen también!, ya que un joven hizo “ingeniería inversa” de los drivers Microsoft Windows para Hyper-V y existe una versión “libre” de los drivers para Windows, se llaman los Xen PV Drivers y al instalarlos en la VM con Windows, modificarán el acceso al “disco virtual” y a la “red virtual” de manera notable.

Para instalarlo, descargue la versión necesaria para la versión de Windows que instaló acá:

http://www.meadowcourt.org/downloads/

Antes de instalar, la tarjeta de red se ejecuta a 100Mbps, el acceso a disco en modo “IDE” y la tarjeta de video era cirrus;

Instale a la VM Windows, verá al instalar:

 

5.- Quiero cambiar de CDROM en virt-manager

Una de las cosas más frustrantes que te puedes encontrar, es que si intentas cambiar el CDROM (expulsar->desconectar en virt-manager) este te pedirá que reinicies la VM, esto debido a que el CDROM es tratado como “un disco más”, sin embargo, es posible cambiar de CDROM en una VM encendida; para ello:

1.- Expulsamos el CDROM en el sistema operativo

2.- Cambiamos a la cónsola de virt-manager (CTRL+ALT+2 en la ventana de la máquina virtual)

3.- Expulsamos (desconectamos) el CDROM en Virt-manager:

(qemu) eject hdc

4.- Montamos el nuevo disco, si es una imagen ISO, escribimos:

(qemu) change hdc /path/to/file.iso

Si es un CD en una unidad de CD-ROM, la ruta física a la unidad

(qemu) change hdc /dev/sr0

5.- Volvemos al sistema operativo y montamos la unidad de CDROM

Conclusiones

Espero que estos trucos les sirvan, a mí me han salvado un mundo en trabajo con virtualización Xen y como siempre, los publico acá por si alguien más los necesita.

Happy Hacking!

[LDAP] Easy LDAP: una manera rápida de instalar un Directorio LDAP

openLDAP es, de facto, el servicio para instalación de directorios LDAP v.3 en software libre más utilizado, pero su instalación es a veces engorrosa y/o complicada para muchas personas.

Aún con conocimientos de openLDAP, el gestionar los cambios en la base de configuración cn=config puede hacerse complicado y/o tedioso y la instalación de un primer DIT (Directory Information Tree) o su configuración puede alargarse innecesariamente.

Para resolver esos detalles, he creado un muy simple y conciso script en Bash que nos permite instalar un openLDAP básico con las siguientes características:

  • * openLDAP en Debian Squeezy/Wheezy con soporte a cn=config
  • * Instalación completamente desasistida (la mayoría de los parámetros los auto-descubre)
  • * Incorpora un DIT DC utilizando el nombre de dominio del equipo (ej: ejemplo.com.ve genera un root DN dc=ejemplo,dc=com,dc=ve)
  • * Seguridad TLS/SSL con certificados x.509 auto-generados
  • Logging personalizado (/var/log/slapd.log) con rsyslog y logrotate
  • Reglas ACLs básicas
  • Tunning básico de cn=config y olcBackend
  • cn=auditlog y changelog habilitados
  • Incorporación de una larga lista de esquemas incluyendo:
      • Samba
      • Asterisk
      • DNSzone
      • ISC DHCP-ldap
      • RFC2307-bis (posixGroup auxiliary)
      • Trac
      • sudo-ldap, entre otros
  • Indexación de todos los atributos necesarios para todos los esquemas
  • Habilitación de SASL Auth (requiere configuración previa de SASL Digest-MD5)
  • Incorporación de las reglas básicas para replicación usando SyncRPEL
  • cn=Monitor habilitado
  • Incorporación de los siguientes módulos (overlays)
      • Integridad Referencial de atributos
      • Datos únicos (uidNumber, gidNumber, etc)
      • Constraints (ej. jpegPhoto !> 512k ó userPassword debe ser mayor que 5 caracteres)
      • Password Policy (ej. auto-cifrado de claves a SSHA)
      • Dynamic Listing (permite crear listas y grupos dinámicos)
      • Ordenamiento por valor (ValSort)

Easy LDAP incorpora un DIT básico FLAT (plano) del que necesita por ejemplo Samba, por lo que las personas no tendrán que convivir con un DIT muy complicado.

El DIT Incorpora:

  • Grupos y Grupos dinámicos
  • Reglas Sudo para root y Administradores
  • Grupo Administradores con permisos de “manage” (administración) sobre todo el DIT LDAP
  • Reglas por defecto del password Policy
  • Grupos para administración de cuentas (account-admins), del LDAP (ldap-admins) y de réplica (replicators) con sus permisos respectivos.
  • Data de ejemplo de algunas entradas (usuarios, grupos, grupos dinámicos y hosts)

Instalando

Para utilizar el script deben descargarlo desde Gitorious:

git clone https://git.gitorious.org/easy-ldap/easy-ldap.git

Página web oficial del proyecto > https://www.gitorious.org/easy-ldap/

encontrarán un archivo install-ldap.conf y uno llamado install-ldap.sh, en el archivo “.conf”, este archivo permite personalizar cosas como el SUFIJO (SUFFIX) si lo desea para algo distinto a “dc=ejemplo,dc=com”, el dominio del equipo (si va a ser distinto al dominio configurado de la máquina), de estar este valor en blanco y el dominio de la máquina no está configurado, este lo preguntará.

Usando

Usar el script es bastante sencillo, solo tiene un parámetro que es la actividad que deseamos hacer:

install-ldap.sh install

Inicia el proceso de instalación de openldap y:

install-ldap.sh uninstall

Desinstala y borra la base de datos existente.

Eso es todo!, respondan las preguntas en pantalla, y dejen que finalice el script.

TODO

Queda por hacer:

  • Que las personas puedan incorporar su propio DIT ú otros DIT (más árboles al bosque LDAP)
  • Configurar una entidad certificadora (para que el certificado no sea auto-firmado) y SASL
  • Configuración de réplicas

¿Más información?

openLDAP es un servicio del cual hay poca documentación en español para actividades complejas como configuración de overlays, tunning del olcBackend o personalización de servicios, aún cuando llevo un wiki en phenobarbital.gnu.org.ve este está bastante desafasado (mi culpa, no tengo Internet en mi apartamento y a veces voy a un cibercafé a conectarme y subir cosas como esta) pero estaré mejorando la documentación y la guía:libro que acompañará este script.

¿Te resultó de Utilidad?, pues dona algo para la causa!, no seas pichirre! …

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.131 seguidores

A %d blogueros les gusta esto: