Estamos migrando la casa. Comparto servidor con un colega. Teníamos un VPS que hasta no hace mucho cubría nuestras necesidades pero que poco a poco se ha ido quedando corto así que nos decidimos por un dedicado.
Lo hemos configurado con una Ubuntu Server 10.04 LTS 64bit con un panel Plesk 10.
Podíamos elegir entre Cpanel y Plesk y de hecho dudamos pero el anterior servidor tenía un Plesk 8, el cual no me resultaba incómodo, y además nos aseguraba la compatibilidad… y efectivamente ha sido una buena elección.
El Plesk 10 modifica un poco la forma en que refleja los planes de alojamiento en el sistema de ficheros pero aún sigue la linea de su predecesor, lo cual tiene sus ventajas.
Para probar el rendimiento del nuevo servidor he movido un subdominio, pongamos test.example.com, de una tienda virtual, en concreto un Prestashop, que utilizo para que el cliente valide los cambios de desarrollo antes de subirlos a producción.
El dominio principal (example.com) sigue alojado en el servidor anterior pero modificando, desde la gestión de DNSs del mismo Plesk 8, la IP del registro A que se corresponde con el subdominio ya lo tenemos apuntando al nuevo servidor. Claro está, ahora hay que decirle al nuevo servidor que albergue ese subdominio (test.example.com) y la forma más rápida es creando un plan de alojamiento para el dominio (example.com) y creando dentro el subdominio (test.example.com).
Efectivamente el dominio example.com sigue alojado en el servidor anterior y así lo indican los DNS pero el subdominio test.example.com ya responde en el nuevo servidor, y lo que es mejor, si utilizas los mismos nombres de usuario FTP al crear los planes de alojamiento, te encuentras con que eso tiene ventajas a la hora de planear una migración. Ahora se verá.
El siguiente paso era importar el proyecto. Trabajo habitualmente con un repositorio, en concreto Subversion, y una opción pudiera haber sido descargar el código desde el mismo repositorio pero algunos ficheros, como imágenes de productos, adjuntos, etc… no se encuentran incorporados en el repositorio y por otro lado hacer un checkout no respeta los permisos de acceso a los ficheros.
La solución pasa por una sincronización con rsync aprovechándonos, como ya he comentado, del hecho de que Plesk está recreando los mismos identificadores de usuarios (UID) y de grupos (GID), como es el caso de los grupos psacln y psaserv.
Para sincronizar utilizo el rsync y le pido que replique el contenido del servidor origen, donde albergaba anteriormente el proyecto en test.example.com, al servidor destino
origen: example.com:/var/www/vhosts/example.com/subdomains/test/httpdocs/
destino: /var/www/vhosts/example.com/subdomains/test/
En concreto el comando es
rsync -r -a -v -e “ssh -l root” –delete example.com:/var/www/vhosts/example.com/subdomains/test/httpdocs/ /var/www/vhosts/example.com/subdomains/test/
El proyecto, incluida toda la estructura del Subversion, son un par de Gigabytes pero como estamos hablando de conexiones entre servidores os podéis imaginar lo rápido que va.
[ Huelga decir que para poder lanzar rsync hace falta tener acceso al shell como root y el servicio SSH accesible en ambas. ]
Sea como sea, como el tema iba a llevar un ratito, es hora de aprovechar el hueco tirando de GTD, que como está muy de moda no sé si se hace necesario explicar, pero que aprovecho para comentarlo.
Se trata de una metodología para mejorar la productividad. Como dice un compañero que se dedica a esto profesionalmente, más que un recetario de trucos para ser productivo, se trata de una receta completa (y compleja) que seguida con esmero consigue que seas más productivo en tu vida. Y cuando digo vida, lo abarco todo, no solo la parte profesional, lo que en mi caso hacía más atractivo aún el tema.
Bien, el caso es una de las que cosas que puedes hacer, de forma más óptima, cuando practicas GTD, es a aprovechar mejor los huecos. Así que mientras rsync hacía su trabajo he aprovechado para hacer un par de tareas de 5 minutos, que he identificado rápidamente, ya que lo tengo todo centralizado en rememberthemilk. Un gran servicio, que muy a mi pesar no cubre todas los requisitos para implementar GTD al 100%.
Una vez acabada la sincronización tenía el subdominio ya funcionando en el nuevo servidor pero como nunca las cosas son perfectas aparecían los detalles, que por otro lado ya estaban previstos.
El anterior servidor era un CentOS y el nuevo un Ubuntu. CentOS utiliza el usuario y grupo apache para el servicio Apache mientras que Ubuntu utiliza el usuario y grupo www-data. Con esto, después de la migración, en el nuevo servidor algunos ficheros, cuyo propietario o grupo eran apache en origen, habían sido ‘traducidos’ por el servidor destino como usuario y grupo 48, el uid y gid del usuario apache en origen.
Para arreglarlo necesitamos identificar (find) todos los ficheros con esa anomalía y modificar su usuario y grupo (chown). Sospechando que podía darse el caso de que algunos ficheros tuvieran el usuario 48 pero no el grupo 48 y viceversa. Dividí la corrección en dos comandos, uno que modificaba el usuario por un lado y otro que hacía lo propio con el grupo.
find . -user 48 -exec chown www-data {} \;
find . -group 48 -exec chown :www-data {} \;
Migración finalizada 
….
Pero antes de despedirme aprovecho para añadir que es obvio que este proceso puede aplicarse, al menos a grosso modo, en cualquier tipo de paquete web, léase Prestashop, WordPress, Drupal, Joomla, etc…
