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). 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. Chaque UID défini dans la table des mots de passe doit avoir un noeud limite correspondant. (Il s'agit de chaque UID unique renvoyé 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 et, lorsque nécessaire, afin de libérer de l'espace de cache pour la lecture d'autres noeuds limites.

Les noeuds limites sont gérés sous forme de hiérarchie arborescente, l'administrateur central étant la cime de l'arbre, et d'autres utilisateurs étant les chefs de groupes plus restreints de l'arborescence. 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 à la rubrique Chapitre 11.

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. Un sous-administrateur est un utilisateur avec un indicateur uselimadm activé qui a le même privilège limadm que le superutilisateur. Un chef de groupe avec un indicateur admin activé est qualifié d'administrateur de groupe et a des privilèges (décrits ci-dessous) sur les utilisateurs du même 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 administrateurs de groupe 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 l'administrateur de groupe se limite aux ressources attribuées au groupe (par exemple, les ressources allouées au noeud limite du chef de groupe). Notez que les administrateurs de groupe peuvent affecter un indicateur admin à n'importe quel utilisateur de leur groupe d'ordonnancement, ce qui sous-divise encore plus leurs responsabilités administratives.

Les administrateurs de groupe peuvent effectuer les tâches suivantes :

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

   Notez que même si un administrateur de groupe 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é.

2. Modifier les indicateurs ou les attributs (sauf flag.uselimadm et cpu.usage) de tout noeud limite dans son groupe d'ordonnancement.

   Les affectations d'indicateur effectuées par les administrateurs de groupe 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é à l'administrateur de groupe. Cette restriction vise à empêcher un administrateur de groupe de contourner les mesures de sécurité dans Solaris Resource Manager.

Les principaux outils d'un administrateur de groupe 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. En outre, il peut ajouter, supprimer et modifier les comptes utilisateurs, et peut modifier toute utilisation, limite ou indicateur de tout noeud limite à l'aide de la commande 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 root. Toute personne connaissant le mot de passe root 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, certains 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.

Plusieurs mesures de sécurité doivent être prises dans Solaris Resource Manager afin d'empêcher la mauvaise utilisation des privilèges administratifs accordés aux sous-administrateurs. Reportez-vous aux rubriques Serveur d'applications type et Programmes de maintenance des noeuds limites.

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. Pour de plus amples informations, reportez-vous au Structure de l'arbre d'ordonnancement.

Structure suggérée de noeud limite d'administrateur de groupe

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. A moins de définir des limites additionnelles, tout utilisateur du groupe d'ordonnancement qui excède sa limite de processus empêchera l'administrateur de groupe 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 administrateur de groupe à 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 central 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 son 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 du noeud limite de l'administrateur de groupe

Dans l'exemple ci-dessus, l'UID du compte de l'administrateur de groupe correspond à celui 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 de l'administrateur de groupe.

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.

Toutefois, 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, dans cet exemple, l'administrateur central peut créer des noeuds limites additionnels pour des nouveaux utilisateurs en tant qu'enfants du noeud limite "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 un UID numériquement élevé, la base de données des limites semblera grande. Cependant, si les UID des utilisateurs ne sont pas successifs, 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 rubrique 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 lors d'une initialisation.

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 seul du code noyau avec authentification de superutilisateur y est écrit.

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 pour générer une version ASCII du fichier et de limadm pour restaurer l'original depuis la version ASCII sauvegardée. 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ées. 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.

La rubrique Commandes limreport et limadm explique l'utilisation des commandes limreport et limadm 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 la base de données des limites).

Etant donné que le contenu de la base de données des limites 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. Lors de l'utilisation de Solaris Resource Manager, l'administrateur doit maintenir la base de données des limites en parallèle avec la correspondance normale des mots de passe Solaris. 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.

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 lorsque l'utilisateur établit une connexion. Reportez-vous à la rubrique Sous-système PAM pour de plus amples informations.

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).

pour supprimer des noeuds limites, on 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.

Si l'UID d'un utilisateur est modifié, le contenu de son noeud limite doit être copié vers le nouveau noeud correspondant au nouvel UID, puis le noeud d'origine doit être supprimé. Pour de plus amples informations, reportez-vous à la rubrique Copie et déplacement de noeuds limites.

Les noeuds enfants doivent être reliés au nouveau noeud limite ou à un autre noeud limite 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é :

   # limreport 'uid==X' - lname preserve> /var/tmp/savelnode.X

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

3. Création d'un noeud limite pour le nouvel 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.

6. Utilisez la commande chown(2) pour remplacer le propriétaire de tous les fichiers de l'UID d'origine par celui du nouvel 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 dont les administrateurs disposent. 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'utilisation sont fixés à zéro.

Le groupe d'ordonnancement du nouveau noeud limite est réglé à l'utilisateur Autre (srmother) 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. L'appelant doit être le superutilisateur, doit avoir un indicateur uselimadm activé, ou être un sous-administrateur qui change uniquement les attributs des membres du groupe d'ordonnancement auquel l'appelant appartient. Des restrictions s'appliquent pour l'utilisation de limadm par les administrateurs de groupe.

• Ils ne peuvent pas changer la valeur de leurs propres attributs.

• L'attribut sgroup d'un utilisateur peut uniquement être affecté à l'appelant ou à un membre du groupe d'ordonnancement de l'appelant.

• Les administrateurs de groupe ne peuvent pas changer les attributs des utilisateurs hors de leur groupe d'ordonnancement.

• Ils ne peuvent pas modifier la valeur d'aucun attribut utilisé pour stocker des usages autres que des utilisations de terminal. Sans cette restriction, les administrateurs de groupe pourraient outrepasser les limites de groupe dans leurs noeuds limites en réduisant l'utilisation de l'un de leurs enfants, réduisant ainsi l'utilisation du groupe.

• S'ils ont un indicateur ayant une valeur différente de la valeur par défaut, les sous-administrateurs ne peuvent modifier la valeur de cet indicateur pour un autre membre de leur groupe que s'ils lui donnent cette même valeur, différente de la valeur par défaut.

  Cette mesure assure que les administrateurs de groupe 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 utiliser limadm, l'appelant doit être le superutilisateur ou avoir un indicateur uselimadm activé. Si l'appelant a seulement un indicateur admin activé, il peut uniquement modifier les noeuds limites des utilisateurs sous les groupes d'ordonnancement pour lesquels 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'utilisation 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'utilisation, 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.

Sous 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, liminfo et limreport. Les conversions et mises à l'échelle effectuées sont expliquées en détail dans les sous-rubriques 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), selon le cas. 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 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).

La 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'utilisation totale 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 le 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 et limadm fournissent à l'administrateur un moyen très simple pour enregistrer et 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 utilisations les plus courantes pour cette combinaison de commandes sont la copie de noeuds limites et la modification de la structure des noeuds limites (consultez les rubriques suivantes).

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 de plus amples informations, reportez-vous à la page limreport(1SRM) du manuel.

Changement de la structure des noeuds limites

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).

La commande limreport permet de générer des attributions de valeur d'attribut en utilisant la syntaxe limadm (reportez-vous à l'identificateur preserve de la syntaxe limadm), 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é devant l'identificateur preserve, il s'agit du premier élément de données transféré à limadm, ce qui fournit la sélection du noeud limite cible.

Si le noeud limite source n'est plus nécessaire, il peut être enlevé à l'aide de la commande 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 un UID, ils seront tous associés. Dans l'exemple ci-dessus, cela importerait peu : la même donnée de noeud limite sera préservée et chargée plusieurs fois. Dans le système Solaris, l'UID 0 détient les noms de connexion root et smtp.