Mostrando entradas con la etiqueta linux. Mostrar todas las entradas
Mostrando entradas con la etiqueta linux. Mostrar todas las entradas

sábado, 7 de abril de 2012

How Linux is built

Como suele ser habitual, la gente de Linux Foundation se ha publicado un vídeo muy interesante sobre cómo y quién construye el kernel de Linux.

jueves, 23 de junio de 2011

SELinux, RHEL y cosas extrañas...

Últimamente entre reuniones de proyectos y coordinación apenas tengo tiempo para ponerme con temas de administración de sistemas, aún así, le sigo dedicando tiempo.
El caso es que he finalizado la fase de desarrollo de un sitio web con Drupal 7 y quería subirlo al servidor de producción. Todo iba como la seda hasta que al levantar el vhost me encuentro con :
[root@XXX httpd]# /etc/init.d/httpd restart
Parando httpd: [ OK ]
Iniciando httpd: Warning: DocumentRoot [/var/www/html/biblioteca] does not exist
Warning: DocumentRoot [/var/www/html/moodle-testing20/moodle] does not exist
[ OK ]


¡DocumentRoot does not exist! Imposible, pensé. Al final, después de darle muchas vueltas leí en este post que podría ser que SELinux impidiese añadir directorios. Basta con añadirlo al contexto de SE y listo:
chcon -R system_u:object_r:httpd_sys_content_t /var/www/html/biblioteca

martes, 21 de junio de 2011

logwatch

La próxima semana voy a impartir un curso de Drupal en Lugo, de 16:30 a 20:30 de Lunes a Viernes y el Sábado día 2 de 10:00 a 13:30.

El primer día lo dedicaré completo a conocer el entorno de trabajo, desde VirtualBox hasta PHPMyAdmin y demás.

El servidor web que utilizaremos será Apache2, como suele ser habitual en este tipo de cursos express. Veremos temas básicos, desde la instalación a la configuración de virtual hosts y como no, también algo de seguridad, que nunca está de más. Repasando apps interesantes me he topado con logwatch, que para los que no lo conocéis es un script en Perl que facilita la visualización amigable de logs. La instalación es vía apt y lo único de debemos hacer para que muestre información en la consola es copia el fichero de ejemplo a /etc/logwatch:
cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/

Es posible configurar los reportes para que se envíen vía email y demás, pero esto lo dejamos para otro momento. Ahí os va la salida de logwatch directamente en la consola:
################### Logwatch 7.3.6 (05/19/07) ####################
Processing Initiated: Tue Jun 21 08:51:10 2011
Date Range Processed: yesterday
( 2011-Jun-20 )
Period is day.
Detail Level of Output: 0
Type of Output/Format: stdout / text
Logfiles for Host: creba
##################################################################
--------------------- dpkg status changes Begin ------------------------

Installed:
libconfig-inifiles-perl 2.52-1
mytop 1.6-6
---------------------- dpkg status changes End -------------------------

--------------------- httpd Begin ------------------------

Requests with error response codes
404 Not Found
/calendar/view.php?view=month&cal_d=1&cal_m=12&cal_y=2037: 1 Time(s)
/calendar/view.php?view=month&cal_d=1&cal_m=3&cal_y=2030: 1 Time(s)
/calendar/view.php?view=month&cal_d=1&cal_m=6&cal_y=1925: 1 Time(s)
http://98.126.15.13/proxyheader.php: 1 Time(s)
http://healthforcaring.com/proxyheader.php: 3 Time(s)
http://www.ezhealths.com/proxyheader.php: 1 Time(s)
http://www.hardjob.net/proxyheader.php: 2 Time(s)


sábado, 9 de abril de 2011

Remake: Unixbench

Preparando el servidor OpenVZ para la "I Noite Drupal & GNU/Linux" de Mugardos he encontrado una perla en Google Code: UnixBench. El objetivo de la aplicación es muy claro: ser un indicador de rendimiento para sistemas operativos basados en Unix partiendo de los resultados base de un SPARCstation 20-60(valor 10,0)

Entre los múltiples tests realizados destacan:
.- Dhrystone : Prueba de manejo de cadenas(sin coma flotante :P)
.- Whetstone: Mide la velocidad y efiencia de las operaciones con coma flotante.
.- Execl Throughput : mide la velocidad a la cual los datos pueden ser transferidos de un archivo a otro, con diferentes tamaños de búfer.

Un consejo. No es un test rápido. En un AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ con frecuencia de 2,5ghz y 8GB de RAM el test necesitó más de 40 minutos para finalizar y mostrar resultados.
Para curiosos, geek y demás fauna, ahí van los resultados:



Version 5.1.3 Based on the Byte Magazine Unix Benchmark

Multi-CPU version Version 5 revisions by Ian Smith,
Sunnyvale, CA, USA
January 13, 2011 johantheghost at yahoo period com


1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10

1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10

1 x Execl Throughput 1 2 3

1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3

1 x File Copy 256 bufsize 500 maxblocks 1 2 3

1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3

1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10

1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10

1 x Process Creation 1 2 3

1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10

1 x Shell Scripts (1 concurrent) 1 2 3

1 x Shell Scripts (8 concurrent) 1 2 3

2 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10

2 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10

2 x Execl Throughput 1 2 3

2 x File Copy 1024 bufsize 2000 maxblocks 1 2 3

2 x File Copy 256 bufsize 500 maxblocks 1 2 3

2 x File Copy 4096 bufsize 8000 maxblocks 1 2 3

2 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10

2 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10

2 x Process Creation 1 2 3

2 x System Call Overhead 1 2 3 4 5 6 7 8 9 10

2 x Shell Scripts (1 concurrent) 1 2 3

2 x Shell Scripts (8 concurrent) 1 2 3

========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)

System: polinico: GNU/Linux
OS: GNU/Linux -- 2.6.32-5-openvz-amd64 -- #1 SMP Mon Mar 7 22:25:57 UTC 2011
Machine: x86_64 (unknown)
Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
CPU 0: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2009.1 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, SYSENTER/SYSEXIT, AMD virtualization, SYSCALL/SYSRET
CPU 1: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2009.1 bogomips)
Hyper-Threading, x86-64, MMX, AMD MMX, Physical Address Ext, SYSENTER/SYSEXIT, AMD virtualization, SYSCALL/SYSRET
18:09:05 up 1:48, 3 users, load average: 0.25, 0.30, 0.23; runlevel 2

------------------------------------------------------------------------
Benchmark Run: sáb abr 09 2011 18:09:05 - 18:38:11
2 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 18476798.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2613.2 MWIPS (9.9 s, 7 samples)
Execl Throughput 1260.8 lps (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 308577.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 100308.1 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 697625.5 KBps (30.0 s, 2 samples)
Pipe Throughput 987893.9 lps (10.0 s, 7 samples)
Pipe-based Context Switching 102266.6 lps (10.0 s, 7 samples)
Process Creation 3968.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2277.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 804.0 lpm (60.0 s, 2 samples)
System Call Overhead 2051427.4 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 18476798.9 1583.3
Double-Precision Whetstone 55.0 2613.2 475.1
Execl Throughput 43.0 1260.8 293.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 308577.4 779.2
File Copy 256 bufsize 500 maxblocks 1655.0 100308.1 606.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 697625.5 1202.8
Pipe Throughput 12440.0 987893.9 794.1
Pipe-based Context Switching 4000.0 102266.6 255.7
Process Creation 126.0 3968.2 314.9
Shell Scripts (1 concurrent) 42.4 2277.5 537.2
Shell Scripts (8 concurrent) 6.0 804.0 1340.0
System Call Overhead 15000.0 2051427.4 1367.6
========
System Benchmarks Index Score 667.9

------------------------------------------------------------------------
Benchmark Run: sáb abr 09 2011 18:38:11 - 19:07:26
2 CPUs in system; running 2 parallel copies of tests

Dhrystone 2 using register variables 36832151.8 lps (10.0 s, 7 samples)
Double-Precision Whetstone 5246.4 MWIPS (9.9 s, 7 samples)
Execl Throughput 3706.6 lps (29.6 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 402547.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 121746.1 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 911624.0 KBps (30.0 s, 2 samples)
Pipe Throughput 1990029.1 lps (10.0 s, 7 samples)
Pipe-based Context Switching 437120.2 lps (10.0 s, 7 samples)
Process Creation 10823.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6206.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 809.3 lpm (60.1 s, 2 samples)
System Call Overhead 2618061.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 36832151.8 3156.1
Double-Precision Whetstone 55.0 5246.4 953.9
Execl Throughput 43.0 3706.6 862.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 402547.4 1016.5
File Copy 256 bufsize 500 maxblocks 1655.0 121746.1 735.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 911624.0 1571.8
Pipe Throughput 12440.0 1990029.1 1599.7
Pipe-based Context Switching 4000.0 437120.2 1092.8
Process Creation 126.0 10823.0 859.0
Shell Scripts (1 concurrent) 42.4 6206.0 1463.7
Shell Scripts (8 concurrent) 6.0 809.3 1348.9
System Call Overhead 15000.0 2618061.3 1745.4
========
System Benchmarks Index Score 1258.5

miércoles, 6 de abril de 2011

Sobre Memcached, Apache2 y Drupal



Llega un momento en la vida de un sitio web levantado con Drupal(este es mi caso) en que, bien por el número de visitas o por la complejidad de las consultas, se hace necesario instalar y configurar un sistema de cacheo de contenido que agilice el proceso de envío de información.

No voy a entrar en que si proxy inverso, APC o mil gaitas, sólo trataré el proceso de instalación y configuración de memcache ejecutado en una máquina corriendo Debian GNU/Linux 6.0 Squeeze y Apache2 un sitio web con Drupal 6. Comenzamos descargando y activando el módulo "Memcache API and Integration" del sitio drupal.org.

A continuación, lo primero que debemos hacer es actualizar las fuentes de nuestra distribución Debian GNU/Linux:
[root@localhost] aptitude update

Una vez finalizado el proceso instalaremos dos paquetes:
  • memcached: "daemon" o servicio de cacheo diseñado específicamente para que los sitios web dinámicos decrementen la carga de las bases de datos almacenados objetos en memoria. Danga Interactive desarrolló memcached para mejorar la velocidad de LiveJournal.com un sitio que tuvo más de 20 millones de vistas de páginas dinámicas cada día para 1 millón de usuarios con un puñado de servidores web y un puñado de servidores de base de datos. memcached reduce la carga de la base de datos a casi nada, mejorando los tiempos de carga de las páginas para los usuarios, la utilización de los recursos y haciendo más rápido el acceso a las bases de datos.
  • php5-memcache y php5-memcached: Extensión que permite a las aplicaciones escritas en PHP5 comunicarse con los servidores memcache.
Como (casi) siempre en Debian GNU/Linux:
[root@localhost] aptitude -y install php5-memcached php5-memcache memcached

Si este paso se ha ejecutado correctamente debemos configurar qué tipo de estrategia hash utilizará memcache para manejar los objetos de la caché. Dos opciones : standard o consistency. Por lo que leído la tendencia es utilizar esta última, ya que si estamos trabajando con varios servidores memcache evitaríamos problemas al tener que compartir una misma instancia de ejecución de PHP-Apache2. Resumiendo:

Añadimos:

memcache.hash_strategy="consistent"
al fichero /etc/php5/apache2/php.ini.

Modificamos el fichero settings.php de nuestro sitio Drupal y añadimos:


$conf = array(
// The path to wherever memcache.inc is. The easiest is to simply point it
// to the copy in your module's directory.
'cache_inc' => './sites/default/modules/memcache/memcache.inc',

'memcache_servers' => array(
'localhost:11211' => 'default',
'localhost:11212' => 'content',
'localhost:11213' => 'filter',
'localhost:11214' => 'menu',
'localhost:11215' => 'page',
'localhost:11216' => 'views',
),
'memcache_bins' => array(
'cache' => 'default',
'cache_content' => 'content',
'cache_filter' => 'filter',
'cache_menu' => 'menu',
'cache_page' => 'page',
'cache_views' => 'views',
),

Lo realmente curioso de esta configuración para Drupal6, o por lo menos a mi llama mucho la atención, es la posibilidad de dedicar distintas máquinas a diferentes objetos de cache: views, menús...Intentaré darle una vuelta a este tema.
Para finalizar, he visto en este blog, que hay gente que reemplaza el fichero /etc/init.d/memcached por un con contenido similar a este:




#!/bin/bash
prog="memcached"
start() {
echo -n $"Starting $prog "
# Sessions cache.
memcached -m 16 -l 0.0.0.0 -p 11211 -d -u nobody
# Default cache.
memcached -m 32 -l 0.0.0.0 -p 11212 -d -u nobody
# Block cache.
memcached -m 32 -l 0.0.0.0 -p 11213 -d -u nobody
# Content cache. Holds fully loaded content type structures.
memcached -m 16 -l 0.0.0.0 -p 11214 -d -u nobody
# Filter cache. Usually the busiest cache after the default.
memcached -m 32 -l 0.0.0.0 -p 11215 -d -u nobody
# Form cache.
memcached -m 32 -l 0.0.0.0 -p 11216 -d -u nobody
# Menu cache.
memcached -m 32 -l 0.0.0.0 -p 11217 -d -u nobody
# Page cache. Bigger than most other caches.
memcached -m 128 -l 0.0.0.0 -p 11218 -d -u nobody
# Views definition cache.
memcached -m 1 -l 0.0.0.0 -p 11219 -d -u nobody
# Views data cache (may need to be increased if heavily used).
memcached -m 32 -l 0.0.0.0 -p 11220 -d -u nobody

# More caches that might be added later:
# Users table.
#/usr/bin/memcached -m 24 -l 0.0.0.0 -p 11219 -d -u nobody
# Path source cache.
#/usr/bin/memcached -m 4 -l 0.0.0.0 -p 11220 -d -u nobody
# Path destination cache.
#/usr/bin/memcached -m 6 -l 0.0.0.0 -p 11221 -d -u nobody
RETVAL=$?
echo
return $RETVAL
}

stop() {
if test "x`pidof memcached`" != x; then
echo -n $"Stopping $prog "
killall memcached
echo
fi
RETVAL=$?
return $RETVAL
}
case "$1" in
start)
start
;;
stop)
stop
;;

restart)
stop
start
;;
condrestart)
if test "x`pidof memcached`" != x; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|restart|condrestart}"
exit 1
esac

¿Por que digo similar? Pues muy sencillo, basta con teclear:
memcached -h
y observar todos los parámetros de configuración que acepta en la línea de comandos. En mi opinión se debe tener especial cuidado a la hora de manejar la cantidad de memoria máxima a utilizar, el protocolo de escucha, el número máximo de conexiones simultáneas. 






[ Memcache funcionando en Drupal 6 ]


lunes, 21 de febrero de 2011

Parsear XML con Python



Desde hace unas semanas estoy leyendo, estudiando y practicando Python. Es un lenguaje tan apasionante como interesante. En pocos días, me atrevería a decir que incluso horas, con unos conocimientos básicos de programación, puedes crear verdaderas maravillas pythonianas.
El caso es en la Asociación Comunidade O Zulo , hemos puesto en marcha un proyecto para customizar una distribución Ubuntu Linux y completarla con material multimedia. Para realización las aportaciones multimedia de este proyecto, todavía un embrión pero os adelanto que tiene muy buena pinta, hemos levantado un sitio web en Drupal dónde los usuarios podrán enviar las imágenes. [Explicación técnica que omito para no aburrir al personal] Para recuperar las imágenes estamos desarrollando un script en Python que lee el XML y vía SQLite completa un álbum en Shotwell. El script básico para parsear el XML es el siguiente:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# xml-parser-ozulo-0.0.1-dev.py
#
# Copyright 2011 Alberto Permuy Leal
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
# MA 02110-1301, USA.
import sys, urllib
from xml.etree import ElementTree as et


def main():
documento = et.parse(urllib.urlopen('http://www.comunidadeozulo.org/rss.xml')).getroot()
entradas = documento.getiterator('item')
for una_entrada in entradas:
elementos = una_entrada.getiterator()
for un_elemento in elementos:
if un_elemento.tag == 'title':
print un_elemento.text
return 0

if __name__ == '__main__':
main()

Es casi idéntico a esta entrada, salvo que he añadido el parse vía urllib.

lunes, 5 de julio de 2010

ipfire, otra sorpresa...


Distrowatch es una referencia en la web si hablamos de lista de distribuciones GNU/Linux y BSDs. A menudo suelo dar una vuelta por Distrowatch para ver las últimas novedades; hoy la he visitado y me he topado con una sopresa : ipfire.

Si hace unas semanas hablaba de Ebox como una solución ideal para servidor empresarial: ficheros,firewall,vpn...etc, ahora toca el turno de ipfire.

Ipfire es una distribución Linux que "sólo" sirve para realizar una función : firewall. En la página oficial del proyecto la definen como "una distribución linux-like,de instalación sencilla y segura".

Me ha llamado mucho la atención la cuidada interfaz web de administración, desde la que podemos realizar prácticamente cualquier función de administración del sistema. En este enlace podéis ver unas capturas de pantalla.

Entre sus muchas caraterísticas destacan:
  • módulo firewall basado en inspección de paquetes netfilter.
  • IDS
  • Posibilidad de crear DMZ
  • Servicios: ntp,dhcp,proxy...
  • Sistema basado en módulos para ampliar funcionalidades
  • VPN
Aún no sé si usaremos Ebox o Ipfire para el Kernel 2010 de Mugardos, pero si me preguntais ahroa mismo, Ipfire tiene las mismas posibilidades que Ebox.

miércoles, 30 de junio de 2010

thttpd, la confirmación de lo minimalista



Dentro del mundo de los webservers todos sabemos que Apache2 se lleva la fama y los aplausos. Por otro lado, Cherokee, nginx y lighttpd poco a poco se hacen con un hueco en difícil campo de los servidores web.
Esta semana he estado jugando un con las listas de correo en Mailman para la recién creada Asociación Comunidade O Zulo. Una Asociación que fomenta la tecnología y cultura libres, de la cual tengo el honor de ser presidente.
Sinceramente, configurar Mailman con Postfix sólo con "auth local" y apache2 es muy sencillo. Pero claro, si tienes un VPS con 128Mb de RAM , el tema se complica. Apache2 consume muchísimos recursos, tanto de RAM como de CPU.
Tocaba buscar una alternativa a Apache2. Lo cierto es que no pensé nunca en dejar Apache2 como servidor www, pero he de reconocer que para la configuración base es ideal y apenas tienes que tocar nada para que funcione. Una vez funcione el servicio, sí me he planteado cambiar el software servidor www.
Paseando por el wiki de Mailman intentando buscar el equilibrio perfecto entre rendimiento y consumo de recursos encuentro thttpd.
La solución que proponen es nginx+thttpd. Como nginx no soporta la ejecución de CGIs en modo "out of the box" proponen enviar las peticiones a CGIs vía directiva proxy_pass de nginx a una instancia de thttpd escuchando en otro puerto del mismo server. ¡Genial! Me ha parecido una idea estupenda y muy profesional. Lo cierto es que ayer de noche no conseguí que funcionase, y al final para salir del paso usamos lighttpd.
La idea no sólo me ha parecido genial a mí, si no que esta solución(la de usar thttpd) la están usando en PayPal.com y en otros sitios web.La instalación en Debian GNU/Linux es tan sencilla como "aptitude install thttpd". En la web del proyecto hay más información sobre directivas, instalación y demás.



viernes, 4 de junio de 2010

Señoras y señores: jubilen 'top'.

No tengo que presentar top, ¿verdad?. Si bien es cierto es una herramienta que, si mal no recuerdo, me ha acompañado en mi viajes por los terminales desde 1999, toca jubilar. A todos nos llega nuestra hora, y top merece descansar en paz.

Hace tiempo que conocía htop, pero desde hace unos meses es mi herramienta de monitorización de proceso favorita. Las razones las dejan bien claras la página web del proyecto, aunque me he tomado la molestias de enumeras algunas en el siguiente listado....

  • .- 'htop' puede desplazarse por la lista vertical y horizontalmente para ver todos los procesos y líneas de comandos completo.
  • .-'top' está sujeto a un retraso por cada tecla que presione sin asignar (especialmente molesto cuando la llave de secuencias de escape-multi son provocados por accidente).
  • .-'htop' inicia más rápido.
  • .-'Con htop' no es necesario que escriba el número de proceso para matar un proceso.
  • .-En 'htop' no es necesario que escriba el número de proceso o el valor renice prioridad a un proceso en el 'top' que hace.
  • .-'top' es más viejo
A modo de anécdota comentar que tanto en Debian GNU/Linux como en Ubuntu Linux htop viene incluído en los repositorios oficiales de las distribuciones.

miércoles, 26 de mayo de 2010

Unable to boot please use a kernel appropiate for your CPU

Openfiler es un sistema operativo para almacenamiento en red. La próxima semana instalaré un sistema SAN con RAID5/iSCSI con Openfiler para que dos máquinas con Microsoft Windows 2003 Server R2 puedan acceder a los volúmenes vía iSCSI. Antes de aventurarme a trastear con máquinas en producción(supongo que nadie será tan osado, sólo supongo), he clonado la instalación con VirtualBox y me he encontrado con el error de podeis leer en el título del post "Unable to boot please use a kernel appropiate for your CPU". Después de leer en los foros de Vbox, dejo constancia de una serie de consejos para instalar Openfiler dentro de VirtualBox.

[Error Virtual Box configuración por defecto]






[Habilitamos PAE en VBOX]








[Seleccionamos interfaz de red Intel]









[Finalmente Openfiler funcionando]











He cambiado la interfaz de red por que "out of the box" Openfiler no carga el módulo la para el chipset AM79Cxx. Sí lo hace con las interfaces Intel, así que un último briconsejo : ojo con las interfaces de red!

jueves, 29 de abril de 2010

openldap, paciencia y algunas tazas de café...



A estas alturas no voy a presentaros openldap. La web del proyecto, aunque un poco cutre en su diseño, viene repleta de información. Este post es simplemente un recordatorio de una receta que me ha servido de mucho a la hora exportar configuraciones desde un entorno de pruebas virtualizado a un entorno en testing con máquinas físicas y usuarios reales haciendo pruebas.

El primer problema lo he tenido, hablamos de Debian GNU/Linux Lenny por supuesto, a la hora de instalar el paquete slapd. Cuando pregunta si a la hora de purgar el paquete deseamos eliminar la base de datos, muchos de vosotros responderíais un NO. Bien, discrepo.Después de unos cuantos días haciendo pruebas, puedo decir que yo respondería que Sí. ¿Por qué? Si por alguna razón deseas reinstalar el paquete, recupera los backups anteriores del base de datos de openldap, y como no coíncidan los dc's lo tienes crudo. Me encuentro en la tesitura de que en el entorno virtualizado los dos servidores Debian corriendo slpad funcionan muy bien. Drupal se valida contra ldap sin problemas y la vida parece ser maravillosa en Maple Town Monogatari. Al migrar las configuraciones al servidor de pruebas: crack! No logro ni siquiera validarme. Por un momento pienso ¿qué he echo mal, si todo parece estar exactamente igual? En una mala decisión, decido purgar el paquete(conservando los registros de la bbdd de ldap). Es aquí cuando todo se torna de color negro y no consigo avanzar. Hoy día 29 era el día marcado en el proyecto para tener ldap corriendo en testing y no llego(al final sí ;) ) a tiempo.Después de perder tiempo leyendo y releyendo documentación y listas de correo decido compilar el paquete.
En algún post anterior he hablado de apt-build, pues hoy me ha salvado la vida.A compilar se ha dicho.

[root@baltasargarzon]time apt-build --build-dir /tmp/slapd --yes --force-yes build-source slapd

En unos 50 minutos tenemos el paquetito listo. Nos damos una vuelta por ....

[root@baltasargarzon] cd /var/cache/apt-build/repository/ && dpkg -i slapd_2.4.11-1_i386.deb && apt-get -f install

Ahora unos pequeños ajustes los ficheros ldap.conf

[root@baltasargarzon]cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

BASE dc=dominio,dc=eu
URI ldap://192.168.15.91

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

Otros ajustes en slapd.conf

[root@baltasargarzon]cat /etc/ldap/slapd.conf
(..)
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb
#The base of your directory in database #1
suffix dc=dominio,dc=eu
rootdn cn=admin,dc=dominio,dc=eu
rootpw admin
# for syncrepl.
# rootdn "cn=admin,dc=dominio,dc=com"
# Where the database file are physically stored for database #1
directory "/var/lib/ldap"

Briconsejo: cifrar el password de root con {SSHA}loquesea.
Ahora sólo falta crear un fichero .ldif con el siguiente contenido para crear la "organización".

dn: dc=dominio,dc=eu
objectclass: dcObject
objectclass: organization
o: Organización
dc: Organización

Como root añadimos el fichero inicial.lidf a la estructura ldap:

ldapadd -x -D "cn=admin,dc=dominio,dc=eu" -W -f inicial.ldif

El password es que le hemos indicado(cifrado o no en el fichero slapd.conf en el parámetro rootpw).
¿Qué herramienta GUI utilizo para gestionar ldap? Gracias un lector de este blog, desde hace unas semanas uso Apache Directory Studio.
Ahora todo parece funcionar correctamente. He tomado alguna que otra taza de café, mi paciencia casi llega a su límite, pero ya estás openldap funcionando bajo Debian GNU/Linux.

lunes, 26 de abril de 2010

EBOX: un proyecto con futuro



Respondía esta mañana un post a un compañero de trabajo, y pensando en ello de camino a casa, me vino a la mente mi afirmación en dicho post acerca del "Software libre como servicio" y no pude para de pensar en EBOX. En párrafos posteriores resumiré qué es y para qué sirve EBOX, pero ahora me quiero centrar la afirmación anterior.Considero que sí es posible ganar dinero con el software libre, ya que mi mente la ecuación software libre = software gratis está rota.De todos es conocida Red Hat Inc como un ejemplo a seguir a nivel mundial en cuanto a viabilidad empresarial con software libre como bandera. Pero no tenemos que mirar hacia EE.UU para fijarnos en empresas viables. Ebox Technologies es la empresa que está detrás de EBOX y un claro ejemplo de una empresa que sobrevive gracias al swlibre.Tampoco tenemos que irnos hasta Zaragoza, en Galicia también tenemos dos ejemplos: TEGNIX y Sognus.
Volviendo al hilo del título del post, EBOX es un todo en uno espectacular.Ahora mismo me pregunto cómo no lo he tenido noticias de este proyecto antes.La verdad es que sí había oído hablar de él, pero mi visión "console based" me impedía dedicarle tiempo.Una cosa no debe estar reñida con la otra y mañana por la tarde instalaré mi primer EBOX en pruebas para una PYME.La documentación del proyecto está muy trabajada, y han liberado docs tanto para usuarios como para desarrolladores, lo cual les honra, y dice mucho de su trabajo.
Por lo visto en su web, EBOX simplifica al máximo la administración de servicios básicos para un SysAdmin, como pueden ser : Firewall, Proxy , Radius ...etc, a través de una interfaz web escrita en PERL desde la que podemos, menos hacer un bocadillo, prácticamente de todo. Intentaré escribir en este blog mi impresiones sobre EBOX en un entorno de producción que es dónde mejor se pueden testear los sistemas y aplicaciones. Mientras esperáis el post, os dejo un vídeo para abrir boca.


eBox Platform - Basic network configuration from eBox Platform on Vimeo.

viernes, 23 de abril de 2010

Dudas RHEL y Debian GNU/Linux


Es cierto, no he tenido mucho tiempo para escribir durante este último mes, pero he regresado con fuerza.El próximo viernes tengo que "defender" una reestructuración de las máquinas del proyecto web el que actualmente trabajo.El planteamiento inicial, por lo que podido comprobar es correcto, y muy a mi pesar la "discusión" se centra únicamente en la elección del sistema operativo, en lugar de comenzar y tratar en profundidad temas, a mi modo de ver, más importantes como pueden ser la escalabilidad, el rendimiento o la seguridad.
Si sois lectores habituales de este blog os habreis dado cuenta de mi predilección por Debian GNU/Linux como sistema operativo. Con el tiempo he intentado huir de la radicalidad de los tiempos más "duros" y ser más sensato en relación a lo que pienso y cómo actúo. Usar Debian GNU/Linux como sistema operativo de escritorio puede resultar una experiencia enriquecedora pero al mismo tiempo frustrante. Enriquecedora por todos los conceptos que puedes llegar a aprender(!= asimilar) y frustrante por que, en ocasiones, el usuario se puede encontrar con trabas que non con poco esfuerzo podrá resolver. Aquí tocamos un tema delicado a mi entender: el tiempo. ¿Cuánto tiempo necesito invertir en mi ss.oo para encontrar un equilibrio entre estabilidad-seguridad-usabilidad? Con Debian GNU/Linux bastante. Reconozco que en los últimos años he desarrollado una especie de manía hacia Ubuntu Linux.Concretamente hacia una parte de "falsos usuarios" que, aprovechando el reciente éxito y penetración en el mercado de Ubuntu Linux, se dedican a inundar la red de iconos cutres de tres al cuarto "usuario ubuntu xxxxx" y comentarios anti-window$, en lugar de aprender y conocer el mundo del software libre, gnu y linux.Uso Ubuntu desde la versión 4.x de 2004, cuando el instalador aún era el propocionado por el proyecto Debian.He de reconocer mi error al criticar Ubuntu cegado por una visión "Debian based" del mundo. Ubuntu en su versión de escritorio es perfecta para el trabajo diario, tanto profesional como personal.Canonical, la empresa que apoya y desarrolla Ubuntu, libera cada 2 años una versión con soporte durante 3 años para máquinas de escritorio y de 5 años para servidores. Qué gran acierto!

Dejo de irme por las ramas y vuelvo al hilo. Debian GNU/Linux para servidores roza la perfección, por lo menos en cuanto a estabilidad,seguridad y "facilidad" de administración. Ubuntu idem pero a nivel de escritorio.¿Qué pinta CentOS en todo esto? La verdad es que no lo sé. Realmente no puedo entender como en una infraestructura de red basada en Debian GNU/Linux, donde hasta hace pocos meses aún podías encontrar alguna máquina con Debian 3.0 Woody, puedes migrar a Red Hat. No lo entiendo. No hay Oracle, no hay Symantec, no hay Java. Sólo Apache2, MySQL y PHP. Que Red Hat tiene su propio modelo de negocio y funciona, pues claro! Eso nadie lo duda. Que sea la opción ideal siempre, amigos lectores, creo que me van a conceder el beneficio de la duda.

De Red Hat me gusta el concepto de RHN. Yum es una gran herramienta para administrar paquetes, pero aún está muy lejos de apt y portage.Las versiones de los paquetes están "bien parcheadas", es decir, con un montón de bugs corregidos, pero a menudo hablamos de versiones muy antiguas...Si a todo esto unimos que RHEL es una distribución de pago, señoras y señores: ustedes mismos!