un blog personal donde anoto cosas... tecnología, viajes, fotos...

Servidores

127.0.0.1 no es “siempre” localhost en MySQL

Peleando con una conexión a MySQL vía un tunel de SSH descubrimos que localhost, aunque resuelva correctamente en el destino a 127.0.0.1 no “es lo mismo” que usar la numeración como dato de conexión.

En clientes que soportan tuneles SSH se establece una conexión via SSH y sobre ella se conecta al servidor MySQL. Eso supone que la conexión a servidor MySQL se hace “desde” el servidor SSH por lo que los datos de conexión no serán servidor.destino.com sino los que usarias localmente desde el propio servidor. Eso afecta también a los permisos del usuario con se conecta entre otros (localhost en lugar de IP remota) y nos permite conectar de manera segura desde distintos orígenes sin tener que crear usuarios adicionales en el servidor de datos.

Pues bien, no está directamente relacionada con  esta entrada en stackoverflow pero leyéndola descubrimos que MySQL establece las conexiones a localhost en este contexto desde el socket (algo así como el archivo de ejecución directo) en lugar del a través del puerto solicitado. Es decir, en este contexto hay que usar 127.0.0.1 como conexión y no localhost en los datos del server MySQL para que funcione

 

marzo 11th, 2013|LAMP, Servidores, Software|0 comentarios

Redimensionando particiones y discos LVM

Los sistemas de particiones LVM se van imponiendo en casi todas las distros del mundo Linux, aunque la realidad es que su soporte, y sobretodo el número de herramientas “amigables” para gestionarlas es muy, muy reducido aún. El sistema LVM divide en capas las particiones física de toda la vida. No es el motivo de este post entrar en detalles, pero básicamente los grupos (VGs) se componen de 1 o n particiones físicas “reales” y sobre estos se construyen las particiones lógicas (LVs) tradicionales sobre las que se crean los sistemas de archivos finales… ext3, ntfs, etc.

Ventajas muchas… poder cambiar tamaño de particiones  “casi” en caliente, emular sistemas RAID, añadir discos y sobretodo su soporte snapshot que permite hacer una “foto” estática del una partición activa a fin de poder copiarla, clonar parte de su contenido, etc. Pero todo a  un precio. Su manejo puede llegar a ser algo complejo desde consola y faltan herramientas “gráficas o amigables” para gestionarlas. A modo de ejemplo, la gran mayoría de software de gestión y clonado de particiones no sabrán manipularlas y mostrarán el contenido de un grupo (VG) como una sola partición. Esto limita el clonado, restauración a otro HD o el redimensionado.

Tras darme algunos cabezazos y dado que la documentación no es excesiva y algo compleja, dejo aquí algunos consejos de mi experiencia a la hora de manejarlas, que espero sean de utilidad para otros:

Clonar particiones LVM

Casi ninguna de las herramientas que hemos probado han funcionado del todo bien. Curiosamente el “perenne” Norton Ghost (version 11 msdos creo recordar) es uno de los que mejor reconoce y permite crear imágenes de una partición lógica. También clonezilla parece reconocerlas, aunque ninguno de los dos será capaz de restaurarlas directamente a LVM, sino como particiones normales (léase físicas o lógicas creadas a mano como LVM).

Redimensionar particiones lógicas LVM

No entraré en detalle porque Google está lleno de documentación al respecto, pero el concepto básico importante es que hay que desmontarlas y si es tu sistema el que está bajo una LVM (/), tendrás que hacerlo con un CD Live o de rescate que soporte LVM y a base de a comandos. Algunos de los enlaces de abajo te podrán ayudar.

En todo caso, Webmin nos ha resultado un gran aliado en el manejo de LVM. Salvo algunas excepciones como mover LVs de un disco físico a otro dentro del mismo VG el resto de acciones las maneja muy bien desde su interface web. No es fácil eso si (salvo que te animes a instalarlo en tu propio sistema Live) tenerlo disponible desde un arranque externo (CD o pen drive).

Redimensionar particiones físicas dentro de un VG

En nuestro caso este ha sido siempre el hueso “duro de roer” :  redimensionar una partición del disco que aloja un grupo en LVM2 para poder acomodar otra partición de otro tipo. En teoria (ver enlaces abajo) el proceso consiste en reducir las LVs dentro del VG que alberga dicha unidad. Como ya hemos dicho si una de ellas es el sistema, hay que hacerlo desde un arranque externo. Después se borra la partición y se vuelve a crear en el mismo cilindro desde consola. Ninguna de las herramientas habituales de gestión de particiones te permitirán hacerlo hoy si ésta es LVM.

En mi caso, me pareció una opción aterradora y finalmente encontré una alternativa más simple y cómoda que sin entrar en detalles consiste a groso modo en:

  • reducir al tamaño objetivo cada una de las particiones lógicas del grupo (LV).
  • añades un HD al equipo con suficiente espacio y con una partición del tamaño final que buscabas reducir y que pueda albergar cuantas LVs necesites del paso anterior
  • añades dicha partición al grupo (VG)
  • mueves tus particiones lógicas a este nuevo disco del grupo. Una joya aquí me resultó el paquete “system-config-lvm” que incluyen por ejemplo debian o CentOS. Deberías poder volcar un live a un pendrive y añadirlo. Yo aún no he encontrado ninguna distribución de rescate que lo incluya. Además permite crear unidades lógicas, añadir y quitar part. físicas, etc

De gran utilidad me resultó en este caso, aprender a instalar un Live Debian 6 en un pen-drive de forma “persistente”. Resulta que si en el mismo pendrive se ubica un partición con la etiqueta “live-rw” el sistema es capaz de escribir los cambios y paquetes adicionales allí. Esto me ha permitido montar mi disco de rescate con un webmin operativo y las utilidades gráficas de LVM mencionadas: system-config-lvm, aunque he tenido que ejecutarlas desde consola (para ello tendrás que cambiar lo primero el password de root en el terminal del live (sudo passwd root)) porque la opción del menú gráfico no arrancaba. Si me funcionó directamente sobre el live de CentOS, aunque en este caso no fuimos capaces de convertir la instalación en “persistent”.

Dejo algunos enlaces que me han resultado de utilidad:

 

octubre 19th, 2011|How to, Servidores, Software|0 comentarios

Apoyando la campaña para “salvar MySQL”

Habría habido una alternativa pero la realidad es que internet no sería lo que es, si no existiera MySQL, el motor de base de datos de código abierto por excelencia que soportan la gran mayoría de aplicaciones, blogs y CMS en casi cualquier lenguaje.

Si cuando Sun la adquirió hace algunos años muchos temieron los cambios que se podían avecinar, ahora que el gigante Oracle ha comprado a Sun, el temor es aún mayor pues el olor a monopolio es alto y dependerá sólo de la buena fe de Oracle el mantener la evolución del proyecto.

En lanzan una petición a la Union Europea para que estudie el caso a nivel de competencia, entre otras iniciativas.

enero 13th, 2010|LAMP|0 comentarios

Pasando tablas de latin1 a UTF8

En general para cualquier aplicación, pero en particular para WordPress, suele ser un lío el convertir una tabla antigua que solía estar en Latin1 a un formato más versátil sobretodo para el castellano, como UTF-8. Detallo mi experiencia con una de WordPress por si resulta útil a alguien.

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 , 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é 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.

diciembre 21st, 2009|LAMP|0 comentarios

Abriendo puertos para DHCP

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.

julio 2nd, 2009|Firewall|0 comentarios