Translate to

Buscar

22 de febrero de 2011

Resolviendo rsync

rsync es un comando que permite copiar sólo las diferencias de un directorio a otro. Evitando copiar otra vez archivos y directorios que no han cambiado, es útil para hacer más eficiente la sincronización de archivos de un punto a otro de la red. En mi caso, para subir a producción los proyectos que desarrollo en mi computadora local.

Hasta ahora
Lo que venía haciendo era comprimir el directorio, pasarlo por ftp al destino, donde lo descomprimía. En The rsync algorithm: The problem dicen que usualmente eso solamente permite ganar un factor entre 2 y 4.

En Windows
Parte del tiempo la paso en Linux y otra parte (por ahora la mayor) la paso en Windows 7. En Linux, rsync suele estar disponible por default. En Windows, hay que instalarlo. Yo instalé cwrsync, que es libre y provee un comando rsync compatible con el original, para usar en consola.

Luego de instalarlo, revise que la carpeta de cwrsync estuviera en el PATH (Panel de Control, Sistema y seguridad, Sistema, Configuración avanzada del sistema, Variables de entorno, Variables del sistema, PATH). Tuve que hacerlo manualmente.

Problema con Git
Puede ser que, al usar rsync le aparezca un mensaje de error como este:

rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(601) [Receive
r=3.0.7]

Tardé varias horas en encontrar aquí que podía deberse a que Git provee una versión de un ejecutable que cwrsync está tomando en lugar del que debería ser. Para solucionarlo, basta con ir al PATH y colocar al directorio de Git después del directorio de cwrsync. Por ejemplo, en mi caso:

Antes:
C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;%JAVA_HOME%\bin;C:\bin\dev\xampp\php;C:\bin\system\gnuwin;C:\bin\dev\drush;C:\Program Files (x86)\Graphics\Graphviz2.26.3\bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Python26;C:\Program Files (x86)\Dev\Git\cmd;C:\Program Files (x86)\Dev\Git\bin;C:\Program Files (x86)\cwRsync\bin

Después:
C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;%JAVA_HOME%\bin;C:\bin\dev\xampp\php;C:\bin\system\gnuwin;C:\bin\dev\drush;C:\Program Files (x86)\Graphics\Graphviz2.26.3\bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Python26;C:\Program Files (x86)\cwRsync\bin;C:\Program Files (x86)\Dev\Git\cmd;C:\Program Files (x86)\Dev\Git\bin

Sin embargo, ahora es Git el que muestra un mensaje de error cuando se ejecuta (aunque, al parecer, realiza bien la acción de todos modos).

Formato de parámetro incorrecto: activa:

Bueno, al menos sabemos la causa y se puede hacer que el PATH sea el adecuado ara git en una consola, y para rsync en otra. Por el momento, hasta hallar una mejor solución a esto.

Probando localmente
Personalmente, puede ser difícil encontrar ejemplos simples que nos ayuden a empezar con rsync. Después de andar medio perdido en el tema, me encaminó este artículo.

Una prueba sencilla es:

rsync -a origen destino

Esto copia el directorio origen dentro de destino.

rsync -a origen/. destino

Esto copia el contenido del directorio origen dentro de destino.

-a es la forma simple de -rlptgoD (no -H) y se supone que funciona bien para el caso usual, que es el de hacer backups de origen en destino.

Hay varias opciones disponibles para el comando.
Se recomienda usar -v para el verbose (más información de lo que está haciendo el comando, se puede colocar -v, -vv, -vvv, etc, según cuánto detalle se desea).
--delete permite que se eliminen del destino aquellas cosas que ya no están en el origen. Usarlo con cautela.

Algo que noté con --delete es que no es lo mismo hacer

rsync --delete -a origen/* destino

que

rsync --delete -a origen/. destino

En el primer caso, usando *, no se produce la eliminación. En el segundo caso, usando ., sí funciona como se espera.

Destino remoto
Lo que deseo es copiar un directorio a un servidor remoto.

Esto se puede hacer con:

rsync -a origen/. username@hostname:path/destino

rsync intentará hacer la copia usando SSH, pidiendo la contraseña.

Hay un modo de configurar ssh para que la autentificación la haga con llaves, pero no he logrado que me funcione hasta el momento.

Algunas opciones recomendadas para el comando usado para copias remotas es:
--progress, que permite ver el avance de la operación
-z, que permite usar un viaje comprimido de lo que se copia
-e ssh, que permite indicar explícitamente que se usa ssh

De ese modo, el comando para sincronizar dos directorios (incluyendo eliminaciones) se vuelve algo como:

rsync --progress --delete -avze ssh origen/. username@hostname:path/destino

Siguientes pasos
  • Que ssh use llaves, para no tener que estar digitando la contraseña a cada rato.
  • Usar drush rsync.
Referencias

14 de febrero de 2011

La segunda libertad en Drupal

Hace un tiempo que me llamaba la atención lo que decían: "Drupal es una marca registrada de Dries Buytaert".
Yo tenia entendido que Drupal era software libre, como supongo la mayoria de la gente que asiste a los eventos de difusion. Y no me era usual ver que alguien del software libre se preocupara porque algo debiera ser de su propiedad. Defienden la cuestión de las atribuciones, saber quien hizo que, tanto por reconocimiento como por fines prácticos, pero ser propietario de una marca no es algo que parezca del estilo del software libre.

Hoy, he leido un poco sobre la cuestión de la marca registrada Drupal:
Parece que esa política está vigente desde agosto del 2009. En resumen, es algo así como "nadie más que yo puede ganar dinero con la palabra Drupal o su logo". Pareciera que alguien hubiera convencido a Buytaert que era buena idea tomar una medida así.

El tuvo la idea de Drupal, el nombre (con typo incluido), inició el proyecto y posiblemente por eso a la mayoría de la comunidad no le importa demasiado que se tome esa licencia.

Sin embargo, si lo que se quiere es que Drupal prospere y progrese, quizas hubiera sido mejor dejar simplemente todo libre.

En el mundo del software libre se habla de cuatro libertades:


LibertadDescripción
0Libre de restricciones. La libertad de usar el programa, con cualquier propósito.
1Libre para aprender y adaptar. La libertad de estudiar cómo funciona el programa y modificarlo, adaptándolo a tus necesidades.
2Libre para compartir y copiar. La libertad de distribuir copias del programa, con lo cual puedes ayudar a tu prójimo.
3Libre para trabajar con otros. La libertad de mejorar el programa y hacer públicas esas mejoras a los demás, de modo que toda la comunidad se beneficie.
Estas libertades son importantes porque forman un sistema que permite al software ser libre.

Se supone que todas estas libertades están garantizadas por Drupal también (tiene la licencia GNU-GPL). Pero, si tuviera que elegir de la lista qué libertad es la afectada con Drupal como marca propietaria, ¿cuál elegiria?.

A mí me parece que las restricciones en el uso de la palabra Drupal y su logo afectan su segunda libertad como software libre. El prohibir usar el nombre de algo, o su imagen, afecta sus actividades de difusión. Para entenderlo mejor, imagínese el extremo que Drupal fuera libre pero tuvieramos prohibido pronunciar la palabra Drupal. Tendríamos que decir algo como el que no puede ser nombrado para referirnos a él, con todo el clima raro asociado a esa situación (mortífagos incluidos).

En cambio, puedo tomar la mascota de Linux, Tux, modificarla, copiarla, prestarla, venderla, etc (siempre y cuando no limite el derecho de otros a hacer lo mismo), sin preocuparme de asuntos de licencias. La creatividad puede fluir sin restricciones, sin importar quién gane o deje de ganar dinero.

Con el logo de Drupal puedo hacer lo mismo excepto que, si significa que gane dinero para mí y no para Buytaert, tengo que pedir permiso. En la comunidad, el derecho de Buytaert limita el de otros a hacer lo mismo. Quizás no sea tan importante para otros, pero a mi me parece que, al preocuparse en eso, ha marcado un punto debil en su poder de difusión. (Para mí que fueron sus abogados). Aunque ahora va rápido, es cierto, tal vez podría ser mejor.

Lógicamente, como novicio aprendiz de Drupal, no soy quién para criticar a Buytaert en sus decisiones. Pero, cuántas cosas se han perdido al intentar poseer algo.

13 de febrero de 2011

Resolviendo Filefield Meta y usando Dynamic Field

He definido un tipo de contenido audio, que tiene un campo cck de tipo filefield, para cargar el mp3.

Activé también el módulo filefield meta (requiere instalar el módulo getid3, el cual requiere descargar la biblioteca getid3 aparte), con la intención de poder captar del mp3 la información de género, autor, duración y otros, como había visto que hacía el módulo audio.

Bueno, no encontraba la información que se supone fielfield meta guardaba. Al menos para mí, no resultaba claro dónde se supone que se hallaba.

Quizás sea uno de esos casos donde se supone que es obvio :-)

Felizmente encontré el post Using FileFieldMeta and GetID3 to display duration of audiofiles (mp3) . Lo bueno es que no sólo me indicó el lugar donde se hallaba la información (dicho sea de paso, ¿en qué lugar de la documentación dice que se guarda en $node->field_audiofile[0]?... no me malentienda, me gusta Drupal y agradezco las muchas cosas que compartimos, pero ¿puedo preguntar, no?), también me mostró que había una forma de definir campos dinámicos para un nodo, de una manera más sencilla que vérselas con el sistema de templates.

Se trata de Dynamic Field. Es como un tipo cck que uno puede agregar al nodo y brinda un campo de texto donde uno puede poner php que será ejecutado cada vez que se muestra el nodo. De ese modo, para poner la duración de la canción subida, puedo definir el campo Duration (field_audioduration) de tipo Dynamic Field y conteniendo la siguiente expresión:

$duration = $node->field_audiofile[0]['data']['duration'];
return floor($duration/60).":".($duration%60);

Posiblemente hayan algunos contras en usar Dynamic Field en lugar de la alternativa de los templates. Quizás la cuestión de la performance. O que es php que se guarda en la base de datos y escapa del control de versiones. Pero en los pros, me parece que es una manera muy cómoda de hacerlo. Y, algunas veces queremos más comodidad de desarrollo que performance.

Tal vez, en el futuro, se pueda hacer que definiciones puedan ser hechas de este modo y se reflejen en disco en lugar de la base de datos, y así haya menos contras. Posiblemente eso también le ayude a módulos como Contemplate y CSS Injector.

Referencias:
Nota:
Dynamic Field no guarda los valores en la base de datos. Eso no es problema al presentar un nodo, pero campos así no pueden ser presentados en una vista. Para ese caso, puede usar Computed Field, que se usa de modo similar, pero permite guardar el resultado en la base de datos y asi tener los campos disponibles también para las vistas.

5 de febrero de 2011

Resolviendo Drush 4.2 en Windows 7

Uso Xampp 1.7.1 en Windows 7. Cuando actualicé drush a la versión 4 venía trabajando bien, pero un mensaje de error empezó a aparecer cuando me actualicé a la versión 4.2. De pronto, ya no podía descargar módulos.

Por ejemplo, al intentar descargar views:

C:\bin\dev\xampp171\htdocs\audioplayer2>drush dl views
Drush has significant limitations on Windows. We seek a co-maintainer  [warning]

to remedy them. See http://drupal.org/project/drush for more
information, and for instructions on disabling this warning.
WD php: chdir(): No error (errno 0) in                                   [error]

C:\bin\dev\drush\includes\drush.inc on line 1165.
Source directory c:\windows\temp/drush_tmp_1296925378/views is not       [error]

readable or does not exist.
Project views (6.x-2.12) could not be downloaded to                      [error]

C:/bin/dev/xampp171/htdocs/audioplayer2/sites/all/modules/views.
chdir(): No error (errno 0) in C:\bin\dev\drush\includes\drush.inc on  [warning]

line 1165.

Me pareció que podía haber un problema de acceso a C:\Windows\temp.

Lo que hice fue entrar al explorador de archivos y hacer clic derecho sobre el icono de C:\Windows\temp, Propiedades, Seguridad, e indicar acceso total para esta carpeta. Fue necesario que aceptara la advertencia de que es una operación de nivel de administrador (estaba como usuario administrador).

Luego de eso, drush pudo hacer la descarga.

Más artículos