No, no me equivoqué de número de versión.

Si bien PostgreSQL 8.4 ya salió y tiene unas cuantas novedades, quisiera hacerme eco de lo que está en la cola de parches a aprobar para integrar la nueva rama de desarrollo de PostgreSQL 8.5. Esta lista está compuesta por cosas como:

• GRANT ON ALL IN schema: Una manera de otorgar permisos a todos los objetos de un esquema.
• Machine-readable explain output v2: Salidas del comando EXPLAIN fácilemente legibles por otro software, es decir, fácilmente parseables para su procesamiento. El comando explain aceptaría como segundo parámetro el formato (además de los actuales) la keyword FORMAT, quedando así: EXPLAIN FORMAT [TEXT | JSON | XML]. Está bueno porque abre la puerta del desarrollo de herramientas de auto-tunning, basado en reglas estilo Sistema Experto.
• SE-PostgreSQL: Security-Enhanced PostgreSQL, una mejora sustancial en la seguridad del SGBD y en el nivel de detalles del sistema de privilegios.
• Replicación Sincrónica: Si algo le faltaba a PostgreSQL es una manera de replicación sincrónica integrada en el gestor. Esperemos que esto sí entre, aunque está bastante discutido el asunto porque es un cambio relativamente “gordo” en los internals del código, pero por lo que leí de estas discusiones parece haber consenso en llevarlo adelante e implementarlo. Por mi parte… ¡lo necesito ya!
• \dL para listas los lenguajes utilizados en psql: Es una nueva característica en psql, la de poder listar los lenguajes instalados en la base de datos (plpythonu, plpgsql, etc.).
• Estadísticas de esperas por bloqueos: La idea es poder tener un historial de los bloqueos sufridos por los clientes en la BD, para poder detectar problemas y saber bien qué pasa en todo momento.

Bueno, de más está decir que no hay ninguna garantía de que todo esto sea finalmente integrado en 8.5, sino que se está evaluando al mejor estilo Software Libre™: peer-review, discusión de estrategias del proyecto, consenso en la comunidad de desarrolladores y posterior aceptación/pedido de mejoras/rechazo. Así que veremos cómo sigue.

Saludos!
Marcelo

Navegando por ahí, me acabo de encontrar con dos herramientas interesantes, que me interesa compartir…

Ninja

La primera llamada Ninja, que viene a ser algo así (traducido de su página web):

Ninja es un sistema de detección y prevención de escaladas de privilegios para GNU/Linux. Mientras está corriendo, monitorea las actividades de los procesos locales por un lado, y de los procesos corriendo como root por el otro. Si un proceso lanza a otro nuevo con UID o GID cero (root), Ninja va a loguear la información necesaria acerca del mismo, y opcionalmente lo puede finalizar si fue creado por un usuario (es decir, un proceso de un usuario) sin autorización.

En mi opinión, si bien hay herramientas más complejas para hacer este tipo de cosas con servicios en producción, parece un buen complemento cuando se necesita algo más sencillo y no tan crítico, como dar acceso de terminal o X  a usuarios finales. Acá hay un post sobre cómo instalarlo en Ubuntu.

KSplice

La otra herramienta, promete algo que sería la salvación para todos los sysadmins: aplicar actualizaciones al núcleo de un SO sin reiniciar el equipo, “al vuelo”, en forma transparente. Esta herramienta de salvación para todos nosotros se llama KSplice, es abierta, y fue tema de investigación y desarrollo por gente del MIT. Si realmente anda bien y funciona, sólo falta que salga en Slashdot (no creo que tarde mucho…).

KSplice funciona creando actualizaciones (aplicables instantáneamente) para el kernel en ejecución. Estas actualizaciones son igual de efectivas que las estándar (supongamos las que provee la distribución que estamos utilizando), con la diferencia de que no hace falta reiniciar para que entren en funcionamiento.

Para esto, necesita el código fuente de la actualización (un parche para el kernel que se está corriendo), más el código fuente del kernel en ejecución. El núcleo no necesita ser modificado por adelantado para que esto funcione (sólo x86 y x86_64).  El proceso de creación y aplicación de un parche es bastante sencillo, y ¡hasta se puede deshacer!

Por el momento sólo funciona con Linux x86, x86_64 y ARM, que su código se puede bajar en forma de fuente, agregar los repositorios GIT, y también descargar una versión binaria para instalar en cualquier distro GNU/Linux.

Las únicas desventajas (si cabe) en cuanto a lo técnico que le veo es que:

• Sólo aplica parches que no cambien la semántica del núcleo (supongo que esto quiere decir que no hacen que cambie su ABI). Sin embargo, ellos mismos afirman que el 88% de los parches de seguridad para núcleo publicados entre Mayo de 2005 y Mayo de 2008 eran aplicables perfectamente con KSplice. Esto hace que sirva en primera instancia para parches de seguridad, y para corrección de fallos en segundo lugar.
• No hay información sobre qué pasa si reinicio el equipo efectivamente con parches aplicados vía KSplice (supongo que todos los cambios se deshacen, ya que esto es al vuelo y no hay modificación sobre la imagen binaria del núcleo en sí mismo).
• Es necesaria la misma versión de compilador (o casi, ya que no hace un chequeo por número estricto de versión, sino que hace un chequeo de posibles conflictos y aborta en caso de detectar uno, afirmando en su web que esto es seguro).

Por otra parte, próximamente van a ofrecer el servicio de actualizaciones, esperemos que cumplan lo que prometen, a mí me cuesta creer que esto sea así de fácil. Sería bueno que todas las distros lo incluyeran e integraran…

Bueno, es todo por ahora.

¡Saludos!

Marcelo

Gracias a este post del sitio de PostgreSQL en español, me entero que terminó la conferencia anual de la comunidad de PostgreSQL, llamada PGCon 2009. Obviamente, la nueva versión que está al caer (8.4) acaparó todo un track completo, así que acá está la lista de charlas para ver de qué se trató.

Particularmente, a mí me interesó mirar los slides de:

• Introducing Windowing functions: Es una nueva e importante característica de PostgreSQL 8.4, el soporte de consultas con varios niveles de aggregates, no sólo el primero con la cláusula GROUP BY, sino que también se pueden subdividir estos grupos (llamados Windows) y ejecutar funciones dentro de cada subrango. Muy interesante.
• No More Waiting: La clásica y necesaria charla sobre las nuevas cosas de PostgreSQL 8.4.
• SkyTools3: Replication (Londiste3): Si hay algo que se le puede “recriminar” a PostgreSQL es la falta de replicación built-in (está prometido para la 8.5, tough). Sin embargo, hay muchas herramientas extra para hacerlo, y Londiste es una de ellas (desarrollada por la gente de Skype, que usa PostgreSQL para todo).

En fin, PostgreSQL es una base de datos muy robusta y confiable, la vengo utilizando profesionalmente y nunca me dejó de a pie. Tiene una excelente documentación, una licencia extremadamente libre (BSD), casi todas las características de las grandes, y un muy buen soporte en la lista de PostgreSQL en español.

Saludos
Marcelo

Este post es sólo para comentar, amigos sysadmins, que este domingo a las 00:00 hs. se “atrasará” una hora el reloj del lado este del país, y que todos aquellos que tengan actualizados el paquete tzdata van a tener actualizados el reloj automáticamente, a diferencia de otras oportunidades donde lo repentino de los caprichos las decisiones políticas hicieron que hubiera que hacer esto a mano.

Para comprobar esto, pueden correr en la consola:

marcelo@marcelo-laptop:~$ zdump -v /etc/localtime | grep 2009
/etc/localtime  Sun Mar 15 01:59:59 2009 UTC = Sat Mar 14 23:59:59 2009 ARST isdst=1 gmtoff=-7200
/etc/localtime  Sun Mar 15 02:00:00 2009 UTC = Sat Mar 14 23:00:00 2009 ART isdst=0 gmtoff=-10800
/etc/localtime  Sun Oct 18 02:59:59 2009 UTC = Sat Oct 17 23:59:59 2009 ART isdst=0 gmtoff=-10800
/etc/localtime  Sun Oct 18 03:00:00 2009 UTC = Sun Oct 18 01:00:00 2009 ARST isdst=1 gmtoff=-7200

Las dos primeras líneas representan las reglas con el cambio mencionado. Si no aparece nada después de correr este comando, actualizen el paquete tzdata.

Saludos,
Marcelo

Leyendo la blogósfera, me detuve en esta crónica de una migración de VMWare Server a KVM, explicando las razones de porqué elegir KVM y no el resto.

Las enumero, tratando de traducirlas lo mejor posible:

• El host corriendo KVM es un Linux estándar sin modificar. Para ambos (Xen y VMWare ESX) se necesita correr un Sistema Operativo modificado especialmente (que lo hace relativamente difícil de mantener al día con actualizaciones de seguridad).
• Siendo incluído en Linux, usted obtiene soporte de KVM en el mismo momento que usted compra soporte estándar de Ubuntu Server. Como de todas maneras teníamos planeado adquirir soporte Ubuntu, tuvimos soporte para nuestra plataforma de virtualización sin costo adicional.
• Performance: La velocidad de KVM es muy buena, ya que está basada en extensiones de hardware. (N. del T.: Ojo, tengo entendido que tanto Xen como VMWare también soportan extensiones de hardware en caso de estar disponible).
• VMBuilder: Ubuntu desarrolló una herramienta (ubuntu-vm-builder, ahora llamada vmbuilder) que puede construir un appliance virtual en aproximadamente un minuto. Esta es una mejora enorme en comparación a la forma que solíamos crear VMs (VMbuilder también puede ahora crear imágenes para Xen y VMWare). (N. del T.: En mi experiencia, sirve únicamente si vamos a crear VMs con SO Ubuntu).
  
• KISS – Keep It Simple, Stupid (Mantenlo Simple, Estúpido!): KVM utiliza todo lo que Linux provee de antemano. Cada VM es un simple proceso, usa su planificador de procesos (scheduler), uno puede reasignar la prioridad (renice) del proceso, asignarlo a una CPU específica… esto resulta en una base de código fuente mucho más pequeña que Xen por ejemplo, de manera que asumo que será más fácil y barato mantenerlo a largo plazo, haciendo que el proyecto más confiable.
• Y lo más importante: Las companías involucradas. Aún cuando a KVM le faltan algunas características, los posts en la lista de desarrolladores muestran parches de código desde empresas como RedHat (que compró KVM el año pasado), AMD, Intel, IBM, HP, Novell, Bull… ¿A quién va a creerle, a un proyecto manejado por una única compañía (Citrix, VMWare), o a un proyecto soportado por tantos actores diferentes?
  

Para mí le falta otra cosa importante: Tiene un desarrollo totalmente abierto y es software de cóodigo abierto.

En donde laburo estuvimos metiendo KVM en un servidor y si bien las herramientas de configuración/administración tienen sus quirks (aunque funcionan relativamente bien), la parte de KVM en sí anda perfectamente y con una excelente performance y confiabilidad. ¡Ah! y Canonical ya había anunciado que iba a soportar KVM como plataforma principal de virtualización también, así que… IMHO, KVM tiene todas las de ganar de acá en adelante.

Espero postear próximamente un poco las experiencias que tuve armando VMs con este software, mientras tanto dejo este enlace que resume la mayoría de las cuestiones con KVM en Ubuntu.

Saludos
Marcelo