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