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

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. Un sous-administrateur est un utilisateur avec un indicateur uselimadm activé qui a le même privilège administratif du programme limadm que le superutilisateur. Un chef de groupe avec un indicateur admin activé est qualifié de sous-administrateur, 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 sous-administrateurs effectuent généralement les mêmes types de contrôle de ressources, mais ceux-ci sont limités aux utilisateurs compris dans leur groupe d'ordonnancement. La division des ressources par le sous-administrateur est limitée aux ressources qui ont été allouées au groupe (par exemple, celles allouées au noeud limite du chef de groupe). Notez que les sous-administrateurs 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 sous-administrateurs peuvent effectuer les tâches suivantes :

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

    Bien qu'un sous-administrateur puisse définir la limite d'une ressource de façon qu'elle soit supérieure à cette limite pour le groupe, les ressources consommées par les membres du groupe sont également considérées comme étant consommées pour les chefs de groupe, et les limites sur les utilisateurs individuels seront appliquées lorsqu'une tentative de dépassement de la limite du chef de groupe est effectuée.

  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'indicateurs par les sous-administrateurs font l'objet de contraintes supplémentaires en ce sens qu'un utilisateur ne peut pas se voir attribuer un privilège qui n'est pas déjà détenu par l'administrateur du groupe. Cette restriction est appliquée pour empêcher un sous-administrateur d'outrepasser la sécurité dans Solaris Resource Manager.

Les principaux outils d'un 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. En outre, il peut ajouter, supprimer et modifier les comptes utilisateurs, et peut modifier tout usage, 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 racine. Toute personne connaissant le mot de passe racine 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 le mauvais usage des privilèges administratifs accordés aux sous-administrateurs. Reportez-vous à "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 plus de détails, voir "Structure de l'arbre d'ordonnancement".

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

Les sous-administrateurs doivent faire face à un problème : ils partagent des limites de groupe avec les membres de leur groupe. 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. Sauf limite supplémentaire, n'importe quel utilisateur dans le groupe d'ordonnancement peut empêcher le sous-administrateur de créer de nouveaux processus simplement en dépassant la limite des processus.

Pour éviter ce problème, le sous-administrateur peut définir des limites individuelles sur chaque membre du groupe. Cependant, pour être efficaces, ces limites pourraient facilement devenir trop restrictives. En outre, le fait d'obliger un sous-administrateur à gérer des limites individuelles est en contradiction avec l'objectif de contrôle hiérarchique des ressources de Solaris Resource Manager.

Pour résoudre ce problème, l'administrateur central peut également changer la structure des noeuds limites dans le groupe. Plutôt que de placer les utilisateurs directement sous le noeud limite du sous-administrateur, un noeud limite de "contrôle" est créé sous le noeud limite du sous-administrateur en tant que seul noeud limite enfant, puis les utilisateurs deviennent les enfants du noeud limite de contrôle comme dans l'arbre ci-dessous.

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

Graphic

Dans la figure ci-dessus, l'UID du compte du sous-administrateur correspond à celle du noeud limite "Actual," le parent 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 "A", "B" et "C" correspondent aux utilisateurs 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.

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 pourrait créer des noeuds limites supplémentaires pour de nouveaux utilisateurs comme enfants du noeud limite "Contrôle" sans avoir à rééquilibrer les limites.