Como cambiar de branch o tags codigo subversioneado en producción

Este es un ejemplo de cómo se podría mantener un desarrollo en producción usando releases para mantener el código en producción.

Creamos el repostorio y los directorios necesarios para el trunk y tags
[shell]cd /tmp

svnadmin create repo
svn mkdir –parents file:///tmp/repo/trunk/src -m” trunk dir”
svn mkdir –parents file:///tmp/repo/tags/ -m “tags dir”[/shell]
Creamos el directorio donde irá el proyecto y el fichero de muestra
[shell]mkdir source
cd source
echo “Hola mundo” > demo.txt[/shell]
Importamos el fichero a repo en trunk/src por que es ahí donde debe meterse el código freso
[shell]svn import demo.txt file:///tmp/repo/trunk/src/demo.txt -m “first import”[/shell]
Ahora vamos crear el directorio donde estaremos desarrollando : devel
Además descargamos el código y se genera la estructura de ficheros de subversion para el control del código
[shell]svn co file:///tmp/repo/trunk/src/ /tmp/devel[/shell]
Lo pongo aquí pero puede hacerse en cualquier momento, generamos la version 1.0 , y la metemos en tags. Será una copia de trunk a tags
[shell]svn copy file:///tmp/repo/trunk/src file:///tmp/repo/tags/demo-1.0 -m “tag v 1.0″[/shell]
Ahora que estamos trabajando con código subversioneado, hacemos cambios para que sea la nueva versión.
Modificamos el texto a inglés y comiteamos
[shell]cd /tmp/devel
# cambiamos demo.txt
echo “Hello everybody” > demo.txt
svn commit -m “demo update”[/shell]
Y generamos la version 2.0
[shell]svn copy file:///tmp/repo/trunk/src file:///tmp/repo/tags/demo-2.0 -m “tag v 2.0″[/shell]
Llegados a este punto tenemos :

  • trunk/src -> con la version más reciente
  • tags/demo-1.0 con la primera version
  • tags/demo-2.0 con la segunda version

Simulamos produccion descargano el codigo de la version 1.0 en pro
[shell]
svn co file:///tmp/repo/tags/demo-1.0/ /tmp/pro
[/shell]

Ya tenemos codigo en produccion, ahora hay que apuntar a otro tag
con este cambio hacemos que el reposotrio sea el que indiquemos para es directorio
[shell]
svn switch file:///tmp/repo/tags/demo-2.0 /tmp/pro
cat /tmp/pro/demo.txt
Hello everybody
[/shell]

Probamos a volver a version 1
[shell]
svn switch file:///tmp/repo/tags/demo-1.0 /tmp/pro
cat /tmp/pro/demo.txt
Hola mundo
[/shell]

Y veremos el contenido actualizado, pudiendo cambiar entre la version 1 o la 2

[DSA-2560-1] Fallo de seguridad en Bind DNS server

En los boletines de seguridad  de Debian se ha publicado la noticia del fallo de seguridad que afecta al servicio DNS bind así como el paquete actualizado que corrige el fallo DSA-2560-1.

Es importante conocer que el fallo provoca que se detenga el servicio de DNS ( Denial of service ). Según se indica de forma escueta,el servicio falla al intentar construir un paquete de respuesta cuando hay una combinación específica de registros DNS. Este caso afecta tanto a servidores autoritativos como recursivos.

It was discovered that BIND, a DNS server, hangs while constructing the additional section of a DNS reply, when certain combinations of resource records are present. This vulnerability affects both recursive and authoritative servers.

Error migration Plesk 11 : Failed to execute scout.

Parallels Plesk Panel 11 migration error

Esta mañana migrando unos dominios a un servidor con Plesk 11 ( de Axarnet estamos probando este proveedor ) nos ha saltado un TOTAL FAIL ! migrando los dominios. El error es este :

 

 

 

 

= STDERR ====================
Failed to execute scout.
The return code is 9
The output on STDERR is
Unable to determine block size in df output. First line looks like ‘S.ficheros Bloques de 512 Usado Libre Ocupado Montado en
‘ at – line 560.

Nos parece tristísimo que a estas alturas, un software con la trayectoria de Plesk cometa estos fallos de principiante. ¿ De que hablamos ? De que la máquina de origen tiene el idioma por defecto como es_ES.UTF-8. Por eso cuando laza un df -h para ver si hay espacio salta el error en castellano…

Como somos perros viejos y no nos las sabemos todas, pero sí algunas, hemos ido directamente a cambiar el idioma en el servidor de origen a ver si cuela. Es una ubuntu así que lo hemos así :

vps:~# update-locale LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=POSIX
vps:~# locale-gen
Generating locales...
  en_US.UTF-8... up-to-date
  es_ES.UTF-8... up-to-date
Generation complete.

y ha funcionado perfectamente. A título personal, no está de más que en los scripts que lanza el agente migrador de plesk incluyan algo como:

export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Como siempre Plesk, sigue decepcionando… en estos pequeños detalles. Esperemos que no aparezcan SQLi’s que nos dejen en bastante mala posición a los usuarios.