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

Chapitre 3 Configuration

La configuration de Solaris Resource Manager est extrêmement flexible pour l'administrateur central (par exemple, l'utilisateur root). Ce chapitre décrit les éléments de configuration suivants :

Paramètres d'initialisation du noyau, utilisés lors du démarrage du noyau (voir Paramètres d'initialisation du noyau).
Paramètres globaux de Global Solaris Resource Manager spécifiés au moyen de la commande srmadm(1MSRM) (voir Paramètres globaux de Solaris Resource Manager - commande srmadm).
Paramètres communiqués au programme limdaemon( 1MSRM) (voir Utilisation de la commande limdaemon).
Sous-système PAM, y compris la gestion des comptes et des sessions (voir Sous-système PAM).

Paramètres d'initialisation du noyau

Le noyau comporte certains paramètres de Solaris Resource Manager pouvant être définis par l'administrateur central lors de l'initialisation du noyau. A l'initialisation, Solaris lit le fichier /etc/system et l'utilise pour configurer les modules du noyau (voir system( 4) pour de plus amples informations). Voici les paramètres pouvant être définis dans le module SHR (qui sont tous des nombres entiers à 32 bits) pour remplacer les réglages par défaut de Solaris Resource Manager :

SRMLnodes

Nombre de noeuds limites à mettre en mémoire cache dans le noyau. Dans les systèmes Solaris, chaque noeud limite du noyau exige environ 3 ko. La valeur zéro (la valeur par défaut) signifie que le noyau déterminera la valeur. En pareil cas, voici l'approche employée :

(nproc / SRMProcsPerUid ) + SRMLnodesExtra

Où nproc est le nombre maximum de processus simultanés autorisés dans le système. La valeur minimum 6 a priorité sur ce calcul. Le maximum spécifié par SRMMemoryMax a également priorité sur ce calcul.

SRMProcsPerUid

Nombre moyen prévu de processus par utilisateur. La valeur par défaut est 4.

SRMLnodesExtra

Biais utilisé dans l'approche heuristique visant à déterminer la taille du tableau de noeuds limites en mémoire. La valeur par défaut est 20.

SRMNhash

Nombre d'entrées dans la table de hachage utilisé pour le mappage des valeurs UID avec les noeuds limites dans le noyau. Sous les systèmes Solaris, chaque entrée a une longueur de 4 octets. La valeur par défaut est zéro, ce qui indique d'utiliser la même valeur que pour le nombre de noeuds limites.

SRMMemoryMax

Inverse de cette valeur est une fraction indiquant le pourcentage maximum de mémoire réelle à utiliser pour le noeud limite et les tables de hachage de Solaris Resource Manager. La valeur par défaut est 20, ce qui signifie qu'un maximum de 5 % de la mémoire réelle sera attribué aux structures de données de Solaris Resource Manager.

SRMMemWarnFreq

Intervalle minimum, en secondes, entre les avertissements de dépassement de mémoire pour un noeud limite. La valeur par défaut est 4.

Par exemple, dans le fichier /etc/system, la ligne

set srmlim:SRMMemWarnFreq=10

indique que des messages de dépassement de mémoire doivent être envoyés au maximum toutes les 10 secondes par utilisateur.

Il existe également certains paramètres ne faisant pas partie de Solaris Resource Manager, mais qui en influencent le comportement, par exemple :

initclass

Nom de la classe d'ordonnancement où le processus init(1M) est lancé. Sous Solaris Resource Manager, ce paramètre devrait avoir la valeur "SHR" (y compris les guillemets). La valeur par défaut sous Solaris est "TS". Si vous voulez que Solaris Resource Manager contrôle les ressources de l'UC, incluez la ligne suivante dans le fichier /etc/system :

set initclass="SHR"

afin de remplacer la valeur par défaut.

extraclass

Nom d'un module de classe d'ordonnancement à charger, sans nécessairement l'utiliser en tant que classe d'ordonnancement par défaut. Pour que Solaris Resource Manager ne contrôle que les ressources autres que l'UC, incluez la ligne suivante dans le fichier /etc/system :

set extraclass="SHR"

Pour initialiser un système sans charger Solaris Resource Manager, il ne faut pas utiliser /etc/system, mais plutôt /etc/system.noshrload. Pour en savoir davantage, consultez la rubrique Initialisation sans Solaris Resource Manager.

Configuration de démarrage multi-utilisateur

Lors d'une initialisation normale du système, lorsque le système passe du mode mono-utilisateur au mode multi-utilisateur, un script d'initialisation de Solaris Resource Manager (voir Annexe A) est exécuté afin de régler divers paramètres de Solaris Resource Manager. Pour de plus amples informations sur ce script, consultez le Chapitre 4.

Si le script d'initialisation (/etc/init.d/init.srm) est modifié, conservez des copies distinctes des versions originale et modifiée. Les mises à jour de Solaris Resource Manager ne conservent pas nécessairement les scripts d'initialisation existants.

Paramètres globaux de Solaris Resource Manager - commande `srmadm`

La commande srmadm permet à l'administrateur de définir, de modifier et d'afficher les paramètres globaux de Solaris Resource Manager. Pour de plus amples informations sur les paramètres, reportez-vous à la page srmadm(1MSRM) du manuel.

Vous pouvez exécuter la commande srmadm autant de fois que nécessaire pour définir divers paramètres. Il n'est pas nécessaire de tous les inclure dans un même appel. La commande srmadm permet également de modifier les paramètres d'exploitation durant l'exécution du système Solaris Resource Manager, bien que certaines précautions doivent être prises.

Les options srmadm d'activation et de désactivation des fonctions principales de Solaris Resource Manager ont une importance particulière pour les administrateurs. à savoir :

fileopen[={y|n}]

La base de données par défaut, /var/srm/srmDB, peut être remplacée au moyen de l'option -f. Il faut noter que la fermeture du fichier de base de données de Solaris Resource Manager en cours de fonctionnement est une action d'urgence. Elle a plusieurs conséquences indésirables : tous les processus continueront de fonctionner sur le noeud limite root délégué, ce qui pourrait leur accorder des privilèges trop élevés ; l'ordonnanceur SHR est désactivé ; Solaris Resource Manager cesse d'appliquer les limites. Lorsque cette option est activée, Solaris Resource Manager n'ouvre pas de base de données des limites, et sa mémoire cache ne contient que le noeud limite root délégué auquel tous les processus sont reliés.

share[={y|n}]

Lorsque cette option est activée, l'ordonnanceur SHR de Solaris Resource Manager est utilisé et l'ordonnancement de l'UC est effectué en fonction de l'algorithme d'utilisation dynamique et de décroissance de Solaris Resource Manager. Ce mode peut être choisi uniquement lorsque le mode fileopen est activé. Si cette option est désactivée, les calculs d'utilisation de l'ordonnanceur SHR cessent, et les processus sont ordonnancés avec priorités égales fixes, selon un mode de "round-robin".

limits[={y|n}]

Lorsque cette option est activée, Solaris Resource Manager applique les limites de mémoire virtuelle et de processus. Ce mode peut être choisi uniquement lorsque le mode fileopen est activé. Si cette option est désactivée, Solaris Resource Manager continue de mettre à jour les attributs d'utilisation, mais n'applique pas les limites.

adjgroups[={y|n}]

Lorsque cette option est activée, l'ajustement global des parts effectives des groupes de l'ordonnanceur SHR de Solaris Resource Manager est employé. Dans la plupart des cas, il est recommandé d'activer cette option. Durant chaque intervalle d'exécution, les utilisations normalisées de toutes les entrées de limite sont recalculées. Si le mode d'ordonnancement adjgroups est activé, un traitement supplémentaire des utilisations normalisées est effectué comme suit. L'ordonnanceur effectue une passe sur l'arbre d'ordonnancement, en comparant la part réelle récente de chaque groupe à sa part attribuée. Les groupes qui ont reçu moins que leur juste part sont biaisés de manière à recevoir une part réelle supérieure lors de l'intervalle d'exécution suivant. Ainsi, les groupes recevront leur part équitable des ressources de l'UC lorsque possible, quelles que soient les actions de leurs membres.

limshare[={y|n}]

Lorsque cette option est activée, l'ordonnanceur SHR applique un plafond de priorité afin de limiter les parts effectives de tous les utilisateurs pour empêcher les utilisateurs ayant une très faible attribution d'acquérir brièvement presque 100 % de l'UC. L'état activé est recommandé.

Le taux de service de l'UC d'un utilisateur est à peu près inversement proportionnel à son utilisation. Si un utilisateur n'a pas été actif depuis longtemps, son utilisation diminue à près de zéro. Lorsque cet utilisateur ouvre une session (ou que le noeud limite devient actif d'une manière quelconque), durant l'intervalle d'exécution suivant, la priorité des processus de l'utilisateur pourrait être suffisamment élevée pour monopoliser l'UC.

Si l'indicateur d'ordonnancement limshare est activé, l'ordonnanceur évalue la part réelle qu'un noeud limite recevra avant l'intervalle d'exécution suivant. Si le résultat dépasse la part attribuée à l'utilisateur par un certain facteur (voir maxushare), l'utilisation normalisée de l'utilisateur est modifié de manière à empêcher cela.

Il existe aussi deux paramètres facultatifs de la commande srmadm utiles à l'administrateur.

Le paramètre -v permet d'imprimer un rapport formaté de tous les réglages de paramètres courants dans la sortie standard. Si deux ou trois options - v sont spécifiées (-V 1, -V 2 et - V 3) le rapport comporte de plus en plus d'informations. Si la commande srmadm est exécutée sans arguments, cela équivaut à spécifier une seule option -v.
Le paramètre -d permet d'initialiser la structure du système Solaris Resource Manager avec les valeurs par défaut, plutôt que de lire les réglages actuels du noyau. Les valeurs par défaut, permettant principalement de contrôler le comportement d'ordonnancement, sont intégrées à la commande srmadm et constituent un bon point de départ pour la personnalisation de Solaris Resource Manager. Le noyau démarre avec les mêmes valeurs préréglées.

Voici des exemples représentatifs de commandes srmadm.

Pour lancer Solaris Resource Manager en activant l'ordonnanceur SHR et les limites de ressources :

# srmadm set -f /var/srm/srmDB fileopen=y:share=y:limits=y

Pour régler le taux de décroissance d'utilisation d'UC avec une demi-vie de 5 minutes :

# srmadm set usagedecay=300s

Pour afficher les réglages actuels des indicateurs et les charges :

% srmadm

Pour afficher tous les réglages par défaut :

% srmadm show -dv

Désactivation de Solaris Resource Manager

La commande srmadm(1MSRM ) permet de désactiver Solaris Resource Manager en désactivant l'indicateur fileopen : tous les processus sont transférés vers le noeud limite root délégué, les autres noeuds limites modifiés dans la mémoire cache sont transférés sur le disque et la base de données des limites est fermée. Cela désactive automatiquement les indicateurs part et limits, ainsi que, respectivement, l'ordonnanceur SHR et l'application des limites. Au besoin, vous pouvez désactiver séparément les indicateurs part et limits en laissant la base de données des limites ouverte. Cela est préférable à la fermeture du fichier, car les processus peuvent demeurer reliés à leur noeud limite correspondant.

Il faut noter que si seul l'ordonnanceur de Solaris Resource Manager est désactivé en cours d'exécution, cela n'aura pour effet que d'interrompre l'algorithme d'utilisation et de décroissance. L'ordonnanceur continue de traiter les processus dans la classe d'ordonnancement SHR, mais à mesure que chacun d'eux reçoit une nouvelle priorité, la même valeur est employée, ce qui produit un ordonnancement simple à "recherche circulaire".

Si vous réactivez Solaris Resource Manager en ouvrant le fichier et en définissant les indicateurs share et/ou limits après la fermeture du fichier, les processus existants ne sortiront pas du noeud limite root. Il est déconseillé de fermer la base de données de Solaris Resource Manager au cours de son fonctionnement normal. Autrement, vous devrez réinitialiser le système pour vous assurer que les processus sont correctement reliés aux noeuds limites.

Utilisation de la commande `limdaemon`

Par défaut, la commande limdaemon consigne des messages au moyen de syslog(3C). Un horodatage est adjoint aux messages.

La commande limdaemon comporte plusieurs options pouvant être définies lors de son exécution :

L'option -m et l'option -p sont utilisées pour étiqueter les messages et contrôler leur acheminement selon la configuration de la commande syslogd(1M).
L'option -c indique à la commande limdaemon de supprimer la mise à jour des utilisations de temps de connexion de terminal.
L'option -d indique à la commande limdaemon de décroître les utilisations de temps de connexion pour tous les terminaux des utilisateurs en session, l'intervalle entre les décroissances étant l'argument de l'option -t (1 minute par défaut).
L'option -Dn indique à la commande limdaemon de décroître les utilisations de temps de connexion pour tous les terminaux et tous les utilisateurs, toutes les n minutes.
L'option -k met fin à l'exécution de la commande limdaemon.
L'option -t peut être employée pour définir la période (en minutes) entre les mises à jour de l'attribut d'utilisation de temps de connexion dans la catégorie du périphérique terminal. La valeur par défaut est 1 minute.
L'option -e peut être utilisée pour supprimer la déconnexion des utilisateurs ayant atteint leur limite de temps de connexion. Cette option est implicitement activée par l'option -c.
L'option -w permet de régler le nombre de minutes avant l'expiration du temps de connexion où le message d'avertissement est affiché. Le délai d'avertissement par défaut est 5 minutes.
L'option -g permet de régler le temps de grâce (en secondes). Le temps de grâce par défaut est 30 secondes.

Dans l'exemple ci-après, la commande limdaemon

% limdaemon -g300

lance le démon et règle le temps de grâce à 5 minutes. Il faut noter qu'il n'est pas nécessaire d'ajouter le caractère de shell "&" à la commande. Lorsque limdaemon est lancé, il devient un démon. En d'autres termes, un processus enfant est créé et se détache du terminal de contrôle pour se placer dans son propre groupe de traitement.

L'administrateur devrait déterminer l'équilibre nécessaire entre les ressources supplémentaires requises pour la mise à jour rapide des attributs d'utilisation du temps de connexion, et l'augmentation de granularité causée par des mises à jour moins fréquentes. Consultez la page de manuel limdaemon(1MSRM) pour de plus amples informations sur ces options et d'autres.

Sous-système PAM

A partir de la version 2.6, les systèmes Solaris prennent en charge les modules PAM (modules d'authentification enfichables). Lorsqu'un utilisateur veut effectuer une opération dans laquelle l'identité de l'utilisateur est modifiée ou définie (par exemple la connexion au système, l'exécution d'une commande "r" telle que rcp ou rsh, l'emploi de ftp ou de su), un ensemble de modules configurables est utilisé pour effectuer l'authentification, la gestion des comptes, la gestion des justificatifs d'identité et la gestion des sessions. Solaris Resource Manager comporte un module PAM permettant de comptabiliser les connexions et de modifier le comportement de la commande su.

Le programme servant à demander l'opération est appelé le service.

Le système PAM global est décrit dans les pages de manuel pam(3), pam.conf(4), pam_unix(5) et pam_srm(5SRM).

Le module PAM de Solaris Resource Manager effectue des fonctions de gestion des comptes et des sessions. Vous pouvez configurer le comportement du module PAM en modifiant le fichier /etc/pam.conf. Pour un comportement normal de Solaris Resource Manager, le module PAM devrait être configuré comme requisite pour tous les services de connexion, la gestion des sessions et la gestion des comptes pour tous les services PAM. Généralement, le module Solaris Resource Manager module doit être placé après tous les autres modules requis ou exigés et avant tout autre module suffisant ou optionnel.

Lors de l'installation, Solaris Resource Manager modifie le fichier /etc/pam.conf de manière à assurer un comportement approprié. Il insère des lignes comme celles-ci pour chaque service (y compris other) dont la gestion des sessions ou des comptes est déjà configurée :

login account requisite pam_srm.so.1 nolnode=/etc/srm/nolnode
other session requisite pam_srm.so.1
other account requisite pam_srm.so.1 nolnode=/etc/srm/nolnode

La première ligne indique que, pour la connexion des services, le module pam_share.so.1 doit être utilisé pour la gestion des comptes, qu'il doit permettre la connexion pour que celle-ci réussisse, et qu'il doit recevoir l'argument nolnode=/etc/srm/nolnode. Reportez-vous à la section pam.conf(4) pour une explication complète des divers indicateurs de contrôle (required, requisite, optional et sufficient).

La deuxième ligne indique que le service de connexion utilisera le module pam_share.so.1 pour la gestion des sessions.

La liste complète des arguments des modules de gestion des comptes et des sessions de Solaris Resource Manager est présentée à la section pam_srm (5SRM).

Gestion des comptes

Lorsque le module PAM de gestion des comptes de Solaris Resource Manager obtient le contrôle :

Il détermine si Solaris Resource Manager est installé et activé ; sinon, il indique au système PAM de ne pas tenir compte de ce module.
Il détermine si l'utilisateur possède un noeud limite ; sinon, il lance un script «no Inode» configurable par l'administrateur.
Il détermine si l'utilisateur a la permission d'utiliser le service et le périphérique demandés.
Il détermine si l'utilisateur a dépassé la limite d'avertissement ; le cas échéant, il lui interdit d'ouvrir une session.
Il lance un script «every login» configurable par l'administrateur.

Si l'une de ces étapes échoue, les autres ne sont pas effectuées, et le module PAM de gestion des comptes de Solaris Resource Manager interdit l'utilisation du service. Si possible, un message explicatif est envoyé à l'utilisateur par le service.

Scripts

Le script «missing lnode» par défaut crée un noeud limite pour l'utilisateur et en avise l'administrateur de système par courrier. Le script par défaut est /etc/srm/nolnode, mais il peut être remplacé en modifiant le fichier /etc/pam.conf et en changeant la valeur de l'option nolnode dans les lignes du module de gestion des comptes de Solaris Resource Manager. Le script «every login» n'est habituellement pas configuré. Vous pouvez cependant le configurer en ajoutant une option [[everylogin=pathname]] à tout module de gestion des comptes de Solaris Resource Manager dans le fichier /etc/pam.conf. Vous exécutez les scripts en tant qu'utilisateur root. L'entrée, la sortie et l'erreur standard sont fermées. Si un script se termine avec une valeur non nulle, l'accès n'est pas accordé. Toutes les informations sont transmises sous forme de variables d'environnement, lesquelles sont dérivées directement des informations transmises au module PAM par le service.

USER: Nom de connexion fourni au programme. Il a été authentifié par consultation dans la table des mots de passe ; s'il est absent, le module de gestion des comptes a déjà envoyé un code d'erreur au module PAM.
UID: ID de l'utilisateur qui est authentifié. Dans le cas des services qui changent l'UID (par exemples su), il s'agit de l'UID de l'utilisateur qui appelle le service ; dans le cas des services qui définissent l'UID (par exemple login), il s'agit de l'UID cible (celui de USER).
RHOST: Lors des tentatives d'accès dans un réseau, cette variable contient le nom de l'hôte à l'origine de la tentative. Autrement, sa valeur dépend de la mise en ouvre.
SERVICE: Nom du service d'accès, par exemple rsh, login et ftp.
TTY: Nom du télétype où le service est appelé. Certains services n'ayant pas (strictement parlant) de terminal de contrôle (comme ftp) attribueront à cette variable de l'information de processus (par exemple ftp12345, où 12345 est l'identificateur de processus (PID) de ftpd; tandis que d'autres la laisseront vide ou la remplaceront par le nom du service.
DEBUG: Si debug a été précisé dans le fichier pam.conf, la variable DEBUG a la valeur "true" ; sinon, elle a la valeur "false". Comme aucune autre variable d'environnement n'est réglée, les scripts doivent définir leur propre variable PATH au besoin.

Le script par défaut 'no lnode' crée le noeud limite dans le groupe d'ordonnancement par défaut (other, si un tel utilisateur existe dans la table des mots de passe, sinon root) et rappelle par courrier à l'administrateur du système de déplacer le nouveau noeud limite à l'endroit approprié dans la hiérarchie d'ordonnancement. Pour consulter un exemple de script, reportez-vous à la rubrique Script 'no Inode' par défaut.

Interaction du module PAM avec des groupes de périphériques

Le module PAM de Solaris Resource Manager consulte les noms de terminal et de service dans la hiérarchie des périphériques ; si des limites sont dépassées ou qu'un indicateur de périphérique a la valeur activé, il envoie un message de refus de permission.

Les catégories de périphérique examinées sont terminal pour le nom du terminal et services pour le type de service demandé. Par exemple, une tentative de connexion rlogin peut essayer d'utiliser un fichier dans le groupe de périphériquesdu réseau ; ainsi, les indicateurs vérifiés pour l'utilisateur (en supposant que tous les indicateurs ont la valeur group) sont tels qu'indiqués ci-dessous. Les indicateurs suivants sont vérifiés dans l'ordre :

terminal.flag.network
terminal.flag.all
services.flag.rlogin
services.flag.netservices

L'accès n'est accordé que si tous ces indicateurs ont la valeur set. En outre, les limites sont vérifiées en fonction des catégories correspondantes ( terminal et services).

Gestion des sessions

Pour les services de connexion (créant une entrée dans le fichier utmp), les fonctions de gestion des sessions du module PAM sont appelées, ainsi que les fonctions de gestion des comptes si les deux sont configurées dans /etc/pam.conf.

La fonction de gestion des sessions de Solaris Resource Manager effectue le chargement des périphériques. Elle vérifie si l'utilisateur a dépassé la limite de temps de connexion ou si son indicateur onelogin est activé et que l'utilisateur est déjà en session ; le cas échéant, elle l'empêche.

Autrement, elle envoie un message au processus limdaemon afin de l'informer de la connexion et du coût configuré pour le terminal où la connexion est effectuée. Elle indique ensuite au noyau que le processus courant est un "processus d'en-tête de session", dont le processus limdaemon doit être informé lors de sa terminaison.

Le processus limdaemon fait alors le suivi des limites de temps de connexion et génère des avertissements en cas de dépassement prochain.