Bienvenue sur le serveur web du logiciel libre

Documentation Wetu

Recherche

Apercu general

Wetu n'est ni plus ni moins qu'une base de données, et des clients pour la consulter et/ou l'alimenter.

Dans la suite, je ne parle que du serveur wetu, qui constitue la base. Un "serveur" peut être serveur de domaine (comme le processus sur venus par exemple), ou être simple client : sur une machine du domaine, il alimente la BD du serveur de domaine, ou la consulte simplement à intervalles réguliers pour en rapatrier les informations. Les "serveurs" wetu peuvent donc être tour a tour "vrais" serveurs, ou simples clients, ou les 2 (cas des serveurs de domaines qui s'échangent mutuellement leurs domaines).

Interactions des "serveurs" wetu avec l'extérieur

Synopsis

Sur un serveur de domaine, on alimente la base de données via tcp ou via udp. Le protocole est au format "texte", donc pas de probleme pour y aller par telnet (tcp). Il y a même une commande help dans ce protocole. Je parle par la suite du protocole tcp/udp _natif_.
On peut consulter la base par tcp, toujours avec le même protocole, via certaines commandes qui permettent de récuperer les machines d'un domaine, les utilisateurs qui sont dessus, etc... On peut aussi consulter cette même base via http (tcp).
Donc, pour l'interaction de la base avec l'extérieur je resume :
- un acces tcp pour l'alimentation/la consultation de la base (utilisé pour les communications inter-serveurs de domaines)
- un acces udp pour l'alimentation seule (utilise par les clients type "client wetu" pour win32, ou heartbeat : le client unix)
- un acces http (tcp) pour la consultation seule
- un acces socket Unix pour l'administration (cf infra)

Administration "live"

A cela, j'ai rajouté la possibilité d'administrer le serveur, c'est à dire de changer "au vol" (en cours d'exécution), certains paramètres de configuration. Cette administration prend la forme d'une socket unix (/tmp/wetu_maintain par defaut), sur laquelle se connecte un client dedié (maintain_agent, dans les sources : wetu/server/management).
A la connexion de cet outil d'administration, un couple login/mot de passe doit être fourni pour authentifier l'administrateur qui se connecte. 2 niveaux d'administration sont disponibles :
- lecture seule (login="anonymous" en principe ; defini à la compilation par le make keys ; pas de passorwd) : en principe aucune modification importante n'est autorisée. Juste la consultation des principaux paramètres de configuration est disponible.
- contrôle total (login="admin" en principe ; login+mot de passe définis à la compilation par le make keys) : possibilité d'agir sur tous les paramètres, et même de tuer le serveur (commande "kill_wetud").
L'administration n'est possible que quand le serveur est déjà lancé, évidemment. Si on veut se connecter en anonymous, il suffit de lancer maintain_agent avec l'option "-a". Sinon, au lancement de maintain_agent, il est demandé login+mdp.
Le maintain_agent présente un prompt, et on y tape les commandes. "help" en donne un apercu. La commande la plus importante est "config" : c'est avec elle qu'on va pouvoir voir les paramètres de configuration (ex: "config log_fname" renverra le nom du fichier de log), et les modifier (ex : "config log_fname /tmp/logloglog" changera le nom de ce fichier de log). Pour avoir la liste des paramètres modifiables : "config help" (voir un exemple dans wetu/doc/config.sample). Et pour savoir à quoi correspond un paramètre de configuration : "config help log_fname" par exemple.
Je conseille vivement d'utiliser cet outil. Une commande est dangereuse : redom (reconstitution de la liste des domaines à partir des fichiers de configuration). Il vaut mieux faire un "kill_wetud" puis relancer le serveur, plutot que de l'utiliser.
Fonctionnement interne
- Hook...
  
  Un hook est un module. Même principe que dans Apache : c'est une structure de données qui definit une brochette de fonctionnalités. Les hooks sont chaînés, et interrogés a la chaîne à chaque évènement qu'ils peuvent prendre en charge.
  Un évènement est pris en charge par le hook si le hook définit un handler pour cet évènement. Cet évènement peut être la connexion d'un client au serveur, une commande de la part du client pour laquelle le hook a defini un handler...
- Les evenements (voir include/server/hooks.h)
  
  Handlers statiques :
  . initialisation du hook
  . post-initialisation ("2e passe")
  . terminaison du serveur
  
  Handlers de "run-time" : . directive de configuration : chaque hook possède une hash-table permettant d'associer un handler à une directive de configuration.
  . début de connexion tcp protocole natif.
  . commande de la part d'un client sur connexion tcp, sur message udp. Même principe.
  . fin de connexion tcp protocole natif.
  . commande d'administration par maintain_agent : même principe.
  . url http : chaque hook définit une hash-table d'url qu'il peut prendre en compte. Une url peut être une url précise, ou un "répertoire" (virtuel) pour lequel il est (co)responsable (éventuellement avec d'autres hooks).
  
  Handlers asynchrones :
  . Threads périodiques devant être lancés. Permet par exemple de renseigner la BD locale ou distantes par la liste des utilisateurs logués sur la machine.
- Intérêt des hooks
  
  On peut rajouter à la volée des fonctions. Par exemple, dans la version "dynamique" du serveur, un seul hook est compilé en dur dans le serveur : "dyn_loader". Ce module possède une directive de configuration et rien d'autre (ou presque) : "add_hook". Grâce à elle, on peut rajouter des bibliothèques partagées qui sont en fait des hooks, dès la phase de configuration (commandes "add_hook machin.so" dans wetu.cfg), ou même en cours de fontionnement.
- Exemple
  
  Le hook le plus complexe est "hook_core_auth". Ce module est sensible à tous les évènements, et permet de filtrer leur prise en compte par les autres hooks, placés *après* dans la chaine des hooks. C'est pourquoi ce hook doit être chaîné en première position (éventuellement juste après dyn_loader quand même).
  Par exemple, quand un client se connecte, hook_core_auth vérifie qu'il a bien le droit de se connecter. Après, puisque les droits d'accès sont ensuite filtrés /par commande/ issue de la part du client, il autorise ou non le client à effectuer telle ou telle commande.
  De même, un client http qui se connecte est plus ou moins autorisé à accéder à telle ou telle partie de l'arborescence. Etc...
- Limitations
  - Absence d'homogénéite dans la gestion de tcp, http, udp, maintain : ce n'est pas très élégant.
  - Gestion des threads périodique des hooks pas très propre.
  - Problèmes de portabilité avec dyn_loader (d'où le passage en libtool). Actuellement : portage assuré vers Linux et Solaris.
Fichiers de configuration

Les fichiers de configuration sont par défaut dans /etc/wetu, sauf quand on l'a redefini via l'argument --with-wetu-configdir=ARG de configure.
- wetu.cfg : le fichier rassemblant ce que j'appelais les "directives de configuration" dans ce qui précédait. Pour connaitre ces directives de configuration, lancer le serveur avec les hooks qu'on veut ("addd_hook bidule" quand on utilise les hooks dynamiques ; faire des touch sur les fichiers qui manquent le cas échéant), puis le maintain_agent. Taper "config help". Un exemple de "sortie" de cette commande est donné dans wetu/doc/config.sample. Quand on a l'accès http qui fonctionne, on peut faire cette consultation via l'url hooks/base/config.
- hierarchy.cfg : définition des domaines gérés localement, ou gérés par d'aures serveurs, et vers quels domaines poster la liste des utilisateurs locaux.
Les fichiers de configuration des hooks (valeurs par defaut, en général surchargeables par des directives de configuration dans wetu.cfg) :
- hook_core_auth :
  . wetup_auth.cfg : droits d'accès/commandes autorisées pour les clients (natifs) qui se connectent en tcp ;
  . local_users : autorise ou non un utilisateur logué sur la machine à figurer dans la liste des personnes connectées ;
  . www_auth.cfg : droits d'accès/url autorisées clients HTTP ;
  . udp_auth.cfg : droits d'accès/commandes autorisées messages UDP.
Synoptique du fonctionnement
- Procédure d'initialisation
  
  . Init des hooks présents en dur dans le serveur.
  . Lecture du fichier de configuration. Chaque directive de configuration passe dans les bons hooks. Eventuellement, des hooks sont chargés dynamiquement (directive "add_hook") : appel de leur handler d'initialisation.
  . Lecture de hierarchy.cfg.
  . Post-init des hooks désormais présents.
- Evenements exterieurs
  
  cf 3.b/
- Spontanement
  
  Périodiquement, un thread se réveille. Ce thread regarde si des hooks ne demandent pas à réaliser un service periodique.
  Pour l'instant, 4 services périodiques :
  . Récupérer les utilisateurs logués en local, et les mettre partout où c'est nécessaire dans la BD locale (c'est nécessaire quand un domaine est du type "hostwrite" dans la config de hiérarchie).
  . Envoyer le contenu/une partie de la BD locale sur un serveur de domaine distant (quand ce domaine distant est du type "autowrite" dans la config de hiérarchie). . Récupérer le contenu/une partie de la BD d'un serveur distant (quand le domaine distant est declaré de type "autoread" dans la config de hiérarchie). . Les services de lecture/écriture d'output.full des passerelles xtalk->wetu et wetu->xtalk.
Hooks proposes
- dyn_loader.
  Permet de charger d'autres hooks. Sensible aux directives de configuration/maintain seulement (config add_hook, dynlib_basedir).
- hook_core_base.
  Définit les service de base de wetu.
  * Directives config de base :
```
port, www_port, default_domain_name,
      	max_rd_len, atomic_rd_len, client_timeout, client_children_max,
      	www_timeout, www_children_max, min_reask, max_reask,
      	inter_chance2, nb_chance2, inter_chance3, nb_chance3,
      	host_outofdate, loglevel, hierarchy_fname, maintain_fname,
      	log_fname, err_fname, detach, debug, periodic_quantum, help,
      	core_base_loglevel, www_global_dir, www_htmlheader,
      	www_htmlfooter, www_logo_tags, www_table_tags, coredump_dir
```
  * Commandes tcp de base :
```
help, quit
```
  * Commandes maintain de base :
```
help, quit, config, lt, lsof, cwd, 
    	lsmem, uptime, lsdom, redom, relife, stats, about, kill_wetud
```
  (ie presque toutes).
  * Périodiquement : Watchdog pour fermer des connexions tcp (http) idle depuis trop longtemps.
  * url de base : /hooks/base , /hooks/base/global_dir , /hooks/base/stats , /hooks/base/config.
- hook_core_db_base : Base pour gérer le protocole tcp natif. Partie dialogue avec client "simple" (tcp/udp).
  * Directives de configuration :
```
db_base_loglevel, db_tcp_ip_check,
      	db_www_db_base, db_www_query_result_default_presentation,
      	db_www_fontparms_domain, db_www_fontparms_host,
      	db_www_fontparms_user, db_www_fontparms_domain_server,
      	db_www_fontparms_user_login, db_www_fontparms_user_from,
      	db_www_fontparms_user_idle, db_udp_ip_check
```
  * Commandes client tcp natif :
```
setver, list, sendme, isend, where
```
  * Commandes udp natif :
```
isend, setver
```
- hook_core_db_s2s : Base pour le dialogue serveur-serveur tcp natif.
  * Directives de config :
```
S2S_refresh_end, S2S_refresh_kill,
      	S2S_loglevel_base, S2S_loglevel_refresh, loose_nbcheck
```
  * Commandes clients tcp natif :
```
s2s, ssendme, sisend
```
  * Périodiquement : rafraichissement d'un domaine : rapatriement à partir d'un domaine local, vers un domaine local. Partie TRES délicate (gestion de toute une session tcp en protocole natif).
- hook_core_auth : Gestion des droits d'accès
  * Directives de configuration :
```
client_auth_fname, www_auth_fname,
      	udp_auth_fname, localusers_auth_fname
```
  * Commande maintain_agent :
```
lsrights, lsexport
```
  * url http : /hooks/auth/connection, /hooks/auth/users
  Toutes les commandes (tcp, udp, http) sont filtrees.
- hook_core_browse : log des acces, visibilité de ce log par http
  * url http : / (pour logger le passage par http), /hooks/browse * commande udp :
```
isend
```
  (pas traiéee : juste pour logger le passage par udp)
  * commande maintain_agent :
```
browse
```
  Toutes les connexions tcp sont loguees.
- hook_core_uri2fs : faire pointer une url (virtuelle) vers un fichier (physique).
  * Directives de configuration :
```
uri2file, uri2dir
```
- hook_xtalk2wetu : transformer un output.full xtalk en domaine wetu
  * Directives de configuration :
```
xtalk2wetu_domains, xtalk2wetu_interval
```
  * Fonction périodique qui lit le output.full
- hook_wetu2xtalk : écrire un output.full xtalk sur la base d'un domaine wetu
  * Directives de configuration :
```
wetu2xtalk_domains, wetu2xtalk_interval
```
  * Fonction périodique qui ecrit le output.full
- hook_gatow : GUI Gnome pour la gestion d'un serveur wetu. Dès que la GUI est terminée, le serveur sous-jacent aussi. Et inversement.
  * (Rien)
Xtalk / Wetu

Xtalk vers Wetu
- Prérequis
  Prévoir de charger le module hook_xtalk2wetu (directive de configuration add_hook, ou compilation en dur dans le serveur).
- Hierarchie des domaines
  Par exemple, si l'on veut que le domaine xtalkd_info corresponde à un domaine géré par xtalk, mettre dans le fichier de configuration de la "hiérarchie" des domaines :
```
localdomain "xtalkd_info" = {};
```
  Note: Les domaines gérés par xtalkd et à importer dans wetu sont OBLIGATOIREMENT du type "localdomain".
- Configuration globale
  Par exemple, lorsqu'on veut que le domaine xtalkd_info corresponde au output.full qui va bien, on met, dans le fichier de conf global :
```
xtalk2wetu_domains xtalkd_info /usr/home/enstb2/stokelev/Utilitaires/xtalk/config/output.full.info
```
  On peut mettre plusieurs lignes comme celle-la dans le fichier de configuration si plusieurs domaines sont gérés par xtalk.
  Remarque: la configuration par défaut lit le output.full toutes les 22 secondes. Modifiable par la directive de configuration xtalk2wetu_interval.
- Exporter ces domaines vers un autre serveur wetu
  Créer une entrée pour cet autre serveur wetu dans le fichier de configuration de la hiérarchie de domaine, qui soit au moins de type "autowrite".
  Par exemple, si on veut exporter vers wetu.maisel :
```
domain "Maisel" = {
      		server = "belgarion.maisel";
      		type = autowrite;
      	};
```
  Ca exportera régulierement (tous les periodic_quantum [cf configuration globale] - par défaut: 5 secondes) tous les domaines du serveur dont belgarion.maisel veut bien.
Wetu -> Xtalk
- Prérequis
  Prévoir de charger le module hook_wetu2xtalk (directive de configuration add_hook, ou compilation en dur dans le serveur).
- Hiérarchie des domaines
  Rien de special a faire. Les domaines peuvent etre des localdomain ou pas.
- Configuration globale
  Par exemple, lorsqu'on veut que le domaine Maisel fasse écrire un output.full qui va bien, on met, dans le fichier de configuration global :
```
wetu2xtalk_domains Maisel /usr/home/enstb2/stokelev/Utilitaires/xtalk/config/output.full.maisel
```
  On peut mettre plusieurs lignes comme celle-la dans le fichier de configuration si plusieurs domaines doivent etre exportés vers xtalkd.
  Remarque: La configuration par defaut écrit le output.full toutes les 22 secondes. Modifiable par la directive de config wetu2xtalk_interval.
Mises au point dans le code
- En cas de changement de configuration de xtalk, il peut être nécessaire de rentrer dans le code des modules. Un certain nombre de facilités ont été prévues pour que ce soit simple.
  . Rajout/Modif de descripteurs pour le champ "ou" des fichiers output.full Pour l'instant, seuls les descripteurs 'C', 'M', 'R', 'I' et 'V' sont reconnus par wetu, et associes respectivement a localhost, maisel-gw, univers, ingrid et vaxli.
  Pour modifier cette association :
  - Dans xtalk2wetu : voir le tableau tab_ou. J'crois qu'c'est clair.
  - Dans wetu2xtalk : voir le tablean tab_ou. Là, ce sont les "masques" qui sont intéressants - savoir différencier une personne logué vers la Maisel depuis les Sun ou depuis un autre PC Maisel.
  . Intervalles de rafraichissement: par défaut, ils sont établis à 22s, et sont modifiables par configuration ou en cours de fonctionnement (direcives xtalk2wetu_interval et wetu2xtalk_interval). Pour modifier la valeur par défaut : voir les X2W_INTERVAL et W2X_INTERVAL. . Divers: le séparateur des champs xtalk est modifiable par la macro XTALK_SEP dans xtalk2wetu (pas dans wetu2xtalk).
TODO
- Une doc d'administration. La partie 2.b/ est un minimum vital. Elle permet de debugger un peu, mais surtout de voir ce que wetu a dans le ventre. Un "config help" dans le maintainer permet de s'en sortir dans la phase de configuration.
- cf "Limitations" des hooks.
- Rendre Gatow plus independant du serveur.

David "d2" Decotigny

le site sera opérationnel dans quelques temps.Veuillez nous excusez des différentes erreurs...

Modifié le 27/02/2000

Presentation

Les activités de mise sous licence libre des logiciels produits par les étudiants de l'ENST de Bretagne

Nouveautés

l'équipe orgranisatrice, les développeurs et le webmaster sont à votre disposition pour toutes vos remarques

Le club

Inscrivez-vous à la Mailing List, découvrez le Club Libre de l'ENST de Bretagne

Chat

Espace de discussion. Inscrivez-vous à la mailing liste du(des) logiciel(s) qui vous intéresse(nt)

Accueil

Recherche

Apercu general

Interactions des "serveurs" wetu avec l'extérieur

Les activités de mise sous licence libre des logiciels produits par les étudiants de l'ENST de Bretagne

Les nouveaux logiciels et documents

tous les logiciels que vous pouvez télécharger sur notre serveur

la foire aux questions pour toutes vos questions

l'équipe orgranisatrice, les développeurs et le webmaster sont à votre disposition pour toutes vos remarques

Inscrivez-vous à la Mailing List, découvrez le Club Libre de l'ENST de Bretagne

Espace de discussion. Inscrivez-vous à la mailing liste du(des) logiciel(s) qui vous intéresse(nt)

La page d'accueil du site

la foire aux questions
pour toutes vos questions