|
Spanish language planetList of feeds
José Parrella: Stressting LDAP for fun and profit
Hace casi dos años, el grupo de Software Libre de PDVSA, la petrolera estatal venezolana, estaba indeciso sobre la utilización de OpenLDAP como solución de directorio compatible con LDAPv3 que les permitiera sustituir parcial o totalmente Microsoft Active Directory. Ellos/as me plantearon su mayor duda: ¿qué tan robusto es OpenLDAP en entornos empresariales? Yo ya había utilizado OpenLDAP extensivamente en entornos empresariales, incluso en convivencia con Microsoft Active Directory cuando trabajé en el Centro de Cómputo de EDELCA, la principal empresa eléctrica en Venezuela. Ese setup ahora está utilizando 389 (antes Fedora Directory Server) para sincronizar claves con MSAD para más de 17 mil personas y centenares de miles de objetos, y a pesar de que lo había visto funcionar bajo cargas muy inusuales, y usábamos clusters con distribución geográfica, yo también tenía la duda de los números. Decidí probar esto en varios frentes. El primero, generar LDIFs muy grandes, y averiguar cuánto representarían en disco una vez almacenados en Berkeley DB, suponiendo que se fuera a utilizar ese popular backend para OpenLDAP. Esto nos daría una idea, exceptuando índices y optimizaciones, de los requerimientos en memoria de un producto como OpenLDAP en escenarios muy grandes. El segundo frente estaba limitado a las pruebas de tiempo de respuesta de la aplicación ante escenarios de búsqueda. La razón por la que pruebo búsquedas es porque esta es la aplicación más común de un directorio LDAP. Mis pruebas fueron locales usando TCP/IP porque, aparte de contaminar los tiempos, en mi experiencia los tiempos de respuesta de un directorio LDAP, cuando está networked, se diluyen en los tiempos de procesamiento de la aplicación; en EDELCA preparé un informe que estudiaba la razón de un problema con GNOME Evolution en el cual el autocompletado tardaba varios segundos en responder, aunque en trazas de red se evidenciaba que el directorio LDAP había respondido en milisegundos (un bug en la aplicación) Imagine otro escenario: en la firma y la comprobación de firma de una infraestructura de llave pública dependiente de LDAP, ¿será el tiempo de respuesta de LDAP determinante cuando estamos potencialmente sobrecargando al cliente calculando hashes para la firma de un documento? Por esto, el tiempo de respuesta local vs. networked no sería un indicativo de la experiencia del usuario final con el directorio, en parte el motivo de la preocupación del cliente. Además hay proxys en LDAP (montamos uno en PDVSA CRP, junto con Penrose como integrador de directorios, o como lo llaman en el mercado, un virtual directory) y estrategias de infraestructura para atacar esto de manera estructural. Como no quería pasar seis meses de mi vida diseñando experimentos y ya que supuse que nadie iba a estar demasiado interesado en los resultados, dejé de lado algunos escenarios de borde y preparé un par de scripts, en Perl como es natural, para escribir LDIFs muy rápido y para consultar LDAPs muy rápido. Utilicé threads en Perl para su implementación (quería consultar en paralelo), aunque estoy prácticamente convencido por Luis Muñoz, Alejandro Imass y Ernesto Hernández-Novich de no repetir el uso de threads jamás. De allí nació un pedestrian LDAP tester, que luego extendí a un stresster de MTAs a través de SMTP y a uno de procesos de autenticación en aplicaciones Web utilizando WWW::Mechanize. Esto es porque el proyecto con PDVSA involucraba las tres cosas: implementamos un cluster de Zimbra Collaboration Suite Community y 389 (FDS) utilizando Debian GNU/Linux en ocho servidores con Xen y NFSv3 para un poco más de 25 mil cuentas, a la fecha 18 meses en producción. Voy a subir los otros scripts pronto, pero vamos con los findings de LDAP, de mi nota informal de Julio 2008: Cargar 200 mil registros (un LDIF de 66 MB.) en la base de datos tiene una representación en BDB de unos 928 MB. Asumamos que requeriríamos, worst case scenario ese espacio en memoria, sin índices ni los registros de replicación. Cargar esos 200 mil registros en OpenLDAP (slapadd) se toma entre 135 y 180 minutos aproximadamente. Afortunadamente la carga se hace sólo una vez. Indizar la base de datos (slapindex) es relativamente rápido y el tiempo se mantiene igual con 1 mil o 200 mil registros. Esto es lógico y bueno. Hice una búsqueda similar a una consulta de una libreta de direcciones popular. Esa búsqueda generó 15 mil resultados (el número de resultados se puede restringir en OpenLDAP, pero a efectos de la prueba lo desactivé) — en mis pruebas, 100 clientes consultando paralelamente por TCP/IP y obteniendo los 15 mil resultados, sin limitar los atributos más allá de las ACLs se tomó: real 0m12.048s user 0m10.413s sys 0m0.768s Lo cual es más que aceptable. Ahora bien, el uso en memoria RAM del servicio está en los 640 MB. de memoria virtual y casi 200 MB. en memoria residente. Esto representa el 15% de la memoria del servidor que utilicé, un HP Integrity descontinuado para 2008, que tiene 2 GB. de RAM. Al introducir índices, estos se cargan en memoria, así como el número de objetos que se quiere tener en caché (yo coloqué 50 mil) por lo que habría que pensar en al menos unos 4 GB. de RAM para un volumen así. Creando índices para los atributos cn, sn, givenName y mail, y ajustando un poco los parámetros de configuración de BerkeleyDB (tabulado del FAQ-O-Matic) la indización se toma un tiempo bastante mayor, para un tiempo de respuesta con la misma búsqueda no mucho menor: real 0m10.540s user 0m8.593s sys 0m0.480s Por lo que, en general, optimizar poco los índices tendría mucho impacto en las cargas y poco impacto en las búsquedas: si vas a indizar, indiza todo lo que quieras y puedas. Lo otro crítico de optimizar es el DBCONFIG; para 2008, y gracias en parte al oscurantismo de Oracle, era más arte que ciencia. El FAQ-O-Matic de OpenLDAP, como siempre, da la mejor información, ver los artículos 1072, 1075, 42, 738 y 893. Now for the goodies, hay tres scripts que publiqué en mi carpeta de CPAN. El primero genera LDIFs, de forma muy básica, entradas tipo libreta de direcciones (plt-ldif-generator); el segundo hace las consultas con threads (plt-bambam) y el tercero es una muestra del patrón de uso del tester (plt-usage-pattern), en shell script. Necesita un Perl razonablemente moderno, compilado con soporte para threads, la librería de Threads de Perl y el módulo Net::LDAP. Un aptitude install libthreads-perl libnet-ldap-perl es suficiente. El primer script también espera que usted provea un root.ldif (el nombre se puede cambiar en el código) con la entrada base del directorio (dc=foo,dc=bar; por ejemplo) y un model.ldif que tenga la entrada modelo con tags que el script sustituirá (obvio, puede usar un LDIF prehecho), algo como: dn: cn=#CN#,dc=foo,dc=bar objectClass: top objectClass: inetorgperson uid: #USER# cn: #CN# sn: #SN# givenName: #FN# Importante: como ya dije antes, algunos casos de uso están fuera de la prueba que realicé, en la mayoría de los casos porque no impactan la prueba sensiblemente (por ejemplo, autenticar las conexiones usando credenciales, cifrado con TLS/SSL y otros, no sería un problema grave) aunque sí podría nombrar algunos elementos que influyen en el performance cuando se lleva OpenLDAP a la práctica en escenarios distintos al trivial, como por ejemplo el uso de muchos schemas y de atributos divergentes en las entradas del directorio, sobrecargar el servicio con temas administrativos como largas ACLs dinámicas y sobre todo altos niveles de verbosidad y overlays de terceros. Afortunadamente, ninguno de estos es un must para un setup grande de LDAP. El código de mis scripts también debe tener bugs y está terriblemente documentado, pero le cumple el propósito perfectamente. Posted Wed Mar 17 04:50:46 2010
DSA-2010 -- kvm -- Múltiples vulnerabilidades
Fecha del reporte: 10 de mar de 2010 Paquetes afectados: kvm Más información: Múltiples vulnerabilidades locales han sido descubiertas en kvm, un completo sistema de virtualización. El proyecto Common Vulnerabilities and Exposures identifica los siguientes problemas: Posted Thu Mar 11 04:07:27 2010
esDebianita del mes de febrero 2010
Desde la Rioja (Argentina) este mes les presentamos a nuestro ingeniero de minas particular: rodri..er..
FroggyPara saber más de él le hicimos la siguiente entrevista: Posted Tue Mar 9 16:39:20 2010
¿Qué sueles buscar cuando entras en esdebian?
* Solución a algún problema puntual. * Algún hilo en el que pueda
ayudar. * Nada en particular, voy a ver qué me encuentro. *
Desahogarme un poco porque soy un incomprendido. * Demostrar lo
guay que soy. * Kejarme xq los moderadoes son unos kretinos q no me
dejan bibir hoygan. * Amol, papito. * Trollear. * Votar en esta
encuesta.
Posted Wed Mar 3 19:44:51 2010
Mario Izquierdo: Compilando drivers de TDT (DVB) AverTV TwinStar 07ca:0825
Me he hecho con un nuevo receptor de TDT USB, el anterior (15a4:9016 Afatech Technologies, Inc. AF9015 DVB-T USB2.0 stick) me estaba dando muchos problemas y la poca señal que llega a mi habitación me hacía perder varios canales. En este HOWTO intentaré de manera sencilla explicar como compilar una nueva versión de V4L previamente parcheada para el nuevo hardware. 1.- Reconocimiento Lo primero es abrir el receptor (si lo piensas devolver no deberías hacerlo) para identificar los chips, en el mío se puede ver que tiene 2 chips (receptor doble) del tipo AF9035B y AF9033. Buscando por varios sitios encuentro este hilo: http://patchwork.kernel.org/patch/61950/ que explicaque hay que aplicar dos parches al kernel y compilar, en lugar de compilar el kernel he usado la rama Mercurial del proyecto V4L. 2.- Descargamos V4L hg clone http://linuxtv.org/hg/v4l-dvb En el enlace que he puesto antes explica que hay que aplicar 2 parches,el primero del método B de este wiki, y el segundo elque adjunta en ese hilo. Yo he aplicado los dos (corregido los rechazos) y preparado un nuevo parche único, que puedes descargar de aquí: af9035.v4l.hg.diff 3.- Parchear En el directorio v4l-dvb ejecutamos lo siguiente: cat /ruta/al/parche/af9035.v4l.hg.diff | patch -p1 4.- Compilar Teniendo nuestras cabeceras del kernel instaladas (apt-get install linux-headers-`uname -r`) ejecutamos make. 5.- Instalar No es recomendable instalarlo encima ya que si algo no va bien tendremos que reinstalar nuestro kernel, vamos a instalarlo en el directorio update del kernel para que si queremos en un futuro podamos borrarlo y no estropear nuestro kernel. Es muy importante compilar e instalar como usuario (no como ROOT) ya que no se ejecutarán o copiarán cosas que no queramos. make install DESTDIR=`pwd`/tmp sudo mkdir -p /lib/modules/`uname -r`/updates sudo cp -ra tmp/lib/modules/`uname -r`/kernel/drivers/media/ /lib/modules/`uname -r`/updates/v4l sudo depmod -a (va a dar errores de copia de firmware... no problem !!!) 5.- Instalar el firmware Descargamos este archivo: dvb-usb-af9035-01.fw y lo copiamos en /lib/firmware/ 6.- Pruebas antes de conectar $ sudo modinfo dvb-usb-af9035 filename: /lib/modules/2.6.32-2-686/updates/v4l/dvb/dvb-usb/dvb-usb-af9035.ko
7.- Conectamos Ejecutamos en un terminal: sudo tail -f /var7log/syslog, debería salir algo como esto:
En /dev/dvb se crearán nuevos dispositivos:
Si algo no funciona, como por ejemplo nos sale esto por el syslog:
... es porque teníamos cargados módulos dvb_* , tenemos que mirar los que estan cargados (lsmod) y quitarlos (rrmod), si sigue sin ir podemos probar a reiniciar. Posted Sat Feb 27 15:38:23 2010
Debian 6.0 Alpha 1
El equipo de Debian Installer se complace en anunciar el instalador de Debian 6.0 Alpha 1. Este es la primera versión liberada desde Lenny y trae consigo muchas características y mejoras. Es importante señalar que se ha deshabilitado el instalador gráfico y los controladores speakup por algunos inconvenientes que se han presentado con el Backend de DirecFB de las librerías GTK+. Actualmente se está trabajando en ésto para la siguiente versión. Algunas características a destacar:
Actualizar a rama testing
Buenas, en esta ocasión veremos cómo actualizar a una versión
testing de nuestro Debian. Si bien se podría descargar una imagen
iso de la versión en cuestión, este método de instalación de una
versión de pruebas puede ser algo trabajoso por la cantidad de
errores que suelen aparecer en el proceso de instalación.
Después
Noten que yo siempre me manejo con las ramas testing, entonces
pongo testing en la categoria del repositorio, lo que me asegura
estar siempre en versiones de prueba.
Lisandro Damián Nicanor Pérez Meyer: Sid, KDE 4 y problemas con bibliotecas
 Una serie de problemas
con cambios de versiones de bibliotecas en Sid, ajenas al equipo
que mantiene KDE, ha logrado que quien actualice su KDE 4 se le
rompa KDM y Kmail muera.Así que los que usen Sid y KDE 4, por favor, eviten actualizar hasta dentro de unos dias. 
DSA-1996 -- linux-2.6 -- Múltiples vulnerabilidades
Fecha del reporte: 12 de feb de 2010 Paquetes afectados: linux-2.6 Más información: Múltiples vulnerabilidades han sido descubiertas en el núcleo Linux que pueden conducir a la denegación de servicio, fuga de información sensible o escalamiento de privilegios. El proyecto Common Vulnerabilities and Exposures identifica los siguientes problemas: Posted Sat Feb 13 03:13:35 2010
Celebración de la DUDESConf III del 9 al 11 de Abril en Coruña (España)
Después del intermedio en 2009, debido a que la
?DebConf internacional fue en Cáceres,
este año se volverá a celebrar la ?DudesConf (aka ?DebConf-es). El evento tendrá lugar en Coruña gracias una vez
más a la gente de GPUL y al patrocinio de Igalia y Debian. La
conferencia será en el fin de semana del 9 al 11 de Abril. Si deseáis asistir, debéis inscribiros. El enlace y las instrucciones estarán pronto disponibles en la página web. Posted Fri Feb 12 22:10:11 2010
Nuevo canal IRC, visitanos en #linues por freenode
Fuente: debian.ues.edu.sv Posted Fri Feb 12 20:59:20 2010
Lisandro Damián Nicanor Pérez Meyer: Adiós kopete-facebook
Facebook
empezó a dar soporte XMMP (Jabber) para su mensajería
instantánea. Y con ésto, el plugin de Kopete para
Facebook se vuelve totalmente innecesario, por lo que pienso
pedir que se remueva del archivo de Debian. No duró mucho, pero al
menos cumplió su función durante ese tiempo.Por supuesto, también sirvió para seguir aprendiendo a empaquetar cosas para Debian 
Ana Beatriz Guerrero Lopez: DudesConf III \o/
The news is out (link in Spanish). We will have this year the third edition of the ?DudesConf a.k.a. the Spanish ?DebConf. Special thanks to GPUL for hosting us another year! Posted Thu Feb 11 18:44:04 2010
Las razones del mal desempeño de Flash en Linux según el desarrollador del plugin
Fuente: m.menea.me Posted Tue Feb 9 13:48:40 2010resume writing services essay editing essay writers
Links:
planets
|
