Basicamente dice algo que ya sabiamos.

1- Usad InnoDB si podeis.

2- Olvidaos de los motores que no sean InnoDB, MyISAM y NDB (para cluster).

Todo esto viene a que está muy en boga probar las nuevas versiones de Federated, y Maria (no son las galletas, es el nombre del futuro motor de almacenamiento de MySQL), y todo parece indicar que lo único que pueden daros son problemas.

Esto no afecta en nada al software ni al desarrollo, o, al menos, eso espero. Muchos productos de la ASF ya funcionan en Windows y no es algo mal, y la ASF ya está financiada por Yahoo y Google.

Ya me gustaría a mi que Microsoft me financiase el viaje a la ApacheCon en New Orleans o en Asia…snif snif.

.

Para los frikis subersivos que están en contra de todo monopolio (aunque los usen todos los dias), siempre os quedará pasaros a NgINX, lighttpd, o programaros vuestro propio servidor web.

Tiene, por ejemplo, una página con el módulo que se crearon para Apache, y otros proyectos opensource. Mod_rest_cache es un módulo para almacenar contenido en una cache en local partiendo de material cogido de otro servidor web.

Las librerias que proporcionan son, en su mayor parte, relacionadas con el streaming de contenidos multimedia.

.

Mis amigos de RTVE también lanzaron hace poco nueva versión de su Web. No es TAN elaborada como la de la BBC, pero al menos tiene agregadores RSS, y esos maravillosos capítulos de Muchachada Nui que me amenizan los ratos después de las comidas..(ejem).

No sirve tan sólo para autenticar, porque el módulo hace unas cuantas cosas más, pero bien puede ser el punto extra de seguridad que puede necesitar un administrador paranoico para proteger esa información vital de la empresa.

.

Recordaros, de cualquier manera, que según la rumorología popular, existe un backdoor en el PROGRAMA PGP para que ciertos gobiernos puedan acceder a la información. Como digo, son sólo rumores (¿o no?).

(Actualizado)

Respecto a esto, un tal Philip Zimmerman dijo:

Q: Are there any back doors in PGP? Come on, you can tell me, I won’t tell anyone.

A: No. There never have been, and never will be, at least as long as I am associated with the product. I didn’t go through all this trouble just to see my product become corrupted. Besides, we publish the PGP source code, so you can check it yourself.

Un ejemplo es “MyCat“, un conjunto de 3 herramientas (por el momento) que sirven para sincronizar ficheros de configuración, y para monitorizar los ficheros de log.

.

No soy muy partidario ultimamente de utilizar aplicaciones demasiado novedosas, y, la verdad, algo ando desesperanzado con el mundillo del open source, ya que me he encontrado ultimamente demasiados proyectos abandonados y sin actualizar. Quizás termine colaborando con este, aportando el script que uso en Perl para monitorizar Tablespaces.

El futuro dirá si esta herramienta será como el MaatKit para MySQL replicado.

Demos la bienvenida, pues, a los tablespaces de Oracle.

Esta funcionalidad permite tener una base de datos con alta disponibilidad y tolerancia a fallos, sin tener que usar enormes cantidades de memoria RAM.

Un tablespace es un fichero en disco en donde Mysql va a ser capaz de almacenar datos, con la estructura que Mysql usa para almacenar datos en RAM.

Lo primero, es crear un fichero de log que MySQL usa internamente para reconstruir los cambios en caso de fallo, etc…Estos ficheros se crearan en el directorio en donde tengamos almacenados los datos del cluster.

CREATE LOGFILE GROUP logfilegroup ADD UNDOFILE ‘logfile.dat’ INITIAL_SIZE 64M ENGINE NDB;

Si tenemos que añadir más ficheros de log en un futuro, usaremos:

ALTER LOGFILE GROUP logfilegroup ADD UNDOFILE ‘logfile2.dat’ INITIAL_SIZE 512M ENGINE NDB;

A modo de guia, el fichero de log ha de ser tan grande como el tamaño de la RAM que uséis para el cluster.

Ahora creamos el tablespace:

CREATE TABLESPACE bbdd_tablespace ADD DATAFILE ‘bbdd_tablespace_1.dat’ USE LOGFILE GROUP logfile group INITIAL_SIZE 512M ENGINE NDB;

Creamos un tablespace de nombre bbdd_tablespace, con un fichero de datos “bbdd_tablespace_1.dat”, asociado al log logfilegroup, y con un tamaño de 512 M.

Si en un futuro queremos añadir más espacio a ese tablespace:

ALTER TABLESPACE  bbdd_tablespace ADD DATAFILE bbdd_tablespace_2.dat INITIAL_SIZE 4G ENGINE NDB;

Para terminar, cuando creamos una tabla, normalmente lo hacemos con el motor por defecto de MySQL:

ENGINE=MyISAM DEFAULT CHARSET=latin1;

La sintaxis para usar tablespaces en un cluster es:

ENGINE=ndb tablespace bbdd_tablespace storage disk charset=latin1;

.

Mi consejo general es no ser tacaños con el espacio. Nunca se sabe cuando vas a sufrir una avalancha de datos.

En el siguiente articulillo, os explicaré como monitorizar esos tablespaces para adelantarnos a los problemas, porque si se llena un tablespace, ni avisa, y falla de manera… severa.

La web de MySQL respecto a tablespaces es un lugar que hay que visitar si estás montando este sistema.

Método 1: http://www.jimdowling.info/ndbinstaller-trac/wiki

NdbInstaller es un instalador que te lo hace todo. Tiene hasta un vídeo y todo de la instalación.

.

Método 2: Este método, mi favorito, consiste en utilizar las utilidades de Johan Andersson. Consta de varios pasos.

1. Vamos a la web del configurador: http://www.severalnines.com/config . Allí encontramos un formulario, y tras rellenar los datos, nos llegará al correo los scripts de configuración necesarios.
2. En el master (el nodo que va a hacer de gestor de los demás), digamos que en /var/lib/mysql-cluster, dejamos el config.ini. Ponemos el script de inicio en /etc/init.d/ndb_mgmd, para arrancar el proceso del Master. Arrancamos el nodo maestro.
3. En el primer nodo, bajamos y compilamos las fuentes. Actualmente, la versión es la 6.2.15. La URL es: http://dev.mysql.com/get/Downloads/MySQL-Cluster-6.2/mysql-cluster-gpl-6.2.15.tar.gz/from/pick. Una vez descomprimido, ejecutamos ./BUILD/compile-pentium-max para hacer el configure. Luego make y, como root, make install. Esto nos deja todo en /usr/local/mysql.
4. Si tenéis mucha prisa, y las máquinas son iguales, hacéis un tar de ese directorio /usr/local/mysql y lo pasáis al resto de servidores, a la misma localización.
5. De los ficheros que nos enviaron por correo, cogemos el my.cnf correspondiente a ese nodo, y lo metemos en /etc, con cuidado de ELIMINAR el directorio /etc/mysql si existe, porque es posible que os de conflicto si están las mysql-common de la distribución instaladas.
6. Además, hay que poner las nuevas librerías en /etc/ld.so.conf.d, para ello creais un fichero “mysql.conf” con las líneas “/usr/local/mysql/lib/mysql”. Cerramos y ejecutamos como root “ldconfig -v”.
7. Añadimos al PATH de sistema /usr/local/mysql/bin y /usr/local/mysql/sbin, por comodidad.
8. Añadimos en /etc/init.d/mysqld el script de inicio del mysql, y en /etc/init.d/ndbd el script de inicio del proceso “ndbd”, que es el nodo de almacenamiento del cluster.
9. Vamos al nodo maestros, ejecutamos “ndb_mgmd”…y debería estar todo arrancado, si le habéis proporcionado bien los datos al formulario.

.

¿Realmente es tan fácil?

Si.

Pero también depende de cada sistema.

.

Este es un pequeño checklist de operaciones que hay que hacer a posteriori:

1- Montar el backup. Un script para hacer backup automaticamente, descartar los que no se quieran cada dia, y ir haciendo un reciclado.

2- Una página de monitorización suele venir bien. Además de monitorizar los procesos “ndbd”, ndb_mgmd”, y el mysql, siempre viene bien que los logs del cluster (en el nodo maestro, en /var/lib/mysql-cluster) os lleguen al correo. Y es vital monitorizar la memoria libre del cluster.

3- Si vais a usar Tablespaces, recordad que estos no crecen solos. Una página de monitorización exclusiva es MUY DESEABLE.

Existen dos módulos:

- Mod_removeip : que es el más utilizado, junto con algun script para eliminar las IPs del error.log.

- Mod_scambleIP: que está recién salido del horno, y que en vez de modificar la IP cambiándola a 127.0.0.1, la CIFRA de manera que luego se pueda usar en awstats con la clave adecuada.

RatProxy es un proxy al que puedes enganchar tu navegador para probar posibles vulnerabilidades de seguridad en las webs por las que navegas…oh, no quise decir eso, quise decir “en TUS webs por las que navegas”….bueno, como siempre, habra unos pocos que usen estas herramientas para mejorar su seguridad, y otros tantos que se dediquen a dar dolores de cabeza a los administradores.

No es, quizás, tan completa como otras herramientas más antiguas, pero es un complemento más a utilizar. Mi recomendado para estos usos, es ParosProxy, porque permite lanzar peticiones modificadas, incluso modificando las cookies de tu navegador.

Categoriza las posibles vulnerabilidades según la importancia, y para instalarlo, bajáis el código fuente, ejecutáis Makefile, y listo. (En ubuntu, necesitais build-essentials, y libssl-dev). Ejecutadlo sin argumentos para ver las diferentes opciones. Cuantas más opciones le deis en la línea de comandos, más vulnerabilidades intentará obtener.

El mejor ejemplo, el modo de sacar la fecha de ayer en LINUX (en solaris no):

# date –date=”yesterday”

jue jul  3 13:46:55 CEST 2008

Y ya puestos, sacar la fecha de dentro de dos meses:

#  date –date=”2 months”

jue sep  4 13:46:20 CEST 2008

O la fecha de hace dos meses:

# date –date=”2 months ago”
dom may  4 13:47:17 CEST 2008

MySQL Cluster es una solución de ALTA DISPONIBILIDAD. Un cluster empieza a ser rentable cuando existe un número de conexiones ALTO. Es decir, allá donde una sola instancia de MySQL empieza a tener problemas de rendimiento, el cluster es capaz de aguantar (y no sólo aguantar, sino crecer adecuadamente y en horizontal hasta un número de conexiones simultáneas y consultas razonable).

.

También es importante saber que el tiempo de recuperación de un Cluster de MySQL es MUY alto comparado a una base de datos de un sólo nodo y varios gigas de tamaño. Dicho en claro, es muy difícil que se caiga el cluster, pero una vez se ha caido, os vais a pasar 10-20 minutos recuperando y arrancando, como mínimo.

Además, añadir otro nodo de almacenamiento no es trivial. Hay que ELIMINAR TODO lo almacenado, añadir el nuevo nodo, y recuperar de backup. Esto es así porque el proceso “ndb” hay de regenerar todo su estructura interna, la cual cambia al añadir otro nodo.

Más…despues del salto.

Las principales diferencias con respecto a una replicación MAESTRO-ESCLAVO son:

- Permite escrituras en todos los nodos de acceso. Salvo configuraciones extrañas, en la replicación Maestro-esclavo se deben enviar los INSERT siempre a un nodo.

- Permite crecer más de dos nodos. Antes que me lo digáis, ya se que existe por ahí una configuración llamada replicación circular, que permite crecer 3+ nodos, pero da muchos problemas. La otra configuración posible con varios servidores MASTER, también es una buena manera de meterse en serios problemas.

Cuando llega el momento en que realmente empezáis a notar ralentización en ciertas querys, los procesos de MySQL no bajan del 90%, y el backup se eterniza, ese es el momento de empezar a pensar en:

1- Contratar un DBA y un látigo para los programadores, y optimizar por una vez todos esos select con “cross join” milenarios.

2- Montar un Cluster de MySQL para dar soporte al crecimiento futuro de tus aplicaciones.

.

Una vez ya se ha decidido probar MySQL Cluster (y fijáos, digo PROBAR), lo primero es sentarse, y ver si las LIMITACIONES (en inglés) de Mysql Cluster

Lo que más me llamó la atención de las limitaciones, es el número máximo de tablas, y ciertos tipos de campos (FULLTEXT) que no se pueden usar.

Además de esas limitaciones, los Cluster de MySQL no conviven muy bien con las consultas con varios JOIN. Es esta una de las limitaciones más serias, puesto que tiene un efecto inmediato en el rendimiento, y a veces no son fáciles reprogramar.

.

La maqueta en la que se ha de probar el Cluster no puede tener menos de 3 nodos. Y esta es la configuración mínima requerida para cualquier cluster.

- 1 nodo de gestión (proceso ndb_mgmd). Este proceso no carga nada, se puede meter en cualquier lado y no ocupa espacio siquiera. Pero, dicho claramente, TIENE QUE ESTAR arrancado, porque es el encargado de coordinar los diferentes nodos y su ausencia puede causar falta de sincronía.

- 2 servidores, cada uno con un nodo de almacenamiento (ndbd), y un nodo de acceso (mysql normales de toda la vida, pero que apuntan al cluster en vez de a local).

Lo mejor, es coger un volcado de las bases de datos que se van a migrar, modificar los tipos de datos y estructura, y probar a meterlos en esta maqueta. De esta manera podremos hacer un DIMENSIONADO adecuado del futuro cluster en producción.

.

¿Y ahora, almaceno las tablas en disco o en memoria?

La decisión es bien fácil. Si te puedes permitir tener servidores con tanta RAM como para que quepa entera tu base de datos, mas el crecimiento futuro, almacena todo en RAM.

Si tu empresa es modesta (aunque sea un google en potencia), puedes almacenar las tablas en disco.

Hay que tener en cuenta que almacenar las tablas en disco aumenta el tiempo de respuesta, aunque las pruebas realizadas indican que este aumento es algo inferior al esperado, sobre todo una vez has ajustado las cachés a disco.

Además, no todo va a disco, sino que almacena los índices en memoria. Esto hace que no podáis pillar el típico server barato de 1 giga de RAM y un disco SATA de 750GB, y haya que ir a servidores con 2+ gigas de RAM si se quieren hacer bien las cosas.

Desde que comenzé con el Cluster, visito el blog de Johan Andersson cada día. En dicha web viene un script para DIMENSIONAR clusters que es sencillamente, perfecto.

La razón de ejecutarlo sobre una maqueta es que el script será capaz de decirte el tamaño de los TABLESPACES que almacenarán las tablas en disco.

Con los datos que os proporcione ese script, y un poco de maña a la hora de estimar el crecimiento futuro de vuestras bases de datos, y de los accesos a la misma, seréis capaces de calcular el número de nodos que necesitáis.

.

Para finalizar esta parte, un apunte sobre el backup. Este se realiza simultáneamente en todos los nodos con la herramienta de backup del cluster. Este deja unos ficheros en el directorio del cluster, sin comprimir. No tiene un impacto excesivo en el rendimiento del cluster, y durante las pruebas este casi ni se inmutó mientras le hacia querys con mysqlslap y hacía el backup a la vez.

Recomiendo utilizar el mk-parallel-dump de maatkit. El rendimiento no tiene comparación con respecto a mysqldump.

A modo de consejo, escalad siempre de 2 a 4 nodos, luego a 8,etc…

.

Al final, podéis haber hecho dos cosas:

- Crear un cluster de MySQL que admite n-mil consultas por segundo, con n-cientos updates simultáneos, sobre bases de datos de varios GB, almacenados parte en disco, parte en RAM, todo en alta disponibilidad con un tiempo de recuperación aceptable.

- Un monstruo inutil que tarda 3 segundos más por consulta que un solo nodo, se cae porque no cabe en la RAM o los tablespaces se llenan, y cuando se cae, no hay manera de levantar en un tiempo razonable. Vuestra empresa pierde dinero, y os vais a la calle por torpes.

Así que mejor, os lo pensáis dos veces antes de instalarlo, y retomáis la opción de ampliar el Mysql Actual.

Proximamente, la instalación de un cluster completo de MySQL, proceso que dura 15 minutos, y causa unas dos semanas de insomnio si se hace mal, y cómo gestionar el monstruo recién creado.

La primera, es vital.

Cluster Configuration Tool, es una web que te genera todos los ficheros de configuración necesarios para un cluster de Mysql con los nodos que tu le definas, y…te los envía al correo, con scripts que hacen el trabajo casi por ti.

Los ficheros de configuración que envía están medianamente optimizados, y es tremendamente fácil de usar. La versión que se recomienda utilizar es la Mysql-5.1.23-ndb-6.2.15.

Visto en el Blog de Johan Andersson (inglés).

Incluye sobre todo arreglos para mod_proxy.

Mención aparte que cada release se retrasa más y más, cada vez incluyen menos cosas nuevas.

¿Para cuando Apache 3?

Desde hace ya bastante escribe un blog (http://c0t0d0s0.org) sobre Solaris y las cosillas que va haciendo.

Su último proyecto es un libro sobre “esas funcionalidades de Solaris” que están ahí, pero nadie usa porque no las conoce. Es gratuito, porque está en fase Alfa, pero el contenido será el mismo cuando esté finalizado.

En mi opinión, es ese libro que hay que tener a mano cuando quieres ir un poco más allá en temas de administración de sistemas en Solaris.

- ¿Las directivas que tengas en el fichero .htaccess?

- ¿El fichero httpd.conf?

La respuesta la marca la directiva AllowOverride en el fichero de configuración.

Si en el fichero de configuración httpd.conf, tenéis activada la directiva AllowOverride, con el parámetro adecuado, entonces el fichero .htaccess será capaz de sobreescribir la configuración que le venga marcada del httpd.conf.

Dicho de otra manera, si yo tengo una directiva en el httpd.conf, que para un determinado directorio mande a www.elmundo.es, la puedo sobreescribir en el .htaccess siempre y cuando la directiva AllowOverride en el httpd.conf me lo permita, y poder redirigir a www.marca.es, en vez de a El Pais.

Existe un módulo llamado mod_qos que realiza esa tarea precisamente.

http://mod-qos.sourceforge.net/

Lo he probado en servidores poco cargados, y funciona muy bien. Como siempre, cuidado a la hora de meterlo en servidores masificados, porque priorizar ciertos recursos respecto a otros…siempre suele traer alguna consecuencia.

Las versiones están actualizadas y mantenidas al dia, con lo cual puede ser un módulo que pase a ser de la lista de “fijos” en mis instalaciones en un futuro.

Capacidades:

• Limitar el número máximo de conexiones a un virtualHost.
• Limitar el ancho de banda como transferencia, o peticiones por segundo.
• Grupos con diferentes tipos de limitaciones.
• Limitaciones a nivel de TCP.

Roy T. Fielding, uno de los configuración de la Apache Software Foundation, dejó en la web de la ApacheCon esta presentación sobre las funcionalidades que podemos esperar para la versión 3.0 de Apache. Es un fichero PDF de 12 MB, en inglés.

A modo de resumen:

- No se podrán fijar opciones en la compilación. Olvidémonos del ./configure –enable-proxy.

- Se podrá utilizar únicamente MPM, el modo multithread. Para cada plataforma irá el modo más adecuado dentro de los diferentes MPM, pero escogido por el desarrollador.

- Reducción de las cabeceras en la comunicación Cliente -> Apache. En vez del típico GET /…bla bla bla, será un G /…

- Desaparece APR. Espero que estén de broma con esto, porque nos va a tocar aprender a programar módulos de otra manera (de nuevo).

Lo que intentan, o al menos eso parece, es replantear de nuevo Apache. Lo que van a utilizar se llama “Waka”, y, en serio, quiero pensar que están de broma. Ese nuevo protocolo podrá aplicarse en conexiones HTTP 1.1.

Todo esto se debe a la baja actividad que ha existido ultimamente. Según parece, los propios desarrolladores han dejado de “divertirse” programando, así que van a replantearselo todo para aumentar la actividad, y es posible que hagan lanzamientos de versiones forzadas en ciertas fechas.

Os iré contando más según salga más información, aunque como conclusión, podría decirse que esos desarrolladores están un poco locos.

Ahora mismo se anda celebrando la ApacheCon, la reunión de freaks de Apache en Europa. Se pueden ver videos sobre las charlas que han dado, las cuales son realmente interesantes. Normalmente están vedadas al público porque para ir a la Apachecon hay que pagar, y claro, gratis, las cosas, no son lo mismo.

Muchos me preguntan acerca de la configuración de SSL en Apache. En Onlamp han sacado un interesante artículo, en inglés, sobre la configuración paso a paso. Me imagino que os ayudará a muchos.

Recordad que sigo intentando echar una mano a todo el que me lo pide en los foros de la web.

Ha sido una experiencia divertida, aunque sigo siendo mucho más rápido con teclas.

Os dejo el link a “Linux Speaks to the Blind“, que son una serie de scripts para manejar varios programas de linux usando sólo tu propia voz.

Hacen bien en puntualizar que PHP se usa mucho en plataformas Windows.  Lo curioso del tema es que…la mayoría van en Windows XP, no en un Windows Server 2008 que necesita un maquinón extremo para funcionar.

Es una buena noticia para Microsoft.

En uno de los laterales podeis ver ejemplos de varios capítulos.

Lo curioso del libro, es que está hecho por dos hispanos. Daniel Lopez y Jesús Blanco. Son participantes en la Apache Software Foundation, además de trabajar para Covalent y BitRock.

No es que me guste el formato. Personalmente prefiero foros porque son mas rápidos,  y llegas a gente que ha sufrido los problemas más diversos.

La lista de cambios la podéis encontrar al principio del directorio en la URL anterior. Trae correcciones poco importantes de seguridad, un  menor consumo de memoria en algunos casos y funcionalidades, y bastantes apaños a módulos como mod_ajp (de conexión con Tomcat) y mod_proxy.

Es bastante extensa debido a que no se lanzó la versión 2.2.7, y se pasó directamente a la 2.2.8.

Actualización: En ese directorio también podéis encontrar un módulo curioso. Mod_ftp, para crear un servidor FTP para servir páginas HTTP.Está en fase Alpha, y, con sinceridad, le queda mucho para que se pueda utilizar.

Con los nuevos foros, va una pequeña molestia. Tendréis que darle a Recuperar Password en los foros para que os deje acceder con vuestra cuenta. Desgraciadamente, el cifrado del password parecía diferente, y es el campo que no he podido mantener en la migración (los mensajes aparecerán en breve…).

Para terminar, un pequeño comentario respecto a los diferentes plugins y extensiones de integración que me he encontrado según probaba software para este blog.

Son todos una basura.

¿El objetivo? Probar la compatibilidad de las diferentes aplicaciones en Microsoft Windows Server 2008.

¿Nuevos aires en Microsoft? ¿Otro evento más para la prensa?

Quizás no venga mál después de todo, porque, ¿cuantos de vosotros usáis Apache en Windows? Seguro que más de uno.

p.d: Hace tiempo ya pasó con Mozilla.  De este evento no hay link, tan sólo un mensaje a las listas  de desarrolladores de la ASF.

1- Si protegéis el directorio raíz del site con un fichero .htaccess, y un formulario de login y password, para que no acceda la gente desde fuera.

2- Si hacéis un ProxyPass /bittorrent/ http://192.168.1.90/bittorrent/

Esa URL de http://michiringuitocasero.com/bittorrent, NO está protegida. Se accede sin clave porque Apache ni siquiera mira el directorio “/” del site para ver si existe un .htaccess.

Más de uno lo tendrá por ahí de esta manera.

¿Alguna recomendación? (Ahorraos el PHP-BB, por favor)

•  Pythoñol y  Comp-jugador, para aprender a hablar español.
• OpenBravo, el bravo ERP para pequeñas y medianas empresas.
• Tan necesario en estos tiempos, una herramienta para calcular los parámetros de la finaciación de LaCaixa. Para que vayáis preparados antes de pedir una hipoteca.
• Esteban, el bot que chatea contigo y te ayuda a aprender castellano.
• Y el premio gordo, se lo lleva “Bocazas“, el applet que te permite añadir chat a tu página Web.

Viva la Eñe.

Para poner a escuchar Apache en un interfaz IPv6 de tu sistema operativo (sin entrar a los diferentes modos que hay para configurar IPv6 en Linux), basta con poner en el httpd.conf:
Listen [::]:80

Esa es la traducción formal a IPv6 de “Listen *:80″. Las direcciones IPv6 van entre “[]“.

Ambos formatos pueden coexistir, pudiendo haber tantas directivas Listen como se quiera.

Listen 127.0.0.1:80

Listen [2032:kkk8::aaa3:aaad:ccca:uiaf]:80

En cuanto a los Virtualhost, se sigue la nomenglatura de siempre, pero adaptándola a IPv6. Los siguientes grupos de Virtualhost (con su respectivo NameVirtualHost), significan lo mismo, solo que uno sirve en IPv6 y otro solo para IPv4.

NameVirtualhost 127.0.0.1:80

<VirtualHost 127.0.0.1:80>

</VirtualHost>

NameVirtualhost [::1] :80

<Virtualhost [::1]:80>

</VirtualHost>

Además, Apache tiene un parámetro a la hora de compilar (--enable-v4-mapped ) que permite convertir automaticamente direcciones IPv4 a IPv6.

¿A quién le puede interesar esto? Probablemente a 3 o 4 de Elmundo.es (famosos por tener ya IPv6 implementado) y a unos pocos administradores previsores, a los que no les guste tener que adaptar sus servidores a toda prisa el dia que haya que migrar a IPv6.

Actualización: Probablemente uno de los mejores documentos para ver como quedará TCP/IP y en qué se transformarán los diferentes protocolos de Internet cuando entre en acción IPv6, es uno de los “libros rojos” de IBM. Es casi como una biblia, pero aviso, es de un nivel técnico muy alto y no es una lectura para cualquiera.

En HowtoForge encontré un tutorial para hacerlo con TLS. No es sencillo, pero funciona. El tutorial es específico para Debian, y está en inglés.

Si tenéis alguna duda respecto del tutorial, sabéis que podéis plantearla en los foros.

ucarp - La alternativa a VRRPv2 para distribución de IPs virtuales entre varios servidores. Sirve para crear estructuras de balanceo. En http://www.ucarp.org/project/ucarp podemos ver diferentes programas que lo utilizan, como PureFTPd.

(Nota, no estoy muerto, sencillamente comenzé un nuevo trabajo. Se aceptan colaboradores para esta cutre-web!!!!)