open source

27 entradas

el video de la ponencia

Ayer me di cuenta de que, por fin, la gente de la DebConf9 había terminado de editar los videos y los había subido a la web, incluyendo la presentación que yo llevé a cabo: Adaptación de Debian a un entorno corporativo. ¡Y estaba hasta contento! La espera había terminado y, finalmente, tendría la oportunidad de ver cómo había salido del trance.

Admito que mi primera idea fue guardar una copia del video pero, bastaron tres minutos viendo mi puesta en escena para que se me quitasen las ganas. De hecho, hasta estuve a punto de no decir ni mú para evitar las risas. Me veo nervioso, torpe y acartonado. ¡Hasta creía que me habían doblado la voz!

En fin, que dejo el enlace a los videos (calidad alta, calidad baja) por sugerencia de mi señora madre, que no pierde ocasión de ver a su pipiolo en acción.

briconsejo: cómo migrar de wordpress 2.0.1 a 2.8.4 en nueve cómodos pasos

Nota: mamá, en serio, ésta entrada puedes saltártela, va del programa con que funciona este blog y, de verdad, es un tanto aburrida. Te dejo un enlace, que seguro que te gustará más. Besos.

Aviso: todo lo que se cuenta en esta chuleta se ha probado, primero, en un entorno de pruebas. Si eres tan estúpido (no, no tiene otro nombre), como para hacer pruebas sobre un servidor en producción, no vengas llorando por aquí. Para la realización de esta migración, es necesario contar con unos conocimientos previos adquiridos, a saber: sentido común, algo de SGBD, un poco de sed, vim y bash y una pizca de coherencia. De nuevo, si no cumples con esto, no vengas a lamentarte.

Esta entrada no deja de ser una lista ordenada de todos los pasos que me llevaron a conseguir el objetivo final. Me funcionó a mí, cierto, y lo escribo por si vuelvo a necesitarlo. Declino cualquier problema o responsabilidad que la aplicación de dichos procesos pueda ocasionar en blogs ajenos. Por si a alguien le interesa, me llevé por delante una docena de veces el blog, antes de conseguir dar con la tecla.

Advertidos estáis.

Hace unas pocas semanas me enfrenté a un desafío que llevaba tiempo esquivando por falta de ideas para abordarlo. Tenía que actualizar el CMS de La curuxa, un Wordpress añejo y, según la documentación oficial, iba a tener que migrar de 2.0.1 a 2.2, luego a 2.4, más tarde a 2.6 y, finalmente, a 2.8. Todo un planazo.

Dicen que la ignorancia es atrevida hasta límites insospechados y, quizá por eso, me propuse explorar nuevas vías. En vez de realizar las recursivas actualizaciones y [ironia=on]mis vastos conocimientos en bases de datos[ironia=off], quise ver qué pasaba cuando utilizas la última versión de WP con una versión de su base de datos antediluviana. El resultado, más o menos esperado, es que WP exigía que se ejecutase el script de actualización y que, a continuación, el blog estaba completo y actualizado, pero con caracteres raros.

«ÿsto va a ser de la base de datos», me dije. Y fisgando en su estructura me encontré con que la codificación de la misma era latin1, mientras que WP sólo hablaba utf8. Así que, los caracteres raros eran problemas de traducción. Para solucionarlo se me pasó por la cabeza usar una compleja pero eficaz sentencia en SQL pero, dado que mis conocimientos en la materia se quedaron en aquel tren, me pasé a la guerra de guerrillas y los script sucios, chapuzas. Ahí, en ese escenario, doy lo mejor de mí.

Al final, tras docena y media de pruebas y errores, de borrón y cuenta nueva, conseguí dejar la base de datos con la codificación correcta y actualizada a la última versión.

Un poco mejor explicado, paso por paso y ordenado:

  1. hacer un backup de la base de datos de producción, con la codificación de caracteres utf8, ya que es la codificación de WP.
  2. editar el fichero de backup, sustituir el nombre del dominio, en mi caso http://lacuruxa.org y http://www.lacuruxa.org, por una dirección local. Yo utilicé http://curu.n1mh.org y lo sustituí con dos comandos de sed:

    sed -i 's/http:\/\/lacuruxa.org/http:\/\/curu.n1mh.org/g' fichero.sql
    sed -i 's/http:\/\/www.lacuruxa.org/http:\/\/curu.n1mh.org/g' fichero.sql

  3. instalar el nuevo WP en la dirección local creada a tal efecto. Después, sobreescribir la base de datos con la obtenida de producción. Abrir la zona de administración en el navegador (http://curu.n1mh.org/wp-admin/) y, ante la petición de actualización, actualizar. Los caracteres extraños inundan el blog. Ante todo, tranquilidad.
  4. editar con vim el fichero de la base de datos, buscando el caracter ÿ y sustituir todos los posibles caracteres raros. En mi caso y usando vim, busqué y sustituí los siguientes:

    :%s/ÿ¡/á/g
    :%s/ÿ©/é/g
    :%s/ÿ­/í/g
    :%s/ÿ³/ó/g
    :%s/ÿº/ú/g
    :%s/ÿ±/ñ/g
    :%s/ÿ<91>/ÿ/g
    :%s/ÿ¼/û/g
    :%s/¿/ÿ¿/g
    :%s/¡/ÿ¡/g
    :%s/«/ÿ«/g
    :%s/»/ÿ»/g

  5. el resto de caracteres raros, que los hay, comienzan por el caracter ÿ y es conveniente buscarlos y eliminarlos a mano. Para todos aquellos que no se puedan procesar con vim, mi recomendación es buscarlos en el blog, copiarlos y pegarlos en vim, que los sustituirá con gusto. Los más problemáticos fueron â?<9d>, â?Ž<8f> y â?<80>.
  6. sustituir la base de datos de prueba con la nueva base de datos e ir viendo qué caracteres fallan. Es, de largo, la parte más tediosa y mecánica. La importación debe hacerse con la codificación correcta:

    mysql -u root -p mysql_user --default-character-set=utf8 < ~diego/Desktop/fichero.sql

  7. con cada importación de la base de datos, hay que acceder desde el navegador a la zona de administración de WP, http://curu.n1mh.org/wp-admin/, y proceder a actualizarla base de datos.
  8. una vez estemos seguros de que están todos los caracteres correctamente codificados, toca revertir el dominio temporal por el bueno. Hacemos una copia de seguridad de la nueva base de datos en un fichero, lo editamos y ejecutamos:

    sed -i 's/http:\/\/curu.n1mh.org/http:\/\/www.lacuruxa.org/g' fichero.sql

  9. y, por último, sólo hay que subir la nueva versión de WP a la web y actualizar la base de datos de producción.

Fácil, ¿verdad? En realidad es más aparatoso que complicado. A partir del noveno punto, comienza una tarea bastante más árdua y callada, la de escoger un tema, adecuarlo, llenarlo de plugins y configurarlo. Pero eso, querido lector, ya es otro cuento.

El resultado, bien visible, se puede ver en la página web de la Agrupación Deportiva La Curuxa.

mesa de tranferencias en software libre

Cómo último acto antes de emprender viaje de fin de semana a Gijón, asistí a la Mesa de Transferencias en Software Libre, en donde mario habló de SESLinEx. Fue un acto bastante interesante donde, además de mario también habló José Luis Redrejo, responsable de gnuLinex, Felipe Pablos Lunas del portal virtual de la Uex y Javi Vázquez, fundador de iGalia, empresa atípica gallega dedicada al software libre.

Tal y cómo se comentaba al principio en los pasillos, poner un evento de estas características durante el horario lectivo de un viernes, en la universidad, es poco menos que condenarlo al olvido, tal y como finalmente sucedió. Durante la primera ponencia todavía había unas cuantas personas haciendo de público pero, al terminar ésta se fueron, dejándonos a los de siempre y convirtiendo el acto en una reunión de colegas.

De las ponencias resaltaría las pares, la de José Luis Redrejo y la de Javi Vázquez. La primera porque hizo una comparación muy interesante entre la primera versión de gnuLinex y la última, los cambios que habían hecho y el feedback con los usuarios. De la segunda, el modelo de negocio, atípico y acertado (desde mi punto de vista) y las motivaciones que puede llevar a una empresa a apostar por software libre.

Más información en: la web de Fundecyt, regiondigital.com e igalia.

mesa de transferencias en software libre, software libre, fundecyt, igalia, gnulinex, seslinex