Réseau XLAN

Réseau Xlan

Xlan est le service d'Harmony qui s'exécute sur le serveur de données.
Attention : il doit aussi être exécuté sur un poste autonome avec une base de données SQL.
En version 7, il gère tous les accès effectués par les fonctions Diva de gestion des fichiers :

• Accès aux fichiers séquentiels-indexés.

• Accès aux bases SQL, par le driver ODBC de la base de données cible.

Réseau Xlan sous Windows

Configuration du réseau Xlan sous Windows

La configuration du réseau XLAN - WINDOWS comprend les étapes suivantes :

Installation et paramétrage du serveur de données Windows

Installation de TCP/IP

Le serveur Xlan utilise le protocole TCP/IP. Ce protocole doit donc être installé et paramétré sur le serveur de données et les postes clients.

Service Xlan

Le serveur Xlan est un service qui s'exécute sur le serveur de données.
L'installateur de Harmony Power Foundation crée automatiquement ce service (DhsXlanServer) dans le registre du serveur.

Configuration du serveur de données

Le chapitre [System] de Divalto.ini peut être modifié sur le serveur de données (par xDivaltoMajIni). Il contient tout d'abord un paramètre spécifique réseau :

• NumeroService. Ce paramètre représente le numéro de port TCP/IP du serveur Xlan. Il doit obligatoirement être renseigné. La valeur 1235 est proposée par défaut. En cas de conflit avec un service existant, il faut changer ce numéro.

Les autres paramètres modifiables de Divalto.ini sont :

• NbFichiersParProcess. Indiquez ici le nombre maximal de fichiers qu'une tâche Harmony est susceptible d'ouvrir simultanément.

• NbFichiersIndexes. Indiquez ici le nombre maximal de fichiers séquentiels indexés différents susceptibles d'être ouverts simultanément. Ce paramètre concerne l'ensemble des tâches Harmony (locales et réseau). Un même fichier ouvert simultanément par plusieurs tâches compte pour une seule unité. Ce paramètre doit être supérieur à 10.

• NbFichiersDivers. Indiquez ici le nombre maximal de fichiers (non séquentiels indexés) différents susceptibles d'être ouverts simultanément. Ce paramètre concerne l'ensemble des tâches Harmony (locales et réseau). Un même fichier ouvert simultanément par plusieurs tâches compte pour une seule unité. Ce paramètre doit être supérieur à 10.

• NbReservEnreg. Indiquez ici le nombre maximal de réservations d'enregistrement susceptibles d'être faites simultanément. Le langage Diva n'impose aucune limite au nombre de réservations mais il convient de ne pas saturer la table "système" associée. Ce paramètre concerne l'ensemble des tâches Harmony (locales et réseau). Il doit être supérieur à 5 fois le nombre de tâches. Si les programmes ne réservent que quelques enregistrements simultanément, prenez comme valeur 10 fois le nombre de tâches.

• NbReservEntites. Indiquez ici le nombre maximal de réservations d'entité susceptibles d'être faites simultanément. Ce paramètre concerne l'ensemble des tâches Harmony (locales et réseau). Il doit être supérieur à 5 fois le nombre de tâches.

La modification de Divalto.ini est facultative car des valeurs sont définies par défaut pour tous les paramètres. Mais en cas de modification, il faut arrêter les services DhsXlanServer et DhsDivalto puis les redémarrer (par xDivaltoRestart).

Messages d'erreur des services DhsDivalto et DhsXlanServer

En cas de problème (erreur au démarrage, arrêt d'un service), consultez le journal des événements du serveur (journal "Applications"). Vous y trouverez le code d'erreur ainsi que le message d'erreur correspondant.

Les programmes Xconsole et xUpdateConfig

Xconsole (lancé sur le serveur de données ou sur un poste client) permet de visualiser l'état du serveur Xlan. Il affiche les connexions, les fichiers ouverts et les réservations d'entité.
xUpdateConfig permet de mettre à jour la configuration du serveur de données, sans qu'il soit nécessaire de stopper et relancer le serveur DhsXlanServer. xUpdateConfig est automatiquement appelé (après confirmation), suite à une modification depuis les zooms "Serveurs" et "Chemins".

Installation de TCP/IP sur le client Windows

Si TCP/IP ne tourne pas déjà sur votre client, procédez à son installation. Vous pouvez tester le bon fonctionnement du réseau TCP/IP par Ping.

Déclaration des serveurs de données Windows du client Windows

Le choix <Paramétrage : Serveurs> du menu Harmony.dhop permet de définir les serveurs de données Harmony d'un ordinateur client. Les paramètres à renseigner dans une fiche serveur Windows sont les suivants :

• Nom de l'ordinateur. Nom Harmony du serveur. Il est conseillé de prendre ici son nom NetBios (nom qui apparaît dans le voisinage réseau).

• Adresse. Adresse IP du serveur (Exemple : 192.1.1.1).

• Type : Serveur Xlan.

• Numéro de port. Numéro du port TCP/IP du serveur Xlan. Ce numéro doit être égal au numéro du service Xlan défini dans Divalto.ini du serveur (la valeur par défaut 1235 est normalement disponible).

• Système d'exploitation du serveur : Windows.

Tests de mise en route
Appelez l'utilitaire Ping pour vérifier que le client et le serveur dialoguent correctement entre eux par TCP/IP.
Sur le client, créez une fiche correspondant à votre serveur. Par Xlog, identifiez-vous sous le nom ROOT. Appelez Xtools et demandez l'affichage du dossier //nom_du_serveur/Divalto/sys (où nom_du_serveur est le nom Harmony que vous avez donné au serveur de données).
Résolution automatique d'adresse
La configuration des serveurs Xlan peut être partielle (méthode semi-automatique, méthode par défaut) ou même entièrement facultative (méthode automatique) :

• Méthode semi-automatique Ici, le nom du serveur doit être présent dans la table des serveurs mais ses paramètres peuvent être laissés à blanc : si la zone adresse est vide, le client Xlan recherche automatiquement l'adresse IP du serveur ; si le numéro de port n'est pas précisé, le client le recherche dans la clé NumeroService du chapitre [System] de Divalto.ini ; les autres paramètres sont figés : type « Serveur Xlan », etc.

• Méthode automatique Cette méthode est activée en plaçant la clé suivante dans le chapitre [System] de Divalto.ini : RechercheServeurAuto=1 Dans ce cas, si le serveur n'est pas dans la table des serveurs, le client Xlan le recherche automatiquement sur le réseau. Ensuite, la méthode précédente est appliquée.

Déclaration des chemins Harmony du serveur de données

Pour accéder aux fichiers du serveur de données par Xlan, il faut obligatoirement passer par un chemin Harmony déclaré sur ce serveur (Cf. rubrique Accès aux fichiers d'Harmony).
Après l'installation du serveur de données, seul le chemin /Divalto (qui pointe sur le dossier d'installation Divalto) est configuré. Pour définir d'autres chemins Harmony, sélectionnez le choix <Paramétrage : Chemins Harmony> du menu Harmony.dhop. En général, on réalisera cette opération sur le serveur de données. Il est toutefois possible de la réaliser sur un poste client (dans le cas, par exemple, où vous n'avez pas installé le run-time d'Harmony sur le serveur). Mais alors attention, pour que les modifications soient bien reportées dans le fichier Fconfig du serveur et non localement, il faut, avant d'appeler Harmony.dhop, mettre //nom_du_serveur/divalto/sys (où nom_du_serveur est le nom Harmony sous lequel vous avez déclaré votre serveur) en première position dans la liste de vos chemins implicites (par Xpath.dhop).

Paramétrage des utilisateurs du réseau Xlan

• Tous les utilisateurs qui accèdent au réseau Xlan doivent être déclarés dans le fichier des utilisateurs Divalto Xlogf.dhfi du serveur de données. En principe, les utilisateurs doivent donc être déclarés deux fois : une fois dans le fichier Xlogf de la station client (serveur d'application ou poste fonctionnant en mode local), une fois dans le fichier Xlogf du serveur de données. Il est toutefois plus pratique de centraliser la gestion des utilisateurs sur le serveur de données (Cf. Déclaration des utilisateurs d'un réseau Harmony). La maintenance du fichier Xlogf du serveur s'obtient par l'utilitaire Xlog1.dhop soit depuis le serveur, soit depuis une station client. Remarque : si vous lancez Xlog1 sur une station client, c'est le fichier Xlogf du serveur qui sera traité par défaut en cas de gestion centralisée des utilisateurs.

• Il faut aussi créer un ou plusieurs fichiers de chemins implicites, permettant aux utilisateurs d'accéder aux dossiers du serveur de données, et indiquer le fichier adéquat dans la zone "Chemins implicites" de chaque fiche utilisateur :

•  

  • Si la gestion des utilisateurs est centralisée, la gestion des fichiers d'implicites l'est également, de la même manière.

  • Si la gestion des utilisateurs n'est pas centralisée, la gestion des fichiers d'implicites ne l'est pas non plus : dans ce cas, il faut créer dans le dossier /Divalto/Sys de chaque station client le ou les fichiers d'implicites utilisés sur cette station.

Pour plus de détails sur les fichiers de chemins implicites et pour des conseils d'implémentation, reportez-vous à la rubrique Déclaration des chemins implicites.

Installation d'un serveur Xlan sécurisé

Principe du serveur de données sécurisé

Par défaut, lorsqu'un utilisateur se connecte à un serveur Xlan, ce dernier vérifie uniquement que le code de cet utilisateur est enregistré dans le fichier Xlogf du serveur de données. Cette connexion simplifiée présente un important défaut, si l'on désire assurer une bonne sécurité sur le site :

• Même si la sécurité est installée côté Windows (à savoir : vous avez déclarés les utilisateurs et vous leur avez attribué des permissions, de manière à ce qu'ils aient un accès limité aux répertoires et aux fichiers via l'explorateur, Excel ou Word par exemple), l'utilisateur, lorsqu'il travaille sous Harmony, accède au serveur en passant par Xlan. De ce fait, il hérite des droits d'accès de Xlan, qui ne peuvent être que complets, tout au moins en ce qui concerne les fichiers Harmony.

Une option de Xlan permet de modifier ce comportement : le serveur sécurisé. Avec un tel serveur :

• Xlan accède aux fichiers non plus avec ses propres droits Windows mais avec ceux de l'utilisateur pour lequel il "travaille".

Mise en place d'un serveur de données sécurisé

Le service XLANSQL s'exécute sous le compte utilisateur Windows ayant activé le service (par défaut le compte système local).
Le mode sécurisé permet au service XLAN de s'exécuter pour chaque session cliente sous un compte utilisateur Windows. Ceci permet d'appliquer à XLAN des droits d'accès aux fichiers différenciés pour des groupes d'utilisateurs. En effet chaque utilisateur Harmony est associé à un utilisateur Windows dont le compte sera utilisé pour la session XLAN sur le serveur de données.
Mise en oeuvre
Pour que Xlan devienne "serveur sécurisé", il suffit de modifier le chapitre [System] de Divalto.ini sur le serveur (par xDivaltoMajIni) en lui ajoutant la clé :
XlanSecurite=3 (cette clé doit être ajoutée dans la base de registre globale à l'ordinateur HKEY_LOCAL_MACHINE).
Attention, il est également nécessaire de respecter certaines règles, côté Harmony et côté Windows :

• Pour s'attribuer les droits d'accès de l'utilisateur, Xlan effectue un "Login" Windows avec un code utilisateur et un mot de passe enregistrés dans Xlogf.

Ce code utilisateur Windows et son mot de passe sont saisis dans le zoom des comptes utilisateur Windows accessible depuis le zoom de création des utilisateurs Harmony ou Divalto.
Les comptes utilisateur Windows doivent impérativement être créés sur le serveur XLAN lui-même. (pour des raisons de sécurité, ces informations ne transitent jamais sur le réseau).
Dans la fiche de l'utilisateur Harmony, la zone "Compte Windows pour Xlan" de l'utilisateur doit être garnie.
Cette méthode permet de créer des "groupes d'utilisateurs". Dans le cas d'une installation de type Saas, on pourra créer un seul compte Windows par société cliente, tous les utilisateurs d'une société cliente utilisant ce compte.
Par défaut le compte utilisateur est recherché dans la base locale des utilisateurs. Pour accéder à un domaine, il faut utiliser l'écriture UPN, c'est à dire : user@domaine.

• Lors de la création Windows des utilisateurs correspondant à ces comptes, ne cochez pas la case : "L'utilisateur doit changer de mot de passe à la prochaine ouverture de session" Mais cochez les cases : "L'utilisateur ne peut pas changer de mot de passe" "Le mot de passe n'expire jamais"

• Vérifiez que le compte sous lequel tourne le service DhsXlanServer a le droit : "Agir en tant que partie du système d'exploitation"

• Sécurisez le fichier Xlog du serveur, en attribuant le droit "Aucun accès" à tous les utilisateurs sauf aux administrateurs.

Remarques

• La manière de procéder ci-dessus est implémentée à partir de la version 6.3a d'Harmony.

• Dans les versions antérieures, il fallait mettre XlanSecurite=1. Dans ce cas, le login Windows se fait avec le même code utilisateur et le même mot de passe que le login Harmony. Cela oblige l'administrateur à créer autant d'utilisateurs Windows que d'utilisateurs Harmony.

Déclaration des mots de passe (gestion centralisée des utilisateurs)

Lorsque la gestion des utilisateurs est centralisée :

• Xlog.dhop ne permet plus de changer le mot de passe.

• La gestion des mots de passe Harmony s'obtient par Xlog1.dhop (ce qui oblige à s'identifier Root).

• La gestion (création/modification/consultation) des "Comptes windows pour xlan" n'est accessible que pour un fichier xlogf local.

• La modification des utilisateurs Harmony est autorisée à condition que la zone "Compte windows pour xlan" soit garnie.

Fonctionnement détaillé du serveur de données sécurisé

Voyons maintenant comment se comporte le serveur sécurisé, en ce qui concerne :

• Le Login de l'utilisateur.

• La Mémorisation des mots de passe.

Login de l'utilisateur (hors client léger)

Le fonctionnement du Login dépend de la variable X_USER (Cf. rubrique Déclaration des utilisateurs) :

• X_USER = "!". La boîte de Login n'est ouverte que s'il y a un mot de passe défini dans Xlogf. Le mot de passe n'est pas demandé car on considère que l'utilisateur s'est déjà présenté de manière sécurisée pour se connecter au serveur de données Windows.

• X_USER = xxxx. La boîte de Login n'est ouverte que s'il y a un mot de passe défini dans Xlogf. Le mot de passe est demandé dans tous les cas.

• X_USER non défini. La boîte de Login est ouverte à chaque nouvelle ouverture de fenêtre Harmony.

Attention :
Si, dans la fiche utilisateur, vous garnissez le champ Alias, les deux codes (code utilisateur et alias) doivent être déclarés dans Xlogf avec le même mot de passe.
De plus, le Login Windows se fera d'après les paramètres de l'alias.
Remarque (cas où la gestion des utilisateurs est centralisée sur un serveur) : si l'utilisateur abandonne la saisie de la boîte de Login, Harmony effectue un Login local (l'utilisateur pourra alors travailler en local mais n'aura pas accès au réseau).

Mémorisation des mots de passe

Tant que la session Windows reste ouverte, Harmony mémorise localement les mots de passe tapés. De cette manière, un utilisateur ne devra saisir son mot de passe qu'une seule fois (cas où X_USER est défini ; si ce n'est pas le cas, rappelons que le mot de passe est demandé à chaque ouverture de fenêtre Harmony).
Pour forcer la ressaisie du mot de passe (l'utilisateur quitte son poste et ne veut pas que quelqu'un ait accès au réseau sans avoir à se représenter), trois méthodes sont possibles :

• Fermer la session Windows (Démarrer : Déconnexion).

• Associer un mot de passe à l'écran de veille et forcer la mise en veille immédiate (Démarrer : Arrêter : Mettre en veille).

• Appeler Xlog.dhop et entrer un code utilisateur à espace. Dans ce cas, Harmony "oublie" le mot de passe de l'utilisateur courant.

Serveur de données semi-sécurisé

Harmony permet également la mise en route d'une version simplifiée du serveur de données sécurisé, baptisée serveur semi-sécurisé. Ici, Harmony effectue la vérification des mots de passe entre le client et le serveur mais pas le login à Windows.
Il n'y a donc pas de mise en œuvre des protections Windows. Par contre, la vérification des mots de passe est bien effectuée : par exemple, un client loggé ROOT en local ne pourra plus accéder au serveur (en tant que ROOT) que si le mot de passe est le même des deux côtés.
Mise en œuvre :
XlanSecurite=2 dans Divalto.ini du serveur.

Sites délocalisés : informations complémentaires

Connexion à un poste délocalisé

Harmony permet la connexion en mode client / serveur de postes délocalisés, par une connexion NUMERIS avec routeur à chaque extrémité de la ligne. Lors d'une connexion du poste client vers le serveur de données, le routeur établit la liaison entre les deux sites. Dans le cas d'une liaison non permanente et s'il n'y a plus de dialogue entre le client et le serveur pendant un certain temps (paramétrable au niveau du routeur), celui-ci raccroche automatiquement. La connexion logique reste active, mais la connexion physique est interrompue. Lorsque le dialogue reprend, le routeur rétablit la connexion physique automatiquement.
L'option KeepAlive
Xlan utilise le protocole TCP/IP pour établir la connexion entre le client et le serveur. A chaque tâche d'un poste client correspond un "thread" Xlan serveur qui s'exécute sur le serveur. La connexion est établie lors du premier accès du poste client au serveur. Elle est libérée à la fin du programme ou lorsque la fenêtre est fermée. Xlan Client envoie alors une trame au serveur afin qu'il libère toutes les ressources qui n'ont pas été libérées par l'application (fichiers non fermés, entités restées réservées, etc.).
Une option du protocole TCP/IP permet de mettre en place une surveillance de la connexion entre le client et le serveur. Si cette option est active, le protocole TCP/IP envoie régulièrement une trame du serveur vers le client afin de vérifier que ce dernier est toujours présent. Cette trame est envoyée s'il n'y a pas de dialogue entre le client et le serveur pendant un certain temps.
Cette option est activée par la mise en place du paramètre KeepAliveTime dans la base de registres de Windows. Ce paramètre indique en milli-secondes le délai au bout duquel le serveur doit interroger le client s'il n'y a pas de dialogue sur la ligne. Si le client ne répond pas immédiatement, le serveur l'interroge plusieurs fois (5 essais en standard). L'intervalle de temps entre chaque essai est déterminé par la valeur en milli-secondes d'un deuxième paramètre, KeepAliveInterval (1 seconde par défaut).
L'installation d'Harmony met en place le paramètre KeepAliveTime dans la base de registres de Windows (valeur 600000 <=> 10 minutes). Ceci permet de libérer les ressources réservées par un poste en cas de coupure brutale de celui-ci.
Dans le cas d'une connexion distante avec un routeur au travers d'une ligne NUMERIS, le paramètre KeepAliveTime provoque le rétablissement de la connexion physique entre les deux sites. Dans ce cas, il est donc impératif d'augmenter sa valeur pour n'établir la connexion physique que toutes les heures par exemple (3.600.000 = 1 heure).
De plus, il est impératif que la connexion soit effectivement rétablie. Si ce n'est pas le cas, le serveur va croire que le client n'est plus présent et va le déconnecter ; supposons alors qu'une application était en attente sur le client ; lorsqu'elle va reprendre, le serveur refusera sa première demande d'accès au serveur ; il en résultera une erreur réseau (0A38 par exemple), voire une erreur 000C (fichier non ouvert).
Pour que la connexion se rétablisse, il faut :

• Que le routeur côté serveur soit paramétré pour être capable d'établir la liaison téléphonique avec le client (le paramétrage du routeur permet d'associer un numéro de téléphone à chaque numéro TCP/IP client) puisque c'est lui qui a ici l'initiative.

• Que le routeur côté client soit paramétré pour accepter les appels de l'extérieur.

• Comme l'établissement de la ligne téléphonique peut prendre un temps supérieur à 5 x 1 seconde, ajouter ou modifier le paramètre KeepAliveInterval pour rallonger l'intervalle entre deux essais de connexion (par exemple 10000 = 10 secondes).

Modification des paramètres KeepAlive
Au menu "Démarrer", choisir "Exécuter" Regedit.
Les paramètres se trouvent dans : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Autres conseils pour la connexion de postes délocalisés

Les temps de réponse sur les postes distants sont conditionnés par la bande passante de la liaison entre les sites. Une liaison à 64 Kbits / s permet de transférer 6 Ko par seconde entre le serveur de données et le client (à titre de comparaison, le débit moyen d'une disquette est de l'ordre de 20 Ko par seconde). De plus, la bande passante peut être partagée par plusieurs utilisateurs ou tâches.
Pour avoir des temps de réponse corrects, il ne faut transférer que les informations strictement nécessaires entre le serveur et le client, à savoir les données partagées.
Il est donc préférable :

• D'installer en local : Les programmes et modules. Les masques d'écran et d'impression. Les fichiers paramètres des menus. Les bitmaps. Les fichiers de manœuvre.

• De n'installer sur le serveur que les fichiers partagés (on évitera également les économiseurs d'écran gourmands en temps UC).

• Pour la gestion des licences concurrentes, d'installer les postes en mode autonome ou d'installer un serveur de licences sur chaque site géographique.

• De configurer les chemins implicites des utilisateurs en mettant en premier les chemins locaux et en dernier les chemins distants.

Windows Terminal Serveur Edition, une alternative

Windows Terminal Serveur Edition est un système d'exploitation de Microsoft permettant de travailler en multiposte sous Windows. Chaque poste de travail client se comporte alors comme un ordinateur virtuel.
L'application s'exécute sur un serveur d'applications. L'image de la session en cours s'affiche sur le poste client.
Un des avantages de ce système est la gestion des utilisateurs mobiles et des postes connectés à distance. En effet, les informations qui transitent entre le client et le serveur d'applications sont uniquement les objets affichés à l'écran, ce qui nécessite une faible bande passante (environ 20 Kbits par poste).