Edit Maintd: Programa de supervisión desde main1

Title:

Last edited: 7:19:47 pm on 19 January 2010 by salchicha.sico.local

+^_@
_
<tt>Tuesday, 19 January 2010, 7:18:16 pm</tt>
Posibles cambios en el formato de los mensajes Se plantean los siguientes cambios:
- Para el ping (estado) mandar sólo los md5sum de (a) ls lista de símbolos (b) la lista de equipos (c) la lista de estado de los equipos. Mandar también la "oldmd5sum" de las tres tablas. Esas "antiguas tablas" (las que tienen el oldmd5sum) es para poder pedir un diff con ellas en vez de la "total".
- Que se pueda requerir cualquiera de las tres listas de forma independiente (o los diff con los oldmd5sum), y la lista (b) contiene un campo con el md5sum de (a), y la lista (c) contiene un campo con el md5sum de (a) y de (b).
- Que los estados de cada equipo no sean de tamaño fijo (4 bytes), sino de tamaño variable (n bytes, suficientes para dar el estado local y todas las "alarmas").
Para el estado de tamaño variable, una manera es poner el número de "items" total, luego un tipo_alarmas+número, y luego las alarmas de ese tipo, tipo_alarmas+numero, alarmas, etc hasta agotar las alarmas de dicho elemento.
- El ping (mandar los md5sum) debería ser cada segundo

_
<tt>Friday, 17 July 2009, 6:45:47 pm</tt>
Courgette bindiffs de ejecutables, el usado (bueno, todavía el que se usará) para las actualizaciones de crome es *courgette>http://dev.chromium.org/developers/design-documents/software-updates-courgette*, que desensambla el ejecutable, pone una tabla de etiquetas y hace la diferencia de eso, con lo que mejora muchísimo de un simple bsdiff.
_
<tt>Friday, 5 June 2009, 7:14:40 pm</tt>
Cosas a hcer en estos momentos Ya está disponible un UI inicial en
= dario@salchicha:~/Programacion/proyectos/sico-maintd/maintd_ui.tcl

Cosas que faltan:
Completar el protocolo tcp

Ahora se manda un allbits, que manda tanto las descripciones como el contenido. Hay que cambiarlo por los siguientes:

sigdesc: manda el signature de las descripciones (el id de tabla)

sigbits: manda el signature de los bits (esto habrá que calcularlo en maintd, ya que ahora no se hace; es equivalente al signature de las tablas pero sobre los 4 bytes de estado)

alldesc: manda el signature enuna línea y después una línea para las tags de cada equipo

allbits: manda el signature en la primera línea y después los bits de cada equipo, precedido por un "n:" o "nn:" o "nnn:" si se repite más de una vez; p.ej sería para 17 equipos:

Mejoras en el UI
Partir la parte de estado en 4 columnas:
# estado remoto (pone ninguno o más de "VIDA EQUIPOS PING")
# estado local (pone ninguno o más de "RAID MEM LOAD DISK")
# estado perfil (pone nombre de perfil y las palabras de ese perfil y opcionalmente un "+" para decir que hay más en error, los posibles son "(maintd) CFG WARN MEM +" "(tcesiv) CONTROL ROUTER DRV UI RELOJ ISA +" "(crp) CRP VIDEOWALL ISAS +")
# estado ocupación (pone GEN RES nn, siendo GEN que se generarán resultados, RES que hay resultados y el nn el número de tareas en curso (no se pone nada si no hay ninguna))
Alternativa: partir el estado en 3+4+9+3=19 y dejar un cuadro para cada texto posible, así se pueden colorear y ver mejor todos los que tienen VIDA mal o CONTROL mal.
_
<tt>Friday, 22 August 2008, 4:29:43 pm</tt>
Explicación de los distintos ficheros del código del maintd

Ficheros ya implementados

! maintd.cfg
Fichero de configuración. Describe quienes son los servidores de nivel del equipo actual y quienes son los clientes (equipos para los que el equipo actual actua de servidor de nivel).

! maintd.c
Llama al resto de los módulos. Tiene el bucle principal del programa.

! maintd_config.c
Lee la configuración y lo guarda en unas estructuras para que lo puedan usar el resto de los módulos. Es muy exhaustivo en el análisis de la sintaxis del fichero de configuración y da indicaciones al usuario de en qué línea y por qué ha encontrado un error. Si el error no es fatal ("warning"), continúa igualmente con el parseado y el programa se puede levantar.

! maintd_data.c
Guarda la información de estado del programa. Funciona de base de datos del programa. Parsea y guarda los datos de los datagramas que se reciben. También prepara los datagramas para enviar en los casos de ser una respuesta que soporta su envío partido en varios datagramas (por tamaño).Tiene las funciones que faltan por implementar

! maintd_tags.c
Librería auxiliar para manejar "sets" de tags. Permite añadir tags al set, buscar un tag, obtener el número de orden de un tag en el "set", reducir el set "borrando" los N últimos tags.

! maintd_udp.c
Implementa la comunicación por sockets UDP. También implementa el select general del programa (soporta tanto UDP como TCP). Encola datagramas para su envío y los envía cuando el S.O. informa de disponibilidad de envío. permite recibir los datagramas pendientes de recepción indicando el cliente o servidor que lo ha enviado

Ficheros que no se han implementado pero serían necesarios

! maintd_cli.c
main() alternativo que hace que el maintd se comporte como un UI para conseguir el estado de todos los descendientes de un equipo. Se le llama desde maintd.c:main() si detecta que tiene parámetros que no empiezan por '-'.

! maintd_tcpui.c
Implementa la funcionalidad de los mensajes TCP contra el UI

! maintd_tcpcmd.c
Implementa la funcionalidad de las conexiones TCP de distribuciones y comandos.
_
<tt>Friday, 22 August 2008, 3:51:42 pm</tt>
Estado de desarrollo El propósito era tener para hoy terminado el Objetivo 1 (es decir, sólo el estado de ARRIBA o CAIDO, que se obtiene por los alive), pero no ha sido posible; ciertamente el tiempo era demasiado justo O:-). El programa tiene poco menos de 2000 líneas y estimo que la funcionalidad que le falta para llegar a eso son unas 200 líneas más. Claramente lo que más tiempo me ha consumido es la elección de objetivos y la elaboración de los documentos de protocolo y de manual de usuario. Sobre todo por el documento de protocolo, realmente...

Código en <tt>salchicha:/home/dario/Programacion/proyectos/sico-maintd/</tt>.

Está hecho:
- Lectura de configuración
- Soporte a múltiples clientes
- Soporte a múltiples servidores de nivel
- Paso de mensajes por UDP
- Recepción y envío de mensajes Alive (contienen la información de estado del equipo actual y todos sus clientes y descendientes).
- Almacenamiento y consolidado de información de estado
- Envío y recepción de mensajes de queryclientids, de manera que siempre se tengan las listas de equipos de los descendientes actualizadas.
- Recepción de mensajes de clientids, de manera que se tiene la lista de equipos de sus descendientes.

Falta por hacer
- Consolidado de la información de clientids de todos los clientes del equipo actual para tener una tabla que mandar a su servidor de nivel
- Preparación de los datagramas UDP que componen el mensaje de clientids para enviar a su servidor de nivel
- Uso de maintd como cliente de línea de comandos para preguntar a otro maintd el estado de todos los equipos de los que tiene datos, usando el protocolo de UI.

Sobre la documentación, está documentado:
- Los objetivos (al final de esta página)
- El fichero de configuración maintd.cfg, en <tt>salchicha:/home/dario/Textos/ManualMaintd/ManualMaintd.pdf</tt>
- El protocolo UDP entre maintds y el protocolo TCP entre maintd y el UI. Falta por definir la parte de distribución de ficheros y ejecución de comandos. Está en <tt>salchicha:/home/dario/Textos/ProtocoloMaintd/ProtocoloMaintd-Especificaciones.pdf</tt>.
_
<tt>Wednesday, 13 August 2008, 7:26:18 pm</tt>
Breve ejemplillo de hostent y sin_addr *Aquí>http://foro.elhacker.net/programacion_cc/asignar_ip_a_una_sockaddrin-t217251.0.html;msg1029735* dan una manera alternativa al memcpy al que estaba acostumbrado:
<table border=1><tr><td><tt>struct sockaddr_in servidor;
stuct hostent &star;p;

p=(struct hostent &star;)gethostbyname(hostname);
servidor.sin_addr=&star;((struct in_addr&star;)p-&gt;p_addr);

/&star; Para sacar la direccion por pantalla &star;/
fprintf(stderr,"La IP es%s:",inet_ntoa(servidor.sin_addr));
</tt></td></tr></table>
_
<tt>Wednesday, 13 August 2008, 6:59:43 pm</tt>
Hechos los manuales del protocolo y de usuario (fichero de configuración maintd.cfg) Están en:
= salchicha:~dario/Textos/ProtocoloMaintd/
= salchicha:~dario/Textos/ManualMaintd/
_
<tt>Monday, 4 August 2008, 5:39:27 pm</tt>
Sobre el UDP *UDPLite with code examples>http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/* UDPLite no es UDP, pero los ejemplos de código se deberían parecer muchísimo. *UDP made simple: Writing a simple UDP client/server in a Unix environment>http://www.abc.se/~m6695/udp.html*. Por último, un *ejemplo completo de select con sockets UDP>http://www-gti.det.uvigo.es/~pedro/pub/lsodtr/boletinse1.html*, aunque es exactamente igual que con sockets TCP.
_
<tt>Monday, 4 August 2008, 4:26:49 pm</tt>
AQUI EMPIEZA EL PROYECTO DE VERANO Es implementar el maintd. Al final se va a hacer en C, usando UDP para el envío de mensajes,y haciendo conexiones TCP sólo para el envío de ficheros.
*Antigua página del maintd.tcl>http://3.0.1.45:8000/Diarios/103*
_
! Descripción del proyecto

- Gestión de los ordenadores mantenidos por sico.
- Supervisión de los servicios críticos.
- Envío de distribuciones.

! Objetivos

# Que estén conectados entre sí. Se usa UDP, y conectado significa un datagrama de vida dentro de los márgenes de tiempo establecidos. ==> CON ESTO OBTENEMOS EL ESTADO ENTRE "ARRIBA" o "CAIDO".
# Que se supervisen aplicaciones importantes. Básicamente son tres cosas: Control, Router y num. de procesos hijos de control. Si todos OK: VERDE. Si Router y Control pero num. de procesos hijos es diferente del esperado: NARANJA. Si falta control, router o no hay hijos de control: ROJO.
# Distribuir ficheros: Se genera un socket TCP del cliente al servidor de nivel; se le manda el tar y/o el sh; se destarea en / y se ejecuta el sh en /tmp. Se lleva la cuenta de los sitios donde se hace, y lo que saca el sh por stdout/stderr.
# Ejecutar comandos Equivalente al anterior, pero el comando es una sola linea de shell que se ejecuta en /tmp.

! Notas sobre la arquitectura

- Topología en estrella.
- Al nodo de un nivel se le denomina "servidor de nivel", y a los que cuelgan de él simplemente "clientes".
- Se configura en el servidor de nivel los clientes que deberán reportar a él (si alguno no reporta, se considera que está CAIDO; habría que hacer un ping adicional para saber si lo está del todo o solo parcialmente)
- Se configura en el cliente el servidor de nivel al que deben reportar
- Hay mensajes UDP en ambas direcciones, dirigidos al puerto 9234/udp
- Hay conexiones TCP en dirección cliente a servidor de nivel al puerto 9234/tcp
- Se puede configurar un servidor de nivel para que acepte una conexión TCP de control, que sería desde el UI del usuario para saber el estado de TODOS los elementos que cuelgan de él y actuar contra ellos, en el puerto 9235/tcp.

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: