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.