SSH- Could not open a connection to your authentication agent

Este mensaje de error aparece cuando se hace ssh-agent  y luego ssh-add.

se soluciona mediante la exportacion a nivel de sesion X siguiente:

en .xinitrc  eval `ssh-agent -s`

Para más info puedes consular mi otro post en referencia a OpenBox y ssh-agent.
http://ferranserafini.blogspot.com/2010/08/openbox-sesiones-ssh-ssh-agent-ssh-add.html

XenServer Pyhton phaser

Phaser python para extraer info de servidores XenServer mediante la api XenApi.py
#!/usr/bin/env python import sys, time import XenAPI def read_os_name(vm): vgm = session.xenapi.VM.get_guest_metrics(vm) try: os = session.xenapi.VM_guest_metrics.get_os_version(vgm) if "name" in os.keys(): return str(os["name"].encode('utf-8')) return None except: return None def main(session): c=0 pool=session.xenapi.pool.get_all()[0] print session.xenapi.pool.get_name_label(pool) for s in session.xenapi.host.get_all(): print "*",session.xenapi.host.get_name_label(s) vms_in_host=session.xenapi.host.get_resident_VMs(s) for vm in vms_in_host: if not session.xenapi.VM.get_is_a_template(vm) and not session.xenapi.VM.get_is_control_domain(vm): nom=session.xenapi.VM.get_name_label(vm) desc=session.xenapi.VM.get_name_description(vm) vmm=session.xenapi.VM.get_guest_metrics(vm) os=read_os_name(vm) print " --" , nom , "->", os, "-->" , desc.encode('utf-8') session.xenapi.session.logout() if __name__ == "__main__": if len(sys.argv) <> 4: print "Usage:" print sys.argv[0], " " sys.exit(1) url = sys.argv[1] username = sys.argv[2] password = sys.argv[3] # First acquire a valid session by logging in: session = XenAPI.Session(url) session.xenapi.login_with_password(username, password) try: main(session) except Exception, e: print str(e) raise

Manual Practico de IPtables

Un gran trabajo.
http://www.pello.info/filez/firewall/iptables.html
1.2 Revision: añadidos los mismos casos pero con DROP por defecto

Esta imagen representa como un paquete recorre las tablas y cadenas del núcleo de netfilter:

Xen Server 5.6 FP1 ebtables? errores trunk VLANs

En los foros de Citrix se comentaba como "Bridge problems with VLANs on second NIC" y la solucion que se planteaba era usar ebtables para bloquear el trafico "tageado" a dicha interface. Hace un tiempo lo puse en este blog.

Resulta que para Xenserver 5.6 FP1 no se puede usar ebtables como en la 5.5 o 5.0 con lo cual hay que buscarse la vida. De momento la única solución que he encontrado es desactivar el brigde xenbr2 (el que me llega el trunk con las vlans) de modo que las interfaces virtuales para cada vlan siguen funcionando. Advierto que aun estoy en fase de pruebas con esto y no se que puede pasar más allá. Solamente puedo decir que de momento en mis maquinas me funciona.

#Sustituye el xenbr2 por el bridge donde llega tu trunk.

/sbin/ifdown xenbr2
/usr/sbin/brctl delbr xenbr2

Para que esto sea permanente se puede poner en /etc/rc.local

Pruebas

• He realizado una prueba, añadir un nueva red en el pool y asignar esta red a una maquina virtual en el dom0 que nos da estos problemas y automaticamente vuelve a el bridge, con lo cual, esta solución no es valida al 100%. Se tendria que volver a bajar el brigde manualmente.

Xen Server 5.6 FP1 Rolling up Update

Después de probar de actualizar diferentes entornos en producción de esta plataforma y basarme en el howto oficial de Citrix para la actualización. Redacto los pasos básicos para actualizar con éxito.

Procedimiento para actualizar un pool con XenServer 5.5/6 a XenServer 5.6FP1
Actualización del Pool Master

1. Identificamos el pool-master. En XenCenter es siempre el primero del pool y además tiene el flag Pool Master=Yes.
2. Migramos todas las maquinas virtuales del master a otro servidor del pool. No ha de quedar ninguna. Si tieneis HA, deshabilitarlo
3. Hacemos un backup la de base de datos: xe pool-dump-database y lo guardamos en un sitio accesible.
4. Apagamos la màquina haciendo un halt. Perderemos el control del pool ya entra en modo "emergencia". Las VM siguen funcionando pero se pierde el control de XenCenter.
5. Ponemos la iso de xenserver 5.6fp1 en la ILO/ILOM/etc.. y arrancamos el setup
6. Hacemos indicamos que sera UPDATE from xenserver xxxx 
7. Una vez finalizada arrancara como master con la nueva versión. Ahora ya es cuestión de ir migrando maquinas hacia el master y actualizar los "slaves" sucesivamente

Actualización de los otros servidores

• El procedimiento es igual que el anterior hay que apagar el servidor y arrancar con el cd de xenserver 5.6fp1 y actualizar, pero en este caso el pool no se pondrá en modo de emergencia y no perderemos el control del pool.

Documentación oficial: https://support.citrix.com/servlet/KbServlet/download/25592-102-649503/installation.pdf 

Mi experiencia en esta actualización es que ha funcionado correctamente en 3 entornos diferentes con más de 4 maquinas por pool, de versión 5.5 a 5.6 FP1 y de 5.6 a 5.6FP1, en entornos Blade IBM/ Servidores IBM series y SunFire 4200

Nagios - Check para los SR XenSERVER

Para los que usamos Nagios, podemos monitorizar que ningún SR se quede sin espacio con el este script instalado en cada uno de los domain0 o si prefieres solo en uno. 

Como la información es leída del pool da igual. Lo único que si lo pones solo en uno, simplemente te saltará la altera como si el error fuera de ese dom0 en concreto. Para gustos los colores. Por cierto veras que esta muuuy inacabado, he reutilizado código y cambios sobre la marcha, pero funciona :D 

Como siempre, disponible desde mi cuenta de github: https://github.com/fsmsystems/stuff/blob/master/check_nagios_xenserver_sr/check_xe-sr_size.sh