Chapitre 5 Gestion des noeuds limites

Le système Solaris Resource Manager est conçu autour d'un ajout fondamental au noyau : une structure de niveau utilisateur appelée noeud limite (lnode). Chaque UID définie dans la table des mots de passe doit avoir un noeud limite correspondant (soit chaque UID unique renvoyée par appels getpwent(3C) successifs). Bien que cela ne soit pas recommandé, un noeud limite peut exister sans entrée correspondante dans la table des mots de passe. Les noeuds limites sont stockés sur disque et transférés vers et depuis la mémoire par le noyau. Les copies de noeuds en mémoire qui ont changé depuis leur lecture initiale à partir du disque sont réécrites dans le cadre des opérations de synchronisation système habituelles, ainsi que sur demande, lors de l'exécution de la commande sync(1M) et, lorsque nécessaire, afin de libérer de l'espace de cache pour la lecture d'autres noeuds limites. Un noeud limite est en fait un emplacement de taille fixe dans lequel nombre de données de niveau utilisateur peuvent être stockées et mises à jour.

Les noeuds limites sont gérés sous forme de hiérarchie arborescente, l'administrateur central étant la racine, et d'autres utilisateurs étant les chefs de groupes plus restreints. L'administrateur central est le superutilisateur (ou utilisateur racine) du système.

Les erreurs relatives aux noeuds limites, dont les orphelins et les boucles de groupe, sont abordés au Chapitre 9.

Administration déléguée

L'administrateur central est le principal responsable de la gestion des noeuds limites. Solaris Resource Manager fait appel à plusieurs contrôles de ressource pouvant être assignés et gérés, et permet de sélectionner certains privilèges d'administration à assigner à des utilisateurs autres que l'administrateur, afin de répartir les tâches d'administration des utilisateurs. Des privilèges d'administration peuvent être assignés en définissant l'indicateur uselimadm ou admin des utilisateurs voulus. Les utilisateurs dont l'indicateur uselimadm est activé jouissent des mêmes privilèges que le superutilisateur dans le programme limadm(1MSRM). Un chef de groupe dont l'indicateur admin est activé est appelé un sous-administrateur et détient des privilèges (voir ci-dessous) relatifs aux utilisateurs au sein de son groupe d'ordonnancement.

L'administrateur central contrôle la division globale des ressources système en créant et en assignant des limites aux groupes d'ordonnancement dont la racine est mère. Les sous-administrateurs effectuent habituellement les mêmes types de contrôle des ressources, mais ils se limitent aux utilisateurs de leur groupe d'ordonnancement. La division des ressources par le sous-administrateur se limite aux ressources attribuées au groupe (par exemple, les ressources allouées au noeud limite du chef de groupe). Notez qu'un sous-administrateur peut assigner un indicateur administratif à tout utilisateur de son groupe d'ordonnancement, subdivisant ainsi ses propres charges administratives.

Un sous-administrateur peut effectuer les tâches suivantes :

1. Créer et supprimer des noeuds limites pour les utilisateurs de son groupe d'ordonnancement.

2. Modifier les limites de ressource de tout utilisateur au sein de son groupe d'ordonnancement.

   Notez que même si un sous-administrateur peut fixer la limite d'une ressource à un niveau supérieur à la limite établie pour le groupe, les ressources consommées par les membres du groupe sont également imputées aux chefs de groupe, et les limites individuelles seront appliquées si un dépassement de la limite du chef de groupe est tenté.

3. Modifier les indicateurs de tout noeud limite dans son groupe d'ordonnancement, à condition que l'indicateur ne soit pas assorti de la condition noadmin. Les affectations d'indicateur effectuées par les sous-administrateurs sont aussi limitées par le fait qu'un utilisateur ne peut se voir accorder un privilège qui n'est pas déjà attribué au sous-administrateur. Cette restriction vise à empêcher un sous-administrateur de contourner les mesures de sécurité dans Solaris Resource Manager.

4. Configurer n'importe lequel de ses propres attributs dotés de la condition selfadmin.

Les principaux outils du sous-administrateur sont les commandes limadm(1MSRM) et limreport(1SRM). Le programme limadm exécute des opérations sur les limites, les indicateurs et d'autres attributs de Solaris Resource Manager pour un ou plusieurs utilisateurs. Combinés au générateur de rapports limreport, ces outils permettent à un groupe d'ordonnancement de s'autogérer sans perturber l'affectation des ressources ni la gestion d'autres groupes d'ordonnancement.

Le superutilisateur est exempté de toute limite de ressource, dispose toujours de privilèges d'administration complets sans égard au réglage de ses indicateurs. Il peut ajouter, supprimer et modifier les comptes utilisateurs, et peut modifier tout usage, limite ou indicateur de tout noeud limite utilisant le programme limadm.

Sécurité

Solaris Resource Manager ayant d'importantes répercussions sur l'administration d'un système Solaris, son installation et sa maintenance doivent être effectuées de façon à assurer la sécurité du système.

L'administrateur dispose de plusieurs méthodes pour assurer la sécurité d'un système Solaris Resource Manager. Comme pour tout système Solaris, la plus importante consiste à assurer la confidentialité du mot de passe racine. Toute personne connaissant ce mot de passe jouit d'un accès illimité aux ressources système, tout comme l'administrateur central.

Des privilèges administratifs spéciaux peuvent être accordés à des utilisateurs dans Solaris Resource Manager par l'intermédiaire de certains indicateurs système au sein de leur noeud limite. Ces privilèges peuvent contribuer à accroître la sécurité du système en permettant de confier des tâches à des utilisateurs sans avoir à leur accorder des privilèges complets de superutilisateur.

Néanmoins, certain de ces privilèges doivent être accordés avec précaution car ils fournissent un vaste éventail de pouvoirs. Le mot de passe des utilisateurs disposant de privilèges spéciaux doit être protégé avec autant de soin que celui du superutilisateur.

Dans certaines circonstances, l'administrateur central risque d'augmenter la vulnérabilité du système s'il néglige l'importance devant être accordée à la manipulation de la structure de l'arbre d'ordonnancement. Il est essentiel que l'administrateur central comprenne comment modifier l'arbre d'ordonnancement correctement et y repérer les problèmes potentiels.

Indicateurs uselimadm et admin

L'administrateur central peut attribuer des privilèges administratifs dans Solaris Resource Manager par l'intermédiaire des indicateurs uselimadm et admin du noeud limite d'un utilisateur. L'indicateur uselimadm de la commande limadm(1MSRM) accorde les mêmes privilèges que ceux de l'administrateur central. Lorsqu'il est défini pour un chef de groupe, l'indicateur admin lui fournit des privilèges administratifs sur les membres de son groupe mais ne lui permet pas de modifier le contenu des noeuds limites extérieurs à son groupe.

Les chefs de groupe dont l'indicateur admin est activé sont appelés des sous-administrateurs. Plusieurs mesures de sécurité doivent être prises dans Solaris Resource Manager afin d'empêcher le mauvais usage des privilèges administratifs accordés aux sous-administrateurs. Pour en savoir davantage, reportez-vous à "Serveur d'applications type" et "Programmes de maintenance des noeuds limites".

Lorsqu'il supprime des noeuds limites, un sous-administrateur doit s'assurer que les sous-arbres sont supprimés à partir du dernier noeud limite en remontant. Si vous commencez au sommet du sous-arbre à supprimer, vous perdrez le contrôle des enfants des noeuds limites qui ont été supprimés, car ils deviendront orphelins lorsque leurs parents seront effacés. Une fois des noeuds limites devenus orphelins, le sous-administrateur ne peut les modifier, car ils se trouvent à l'extérieur du groupe d'ordonnancement.

Structure suggérée de noeud limite sous-administrateur

Un des problèmes auxquels les sous-administrateurs peuvent être confrontés est qu'ils partagent les mêmes limites de groupe que les membres. Par exemple, si une limite de processus est définie sur le noeud limite du chef de groupe, elle fixe le nombre de processus pouvant être utilisés par l'ensemble du groupe, incluant le chef de groupe. À moins de définir des limites additionnelles, tout utilisateur du groupe d'ordonnancement qui excède sa limite de processus empêchera le sous-administrateur de créer de nouveaux processus. Pour éviter cela, l'administrateur doit définir des limites individuelles pour chaque membre du groupe. Pour que ces limites soient efficaces, il peut être nécessaire de les définir avec des contraintes excessives. De plus, le fait de forcer un sous-administrateur à gérer des limites individuelles va à l'encontre du but de Solaris Resource Manager qui vise à contrôler les ressources de manière hiérarchique. L'administrateur peut contourner ce problème en modifiant la structure des noeuds limites au sein de son groupe. Au lieu de placer les utilisateurs directement sous leur propre noeud limite, il peut créer un noeud limite "contrôle" sous le sien en tant que seul noeud limite enfant, puis rendre les utilisateurs enfants du noeud Contrôle, comme dans l'arbre ci-dessous.

Figure 5-1 Structure de noeud limite de sous-administrateur

Dans l'exemple ci-dessus, l'UID du compte du sous-administrateur correspond à celle du noeud limite "Réel", père de l'arbre. Il s'agit du noeud limite dont l'indicateur admin serait activé. Un compte fictif serait créé pour le noeud limite "Contrôle". Il n'est pas nécessaire d'autoriser une ouverture de session sur ce compte. Les noeuds limites "A", "B" et "C" correspondent aux utilisateurs placés sous le contrôle du sous-administrateur.

Dans cet exemple, la limite de processus du noeud "Réel" pourrait être de 100, tandis que celle du noeud "Contrôle" pourrait être de 90, et les limites des utilisateurs individuels sont de 0. Avec cette configuration, même si les utilisateurs A, B et C utilisaient un total de 90 processus (maximum autorisé), le sous-administrateur pourrait quand même créer 10 processus. Ici, des utilisateurs peuvent quand même empêcher les autres de créer des processus. La seule façon de l'éviter est de fixer des limites individuelles pour les utilisateurs visés. Toujours dans notre exemple, ces limites pourraient être de 40 pour chaque utilisateur, ce qui assurerait une certaine souplesse tout en empêchant un seul utilisateur de priver les autres de ressources. Notez également que le sous-administrateur peut créer des noeuds limites additionnels pour des nouveaux utilisateurs en tant qu'enfants du noeud "Contrôle" et ce, sans avoir à rééquilibrer les limites.

Base de données des limites

La base de données des limites contient les informations sur les utilisateurs et permet à Solaris Resource Manager d'effectuer le contrôle des ressources. Elle contient un noeud limite par UID, auquel on accède en utilisant l'UID comme index direct dans le fichier. S'il existe un noeud limite pour une UID numériquement élevée, la base de données des limites semblera grande. Cependant, si les UID des utilisateurs ne sont pas successives, la base de données des limites comportera de grands trous et, sur un système de fichiers le permettant, elle pourrait être stockée sous forme de fichier réparti. Autrement dit, aucun bloc de disque ne sera assigné au stockage des sections "vides" du fichier. Le système de fichiers ufs accepte les fichiers répartis, mais pas le système de fichiers tmpfs. Pour en savoir davantage sur l'incidence des fichiers répartis sur l'enregistrement et la restauration de la base de données des limites, reportez-vous à la section "Enregistrement et restauration de la base de données des limites".

Chaque fois qu'un utilisateur est créé, vous devez créer un noeud limite.

Création de la base de données des limites

Le fichier de démarrage de Solaris Resource Manager (/etc/init.d/init.srm) génère une base de données des limites initiale à sa première exécution ou chaque fois qu'il est manquant.

La base de données des limites réside habituellement dans le répertoire /var/srm.

La base de données et son groupe doivent appartenir au superutilisateur, qui doit être le seul autorisé à la consulter. Aucune permission en écriture n'est requise puisque que seul du code noyau avec authentification de superutilisateur permet d'y écrire.

La sécurité du système pourrait être compromise si un utilisateur pouvait écrire dans la base de données des limites Solaris Resource Manager.

Enregistrement et restauration de la base de données des limites

La base de données des limites pouvant être un fichier réparti, sa copie doit faire l'objet de précautions particulières. Le fichier occupera probablement beaucoup d'espace disque s'il est enregistré par un utilitaire ne prenant pas en charge les fichiers répartis, car les sections vides seront lues comme une suite de zéros et inscrites sous forme de vrais blocs de données au lieu de sections vides. Cela peut se produire si le fichier est copié, sauvegardé ou restauré par un utilitaire tel que tar(1), cpio(1) ou cp(1) ; cependant, des programmes comme ufsdump(1M) et ufsrestore(1M) préserveront les trous.

La sauvegarde et la restauration de la base de données des limites peuvent également être effectuées à l'aide de limreport(1SRM) pour générer une version ASCII du fichier et de limadm(1MSRM) pour restaurer l'original depuis la version ASCII. Par exemple, la commande :

limreport 'flag.real' - lname preserve > /var/tmp/savelnodes 

créera le fichier /var/tmp/savelnodes, qui contient une représentation ASCII des noeuds limites de chaque utilisateur dans la table des mots de passe. Notez que cette opération ne sauvegardera pas les noeuds limites n'ayant pas d'entrée correspondante dans la table des mots de passe. En règle générale, il ne devrait pas y avoir plus de noeuds limites que le nombre total d'UID dans la table des mots de passe.

La commande :

# limadm set -f - < /var/tmp/savelnodes

recréera les noeuds limites dont les données ont été sauvegardés. Cette commande ne supprimant pas les noeuds qui n'ont pas été sauvegardés, ces techniques peuvent également servir à sauvegarder et à restaurer des noeuds sélectionnés plutôt que l'ensemble de la base de données des limites.

"Commandes limreport et limadm" explique l'utilisation des commandes limreport(1SRM) et limadm(1MSRM) plus en détail. Il est utile que l'administrateur se familiarise avec ces commandes pour sauvegarder et restaurer des noeuds limites, car elles peuvent servir lorsqu'une modification est apportée à l'interprétation de l'arbre des noeuds limites (telle que définie par le fichier de configuration).

Étant donné que le contenu de la base de données change régulièrement lors des opérations habituelles du système, il est recommandé d'effectuer les sauvegardes pendant que le système est au repos ou en mode mono-utilisateur. De même, la restauration de l'ensemble de la base de données des limites devrait être faite uniquement lorsque Solaris Resource Manager n'est pas utilisé, par exemple, en mode mono-utilisateur.

Création et suppression de noeuds limites

Chaque fois qu'un utilisateur est créé, un noeud limite correspondant doit être créé, et ses limites et privilèges définis. L'utilisateur ne peut ouvrir une session tant que son noeud limite n'est pas créé. Lorsqu'il utilise Solaris Resource Manager, l'administrateur doit assurer la maintenance de la base de données en parallèle avec la base de données de mots de passe Solaris habituelle. La commande :

# limreport \ !flag.real - uid lname 

peut être utilisée pour imprimer la liste des UID et des noms de compte des utilisateurs n'ayant pas de noeud limite correspondant.

Dans cette version, les noeuds limites ne sont pas créés et supprimés automatiquement par les commandes système utilisées pour créer et supprimer des comptes. Ces opérations doivent être effectuées par l'administrateur. Cependant, il est possible de créer des noeuds limites sur demande. Pour plus de détails, voir "Sous-système PAM".

De même, juste avant de supprimer un compte dans la table des mots de passe, le noeud limite correspondant doit être effacé de la base de données des limites avec la commande limadm(1MSRM).

Si une UID est changée, le contenu de son noeud limite doit être copié vers le nouveau noeud correspondant au nouveau numéro, puis le noeud d'origine doit être supprimé. Reportez-vous à la section "Copie et déplacement de noeuds limites".

Les noeuds enfants doivent être reliés au nouveau noeud ou à un autre noeud père approprié. La commande :

# limreport 'sgroup==X' '%u\tsgroup=Y\n' uid | limadm set -u -f - 

permet de détecter tous les noeuds limites ayant un groupe d'ordonnancement père dont l'UID est X et d'en faire les enfants du noeud ayant l'UID Y.

Les étapes ci-après illustrent le changement d'UID d'un noeud limite de X à Y.

1. Enregistrement de l'état du noeud limite dont l'UID doit être changée :

   # limreport 'iud==X' - lname preserve > /var/tmp/savelnodes.X

2. Remplacement de l'ancienne UID (X) correspondant à cet utilisateur par la nouvelle UID (Y) dans la table des mots de passe.

3. Création d'un noeud limite pour la nouvelle UID et restauration de l'état enregistré au préalable :

   # limadm set -f /var/tmp/savelnode.X

4. Remplacement du groupe d'ordonnancement de tous les noeuds limites enfants du noeud à modifier (UID X) par le nouveau noeud limite (UID Y) :

   # limreport 'sgroup==X' '%u\tsgroup=Y\n' uid | limadm set -u -f -

5. Assurez-vous qu'aucun processus n'est relié à l'ancien noeud limite. Voir "Création et suppression de noeuds limites".

6. Utilisez la commande chown(2) pour remplacer le propriétaire de tous les fichiers de l'UID d'origine par celui de la nouvelle UID. Par exemple :

   # find / -user X -print | xargs chown Y

7. Supprimez l'ancien noeud limite :

   # limadm delete X

Programmes de maintenance des noeuds limites

La commande limadm est le principal outil de maintenance des noeuds limites. Elle permet de changer les valeurs d'attribut de Solaris Resource Manager pour une liste de comptes utilisateur. Si aucun noeud limite n'existe pour un utilisateur, un noeud vide est d'abord créé par défaut. Voici les propriétés des nouveaux noeuds limites :

• flag.real est activé ;

• les attributs cpu.shares et cpu.myshares sont fixés à 1 ;

• les indicateurs uselimadm et admin sont fixés à "clear" ;

• tous les autres indicateurs sont fixés à "inherit" ;

• tous les attributs de limite et d'usage sont fixés à zéro.

Le groupe d'ordonnancement du nouveau noeud limite est réglé à celui de l'appelant de limadm s'il s'agit d'un sous-administrateur ; sinon (si l'appelant est root ou que son indicateur uselimadm est défini), il est réglé à l'utilisateur Autre si un noeud limite existe pour ce compte d'utilisateur, ou au noeud limite racine si ce n'est pas le cas.

L'appelant de limadm doit disposer de privilèges d'administration suffisants pour effectuer les changements indiqués. Il doit s'agir du superutilisateur, avoir un indicateur uselimadm activé, ou s'agir d'un sous-administrateur modifiant uniquement les attributs des membres de son groupe d'ordonnancement. Certaines restrictions s'appliquent à l'utilisation de limadm par un sous-administrateur : --

• il ne peut changer la valeur de ses propres attributs, à l'exception de ceux dotés de la condition selfadmin (par exemple, l'attribut cpu.myshares) ;

• l'attribut sgroup peut être affecté uniquement à un chef de groupe membre du groupe d'ordonnancement de l'appelant ou à l'appelant même ;

• il ne peut changer les attributs des utilisateurs d'autres groupes d'ordonnancement ;

• il ne peut modifier la valeur de tout attribut utilisé pour stoker les usages. Si cette restriction n'était pas établie, le sous-administrateur pourrait contourner les limites de groupe dans son propre noeud limite en diminuant l'usage de l'un de ses enfants, réduisant ainsi l'usage du groupe ;

• si la valeur d'un indicateur est contraire à sa valeur par défaut, il ne peut modifier cette valeur pour un membre du groupe, sauf pour la fixer à la même valeur contraire. Cette mesure assure que les sous-administrateurs dont des privilèges ont été explicitement interdits ne peuvent accorder ces privilèges à des utilisateurs sous leur contrôle.

La commande limadm permet à un administrateur de supprimer un noeud limite sans effacer le compte correspondant dans la table des mots de passe. Pour pouvoir utiliser limadm, l'appelant doit être le superutilisateur, ou avoir un indicateur uselimadm ou admin activé. Si seul l'indicateur admin de l'appelant est activé, il peut supprimer uniquement les noeuds limites des utilisateurs dont il est le chef de groupe.

Unités

Dans Solaris Resource Manager, les valeurs sont représentées par l'un des trois types d'unités suivants :

Proportionnée

L'unité proportionnée est le format par défaut, facilement lisible, qui permet d'afficher et d'entrer des valeurs. Elle contribue à éviter les erreurs des utilisateurs en réduisant le nombre de chiffres à entrer. --

Brute (ou non proportionnée)

Les unités brutes sont les unités élémentaires de représentation d'une valeur. Par exemple, les unités brutes pour l'usage de la mémoire virtuelle sont des octets, tandis que les unités brutes pour le débit de la mémoire virtuelle sont des octets par seconde. Ces dernières sont surtout utilisées pour la facturation de l'usage, lorsque des quantités exactes sont nécessaires. --

Interne

Les unités internes sont utilisées par Solaris Resource Manager pour stocker des attributs de mémoire en unités machine plutôt qu'en octets.

Conversions

Les programmes Solaris Resource Manager convertissent les unités internes utilisées pour stocker des valeurs d'attribut, ce qui permet de toujours présenter des unités proportionnelles ou brutes à l'utilisateur. Sauf quelques exceptions, cela signifie que l'utilisateur n'a pas à se préoccuper des unités utilisées par Solaris Resource Manager.

Dans Solaris Resource Manager, les expressions exa, péta, téra, giga, méga et kilo sont utilisées pour représenter les puissances de deux et non de dix. Par exemple, un méga-octet compte 1 048 576 octets et non 1 000 000. La puissance de deux de chaque expression est 60 (exa), 50 (péta), 40 (téra), 30 (giga), 20 (méga) et 10 (kilo).

Les programmes constituant l'interface utilisateur principale du système Solaris Resource Manager sont limadm(1MSRM), liminfo(1SRM) et limreport(1SRM). Les conversions et mises à l'échelle effectuées sont expliquées en détail dans les sous-sections suivantes.

Commande limadm

Lors d'un changement de valeurs d'attribut, limadm permet d'ajouter des caractères aux nombres : [EPTGMK][B][.][wdhms]. Les majuscules et les minuscules sont interchangeables. Si l'attribut exprime une quantité de stockage (attributs de mémoire) ou un débit de stockage, un caractère du premier groupe (EPTGMK) est permis. Cela est multiplié par le nombre d'octets compris dans un exa-octet (E), un péta-octet (P), un téra-octet (T), un giga-octet (G), un méga-octet (M) ou un kilo-octet (K). Le caractère B facultatif peut être ajouté pour faciliter la lecture, mais n'a aucun effet. Si l'attribut exprime le temps (date ou heure) ou le débit de stockage, un caractère du deuxième groupe est permis. Cela est multiplié par le nombre de secondes que compte une semaine (w), un jour (d), une heure (h), une minute (m) ou par le nombre de secondes (s), selon le cas. Un point facultatif peut séparer les unités de stockage et de temps (par exemple, mh, M.h et MB.h expriment tous des "méga-octet par heure"). Si le suffixe M porte à confusion, limadm tente de déduire sa signification selon le contexte. Si cela est impossible, la valeur méga est interprétée par défaut de préférence aux minutes.

Ces caractères de conversion sont utiles pour éviter les erreurs d'ordre de grandeur en entrant des nombres élevés, mais la quantité est stockée en unités internes, peu importe la méthode d'entrée utilisée.

Le caractère spécial u peut aussi être utilisé seul mais uniquement pour les valeurs d'attribut de mémoire. Il indique que le nombre est en unités machine (internes) et non en octets.

Commande liminfo

La commande liminfo(1SRM) utilise les mêmes suffixes pour les rapports que limadm(1MSRM) emploie pour l'entrée (voir ci-dessus). Normalement, liminfo convertit les valeurs en formats proportionnels appropriés pour l'impression, mais l'option -r peut être utilisée pour forcer liminfo à imprimer les valeurs brutes. Par exemple, la mémoire est habituellement exprimée à l'aide d'une unité proportionnelle pertinente comme le méga-octet (p. ex. 102 Mo), mais l'option -r forcera l'impression en octets (p. ex. 106 954 752 octets).

Commande limreport

La commande limreport(1SRM) indique toujours les valeurs sous forme brute. Si des valeurs proportionnelles sont requises, la conversion doit être énoncée explicitement dans l'expression utilisée pour afficher la valeur. Par exemple, pour afficher l'usage total de mémoire virtuelle pour tous les utilisateurs en kilo-octets arrondis au ko près :

# limreport 'flag.real' '%-8.8s %d KB\n' lname '(memory.usage+1k-1)/1k' 

Comme on le voit dans cet exemple, il est possible d'utiliser des suffixes proportionnels pour les nombres dans des expressions, ce qui simplifie la conversion des unités brutes en valeurs proportionnelles.

Notez que les unités internes de certains attributs diffèrent de leur forme brute. Normalement, l'utilisateur n'a pas à s'en préoccuper, car tous les programmes Solaris Resource Manager convertissent en unités proportionnelles ou brutes mais, à titre d'exemple, certaines expressions de limreport qui précisent une correspondance exacte sur un nombre d'octets échoueront toujours si un nombre indiqué n'est pas un multiple intégral de l'unité interne pertinente.

Manipulation de noeuds limites

Commandes limreport et limadm

Les commandes limreport(1SRM) et limadm(1MSRM) fournissent à l'administrateur un moyen très simple d'enregistrer et de restaurer le contenu des noeuds limites de n'importe quel nombre d'utilisateurs. La commande limreport permet de sélectionner et d'extraire les noeuds limites à enregistrer, tandis que limadm permet de les restaurer. Les usages les plus courants pour cette combinaison de commandes sont la copie de noeuds limites et la modification de la structure des noeuds limites.

La commande limreport est un outil polyvalent pour sélectionner et afficher les attributs des utilisateurs. Elle fournit deux niveaux de sélection : la sélection de noeuds limites et la sélection d'attributs à afficher pour chaque noeud limite sélectionné. La sélection des noeuds limites s'effectue au moyen d'une expression de sélection, pouvant être une condition simple ou un ensemble de conditions reliées par des opérateurs logiques avec une syntaxe de type C. La sélection des attributs s'effectue en listant les noms symboliques des attributs voulus. Le mode d'affichage des attributs peut être précisé par une chaîne de commande de format similaire à la fonction limreport de C, avec des extensions pour traiter les types spéciaux de Solaris Resource Manager. Si une chaîne de commande de format '-' est précisée, limreport utilise les formats par défaut pour chaque attribut affiché. Pour en savoir davantage, voir limreport(1SRM).

La commande limadm permet de changer le contenu d'attributs dans un noeud limite si le demandeur détient les privilèges requis. Les commandes de modification peuvent être précisées directement sur la ligne de commande ou en spécifiant le nom du fichier qui les contient (à l'aide de l'option -f ).

limreport permet de générer des attributions de valeur d'attribut en utilisant la syntaxe lim (reportez-vous à l'identificateur "preserve" de la syntaxe lim), dont la sortie peut être entrée dans limreport à l'aide de l'option -f . Cette méthode permet à l'administrateur d'utiliser les deux programmes ensemble pour sélectionner le contenu à sauvegarder ou à restaurer dans la base de données des limites.

Copie et déplacement de noeuds limites

La commande :

# limreport 'uid==X' - Y preserve | limadm set -u -f -

copie un noeud limite de l'UID X à l'UID Y. L'expression 'uid==X' permet de sélectionner le noeud limite source. L'identificateur "preserve" force limreport à extraire toutes les valeurs d'attribut qui ne sont pas en lecture seule dans une syntaxe pouvant être acheminée à limadm. L'UID Y étant placée devant l'identificateur "preserve", il s'agit du premier élément de données transféré à lim, ce qui fournit la sélection du noeud limite cible.

Si le noeud limite source n'est plus nécessaire, il peut être enlevé avec limadm.

La prudence est de mise si vous utilisez une concordance par UID en tant qu'expression de sélection limreport. Si plusieurs comptes partagent une UID, ils seront tous associés. Dans l'exemple ci-dessus, la même donnée de noeud limite sera préservée et chargée plusieurs fois. Dans le système Solaris, l'UID détient les comptes root et smtp.