MarioDebian, mi devlog

Bitácora de un desarrollador newbie.

TcosMonitor, 0.0.4
Poquito a poco (o mucho a mucho) he empezado a hackear el interfaz y las tripas de TcosMonitor y sobre todo de la parte del servidor tcosxmlrpc (que se ejecuta en el terminal), hacía bastante que no programaba en C por lo que cada vez que uso punteros y demás me salen sarpullidos :(, pero he conseguido que compile sin warnings, incluso con los flags: -ansi -pedantic

Después de algún consejo sobre el anterior artículo he cambiado algunas cosas, así ahora para ejecutar aplicaciones sobre el terminal por medio de XML-RPC se necesita usuario y contraseña, la manera de hacerlo de momento es un poco chapuza, hago una petición de login con un usuario y contraseña y creo un archivo temporal que se borrará en la siguiente petición a una función que necesite login, las funciones que devuelven información (que ahora son bastantes) no necesitan login.

He estado en la escuela y he probado TcosMonitor en idefix (servidor de 24 terminales y bastantes cosas más), casi no había terminales conectados (el aula magna está para exámenes estas fechas), así que he probado con un terminal desde el despacho (que tiene una VPN al aula magna), esta es la captura:



Esta vez los datos son REALES, es decir hay 5 máquinas conectadas al puerto 6000 del servidor, tres de las cuales están dentro del escritorio y dos (las que pone unknow) en el gestor de login (GDM) .

La máquina del despacho es magna25 que como se puede ver al seleccionarla en la lista y por medio de peticiones xml-rpc obtiene toda la información que el programa la pide.

El número de procesos se obtiene con un simple «ps aux|grep ^usuario» y el tiempo logeado restando de la fecha actual la fecha del último login a traves del comando «last»

Me falta mejorar un poco el aspecto de la aplicación y meter dentro de una tabla los datos para que queden un poco más chulos ¿como se mete una tabla dentro de un textview?



Hace un año: Actualizaciones

TcosMonitor, herramienta para monitorizar redes de clientes ligeros
Muchos de los que visitais mi blog ya conoceis de la existencia de iTALC, una aplicación «Gran Hermano» para monitorizar redes mediante el protocolo RFB/VNC.

Esta herramienta está muy muy bien, pero tiene ciertas carencias:
  • No es capaz de obtener información del sistema operativo destino.
  • NO fue diseñada para redes PXES/LTSP/TCOS. (aunque con un parche es posible al 50%)
  • Consume una cantidad enorme de ancho de banda y cpu (probado con 24 terminales).
  • No es personalizable (al menos sin tener un buen nivel de C++)
  • El desarrollador parece haber abandonado/dejado de lado el proyecto (las actualizaciones del CVS tienen varios meses)
Con todo esto encima de la mesa y entre examen y examen me he puesto a desarrollar una heramienta para monitorizar e iteraccionar con el cliente ligero (la teoría suena bastante bien)

La idea consiste en lo siguiente, el terminal es un pc normal y corriente en el que se pueden ejecutar aplicaciones bajo demanda (bastante pocas), como puede ser reiniciar, apagar, mostrar uso de memoria, reiniciar entorno gráfico, bloquear pantalla, etc... iTALC puede hacer muchas de estas cosas pero para ello debemos tener abierta una conexión RFB permanente.

TcosMonitor consiste en dos pequeñas aplicaciones (con sus scripts «hooks-addons» lanzadores) que hacen dos servidores, un servidor httpd que ya viene incluido en busybox, y un nuevo servidor tcosxmlrpc que he programado yo en C (xmlrpc-c).

Con la coletilla XML-RPC ya os podeis imaginar por donde van los tiros, es sencillamente genial, una aplicación cliente python (con 3 líneas sobra) se conecta con el servidor y le pasa los parámetros que necesitemos a un método del servidor, tcoxmlrpc los procesa y devuelve un resultado (en caso de devolver algo).

Por ejemplo, cosas que ya tengo programadas, hay una clase en tcosxmlrpc que se llama tcos.exe que recibe como parámetro un string con el nombre de la aplicación a ejecutar (o la órden entera de la línea de comandos), la guarda en un archivo en el terminal y otra aplicación lee esa «cola de tareas» para ir procesándola de una en una. Ejemplo simple:

#!/usr/bin/env python
import xmlrpclib

server = xmlrpclib.Server("http://192.168.0.101:8080/RPC2")
result = server.tcos.exe("killall Xorg ; startremotex")

Como veis con el import son 3 líneas para decirle al terminal que se reinicien las X. Esta parte de código se ejecuta desde el equipo que usemos como monitor del aula (normalmente el servidor de terminales)

En el terminal hay corriendo un servidor XML-RPC (basado en abyss) que ejecuta lo siguiente:

static xmlrpc_value *
tcos_exe(xmlrpc_env *env, xmlrpc_value *in, void *ud)
{
char *s;
size_t *len;

xmlrpc_parse_value(env, in, "(s#)", &s, &len);
if (env->fault_occurred)
return xmlrpc_build_value(env, "s", "params error");;

job_exe(s);

return xmlrpc_build_value(env, "s", s);
}

[...]

void job_exe( char *cmd )
{
FILE *fp;
char job[200];
sprintf(&job, "echo "%s" >> %s", cmd, JOB_FILE);
fp=popen(job, "r");
}


Esto es parte de tcosxmlrpc.c que recibe como parámetro un string y se lo pasa a la funcion job_exe para que escriba en el archivo de colas de procesos una nueva entrada. La explicación de hacer esta chapuza es que en la mayoría de los casos quiero que la petición corra en segundo plano y ni con system() ni con popen() ni con fork() lo he sabido hacer, y mira que he probado cosas....

Ejemplo de funcionamiento:

Salida de un client.py de ejemplo:

Exec return=startlocalx
time to get exec 0.022885

PYTHON::Evolution status is=1
PYTHON::time to get status 0.064822

PYTHON::Apache2 status is=1
PYTHON::time to get status 0.079125

PYTHON::app-no-runnning status is=0
PYTHON::time to get status 0.071517

PYTHON::update_system_info status is=[1]
PYTHON::time to get status 0.034349

PYTHON::version is=['0.0.2']
PYTHON::time to get version 0.006734


Salida de depuración de tcosxmlrpc:

tcosxmlrpc::tcos_exe() Init
tcosxmlrpc::tcos_exe s="startlocalx"
xmlrpc::job_exe() exec=> "echo "startlocalx" >> /tmp/tcosxmlrpc.dat"
tcosxmlrpc::tcos_status() Init
tcosxmlrpc::tcos_status() pidof evolution
tcosxmlrpc::tcos_status() exec cmd="pidof evolution| grep [1234567890] | wc -l"
tcosxmlrpc::tcos_status() reading from fp pointer
tcosxmlrpc::tcos_status() ret value=1
tcosxmlrpc::tcos_status() Init
tcosxmlrpc::tcos_status() pidof apache2
tcosxmlrpc::tcos_status() exec cmd="pidof apache2| grep [1234567890] | wc -l"
tcosxmlrpc::tcos_status() reading from fp pointer
tcosxmlrpc::tcos_status() ret value=1
tcosxmlrpc::tcos_status() Init
tcosxmlrpc::tcos_status() pidof app-no-runnning
tcosxmlrpc::tcos_status() exec cmd="pidof app-no-runnning| grep [1234567890] | wc -l"
tcosxmlrpc::tcos_status() reading from fp pointer
tcosxmlrpc::tcos_status() ret value=0
tcosxmlrpc::update_system_info() job=webserver.sh update
xmlrpc::job_exe() exec=> "echo "webserver.sh update" >> /tmp/tcosxmlrpc.dat"
tcosxmlrpc::tcos_version() 0.0.2
Estas pruebas estan hechas en local, es decir, arrancando el servidor y el cliente en la misma máquina de ahí que los tiempos sean mínimos, cuando las máquinas son distintas apenas ningún proceso supera los 0,5 segundos...

Todo esto está muy bien pero resulta que hay que ponerlo de alguna manera que sea sencillo de manejar, y que mejor que hacer un GUI en pygtk???
¿he dicho alguna vez que python mola?

He aquí una captura de lo puede llegar a ser TcosMonitor (la interfaz aún no funciona y los datos que aparecen son simulados)

TcosMOnitor screenshot (mockup)

La parte inferior es para mostrar información y acciones del terminal (cpu, ram, swap, particiones, procesos, versión de tcos, personalizar imagen de arranque de tcos, abrir una sessión VNC o iTALC con el cliente, posiblemente una captura de pantalla del terminal en el momento que se genere, y lo que se me vaya ocurriendo)

Se me ocurre que puede ser una aplicación killer-app para aquellos ciber-café que funcionen como thin clients....




El mundial de futbol por consola (software libre 100%)
Mucha gente se queja que el sopcast (versión de linux) ha dejado de funcionar o no se ve en determinados canales....

Esta mañana mientras leía el planet debian he descubierto algo bastante gracioso y que me ha recordado a La Guerra de las Galaxias en ASCII.

Ver los partidos del mundial por telnet:

Tan sencillo como:

$ telnet ascii-wm.net 2006

En estos momentos está saturado, hay dos mirror más:

$ telnet diego.ascii-wm.net 2006 
$ telnet pinguin.eikon2.fs.ei.tum.de 2006
Más info en la web oficial ASCII-WM 2006. Captura de pantalla. Por lo visto trasnsmiten con 10 minutos de retraso...




MIcrosoft y el software libre, futuro poco prometedor.
Antes de seguir leyendo, AVISO, este post puede producir daños irreparables en tu conciencia de usuario de software libre.

Depués de ver esta noticia en meneame, he gastado malgastado casi 20 minutos viendo las novedades en un flash muy bien trabajado de Windows Vista y de Office 2007.

Hace un tiempo tenía pensado que era Microsoft el que plagiaba cosas, pero me doy cuenta que mucho del software libre esta a años luz del monopolio de Microsoft. Actualmente más del 80% de los equipos informáticos que hay en el mundo necesitan sólo tres sencillas cosas:

  • Un sistema operativo estable y seguro ( aquí a Microsoft todavía le falta algo....)
  • Un paquete ofimático sencillo y potente ( el Office 2.007 parece que lo es )
  • Un entorno de trabajo compartido ( share point es una buena opción ¿qué hay en linux? ¿svn? ¿phpgroupware? )
Si nos miramos el ombligo (usuarios de software libre) vemos que en algunas de estas cosas las mejoramos pero no podemos atender a las necesidades de "el gran público" ya que los paquetes ofimáticos libres son bastante pobres. Si, para que negarlo, no está muy bien que Openoffice.org sea un mastodonte dependiente de java (no libre, y ya se que funciona con el java libre también) o que nos dediquemos a cosas como Xgl o Compiz que dependen estrechamente de software no libre como son los drivers de Nvidia o ATI. Alternativas como AIGLX y uso de drivers libres (sobre todo DRI) son merecedoras de más apoyo aunque sean menos potentes.

El momento de la neutralización de escritorios debería acelerarse para de una ver por todas ser un candidato serio de una empresa que siempre ha sido (y si no lo cambiamos) será dueño y señor del software de uso común.

Hay cosas que no siguen haciendo bien, y muchas de ellas se pueden ver en la wikipedia, pero en otras han imitado el comportamiento de aplicaciones Mac o GNU descarádamente, por ejemplo una especie de sudo o el aero o las pestañas del ie, por decir algunas.

Si ellos imitan, ¿por qué no lo podemos hacer nosotros? La idea del Office 2007 y sus pestañas me parece cojonuda, ¿cómo no se le ha ocurrido a alguien antes?, los menús parecen de de prehistoria después de ver el video de Office 2007, OpenOffice.org, Abiword o la suite de KDE (que hace mucho tiempo que no uso) simplemente son de hace 5 años.

Antes de que Microsoft o Google acoten el mercado (si, google va en ese camino) el software libre debería mover pieza, y no sólo un peón sino alguna torre o la reina...

No quiero tocar temas económicos, y sí, ya se lo que valen las licencias de los paquetes básicos (o más bien capados) de Windows y Office.

Para todos aquellos asíduos del blog, no os preocupeis, no pienso cambiarme, pero si que lo quiero probar (no se lo digais a nadie pero me estoy descargando la beta).

Ya comentaré algo más cuando lo pruebe.