Hace unos días mi amigo asturiano Alejandro me pasó la salida del comando df en la ruta /opt/vyatta/config de su máquina Vyatta ya que veía algo raro que no le cuadraba. Hay que decir que esa máquina Vyatta en ese momento la gestionaban dos personas una por SSH y otra por GUI.
Para el que no lo sepa la ruta /opt/vyatta/config es la ruta que el sistema Vyatta usa para llevar control de los cambios que se van haciendo a la configuración y que se aplican con “commit”. Publico esto porque creo que al final llegamos a conclusiones interesantes que pueden ser útiles a otros.

Esta es la salida del comando df que Alejandro me pasaba por mail:

root@R1:~# df /opt/vyatta/config/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 4128444 1445008 2473724 37% /
tmpfs 3114444 0 3114444 0% /lib/init/rw
udev 3100800 120 3100680 1% /dev
tmpfs 3114444 4 3114440 1% /dev/shm
/dev/xvdb1 41279536 5309564 33873092 14% /var/log
none 3114444 1776 3112668 1% /opt/vyatta/config
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AC02E9C99
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AC02E9C99
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20ACFE2A7C2
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20ACFE2A7C2
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AFD27B2B3
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AFD27B2B3
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AD76544E1



Y a partir de aquí la sucesión de mail que nos fuimos enviando al respecto:

Yo:


La verdad es que no he visto eso antes.
Estas haciendo algo “especial” scripting?
Dame más datos. Qué versión? Cuando pasa? Qué tipo de config estás haciendo?

Cuéntame mas.

Alejandro:



Verás hemos configurado el Vyatta dos personas uno más partidario de ((via consola via ssh, via putty , y creo que vnc usa el citrix )), otro ((via web interface)).
En realidad aparentemente sería lo mismo ¿o no?, no lo se, dudo, el caso es que me imagino que cada vez que hacemos un save config vía web y elegimos el archivo de configuración config.boot, creo que genera una carpeta con la imagen en subcarpetas, probablemente para que exista la posibilidad de restaurar o volver a una config anterior, no lo se …
Seguro que entre los commits realizados por consola y los commit vía web hay algo de “lio” “tomate”, lo más probable es que se resuelva con un reboot, pero…
Cada una de esas carpetas montadas en unionfs son, según yo creo los rastros de estas acciones. 

none 3114444 1776 3112668 1% /opt/vyatta/config
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AC02E9C99
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AC02E9C99
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20ACFE2A7C2
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20ACFE2A7C2
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AFD27B2B3
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AFD27B2B3
unionfs 4128444 1445008 2473724 37% /opt/vyatta/config/tmp/new_config_170DC20AD76544E1



como medida, intentaré que no se realicen mas commits saves vía web, creo que hay algún bug por ahí en la versión que tengo y de ahí que este más seguro usando la consola, es decir via ssh, via putty ,y creo que vnc usa el citrix desde donde accedo via xen center a mi máquina virtual Vyatta…

Respecto a la versión, lo más probable es que estemos algo “viejunos” 

Version: VC6.2-2011.02.09
Description: Vyatta Core 6.2 2011.02.09
Copyright: 2006-2011 Vyatta, Inc.
Built by: autobuild@vyatta.com Built on: Wed Feb 9 20:04:26 UTC 2011
Build ID: 1102092027-7353197
Boot via: disk
Uptime: 13:15:55 up 90 days, 23:13, 1 user, load average: 1.15, 0.89, 0.84
dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied

Yo:

Buenas caballero, te cuento las pruebas.

En cuanto al funcionamiento del CLI y del GUI para la gestión de “commits” no es igual.

Pruebas desde CLI con putty y mirando con WinSCP lo que pasa en /opt/vyatta/config/tmp:

  1. Abro sesión y hasta que no entro en modo configuración no aparece nada en tmp, en cuanto ejecuto comando “configure” aparecen dos carpetas nuevas, “new_config_xxxx” y “tmp_xxxx” siendo xxxx dígitos decimales, si hago cualquier cambio en la config y ejecuto commit las carpetas se actualizan, solo con commit, no con save, con save entiendo que lo que hace es leer esa config temporal y almacenarla de forma persistente en config.boot (no es la config tmp la que se guarda con save si no la config active, ver punto 4)

  2. Salgo del modo configuración con “exit” y desaparecen las carpetas anteriores de tmp. (Habiendo hecho cambios en la config y después commit pero no save)

  3. Con la misma sesion SSH vuelvo a entrar en modo config, aparecen de nuevo en tmp las carpetas anteriores, hago un show y veo que los cambios que hice aún siguen ahí y no se han perdido aunque no haya hecho save antes de salir del modo configuración. Hago “save” y se guarda todo lo modificado correctamente.

  4. Vuelvo a cambiar la config y a hacer commit y esta vez cierro la sesión SSH sin guardar con save. Abro nueva sesión SSH y los cambios que acabo de hacer que no he salvado siguen estando aplicados, esto significa que al hacer commit todo se almacena en la carpeta paralela /opt/vyatta/config/active que mantiene los cambios que se van haciendo con commit.

  5. Abro otra sesión SSH paralela sin cerrar la anterior y entro en configuración, se crear otras dos carpetas “tmp_yyyy” y “new_config_yyyy” los cambios que hago en la config con commit en una u otra sesión se reflejan también en la paralela. Salgo de la nueva sesión SSH sin logout (a lo bruto, cerrando la ventana del putty) y las carpetas referentes a esta sesión yyyy esta vez no desaparecen.

  6. Abro sesión por http, aparece otras dos carpetas nuevas en tmp pero esta vez en vez de 4 dígitos decimales tienen 16 hexadecimales y con la misma estructura que antes “tmp_hhhhhhhhhhhhhhhh” y “new_config_hhhhhhhhhhhhhhhh” cada vez que hago cambios en la config y hago commit las carpetas se actualizan.

  7. Abro sesión http paralela sin cerrar la anterior desde otro equipo pero esta vez no aparecen nuevas carpetas, parece que se usan las anteriores del punto 7. En este caso los cambios que hago a la configuración desde una sesión http no se reflejan en la otra http pero si que se ven desde ssh. Hago un cambio desde http y desde el otro http no lo veo, trato de engañar al sistema haciendo save desde la sesión http que no ve los cambios y desde ssh veo que lo que se almacena es siempre lo que se ha hecho commit, es decir aunque haya salvado desde la sesión http que no veía los nuevos cambios hechos en la otra http, al hacer un save desde esa, lo que se guarda en config.boot son siempre los cambios que se han aplicado con commit (y que han pasado a la config active).

  8. Si dejo que la sesión http caduque las carpetas de tmp pertenecientes a esa sesión no se borran y permanecen en tmp hasta reinicio, esto ocurrirá tantas veces como caduque la sesión.



Entonces, preguntas:

  • Hay algún problema si se gestiona una maquina vyatta desde CLI y desde GUI a la vez por dos usuarios distintos? bueno, depende, el problema no es que la config que uno esté haciendo se pierda si el otro hace save, el problema es que el que administra desde GUI no ve los cambios que hace el otro por lo que se puede llegar a que se hagan configuraciones enfrentadas entre si y esto de lugar a un comportamiento inesperado.

  • Y por qué salen tantas carpetas de sesión http (identificadas con 16 digitos hex) en tmp? mi respuesta es que son sesiones http caducadas, cada vez que caduca la sesión http y se vuelve a entrar por http las anteriores quedan reflejadas, puede ser esto Alejandro? que la sesión http haya caducado varias veces? si crees que no ha caducado tantas veces como carpetas con distinto id tienes en tmp dímelo y seguimos investigando.



Moraleja:

El GUI es una basura!!

Alejandro:



Muchas gracias es exacto si.

Deberé reiniciar el Debian y evitar el administrar dos personas y vía web menos aun.
Son sesiones caducadas y el análisis es de 10, si yo precisase de un equipo de seguridad, contaría contigo sin dudarlo.

Oye muchas gracias.

Un hilo del foro Vyatta al que podrías complementar te lo adjunto:
http://www.vyatta.org/forum/viewtopic.php?t=4320&sid=d51db4a73f5ed46985ae54b08b967a4f

Salud2


Funcionamiento del proceso commit en Vyatta para diferentes usuarios CLI y/o GUI