Aunque hacía tiempo que lo usábamos, hace unas semanas actualizamos a la última versión estable del momento (1.2.3) con idea de poner en marcha un sistema eficaz de balanceo y fail over entre 2 ADSLs. Nuestros anteriores intentos en base a IPTABLES y marca de paquetes en Linux habían tenido resultados desiguales y era de estas “asignaturas pendientes” en las que nos habíamos dado por vencido.

Seguimos con algunos matices este tutorial de la propia documentación y el resultado fue el esperado y de forma más rápida de lo previsto. El problema nos surgió cuando empezamos a tener problemas con la red Windows de la oficina y la conexión a uno de los servidores Samba. Las maquinas empezaban a quejarse de “Nombre de usuario duplicado” en la red a pesar de que el trafico por TCP/IP funcionaban sin problemas, así que tras volvernos locos con otras opciones, determinamos que el problema tenía que estar en los cambios en el router.

Para crear la configuración de balanceo se crean dos reglas que fuerzan que el trafico de cada una de las interfaces de red de salida circulen obligatoriamente por ella. Parece que al hacer pfsense broadcasting en la LAN, los paquetes UDP que usa Netbios en los puertos 137, 138, 139 son replicados y la red de Windows (en realidad protocolos CIFS/Samba) estima que el mismo nombre de red esta presente en x ocasiones y deja de funcionar. Una explicación más clara que nos dio la pista correcta aquí y aquí.

La solución, crear una regla en el firewall de la LAN para que bloquee todo el tráfico a esos puertos, es decir cualquier cosa desde la LAN con cualquier destino en ese rango de puertos: 137 al 139. El bloqueo del puerto 67 también salía en alguna referencia al mismo tema, aunque entiendo que no es necesario. Aquí un pantallazo.

Confiemos que alguien le ahorre algunas de las horas que nos costo a nosotros dar con ello.

Un antiguo blog que queríamos actualizar tenía sus tablas en Latin1 y queríamos convertirla a una completamente en UTF8 (es decir BBDD y tablas). Es importante tener en cuenta tanto la codificación de tablas originales como la del propio wordpress (“define(‘DB_CHARSET’, ‘utf8′);”), porque las opciones de conversión varían en cada caso. En este caso concreto es:

BBDD en Latin1
Tablas en Latin1
Wordpress DB_CHARSET: UTF8

El objetivo era pasarlo todo a UTF-8 que es como mantenemos todas las tablas que podemos ya. Encontré diversas pistas sobre conversiones como ésta, haciendo uso de ICONV para convertir el texto del dump, pero me costó un rato darme cuenta de que nuestros datos NO necesitaban conversión porque estaban ya en UTF-8 (el WP los almacenaba así por su configuración), asi que esa ruta no sirvió. Su la codificación del WP hubiera estado en latin1, probablemente si es el camino correcto. Pensé entonces que sencillamente modificando todos los “DEFAULT CHARSET=latin1;” del dump de MySQL a “utf8″ estaría todo listo pero a pesar de ello, nada.

Finalmente, encontré esta entrada que me dio una pista adicional sobre la que ya sospechaba. Al hacer el dump, el propio MySQL está haciendo una conversión en función al sistema cliente, por lo que si los datos estaban ya codificados y sólo hay que cambiar la creación al importar la tabla, es importante que la exportación se haga también en el formato antiguo:

$ mysqldump –default-character-set=latin1 –databases wordpress > m.sql

Después a modificar la SQL para que al importar la nueva se haga ya en UTF-8.

$ replace “CHARSET=latin1″ “CHARSET=utf8″ \
    “SET NAMES latin1″ “SET NAMES utf8″ < m.sql > m2.sql

Ojo, porque el dump creará la bbdd con el mismo nombre en algunos casos, así que comprobar el dump también esto, sobretodo si pensaís cambiar el nombre a la misma. Comprobar si teneís:

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `cambiarestenombrealdedestino` /*!40100 DEFAULT CHARACTER SET utf8 */;

El resto lo podéis encontrar en alguno de los enlaces.

Cabe mencionar también, aunque no viene al caso, que además del cambio de codificación estaba haciendo un upgrade de WP de la version 2.0 a la 2.8.6, por lo que cada vez que probabá, había que hacer un upgrade, cambiar la tabla options para la copia de pruebas, tema, etc… La actualización de versión de WP sorprendentemente sin problema alguno, aunque desactive los plugins la primera vez, con tanto dump se me olvidó al final, pero la copia nueva funcionó sin problemas. Eso si, si no hay tema en la tabla wp_options tal vez tengáis que setear un par de campos a mano con el nombre de alguno de los nuevos, si es que por si mismo, no se setea en “classic”.

No se si me explicado muy bien… pero de haber encontrado estas pistas antes, me hubiera ahorrado al menos un par de horitas de pruebas.

El otro día me volví un poco loco echando a andar un servidor DHCP con dnsmasq en un servidor. El motivo, que el firewall bloqueaba las peticiones a los puertos UDP en cuestión 67 y 68. Si esos puertos están bloqueados las maquinas no podrán consultar el servidor.

Más info en: http://www.faqs.org/docs/iptables/lettingdhcprequests.html ]]>

El otro día me volví un poco loco echando a andar un servidor DHCP con dnsmasq en un servidor. El motivo, que el firewall bloqueaba las peticiones a los puertos UDP en cuestión 67 y 68. Si esos puertos están bloqueados las maquinas no podrán consultar el servidor.

Más info en: http://www.faqs.org/docs/iptables/lettingdhcprequests.html ]]> http://premeditado.com/index.php/2009/07/abriendo-puertos-para-dhcp/feed/ 0