LES CAHIERS d'AIX

Publication réservée aux abonnés du Point Service AIX
Janvier 1998

La gestion des licences : de iFOR/LS à LUM

Jean-Luc GESTIN

Introduction

Pour rester serein dans un tel cas, souvenez-vous de cet article et n'hésitez pas
à vous y reporter. Vous gagnerez du temps.

Gestionnaires de licences et versions d'AIX

• En AIX V4.1 ou V4.2, le gestionnaire des licences est normalement le
  produit iFOR/LS (information For Operation Retrieval and Licence System),
  qui est une évolution du précédent produit NetLS.
  
  Ce code fait partie de la souche système AIX V4.1 ou V4.2.
  

• En AIX V4.3, une nouvelle version de iFOR/LS est proposée, plus riche
  en fonctionnalités : LUM V4.0 (Licence Use Management).
  
  Ce code fait partie de la souche système AIX V4.3.
  

• Certains produits, IBM ou non, destinés à la version 4.3 AIX peuvent
  également tourner en version 4.1 ou 4.2.
  Mais comme ces produits ont été conçus avant tout pour travailler en AIX V4.3,
  donc avec LUM V4.0, afin d'assurer la compatibilité d'utilisation
  c'est en fait LUM V4.0 qui a été adapté pour travailler également
  avec AIX V4.1 et AIX V4.2.
  
  Le code de LUM V4.0 est alors livré directement sur le
  CD-Rom du produit de langage.
  
  C'est le cas, par exemple, des produits IBM :
  
  
  
  • C for AIX V4.3, numéro 5765-C64
    
  • XL Fortran V5, numéro 5765-C10
    
  
  

Comment utiliser ce dossier

Utilisation de iFOR/LS en AIX V4.1 ou V4.2

L'environnement iFOR/LS

• Des licences iFOR/LS.
  
• De la "cellule" iFOR/LS (vue logique qui s'affranchit de la topologie
  du réseau sous-jacent). Elle contient les clients et le(s) serveur(s) iFOR/LS.
  
• Du fichier user_file.
  
• D'un ou de plusieurs serveurs iFOR/LS.
  
• Des clients iFOR/LS.
  

Les licences iFOR/LS

La licence est attachée à un système, désigné comme serveur de
licence. La clef de licence intègre le uname
du système, que vous obtenez avec la commande uname -m.

Ceci implique deux contraintes :

• Pour déplacer cette licence sur un autre système, il faut demander
  une nouvelle clef auprès du Centre des clefs de Copenhague.
  
• Les conséquences éventuelles de certains problèmes matériels (hardware)
  peuvent conduirent :
  
  
  
  • A la perte du uname du système.
    
  • Au remplacement de la carte mère.
    
  
  Dans ce cas, les licences basées sur l'ancien uname ne fonctionnent
  plus, et il faut également demander une nouvelle clef auprès du Centre des clefs de
  Copenhague.
  

La licence intègre également la notion de "date de début d'utilisation".

Si la date de votre système n'est pas à jour, la licence peut très bien
refuser de fonctionner. Par exemple : votre licence vous est délivrée le
1er avril, jour où vous souhaitez l'utiliser, or votre système indique
la date du 25 mars... Vous devrez attendre une semaine pour pouvoir utiliser la
licence, ou alors mettre à jour la date de votre système,

Les types de licences

• La licence "Nodelocked".
  
  Elle est associée à la station de travail
  et ne peut jamais être partagée sur le réseau entre plusieurs systèmes.
  
  Lorsqu'il est invoqué, le produit logiciel recherche la licence dans le fichier
  /usr/lib/netls/conf/nodelock
  qui contient la liste des licences nodelock valides.
  
  Une licence nodelock n'utilise pas le réseau et ne
  nécessite pas la mise en place d'un serveur de licences.
  

• La licence "Concurrent-use" (ou licence flottante).
  
  Elle est associée à la machine serveur de licences.
  
  Il doit y avoir un serveur de licences iFOR/LS actif sur le réseau.
  
  Ce type de licence peut être distribué à toute machine du réseau qui en fait la
  demande. Le nombre d'utilisateurs simultanés est limité par le nombre de licences achetées :
  le produit est dit "vendor-managed".
  
  Les licences concurrent-use sont comme des jetons que le serveur
  iFOR/LS distribue sur demande des clients, qu'il récupère et fait
  circuler d'un client à l'autre selon leurs besoins.
  
  Il est intéressant d'avoir un nombre de licences inférieur au nombre
  d'utilisateurs potentiels afin d'optimiser leur utilisation.
  

• La licence "Use-once".
  
  Identique par ailleurs à une licence flottante,
  elle ne peut être utilisée qu'une seule fois, dans les limites de sa période de validité.
  
  Le nombre de licences use-once fournies est décrémenté chaque
  fois qu'une requête de licence est satisfaite : la licence est consommée.
  

Choix entre licence "Nodelock" et "Concurrent-use"

• Dans le premier cas, vous avez besoin d'utiliser des licences
  réparties, "Concurrent-use", et par conséquent d'installer iFOR/LS.
  

• Dans le second cas, des licences "Nodelock" suffisent,
  et vous n'avez pas besoin d'installer iFOR/LS sur votre système.
  

La "cellule" iFOR/LS

• Un ou des serveurs de licences iFOR/LS.
  
• Des clients qui seront servis par ce(s) serveur(s).
  

Règles

• Un poste de travail, client ou serveur, ne peut appartenir qu'à une seule cellule à la fois.
  
• Chaque cellule est gérée par un daemon glbd indépendant.
  
• Il existe deux types de cellules :
  
  
  
  • Une cellule par défaut, désignée par un identifiant de valeur
    constante, prédéfini dans le code du produit iFOR/LS.
    
  • Une cellule dite alternée, désignée par un identifiant qui lui est
    propre et construit lors de la création de la cellule.
    
  
  
• Une cellule est mise en place au moment de la création du serveur
  de licences, lorsque le script netls_config est lancé. Le type
  de la cellule mise en place dépend du choix fait lors de cette création.
  

La cellule "par défaut"

• C'est la cellule qui est créée lorsque vous lancez netls_config et
  que vous sélectionnez le choix n° 2 : "Utiliser le nom par défaut comme nom de
  cellule système".
  
  (Voir le chapitre "Installation d'un serveur iFOR/LS dans une nouvelle cellule alternée")
  
• Comme elle utilise un identifiant de valeur fixe, les hôtes de cette
  cellule n'ont pas besoin de posséder un fichier de configuration
  /etc/ncs/glb_obj.txt (voir le chapitre "La cellule "alternée"").
  
• Il ne peut y avoir qu'un seul et unique serveur iFOR/LS dans une cellule par défaut.
  

Les inconvénients de la cellule par défaut

Jugez-en : si vous installez votre serveur de licences dans une cellule par défaut,
les "n" licences que vous avez achetées deviennent disponibles pour :

• Tous les utilisateurs connectés sur le réseau local à votre serveur et
  qui ne font pas partie d'une cellule alternée.
  
• Tous les utilisateurs situés au-delà d'un ou de plusieurs routeurs si :
  
  
  
  • Ils peuvent atteindre votre serveur par la commande ping.
    
  • Ils ne font pas partie d'une cellule alternée.
    
  • Ils possèdent un fichier glb_site.txt qui référence votre serveur.
    
    (Pour une explication sur ce fichier, voir "Les clients iFOR/LS").
    
  
  

Conclusion

• Un utilisateur d'un autre service peut installer sur son système un
  logiciel dont vous avez une licence, et utiliser vos licences.
  
• Un autre administrateur peut lancer son propre serveur
  iFOR/LS dans la cellule par défaut où se trouve déjà le vôtre.
  
  Comme l'identifiant de cette cellule
  est fixe et identique pour tous, ce second serveur se retrouvera en fait
  dans la même cellule que la vôtre. Ceci engendre, à terme,
  des problèmes de conflit d'usage et de synchronisation des bases.
  
• Vous le comprenez, une cellule par défaut est ouverte à tous et
  vous n'avez pas la possibilité de maîtriser cet environnement.
  

La cellule "alternée"

• C'est la cellule qui est créée lorsque vous lancez netls_config et
  que vous prenez le choix n° 3 "créer une nouvelle cellule alternée
  comme nom de cellule système".
  
  (Voir le chapitre "Installation d'un serveur iFOR/LS dans une nouvelle cellule alternée")
  
• Cette cellule est caractérisée par un identifiant unique, appelé
  UUID (Universal Unique IDentifier).
  
  L'UUID se définit par une chaîne de caractères, créée sur le serveur de
  licences iFOR/LS dans le fichier /etc/ncs/glb_obj.txt.
  Il comporte 16 octets.
  

  
  Exemple : 54c7874546ae.02.81.87.92.34.00.00.00
  

  
  L'UUID est créé en intégrant les informations suivantes :
  

  
  
  • Sur 6 octets, la date et l'heure de création de l'UUID.
    
  • 2 octets sont réservés.
    
  • Sur 8 octets, la valeur du uname de la machine qui héberge
    le serveur iFOR/LS. Vous l'obtenez en passant la commande uname -m.
    
  
  

  
  Ainsi :
  

  
  
  • Un UUID est étroitement lié au système hébergeant le serveur de licences qui l'a généré.
    
  • Deux UUID créés sur le même système seront toujours distincts l'un de l'autre.
    
  
  

Avantages de la cellule alternée

• Un client iFOR/LS appartient à une cellule alternée s'il possède le fichier
  /etc/ncs/glb_obj.txt du serveur iFOR/LS duquel il souhaite obtenir les licences.
  
• Un client qui ne possède pas de fichier /etc/ncs/glb_obj.txt ne
  peut pas faire partie d'une cellule alternée, ni accéder à ses licences.
  
• L'administrateur du serveur de licences détient seul le droit d'autoriser ou non
  la duplication de ce fichier sur les clients de son choix.
  
• La cellule alternée est le seul moyen de conserver un contrôle
  total sur l'environnement NetLS que l'on a choisi.
  
  C'est le choix le plus recommandé.
  

Le fichier des utilisateurs : "user_file"

Exemple d'utilisation

Or, un système client ne peut appartenir qu'à une seule cellule à la fois...

• La première solution consiste à créer :
  
  
  
  • Une cellule CATIA, distribuant uniquement des licences CATIA.
    
  • Et une cellule Cset&supplus.&supplus., distribuant uniquement des
    licences Cset&supplus.&supplus..
    
  
  Mais dans ce cas, un utilisateur de CATIA qui souhaite compiler ne peut pas le faire,
  sauf si une licence Cset&supplus.&supplus. est introduite sur le serveur iFOR/LS de la
  cellule CATIA ; mais alors tous les utilisateurs de la cellule CATIA peuvent
  accéder à cette licence...
  

• Dans la cellule CATIA, si nous souhaitons restreindre l'accès du Cset&supplus.&supplus.
  à certains utilisateurs, il faut mettre en oeuvre un fichier user_file.
  
  Ainsi, il n'est même plus nécessaire de créer des cellules séparées pour les groupes CATIA et
  Cset&supplus.&supplus. car les limitations d'accès, pour chaque utilisateur,
  se décident au niveau du user_file.
  
  Ce fichier doit être placé dans le répertoire /usr/lib/netls/conf.
  

Exemple de fichier "user_file"

+--------------------------------------------------------------------------------+ | | |vendor "IBM Software Solutions Toronto" "IBM C for AIX" | |allow ouioui -p 2 bud jyb -p 1 fred | |vendor "Dassault Systemes" all | |disallow gloups | | | +--------------------------------------------------------------------------------+

Explications

• Le produit "IBM C for AIX" du vendeur "IBM Software Solutions Toronto" peut être
  utilisé par les utilisateurs ouioui, bud, jyb, et fred.
  
• L'utilisateur ouioui est en priorité 2.
  
  Les utilisateurs bud et jyb sont en priorité 1, la plus haute.
  
  L'utilisateur fred n'a pas de priorité décrite, son défaut est donc 3, la plus basse.
  
• Aucun autre utilisateur n'est autorisé à utiliser le produit "IBM C for AIX".
  
• "all" signifie que tous les produits du vendeur "Dassault Systemes"
  ont le même niveau de priorité.
  
  Donc tous les utilisateurs, sauf gloups, pourront accéder à ces produits.
  
• D'autres mots-clefs peuvent être employés pour décrire les accès,
  mais leur usage est plus spécifique.
  
  Vous pouvez consulter le "iFOR/LS system management guide" - SC23-2665.
  

Le "moteur" iFOR/LS

• llbd (Local Location Broker Daemon)
  est le gestionnaire de la base de données locale LLB.
  
• netlsd (NETwork Licence Server Daemon)
  est le gestionnaire de distribution des licences aux clients.
  
• glbd (Global Location Broker Daemon)
  est le gestionnaire de la base de données globale.
  

llbd : le gestionnaire de la base de données locale

• Conserve des informations sur les gestionnaires principaux glbd et netlsd.
  
• Permet la communication vers ou entre les gestionnaires principaux.
  

netlsd : le gestionnaire de distribution des licences

• Distribuer une licence d'utilisation à un client.
  
• Vérifier si le client a toujours besoin de la licence : le heartbeat,
  intervalle de vérification, est fixé à 15 minutes par défaut. Cette
  valeur est définie au niveau de chaque application par le fournisseur
  (la valeur du heartbeat est un choix technique
  fait par le fournisseur du produit lors de sa conception).
  
  Lorsqu'elle démarre, l'application transmet son heartbeat au serveur iFOR/LS.
  
• Décider de l'action à entreprendre s'il n'y a plus de licence disponible :
  
  
  
  • Attribuer un jeton, bien que les droits soient épuisés (softstop).
    
  • Ou ne pas attribuer de jeton (hardstop).
    
    Dans ce cas :
    
    
    
    • Prévenir le client de la situation par un message,
      
    • Mettre ou non le client en file d'attente, etc.
      
    
    Cette décision de hardstop ou de softstop est un choix marketing
    fait par le fournisseur du produit lors de sa conception.
    
  
  

netlsd "écoute" dynamiquement sur un port affecté au démarrage, de
valeur supérieure à 1024.

glbd : le gestionnaire de la base de donnée globale

• Qui sont les clients et les serveurs qui font partie de
  l'environnement NetLS ? Où se trouvent-ils (adresse IP, numéro de port) ?
  
• Quelles licences ont été distribuées et à quels clients ?
  
• Depuis combien de temps un client utilise-t-il une licence ?
  
• Reste-t-il des licences disponibles ? Etc.
  

Pour cela, il doit s'appuyer sur une base de données globale,
la GLB (Global Location Base) qui décrit la
topologie de l'environnement NetLS pour la cellule associée.

Cette base est gérée par le daemon glbd.

Les clients iFOR/LS

Aucun daemon llbd, glbd, ou netlsd ne doit y tourner, à moins bien
sûr que ce client ne soit en même temps le serveur de licence.

Le mode d'accès à une licence est le suivant :

• Un utilisateur lance une commande relative au logiciel (par exemple, une compilation).
  
• Le logiciel s'interroge : ai-je une licence pour fonctionner ?
  
  Cette fonction de validation d'une licence est une couche
  logicielle spécifique, que l'éditeur a intégrée à son produit lors de sa conception.
  
• Le logiciel vérifie l'existence d'une licence locale dans le fichier
  /usr/lib/netls/conf/nodelock.
  
  Si ce fichier n'existe pas ou est vide,
  alors il doit trouver un serveur de licences sur le réseau.
  

  
  

• Le logiciel vérifie l'existence du fichier /etc/ncs/glb_site.txt
  (nous verrons plus loin son utilité).
  
  Si ce fichier n'existe pas ou est vide,
  alors un broadcast est lancé sur le réseau afin de trouver un serveur de
  licences.
  
• Le broadcast s'adresse au système qui contient la GLB. Le daemon
  glbd reçoit la requête. Il la transfère au daemon netlsd si glbd
  et netlsd sont installés sur le même système. Sinon, il redirige le client
  vers le système possèdant le netlsd.
  
• Le serveur de licences netlsd distribue au client une licence d'utilisation.
  
  Le produit peut alors exécuter la commande.
  
  Sinon, le client n'obtient pas de licence, et la commande échoue.
  

Cependant, une cellule iFOR/LS s'affranchit de la topologie du réseau sous-jacent.
Ainsi, un client iFOR/LS peut faire partie de la même "cellule"
que votre serveur de licences, bien qu'il soit installé sur un réseau
situé à 5 routeurs de distance du réseau attaché à votre serveur...

Mais alors, comment le client peut-il "voir" votre serveur, puisque le broadcast
ne "traverse" pas les routeurs ?

C'est ici qu'intervient le fichier glb_site.txt.

Ce fichier contient la référence à votre serveur de GLB, sous la forme :

• ip:<Hostname>
  
  où <Hostname> représente le nom d'hôte de votre système.
  
• ip:#<adresse IP>
  
  où <adresse IP> représente l'adresse IPV4 de votre système.
  

Ainsi, le client ne lance plus de broadcast sur son réseau local,
mais s'adresse directement au système supporant le glbd, pour pointer
ensuite sur le serveur de licences netlsd.

Un client, situé sur le même réseau local que son serveur, a tout
intérêt à utiliser quand même ce fichier /etc/ncs/glb_site.txt ; ceci
élimine les broadcasts qui chargent inutilement le réseau.

Enfin, ce fichier peut contenir plusieurs lignes, chacune référençant
un serveur différent, à la manière des fichiers /etc/resolv.conf du DNS.

Ainsi, vous pouvez répartir la charge des requêtes de licences sur votre réseau
entre plusieurs serveurs, chaque groupe d'utilisateurs référençant
en priorité son propre serveur, puis celui des autres groupes en backup.

Dans ce cas, lorsqu'une requête de licence échoue auprès du
premier serveur de la liste, le second est sollicité après un délai (timeout),
puis le suivant, etc.

Configurations diverses

GLB séparée du netlsd

--------------     1      --------------    2       --------------
|  système A | <--------  |  client    | ---------> |  système B |
|   GLB      |  serveur?  |            | licence ?  |            |
|    glbd    | ---------> |            | <--------- |   netlsd   |
|    llbd    |  syst.B    |            |    OK !    |   llbd     |
--------------            --------------            --------------
 

Dans ce cas, lorsque le client recherche une licence, la requête est
dirigée sur le système qui héberge le GLB (opération 1).

Le glbd
précise alors au client la localisation du serveur qui héberge le netlsd.

La requête est alors dirigée sur le gestionnaire de licences (opération 2).

GLB dupliquée

Exemple

---------------          ---------------           ---------------
|  système A  |          |  système B  |           |  système C  |
|     GLB     |          |     GLB     |           |             |
|    glbd     |          |    glbd     |           |   netlsd    |
|    llbd     |          |    llbd     |           |   llbd      |
---------------          ---------------           ---------------
 

Dans ce cas, chaque hôte d'une GLB doit supporter un glbd.

Cette configuration nécessite de garantir la bonne reproduction et la
synchronisation périodique des bases. C'est le gestionnaire de
reproduction des données drm (Data Reproduction Manager)
qui s'assure de ce travail.

drm fait partie du glbd.

L'outil drm_admin permet de gérer ces mises à jour.

netlsd dupliqués

 
---------------          ---------------           ---------------
|  serveur A  |          |  serveur B  |           |   client    |
|   netlsd    |          |   netlsd    |           |             |
|     GLB     |          |     GLB     |           |             |
|    glbd     |          |    glbd     |           |             |
|    llbd     |          |    llbd     |           |             |
---------------          ---------------           ---------------
 
 

Il faut comprendre qu'une limitation demeure : chaque licence
est liée à son système serveur par son uname. Si un serveur tombe,
les licences correspondantes ne peuvent pas être transférées sur l'autre
serveur disponible.

Exemple :

Dans une cellule de 40 utilisateurs, qui contient 2 serveurs
de 10 licences, la chute d'un serveur entraîne le partage, en mode
dégradé, des 10 licences restantes parmi les 40 usagers.

Cette duplication des serveurs impose également un travail de maintenance,
pour synchroniser les GLB lorsque l'un des serveurs tombe.

glbd et netlsd ensemble

 
---------------
|   netlsd    |
|     GLB     |
|    glbd     |
|    llbd     |
---------------
 

Ordre de démarrage et arrêt des daemons

• Un llbd doit toujours être démarré AVANT un glbd ou un
  netlsd, car ces deux serveurs s'appuient sur la LLB pour communiquer.
  
• Un glbd doit toujours être démarré AVANT un netlsd, car
  ce dernier s'appuie sur la GLB pour gérer les licences.
  

Donc l'ordre de démarrage doit toujours être :

1. llbd
   
2. glbd
   
3. netlsd
   

L'ordre inverse doit être utilisé lors de l'arrêt des daemons.

Pour éviter les erreurs, deux commandes font ce travail à notre place :

• srv_start démarre les daemons dans l'ordre.
  
• srv_stop stoppe les daemons dans l'ordre inverse.
  

Lorsque l'administrateur fait un boot sur un système serveur de
licences flottantes, l'ordre de démarrage des daemons llbd, glbd, et
netlsd est déterminé par l'exécution des fichiers etc/rc.ncs, puis
/etc/rc.netls, telle qu'elle est décrite dans /etc/inittab :

+--------------------------------------------------------------------------------+ | | |rcncs:2:wait:sh /etc/rc.ncs > /dev/console 2>&1 Start NCS | |netlsd:2:wait:sh /etc/rc.netls >/dev/console 2>&1 Start netls | | | +--------------------------------------------------------------------------------+

Note: Ces deux lignes sont ajoutées dans /etc/inittab selon les
choix effectués lors de l'exécution du script netls_config, lors de
l'installation du serveur iFOR/LS.

Par contre, à l'arrêt du système, l'ordre d'arrêt de ces mêmes daemons
n'est, à priori, décrit nulle part...

Donc, si les daemons ne sont pas stoppés dans le bon ordre par le système,
leur redémarrage se passe généralement mal : soit le glbd,
soit le netlsd tombe sans que personne ne comprenne pourquoi,

Il suffit, dans ce cas, de lancer un
srv_stop suivi d'un srv_start pour que tout rentre dans l'ordre.

Pour éviter ce désagrément, une solution simple consiste à rajouter
la commande srv_stop dans le script de la commande /usr/sbin/shutdown.

Synthèse

• Serveur(s) et clients sont dans une cellule alternée.
  
• Chaque client n'a besoin que :
  
  
  
  • D'un glb_obj.txt pour appartenir à la cellule alternée.
    
  • D'un glb_site.txt qui pointe sur le système hôte du GLB pour ne pas
    polluer le réseau avec des broadcasts inutiles.
    
  • Des applications nécessitant les licences.
    
• Un client n'a pas besoin de tourner de llbd, glbd ou netlsd.
  
• Si possible, un seul serveur de licences suffit.
  

Mise en oeuvre d'un environnement iFOR/LS

Obtention des clefs de licences

Si vous avez besoin d'obtenir des clefs de licences, les coordonnées
du centre IBM qui gère ces demandes sont les suivantes :

IBM Software Manufacturing Solutions, Denmark

Sortemosevej 21

DK-3450, Alleroed

Denmark.

• Heures d'ouverture : de 8H00 à 23H00.
  

• Tél : 0 800 91 02 12 (Votre interlocuteur parle français)
  

• Fax : 45 48 14 22 07 (Directement depuis la France)
  

• e-mail : DKIBM06@IBMMAIL
  
  ou :     DKIBM06@IBMMAIL.COM
  

Si vous souhaitez obtenir de nouvelles clefs ou un
remplacement des clefs actuelles, si votre système connaît un problème
de uname, vous devez fournir les renseignements suivants :

• Code client :
  
• Nom du demandeur :
  
• Tel :
  
• Fax :
  
• Numéro du code logiciel (format xxxx-xxx) :
  
• Nombre d'utilisateurs :
  
• Date d'expiration :
  
• Type de clef (Nodelock, Concurrent) :
  
• Type et niveau du système d'exploitation :
  
• uname -m du système :
  
• Valeur du champ "licence annotation" (identique au nombre d'utilisateurs) :
  

Nettoyage d'un environnement iFOR/LS

Entrer les licences dans le serveur est un travail fastidieux... Si
vous souhaitez ne pas avoir à le refaire lors de la seconde installation,
il ne faut pas effacer les fichiers lic_db.bak et lic_db.

+--------------------------------------------------------------------------------+ | | |#!/bin/ksh | |srv_stop | |sleep 5 | |rm -f /etc/ncs/glb.e | |rm -f /etc/ncs/glb.p | |rm -f /etc/ncs/glb_site.txt | |rm -f /etc/ncs/glb_obj.txt | |rm -f /etc/ncs/glb_log | |rm -f /tmp/llbdbase.dat | |# fichiers à conserver si des licences ont déjà été entrées | |# rm -f /usr/lib/netls/conf/lic_db.bak | |# rm -f /usr/lib/netls/conf/lic_db | |rm -f /usr/lib/netls/conf/cur_db | |rm -f /usr/lib/netls/conf/log_file | |rm -f /usr/lib/netls/conf/list_targetids | |rmitab netlsd | |rmitab rcncs | | | +--------------------------------------------------------------------------------+

Préparation avant la mise en oeuvre d'un serveur iFOR/LS

1. Vérifiez la date et l'heure de votre système.
   
   Nous avons vu qu'une date incorrecte peut bloquer la disponibilité d'une clef de licence.
   
   
   
   • smit date
     

2. Vérifiez que le nom du système est correctement configuré sur votre serveur.
   
   D'une façon générale, toute la couche de communication basée sur TCP/IP doit être
   correctement paramétrée en fonction de votre environnement.
   
   
   
   • Le hostname de votre système est-il en phase avec le mécanisme de
     résolution de noms utilisé (DNS, NIS, ou /etc/hosts) ?
     
   • Dans le cas d'un SP2 ou d'une machine possédant plusieurs cartes
     réseaux, sur quel réseau allez-vous distribuer vos licences ? Quel
     est le nom de la carte correspondante ?
     
   • Votre serveur peut-il être atteint par la commande ping ?
     

3. Vérifiez que les ensembles de fichiers nécessaires sont installés :
   
   utilisez la commande lslpp -h <fileset_name>
   
   En AIX V4, les filesets sont :
   
   • X11.base.rte
     
   • X11.base.lib
     
   • X11.motif.lib
     
     Certains outils livrés avec iFOR/LS (ls_admin et ls_stat) ont des
     liens avec les bibliothèques X11 et nécessitent la présence des
     filesets X11, même si leurs interfaces graphiques ne sont pas utilisées.
     
   • bos.net.tcp.client
     
   • bos.sysmgt.loginlic
     
   • bos.net.ncs
     
     Contient les daemons NCS et des outils d'administration.
     
   • bos.ifor_ls.server
     
     Contient netlsd et les scripts de configuration.
     
   • bos.ifor_ls.client
     
     Contient des outils d'administration, des utilitaires et des écrans SMIT.
     

4. Pour pouvoir utiliser directement les différentes commandes et
   outils de iFOR/LS, rajoutez les chemins suivants dans la variable
   d'environnement PATH située soit dans /etc/environment, soit dans le
   fichier .profile de l'utilisateur root :
   
   
   
   • /usr/lib/netls/conf
     
     Contient le script de configuration netls_config, et les fichiers de gestion des licences
     (lic_db.bak, lic_db, cur_db, log_file, list_targetids).
     
   • /usr/lib/netls/bin
     
     Contient les outils de gestion du serveur de licences
     (ls_admin, srv_stop, srv_start, ls_tv, ...)
     
   • /usr/lib/ncs/bin
     
     Contient les outils de gestion du serveur de GLB (drm_admin, lb_admin,
     lb_find, ...).
     
   • /etc/ncs
     
     Contient les fichiers de gestion de la cellule (glb_obj.txt, glb_site.txt)
     et de la GLB (glb.e, glb.p, glb_log).
     
   
   

Préparation à la mise en oeuvre d'un client iFOR/LS

• Vérifiez la présence sur votre système du fileset bos.ifor_ls.client
  

• Parmi les différentes commandes et outils iFOR/LS, le client n'a
  besoin que de ceux lui permettant de vérifier l'existence sur le réseau
  d'un serveur de licences valide : ls_tv
  

• Rajoutez les chemins suivants dans la variable
  d'environnement PATH, située soit dans /etc/environment, soit dans le
  fichier .profile de l'utilisateur root :
  
  
  
  • /usr/lib/netls/bin pour utiliser ls_tv
    
  • /etc/ncs pour gérer glb_obj.txt et glb_site.txt
    
  
  

Cas particulier : plusieurs cartes réseaux sur le serveur iFOR/LS

Si le système sur lequel vous souhaitez installer votre serveur
possède plusieurs cartes réseaux, netls_config n'étant pas conçu pour
gérer une telle situation, les licences risquent d'être distribuées
sur un réseau qui ne vous convient pas...

Ce cas se présente souvent lorsque la console d'un SP2 est choisie comme serveur de licences.

Lorsqu'il y a plus d'un adaptateur actif, il n'y a aucun moyen pour indiquer explicitement à la
couche NCS quel adaptateur réseau utiliser. NCS en choisira un au hasard, chaque fois que les
daemons NCS (llbd et glbd) seront démarrés.

Exemple

---------------            ---------------             ---------------
|             |            |   serveur   |             |   client    |
|             |  réseau    |   netlsd    |    réseau   |             |
|             |---------en0|     GLB     |tr0----------|             |
|             |    A       |    glbd     |      B      |             |
|             |            |    llbd     |             |             |
---------------            ---------------             ---------------
 

Si vos licences sont distribuées sur le réseau A alors que vous
les attendiez sur le réseau B, vous avez toujours la possibilité
de rendre votre système "routeur" par la commande :
no -o ipforwarding=1.

Ainsi, un client du réseau B pourra accéder aux licences distribuées sur le réseau A,
en traversant le serveur, à condition d'avoir un glb_site.txt qui pointe
correctement sur l'adresse IP ou le nom de la carte "en0".

Cependant, il est préférable de distribuer les licences directement là où elles sont nécessaires...

La seule façon de forcer NCS à se placer sur la carte de notre choix, consiste à s'assurer
que toutes les autres cartes réseaux sont inactives durant le démarrage des daemons NCS.

Ceci peut se faire à deux moments :

• Au boot du système.
  
• Lors du recyclage des process NCS, avec la commande srv_start.
  

Inactiver toutes les interfaces réseaux, sauf une, peut avoir un impact
majeur si elles sont déjà en cours d'utilisation lorsque
l'administrateur décide de reconfigurer son serveur de licences.

Une telle manoeuvre est à proscrire sur un système en production.

Il convient donc de bien choisir son moment pour effectuer cette manoeuvre...

La procédure décrite au chapitre suivant peut être utilisée pour forcer temporairement
NCS à se placer sur l'interface de votre choix. Cependant, ce choix ne
persistera que jusqu'au prochain redémarrage des daemons NCS.

Forçage temporaire du serveur iFOR/LS sur une carte

• Une carte Token Ring (tr0),
  
• Et une carte Ethernet (en0).
  

Il va donc falloir inactiver l'interface en0 et garder active l'interface
tr0 pendant le redémarrage des daemons NCS :

• srv_stop (stoppe les daemons NCS)
  
• ifconfig en0 down (inactive la carte en0)
  
• ifconfig en0 detach (retire l'interface de la liste des interfaces réseau)
  

• srv_start (redémarre les daemons NCS sur l'interface tr0)
  
• chdev -l en0 -a state=up (réactive l'interface
  en0 pour les autres process.)
  

Forçage permanent du serveur iFOR/LS sur une carte

Vous pouvez également configurer de la même façon le script de la
commande srv_start en faisant attention au point suivant :
il faut, dans ce cas, prévoir un message de WARNING pour prévenir l'opérateur qu'il est
sur le point de stopper l'interface XXXX, ou les interfaces XXXX, YYYY, ZZZ, ...

Il faut alors proposer le choix entre :

• Continuer l'opération (à ses risques et périls)
  
• Quitter sans désactiver les interfaces
  

Note: De telles modifications peuvent éventuellement être perdues
si des PTF viennent mettre à jour des filesets NCS ou NETLS...

Pensez donc à garder une copie des fichiers modifiés.

Installation d'un serveur iFOR/LS dans une nouvelle cellule alternée

1. Mettez-vous en langue américaine : export LANG=C
   

2. Lancez le script netls_config
   
   A la série de questions qu'il vous pose, répondez :
   
   
   
   • Q - Do you want the "llbd" started automatically when the machine boots ?
     
     R - " y "
     
   • Q - Do you want "netlsd" started automatically when the machine boots ?
     
     R - " y "
     
   • Vous pouvez éventuellement rencontrer la question suivante :
     
     Q - There exists an initialized database already for the glbd. Do you wish to
     use that database when starting the "glbd" daemon ?
     
     R - " n " (Dans la mesure où vous souhaitez
     créer une nouvelle cellule alternée.)
     
   • Une liste de toutes les cellules que votre machine peut identifier
     dans votre environnement réseau vous est alors présentée :
     
     
     
     • Si vous installez votre machine dans une nouvelle cellule alternée, ces
       informations ne vous sont pas utiles.
       
     • Si vous avez l'intention de rejoindre une cellule alternée existante, notez le numéro
       attribué à cette cellule (ces numéros peuvent être affectés de façon différente chaque fois
       que netls_config est lancé, en fonction de la rapidité de réponse des serveurs).
       
     
     
   • Trois ou quatre options vous sont alors présentées (l'option 4 n'apparaît pas
     si aucune cellule alternée n'est détectée) :
     
     
     
     • 1 - Continue with installation without choosing a Cell Name.
       
     • 2 - Use the default for the system Cell Name.
       
     • 3 - Create a new alternate cell for the system Cell Name.
       
     • 4 - Choose an existing alternate cell for the system Cell Name.
       
     
     
     
     
     1. Choisissez " 1 "
        
        si vous ne savez pas quelle configuration choisir et souhaitez quitter le script.
        
        Vous devrez relancer Netls_config plus tard.
        
     2. Choisissez " 2 "
        
        si vous êtes seul ou si vous êtes d'accord pour que
        tous les systèmes de votre réseau aient accès à vos licences.
        
     3. Choisissez " 3 "
        
        si vous lancez votre serveur dans une nouvelle cellule alternée.
        
     4. Choisissez " 4 "
        
        si vous rejoignez une cellule existante.
        
        Le numéro de la cellule que vous souhaitez rejoindre vous est alors demandé :
        entrez ce nombre.
        
     
     
   
   

3. Lorsque le script netls_config a fini de tourner, il a créé
   un nouveau script nommé netls_first_time, lancez ce dernier.
   
   Les daemons nécessaires au serveur de licences sont alors lancés.
   
   Ce script n'est lancé qu'une fois : les démarrages et arrêts ultérieurs des
   daemons seront assurés par les commandes srv_start et srv_stop.
   

4. Vérifiez avec la commande ls_tv que votre serveur est correctement configuré.
   

   
   

   L'installation est terminée.
   

5. Si nécessaire, entrez vos licences avec l'utilitaire graphique ls_admin
   

6. Et pour finir, ajoutez la commande srv_stop
   dans le script de la commande /usr/sbin/shutdown
   (voir le chapitre "Ordre de démarrage et arrêt des daemons").
   

Synchronisation de GLB multiples

Dans ce cas, une solution simple existe, il faut resynchroniser les GLB
en suivant la procédure suivante :

• export LANG=C
  
  passage en langue américaine.
  

• cd /etc/ncs
  
  positionnement dans le répertoire des outils iFOR/LS.
  

• lb_admin
  
  lancement de l'outil lb_admin.
  

• lb_admin: use local
  
  positionnement sur le LLB.
  

• lb_admin: clean
  
  effacement des entrées invalides dans le LLB.
  
  Si l'outil vous demande une confirmation des suppressions, entrez "y".
  

• lb_admin: use global
  
  positionnement sur le GLB.
  

• lb_admin: clean
  
  effacement des entrées invalides dans le GLB.
  
  Si l'outil vous demande une confirmation des suppressions, entrez "y".
  

• lb_admin: quit
  
  sortie de l'outil lb_admin.
  

• drm_admin
  
  lancement de l'outil drm_admin.
  

• drm_admin: set -o glb -h ip:<HOSTNAME>
  
  où <HOSTNAME> représente le nom du système qui "tourne" le GLB.
  

• drm_admin: merge_all
  synchronisation des GLB dans la cellule.
  
  
  
  • Si des messages apparaissent déclarant qu'un hôte ne peut être atteint,
    il faut le retirer de la liste du GLB avec la commande suivante :
    

    
    drm_admin: purgerep ip:<HOSTNAME>
    
    où <HOSTNAME> représente le nom du système déclaré non joignable.
    

    
    

    Note: Si un système est purgé de la liste, il ne doit plus faire tourner de GLB.
    
    Si un GLB doit tourner sur ce système, il faut à nouveau le configurer
    avec le script netls_config et le joindre à la cellule.
    

  
  

  
  

• drm_admin: merge_all
  
  synchronisation des GLB selon la liste obtenue à la suite des purges.
  

• drm_admin: quit
  
  sortie de l'outil drm_admin.
  

Les outils d'administration d'IFOR/LS

Table 2. Outils de gestion de l'environnement de licences.

Domaine	Outils	Utilisation
Les outils de la couche NCS	lb_find	Va voir, au-delà de la cellule proche, quels sont les autres serveurs iFOR/LS du réseau. Permet de trouver et délivrer un UUID de cellule existante.
	lb_admin	Enregistre les serveurs NCS dans les Bases de Données GLB ou LLB. Utilisé en consultation, ajout et suppression d'entrées dans une Base de Données désignée.
	drm_admin	Gère les reproductions des Bases de Données de GLB : recopie, fusion, interruption, suppression.
Les outils de la couche iFOR/LS	ls_targetid	Donne le uname du système.
	ls_stat	Affiche les informations sur l'état des licences sur le réseau (disponibilité).
	ls_admin	Outil graphique. Edite la base de données des licences. Permet d'ajouter et de supprimer des fournisseurs, des produits, des licences.
	ls_rpt	Génère des rapports sur les évènements du serveur : reporting, contrôle.
	ls_tv	Vérifie que les serveurs de licences fonctionnent et indique quels sont les serveurs actifs.
	ls_dpass	Permet d'accéder à des licences complexes et de les gérer.
	uuid_gen	Permet de générer un nouvel UUID.
	srv_start	Démarre les daemons dans l'ordre.
	srv_stop	Stoppe les daemons dans l'ordre.
Les fichiers de base de données dans /usr/lib/netls/conf	lic_db	Informations fournisseur, produits, licences.
	lic_db.bak	Sauvegarde de la Base de Données des licences.
	cur_db	Informations sur l'état courant des licences (fichier binaire chiffré).
	nodelock	Fichier plat contenant les licences nodelock.
Les fichiers de base de données dans /etc/ncs	glb.e	Contient le fichier de la Base de Données du GLB.
	glb.p	Contient la file d'attente de propagation du GLB.
	glb_obj.txt	Contient l'UUID qui identifie de façon unique une cellule alternée.
	glb_site.txt	Contient la liste du (des) serveur(s) de licences de la cellule considérée : adresse IP ou hostname.

Utilisation de LUM en AIX V4.3, V4.2 ou V4.1