Editorial


La gestion des licences : de iFOR/LS @ LUM (2ème partie)

Jean-Luc GESTIN et Damien OZENNE

Introduction

La première partie de cet article, traitant principalement du produit iFOR/LS, a été publiée dans "Les Cahiers d'AIX" numéro 23.
Cette deuxième et dernière partie traite de l'utilisation du produit LUM en AIX V4.3, V4.2, ou V4.1.

A partir d'AIX V4.3, la gestion des licences est assurée par LUM V4.0 (Licence Use Management system). Il s'agit de la version améliorée du produit iFOR/LS (information For Operating and Retrieval/ Licensing System).
LUM assure la compatibilité ascendante avec iFOR/LS et NetLS, donc un environnement de licences existant reste préservé.

D'autre part, LUM est présent chez d'autres constructeurs : vous pouvez donc le trouver sur les systèmes Sun(TM), SiliconGraphics(TM), HewlettPackard(TM), Microsoft(TM)...

Les nouveautés de LUM :

Par rapport @ iFOR/LS, LUM est enrichi de nombreuses fonctions, mais une personne familiarisée avec iFOR/LS peut facilement "retrouver ses marques".

Voici les différences dont il faut avoir connaissance :

Licence "vendor-managed" versus licence "user-managed"

Produit "vendor-managed"
Avec iFOR/LS, les produits sont "vendor-managed" : leur distribution est étroitement contrôlée par le vendeur du produit. L'inconvénient de ce système c'est que lorsque le serveur de licences devient indisponible, il faut, pour utiliser ces clefs sur un autre serveur, demander au centre de Copenhague des clefs neuves basées sur le nouvel "uname". Ceci peut retarder le retour en production.

Produit "user-managed"
Avec LUM, les produits peuvent être "user-managed", selon le choix fait par le vendeur, concepteur du produit.

Pour un produit "user-managed", le vendeur fait confiance @ l'administrateur pour gérer consciencieusement l'usage des licences qu'il achète.
Cette évolution accompagne l'évolution des moeurs dans les métiers de l'informatique : l'utilisation de logiciels sans licence n'est plus le fait que d'utilisateurs privés, @ domicile.

Ceci est rendu possible par la mise @ disposition de licences multiples depuis un "fichier réservoir" appelé "Enrollment Certificate File" ou E.C.F.
Le nombre de licences disponibles est précisé dans le champ "LicenceCount" de l'E.C.F.

Les avantages de ce type de gestion sont :

La modularité d'utilisation est alors maximale.
En contrepartie, LUM offre des outils pour gérer les utilisations qui dépassent les licences achetées.

"Enrollment Certificate File"

L'Enrollement Certificate File est un fichier particulier, fourni par le vendeur sur le support du produit (CD-Rom).

Pour chaque produit, deux fichiers sont le plus souvent fournis :

Ces fichiers sont installés sur le système en même temps que le produit lui-même. Leur localisation est variable.
Par exemple :

L'ECF contient deux types d'informations :

Les pré-paramétrages de la commande i4blt déterminent, entre autres, le nombre maximum de licences qui pourront être extraites de l'E.C.F et leur durée de validité.
Ils ne sont pas modifiables.
Deux paramètres restent du ressort de l'administrateur :

Parmi les paramètres de licences, on trouve :

Licences "simple" ou "compound"

Le vendeur peut créer deux styles de licences, simples ou composées, qui correspondent au type de mot de passe utilisé pour la licence dans l'E.C.F. Dans l'E.C.F, une licence "compound" est identifiée avec le paramètre LicenseStyle=Compound, et le type de licence distribué est indiqué par le paramètre DerivedLicenseType.
Pour une licence simple, le type de licence est indiqué par le paramètre LicenseStyle.

Administration éloignée des serveurs

Depuis un seul serveur principal, les outils d'administration fournis avec LUM permettent de gérer plusieurs serveurs de licences éloignés. C'est par exemple le cas dans un environnement de licences multiserveurs au sein d'une même cellule.
Le serveur principal est celui sur lequel le Central Registry est mis en oeuvre.

Pour tenir le rôle de serveur principal LUM, il est intéressant de choisir un système déj@ orienté "communications" (serveur NFS, DCE, NIM, ...).

Parmi les services éloignés disponibles, fournis par i4blt, notons :

Il est donc fortement recommandé de ne pas désactiver cette possibilité d'utilisation éloignée.

Le Central Registry

La plus grande liberté accordée aux utilisateurs de licences "user-managed" implique sa contrepartie : l'obligation, incombant @ l'administrateur, de se mettre en règle avec les vendeurs si les impératifs de production l'obligent @ utiliser des licences non payées.

Le Central Registry joue de ce fait un rôle clef :

Le Central Registry est nécessaire pour gérer des licences réseau.
Il doit y en avoir :

Le choix de la machine hébergeant le registre central est très important car, une fois configuré, il ne pourra plus être déplacé par la suite.
De plus, le registre central est utilisé ponctuellement ou régulièrement par le produit, suivant le type de licence utilisé.

La gestion des dépassements de licences

Deux outils sont proposés pour permettre cette gestion :

Le "threshold"
Le threshold est un seuil exprimé en pourcentage du nombre de licences disponibles.
Il varie de 0 @ 100%. Si le nombre de licences utilisées simultanément est supérieur au seuil considéré, des messages sur ce niveau d'utilisation sont inscrits dans les fichiers de log.
Ceci permet de surveiller la montée en charge d'un type de produits, pour anticiper le moment o¦ un achat de licences supplémentaires sera nécessaire.

Le "high-water mark"
Le "high-water mark" indique le nombre maximum de licences "softstop" utilisées au-del@ du nombre de licences enregistrées pour un produit.
Il permet de mesurer l'ampleur du dépassement effectif du nombre de licences achetées, et donc d'y remédier.
Bien sûr, ce niveau n'a pas de raison d'être lors de l'utilisation d'un produit qui travaille selon la police "hardstop".

Les fichiers de "logging"

Il existe trois fichiers de logging :

Ces fichiers contiennent tous les événements collectés par LUM.
Le choix des événements collectés se détermine lors de la configuration du serveur correspondant, par "i4cfg -script". Il est ensuite possible d'éditer le fichier i4cfg.ini, pour modifier, en fonction des besoins spécifiques, les champs : LogGrant, LogCheckin, LogWait, LogVendor, LogProduct, LogTimeout, LogErrors, LogVendorMsg, LogSvrStartStop.

Le nombre de fichiers de logging et la taille maximale de chacun d'eux, se paramètrent après la configuration du serveur. Il faut alors éditer le fichier i4ls.ini, qui garde la mémoire de ce qui a été configuré, et modifier les paramètres :

Quand un fichier de log est plein, un nouveau est démarré.
Le nombre maximum de fichiers de log (nn) varie de 00 @ 99, puis la nouvelle version du fichier 00 vient écraser l'ancienne 00.

La version courante du fichier de log est suffixée par le symbole "_".
Exemple :


+--------------------------------------------------------------------------------+
|

| |logdb00 | |logdb01_ | |logdb02 | |

| +--------------------------------------------------------------------------------+


Dans le schéma ci-contre, o¦ l'on utilise trois fichiers de log, l'ordre de remplissage a été : 00, 01, 02, puis @ nouveau 00 et 01.
Le fichier courant est logdb01_, le précédent est logdb00 et le plus vieux est logdb02.


Afin d'éviter la saturation du filesystem o¦ vos logs s'incrémentent, vous pouvez supprimer les logs dont l'entrée est antérieure @ la date de votre choix, gràce @ la commande :

Police "softstop" versus police "hardstop"

Cette notion existait déj@ avec iFOR/LS, bien que peu utilisée.

La notion de police hardstop s'accorde naturellement avec une utilisation des licences du type "vendor-managed", comme c'est le cas avec iFOR/LS.

La notion de police "softstop" était minoritaire avec iFOR/LS. Elle devient la règle pour tous les produits qui choisissent de travailler avec des licences "user-managed" en LUM.

Règles "vendor-controlled" versus "customer-controlled"

La plus grande liberté laissée @ l'administrateur sur sa gestion des licences, s'accompagne d'une plus grande latitude @ fixer lui-même les règles du jeu.
Certaines règles restent sous le contrôle du vendeur, tandis que d'autres passent sous le contrôle de l'administrateur.

Règles "customer-controlled"

Basculement hardstop/softstop
L'administrateur peut choisir de basculer des produits softstop en police hardstop, afin d'interdire la multiplication des utilisations illicites, et donc de mieux maîtriser son environnement.

Basculement per-server/per-seat
L'administrateur peut choisir de basculer des produits travaillant avec une police "per-server" en police "per-seat". Dans ce cas, le retour en police "per-server" n'est plus possible (voir le chapitre "Les différents types de licences").

Restriction d'accès par "user_file"
Cette notion existait déj@ en iFOR/LS, mais uniquement pour les serveurs de licences réseau.
Cette possibilité est maintenant étendue aux licences nodelock tournant sur une seule machine. Alors que cette licence était auparavant disponible @ tous les utilisateurs de la machine, son utilisation peut dorénavant être restreinte @ certains utilisateurs, par user_file.
Pour gérer ce fichier, un nouveau daemon fait son apparition : "i4llmd" qui est le gestionnaire de serveur de licence nodelock.

Règles "vendor-controlled"

Try & Buy
La licence est @ durée limitée.
Le décompte démarre au premier enregistrement ou au premier lancement du produit.
Ces licences sont destinées @ un usage commercial.

Multi-use
Une seule licence de ce type permet des invocations multiples du même produit.
Cet usage est adapté, chez les développeurs, pour des campagnes de compilations. Ceci permet d'éviter l'écroulement du réseau sous les requêtes de licences, lorsque des programmes de compilations automatisées sont lancés.

File d'attente de produit
Selon la conception du produit, une file d'attente peut être prévue ; si toutes les licences disponibles sont en cours d'utilisation, le client surnuméraire est mis en file d'attente de disponibilité d'une licence.

Licence annotation
Ce champ est mis @ la disposition du vendeur pour modifier l'usage de ses licences selon des critères spécifiques : groupes de facturation, etc.

Hardstop/softstop
Nous avons vu ces règles plus haut...
La décision ultime de rendre son produit utilisable selon les polices hardstop ou softstop, reste du ressort du vendeur.

"Namespace binding" versus "direct binding"

Backups automatique et manuel de l'environnement LUM

Parce qu'une panne de serveur de licences a des impacts directs sur la production d'un grand nombre d'utilisateurs, LUM intègre une procédure de backup de l'environnement de licences.
Cette fonction permet de sauvegarder le serveur de licences dès sa configuration terminée, afin de restaurer un environnement neuf en cas de problème.

Il existe deux types de backup :

Le backup automatique des serveurs de licences
LUM exécute un backup automatique et périodique sur les serveurs de licences, en copiant les fichiers et les bases de données LUM sous /tmp.
Les éléments sauvegardés sont listés dans le script /var/ifor/scripts/db_back.sh.
Les caractéristiques du backup doivent rester homogènes sur les serveurs d'une même cellule.
Le fichier i4ls.ini propose plusieurs paramètres pour gérer ce backup :

En cas de corruption, la procédure de réinstallation du backup est la suivante :

Le backup manuel des clients de licences réseau
On peut démarrer la procédure de backup en exécutant le script /var/ifor/scripts/db_back.sh.
Cette commande copie les fichiers et les bases de données dans le fichier de backup : /tmp/iforls_bak_DATE_SERVERNAME.

En cas de corruption, la réinstallation du backup se fait par la commande suivante :
/var/ifor/scripts/db_recov.sh

Par exemple :
/var/ifor/scripts/db_recov.sh /tmp/iforls_bak_DATE_SERVERNAME

Les différents types de licences

Avec NetLS ou iFOR/LS
NetLS ou iFOR/LS proposent les licences suivantes, selon les types de configurations :

Avec LUM
En plus des licences ci-dessus, LUM permet d'utiliser les types de licences suivants, selon les configurations :

Les différents types de daemons

Le passage d'iFOR/LS @ LUM ne modifie pas la fa\on de travailler au niveau de la couche NCS : les daemons llbd et glbd subsistent en "namespace binding".

Par contre, LUM modifie la distribution des licences :

Séquence de démarrage et d'arrêt des daemons

Comme en iFOR/LS, cette séquence est cruciale pour le fonctionnement harmonieux de l'ensemble. Elle l'est d'autant plus que le nombre de daemons @ exécuter croît sensiblement.

Quand l'ensemble des daemons LUM est sollicité sur un système :

Afin d'épargner les mémoires défaillantes, voici quelques rappels :

Mise en oeuvre

LUM doit être installé sur chaque système AIX utilisant un produit géré par LUM, qu'il s'agisse d'un serveur de licences ou d'un client.

Installation de LUM

Liste des "packages" de LUM V4.0.2

Table 7. Liste des packages de LUM V4.0.2.
Package Remarques
ifor_ls.base Base LUM V4.
Contient ifor_ls.base.cli et ifor_ls.base.gui
ifor_ls.compat Compatibilité LUM V4.
Contient ifor_ls.compat.cli et ifor_ls.compat.gui
ifor_ls.libraries Obligatoire pour AIX v4.1 ou v4.2
ifor_ls.msg.en_US
ifor_ls.msg.fr_FR
ifor_ls.ipf.en_US
ifor_ls.ipf.fr_FR
ifor_ls.html.en_US
ifor_ls.html.fr_FR

Liste des "filesets" obligatoires de LUM (lslpp -l "*ifor*")

Table 8. Liste des filesets obligatoires de LUM (lslpp -l "*ifor*").
Filesets obligatoires Remarques
bos.net.ncs Network Computing System V1.5.1
bos.rte.ifor_ls Bibliothèques iFOR/LS
ifor_ls.base.cli Code LUM + commandes en ligne
ifor_ls.libraries Bibliothèques LUM (fileset inexistant sur certains AIX V4.3)
ifor_ls.msg.en_US.base.cli Messages pour le code LUM (en anglais)
ifor_ls.msg.fr_FR.base.cli Messages pour le code LUM (en fran\ais)

Liste des "filesets" optionnels de LUM

Table 9. Liste des filesets optionnels de LUM.
Filesets optionnels Remarques
ipfx.rte Requis pour LUM GUI
ifor_ls.base.gui Graphical User Interface LUM
ifor_ls.msg.en_US.base.gui Messages pour le GUI LUM (anglais)
ifor_ls.msg.fr_FR.base.gui Messages pour le GUI LUM (fran\ais)
ifor_ls.compat.cli Code de compatibilité LUM
ifor_ls.compat.gui GUI de compatibilité LUM
ifor_ls.msg.en_US.compat.cli Messages pour compatibilité LUM (anglais)
ifor_ls.msg.en_US.compat.gui Messages pour compatibilité GUI LUM (anglais)
ifor_ls.msg.fr_FR.compat.cli Messages pour compatibilité LUM (fran\ais)
ifor_ls.msg.fr_FR.compat.gui Messages pour compatibilité GUI LUM (fran\ais)
ifor_ls.html.en_US.base.cli Guide LUM html (anglais)
ifor_ls.html.fr_FR.base.cli Guide LUM html (fran\ais)

Les PTF d'adaptation nécessaires en AIX V4.1 et V4.2

En AIX V4.3
LUM V4 fait partie du BOS (Base Operating System) de AIX V4.3. Utilisez le CD-Rom 1/3 de la souche système pour le code LUM, et le CD-Rom 3/3 de la souche système pour la documentation en format html.

En AIX V4.1 et V4.2
La version LUM V4 est également utilisable en AIX V4.1 et AIX V4.2.
Dans ce cas, il faut rajouter :

Table 10. PTF @ appliquer.
Système APAR PTF Fileset Niveau AIX
AIX V4.1 IX77914 U457860 bos.net.ncs V1.5.1 4.1.3.4
IX46187 U448083 bos.rte.ifor_ls 4.1.3.2
IX65979 U449489

AIX V4.2 IX46187 U448419 bos.net.ncs V1.5.1 4.2.1.0 (pré-requis)
IX71268 U452381 bos.net.ncs V1.5.1 4.2.1.1
IX46187 U448452 bos.rte.ifor_ls 4.2.1.0 (pré-requis)
IX46187 U456835 bos.rte.ifor_ls 4.2.1.1
IX64105 U447258

Si l'on est en AIX V4.1 ou AIX V4.2, on peut trouver le code source de LUM V4 sur certains CD-Rom de produits langages :

Lors de la réception d'un tel produit, il est important de prendre le temps de lire la documentation "README.FIRST" fournie dans la boîte. Elle contient de nombreuses indications pour vous faciliter l'installation de LUM.

Note: Seul LUM V4 est valide pour les logiciels de développement AIX utilisant LUM (la version minimum conseillée est la 4.0.2).
La version précédente de LUM (LUM V1) peut éventuellement être installée sur votre système, mais seul IBM C for AIX V4.1 peut fonctionner avec LUM V1.
Il est donc important de vérifier la version installée.

Détermination de la version de LUM installée
Plusieurs méthodes sont utilisables pour déterminer la version de LUM installée sur le système :

Mise @ jour du code LUM
La dernière version de LUM disponible @ l'heure actuelle est la V4.0.3.
Elle peut être obtenue aux URL suivantes :

Configuration des serveurs de licences LUM

Après l'installation du code LUM, il faut configurer LUM sur chaque machine. Le détail de la configuration dépend du rôle de la machine dans l'environnement et du type de licence.

Effacement d'un environnement LUM
Si, @ la suite d'une série d'essais, on ne sait plus o¦ l'on en est de la configuration LUM, le plus simple est de tout nettoyer proprement.

Le script suivant permet d'effacer l'environnement LUM standard :


+--------------------------------------------------------------------------------+
|

| |ú|/bin/ksh | |i4cfg -stop | |sleep 10 | |rm -f /etc/ncs/glb.e | |rm -f /etc/ncs/glb.p | |rm -f /etc/ncs/glb_log | |rm -f /etc/ncs/glb_obj.txt (2) | |rm -f /etc/ncs/glb_site.txt (2) | | | |rm -f /var/ifor/*.dat | |rm -f /var/ifor/*.idx | |rmitab i4ls | |cp /var/ifor/i4ls.ini.bak /var/ifor/i4ls.ini | |

| +--------------------------------------------------------------------------------+



Migration de NetLS - iFOR/LS vers LUM
Il est possible de migrer vers LUM V4 @ partir des versions suivantes :

A l'installation de LUM, les opérations suivantes sont réalisées :

Enrichissement d'une configuration LUM existante
Après avoir migré un environnement existant de licences partagées iFOR/LS vers LUM, on obtient un serveur LUM de licences partagées travaillant en Namespace Binding, plus un serveur LUM de licences nodelock lancé par défaut.

Si l'on souhaite enrichir cet environnement sans perdre l'existant, il faut choisir avec soin les options de configuration lorsque l'on exécute i4cfg -script :

+-------------------------------------------------------------------------------------+
|

| |From a Licence Management point of view, you can choose to configure this system as :| | | |1. Network Licence Client | |2. Nodelock Licence Server (and/or Network Licence Client) | |2. Network (and/or Nodelock) Licence Server | |4. Central Registry (and/or Network and/or Nodelock) Licence Server. | | (*) Remember that one and only one Central Registry Licence Server | | (i4gdb daemon) can be active in a Licensing domain. | |

| +-------------------------------------------------------------------------------------+


Le script travaille par ajouts successifs et reconnaît les objets déj@ installés, s'ils sont décrits dans l'option que l'on a choisie.
S'ils ne sont pas décrits dans l'option choisie, LUM ne reconnaît pas les objets déj@ installés et la nouvelle configuration écrase l'ancienne.

Exemple
On possède un serveur de licences partagées.
On souhaite ajouter un serveur de licences nodelock sur le même système, sans perdre la configuration précédente.

Autre exemple
Le système est déj@ serveur de licences nodelock
On souhaite le configurer (via le réseau) comme "client" d'un serveur de licences partagées.
C'est le choix nó 2 qui convient.
Le choix nó 1 effacerait la configuration actuelle de serveur de licences nodelock.

Principe
Il faut respecter le principe suivant pour toutes les mises @ jour d'un environnement LUM :

La commande i4cfg -list permet de vérifier ce qui tourne sur le système.
On peut alors enrichir sa configuration en préservant l'existant.

Utilisation du "Direct Binding"
Si l'on souhaite utiliser le mécanisme de Direct Binding dans un environnement de licences, il faut respecter les points suivants :

Outil de configuration LUM
L'outil de configuration de l'environnement LUM peut être lancé sous deux présentations différentes :

Documentation LUM
Trois manuels sont disponibles :

O¦ trouver la documentation LUM ?
La documentation est disponible sous quatre (cinq) formats et en 10 langues (anglais, francais, allemand, italien, espagnol, etc.) :

  1. Format HTML. La documentation est consultable, gràce @ votre butineur préféré, dans le fichier :
    http:/usr/opt/ifor/ls/os/aix/doc/<language>

  2. Format IPF (Information Presentation Facility/6000).
    La consultation se fait gràce @ IPF (fileset : ipfx.rte). Par exemple, pour obtenir le manuel "Command Reference" exécuter :
    xview /usr/opt/ifor/ls/os/aix/doc/<language>/lumcmd.inf

  3. Format POSTSCRIPT.
    Le guide "Using License Use Management Runtime for AIX", fichier en anglais de 9,2 Mo et 224 pages, est disponible sur le Web @ l'adresse suivante :
    ftp://ftp.software.ibm.com/software/lum/aix/doc/V4/lumusg.ps

  4. Format PDF (Adobe Acrobat Reader)(TM).
    Même procédure que pour le format Postscript, mais @ l'adresse :
    ftp://ftp.software.ibm.com/software/lum/aix/doc/V4/lumusg.pdf

  5. Sous la forme de brochures traditionnelles.
    Il est possible de commander cette documentation, référence SH19-4346, auprès de :

    +--------------------------------------------------------------------------------+
    |

    | |IBM Direct | |Tél : 0 801 TEL IBM (0 801 83 54 26) | |Fax : 0801 329 426. | |

    | +--------------------------------------------------------------------------------+


Positionnement des PATH

Contrôle de l'environnement

Configuration d'un serveur de licences nodelock

Voici la marche @ suivre pour configurer un serveur de licences nodelock sur un système :

Configuration d'un premier serveur de licences réseau

Pour configurer un premier serveur de licences réseau sur un système, il est nécessaire d'installer préalablement un "Central Registry".

Voici la marche @ suivre :

Explications @ propos de "DCEDWAITTIME"
Le llbd NCS et le daemon DCE utilisent le même port TCP/IP Nó 135.
Or, si DCE est installé, le daemon DCE va se substituer au llbd.
Dans ce cas, LUM attend pendant 20 secondes que le daemon DCE démarre.
S'il ne démarre pas, alors llbd démarre.

Cette durée de 20 secondes est celle par défaut. Elle peut être modifiée par la variable DCEDWAITTIME dans le fichier i4ls.ini.

Configuration d'un client de serveur de licences réseau

En iFOR/LS, seule la configuration du serveur de licences réseau est nécessaire. Les clients de ce serveur n'ont besoin d'aucune configuration spécifique, si ce n'est celle des fichiers glb_site.txt et glb_obj.txt.

En LUM, une configuration simple des clients est nécessaire car il faut maintenant leur préciser :

Marche @ suivre
Lancer i4cfg -script, et donner les réponses suivantes :

Explications sur l'ordre d'apparition des cellules
Attention, l'ordre dans lequel la liste des cellules est présentée (alternate_1, alternate_2, alternate_3, ...) peut varier d'un run @ l'autre du script i4cfg -script.
En effet, cet ordre est déterminé en fonction de la vitesse @ laquelle est détectée chacune des cellules sur le réseau ; il dépend donc de la charge du réseau.

Les étapes de post-configuration

Equivalence des outils entre iFOR/LS et LUM

Table 14. Equivalence des outils entre iFOR/LS et LUM.
iFOR/LS LUM Outil servant @ :
netls_config
puis
netls_first_time
i4cfg (GUI)
ou
i4config
configurer le serveur de licences.
ls_tv i4tv
i4blt -ln
i4cfg -list
vérifier si le serveur est bien généré.
srv_start i4cfg -start démarrer les daemons dans l'ordre.
srv_stop i4cfg -stop stopper les daemons dans l'ordre.
ls_admin (¹) i4blt (GUI)
ou
i4blt -
enregistrer les licences flottantes.
XXXXXXXX i4nat enregistrer les licences nodelock.
(existait en LUM V1 mais a disparu en LUM V4)
ls_rpt (¹) i4blt -r générer un rapport d'événements.
ls_stat (¹) i4blt -s faire des statistiques sur l'usage des licences.
Note:
(¹) Ces commandes sont obsolètes en LUM et ne sont supportées que pour assurer une compatibilité ascendante avec les versions précédentes de LUM : NetLS, iFOR/LS et LUM V1.0.

L'outil universel : i4blt
En LUM, l'outil i4blt permet quasiment toutes les manipulations d'administration sur un serveur local ou éloigné.

Table 15. Commandes de "l'outil universel" i4blt.
Commande Fonction
i4blt -h Affiche l'aide de la commande.
i4blt -a Enregistrement des licences dans la base de données du serveur.
i4blt -U Update : modification des polices de licences hardstop/softstop, per-server/per-seat, ...
Active le high-water mark, et le remet @ zéro.
i4blt -d Suppression des licences de produits. i4blt -m Gère le threshold : % licences in use pour un produit donné.
i4blt -E Extrait les licences depuis une licence composée et les distribue sur d'autres serveurs.
i4blt -R Gère les licences réservables pour usage exclusif.
i4blt -l Affiche une liste des : -ls serveurs, -lp produits, -lv vendeurs, -ln serveurs actifs.
i4blt -s Génère des rapports statistiques sur l'usage des licences.
i4blt -r Génère des rapports d'événements d'après les fichiers de logs.
i4blt -C Cleanup : met @ jour le nombre de licences en cours d'usage.
i4blt -x Efface les fichiers de log du serveur de licences et du Central Registry.

Enregistrement des licences LUM
Selon le type de serveur LUM configuré, vous devez utiliser :

Procédure d'enregistrement des licences

Conseil
Pour plus de clarté dans la gestion des licences avec LUM ou la configuration de LUM, utiliser l'interface graphique (i4cfg et i4blt).

On peut trouver d'autres informations sur Internet, @ l'adresse :
http://software.ibm.com/is/lum

Conclusion

Avec LUM, l'acheteur a plus de liberté dans la gestion des licences.
Il est de son devoir de se conformer aux conditions d'utilisation sur lesquelles le fournisseur a établi sa facturation.

De plus, LUM fournit les informations relatives aux produits sous licence, permettant ainsi @ l'acheteur de respecter les conditions du contrat d'achat. Des opérations telles que l'enregistrement, la distribution, la mise @ jour et la suppression de licences, sont consignées dans une base de données LUM impossible @ falsifier.      .



Footnotes:

(1) Remarque : Lors d'une migration de ces licences de NetLS ou iFOR/LS vers LUM, le Central Registry n'est pas créé automatiquement.

(2) Remarque : Se poser la question selon la nature du problème et l'environnement existant.


[ Top of Page | Previous Page | Next Page | Table of Contents ]