Guide d'administration du système Solaris Resource Manager 1.3

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

Ce diagramme montre le noeud limite contrôle créé comme enfant unique sous le noeud limite d'un administrateur de groupe. Les utilisateurs sont ensuite définis comme enfants du noeud limite contrôle.

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.