| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Pages de manuel d'Image Packaging System Oracle Solaris 11 Information Library (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Pages de manuel d'Image Packaging System Oracle Solaris 11 Information Library (Français) |
- Image Packaging System
La structure IPS (Image Packaging System, système d'empaquetage d'image) pkg(5) permet de gérer les logiciels tout au long de leur cycle de vie (installation, mise à jour et suppression). L'empaquetage d'image gère les logiciels en unités de packages, c'est-à-dire des collections d'actions, définies par un ensemble de paires clé/valeur données et, souvent, d'une charge utile. Dans de nombreux cas, les actions sont des fichiers trouvés dans un système de fichiers, mais elles peuvent également représenter d'autres objets pouvant être installés, tels que des pilotes, des services et des utilisateurs.
Chaque package est représenté par un identificateur de ressource de gestion des pannes (FMRI) avec le schéma pkg:. Le FMRI complet pour un package se compose d'un schéma, d'un éditeur, le nom du package, et d'une chaîne de version au format suivant :
pkg://solaris/system/library/c++-runtime@0.5.11,5.11-0.174.0.0.0.0.0:20110921T190358Z
solaris est l'éditeur. system/library/c++-runtime est le nom du package. Bien que l'espace de noms soit hiérarchique et de profondeur quelconque, il n'y a aucun confinement imposé ; le nom est arbitraire. Les informations sur l'éditeur sont facultatives, mais doivent être précédées de pkg:// s'il est présent. Un FMRI qui inclut l'éditeur est souvent désigné comme étant "entièrement qualifié". Si les informations sur l'éditeur ne sont pas présentes, le nom de package doit généralement être précédé par pkg:/.
Souvent, les clients de package permettent d'omettre le schéma d'un FMRI s'il ne contient pas d'informations sur l'éditeur. Par exemple, pkg:/system/library/c++-runtime correspond à system/library/c++-runtime. Si le schéma est omis, les clients permettent également l'omission de tous les composants d'un nom de package excepté le dernier pour la mise en correspondance. Par exemple, vous pouvez écrire indifféremment system/library/c++-runtime, library/c++-runtime ou c++-runtime, ce qui correspond aux packages nommés c++-runtime ou dont le nom se termine par /c++-runtime.
Un nom d'éditeur permet d'identifier une personne, un groupe de personnes, ou une organisation en tant que source d'un ou plusieurs packages. Afin d'éviter toute collision de nom d'éditeur et de faciliter l'identification de l'éditeur, une bonne pratique consiste à utiliser en tant que nom d'éditeur un nom de domaine représentant l'entité qui publie les packages.
La version suit le nom du package, séparés par un signe arobase (@). La version se compose de quatre séquences de nombres, séparées par des signes de ponctuation. Les éléments des trois premières séquences sont séparés par des points, et les séquences sont arbitrairement longues. Les zéros non significatifs dans les composants de version (par exemple, 01.1 ou 1.01) ne sont pas autorisés. Les zéros finaux (par exemple, 1.10) sont autorisés.
La première partie de la version désigne la version du composant. Pour les composants étroitement liés au système d'exploitation, il s'agit généralement de la valeur de uname -r pour cette version du système d'exploitation. Pour un composant avec son propre cycle de développement, cette séquence est un numéro de version à points, tels que 2.4.10.
La seconde partie de la version qui, si elle est présente, doit suivre une virgule (,), est la version de compilation. La version de compilation indique la version du système d'exploitation sous laquelle le contenu du package a été créé, et fournit une version du système d'exploitation minimale sous laquelle le contenu est prévu pour fonctionner correctement.
La troisième partie de la version, si elle est présente, doit suivre un trait d'union (-), et désigne la version de la branche. La version de la branche est un composant de version qui donne des informations spécifiques au fournisseur. La version de la branche peut être incrémentée lorsque les métadonnées de package sont modifiées, indépendamment de la version du composant. La version de la branche peut contenir un numéro de version de compilation ou d'autres informations.
La quatrième partie de la version, si elle est présente, doit suivre un signe deux-points (:) et désigne un horodatage. L'horodatage indique la date à laquelle le package a été publié.
Lorsque vous effectuez des comparaisons entre les versions, aucun des composants de la version complète n'est pris en compte, à moins que les composants à sa gauche soient les mêmes. Par conséquent, une version 4.3-1 est supérieure à 4.2-7 car 4.3 est supérieur à 4.2, et 4.3-3 est supérieur à 4.3-1 car 3 est supérieur à 1.
De nombreuses parties du système, n'affichent pas les FMRI complets, et acceptent les entrées plus courtes afin de réduire le volume d'informations affichées ou requises. En règle générale, le schéma, l'éditeur, la version de compilation et l'horodatage peuvent être omis. Parfois, toutes les informations sur la version peuvent être omises.
Les actions représentent les objets d'un système pouvant être installés. Les actions sont décrites dans le fichier manifeste d'un package. Chaque action est essentiellement constituée de son nom et d'un attribut clé. Ensemble, elles se rapportent à un objet unique suivant un historique des versions. Les actions peuvent comprendre d'autres attributs. Certains attributs sont interprétés directement par le système d'empaquetage. D'autres attributs ne peuvent être utiles qu'à l'administrateur système ou à l'utilisateur final.
Les actions ont une représentation en texte simple :
action_name attribute1=value1 attribute2=value2 ...
Les noms d'attributs ne peuvent pas contenir de blancs, de guillemets ou de signes égal (=). Tous les caractères après le premier signe égal appartiennent à la valeur. Les valeurs peuvent contenir tous ces caractères, bien qu'il faille placer les espaces entre guillemets simples ou doubles. Les guillemets simples n'ont pas besoin d'être remplacés par des caractères d'échappement à l'intérieur d'une chaîne qui est entre guillemets doubles, et les guillemets doubles n'ont pas besoin d'être remplacés par des caractères d'échappement à l'intérieur d'une chaîne qui est entre guillemets simples. Un guillemet peut être précédé d'une barre oblique inverse (\) afin d'éviter l'interruption de la chaîne entre guillemets. Une barre oblique inverse peut être placée dans une séquence d'échappement avec une barre oblique inverse.
Les attributs peuvent être nommés plus d'une fois avec plusieurs valeurs. Celles-ci sont traitées en tant que listes à puces.
Les actions avec de nombreux attributs peuvent créer des lignes longues dans un fichier manifeste. Ces lignes peuvent être renvoyées à la ligne en terminant chaque ligne incomplète par une barre oblique inverse. Notez que ce caractère de suite doit apparaître entre les paires attribut/valeur. Ni les attributs, ni leurs valeurs, ni la combinaison des deux, ne peuvent être fractionnés.
La liste des attributs ci-dessous n'est pas exhaustive. En fait, les attributs qui peuvent être reliés à une action sont arbitraires, et les ensembles d'attributs standard sont faciles à augmenter pour incorporer des développements futurs.
Certains attributs d'action déclenchent l'exécution d'opérations supplémentaires en dehors du contexte du package. Ces attributs sont présentés dans la section Actionneurs ci-dessous.
L'action file représente un fichier ordinaire. L'action file fait référence à une charge utile et possède quatre attributs standard :
Chemin du système de fichiers où le fichier est installé. C'est un attribut clé d'action file.
Les autorisations d'accès (sous forme numérique) au fichier. Il s'agit d'autorisations simples, et non d'ACL.
Nom de l'utilisateur propriétaire du fichier.
Nom du groupe auquel appartient le fichier.
La charge utile est un attribut de position dans la mesure où il n'est pas nommé. Il s'agit du premier mot après le nom de l'action. Dans un manifeste publié, il correspond au hachage SHA-1 du contenu du fichier. S'il est présent dans un manifeste qui n'a pas encore été publié, il représente le chemin d'accès à la charge utile. Reportez-vous à pkgsend(1). L'attribut de hachage peut être utilisé à la place de l'attribut de position, mais sa valeur doit inclure un signe égal. Les deux peuvent être utilisés dans la même action. Cependant, les hachages doivent être identiques.
Il existe d'autres attributs :
Indique que le contenu du fichier ne doit pas être remplacé pendant la mise à niveau s'il est déterminé que le contenu a été modifié depuis l'installation ou la dernière mise à niveau du fichier. Lors des installations initiales, si un fichier existant est trouvé, il est récupéré (et stocké dans /var/pkg/lost+found).
Si la valeur de preserve est renameold, le fichier existant est renommé avec l'extension .old, puis remplacé par le nouveau fichier.
Si la valeur de preserve est renamenew, le fichier existant est isolé, et le nouveau fichier est installé avec l'extension .new.
Si la valeur de preserve est legacy, ce fichier n'est pas installé lors d'installations de package initiales. Pendant les mises à niveau, tout fichier existant est renommé avec l'extension .legacy, puis remplacé par le nouveau fichier.
Si la valeur de preserve est true (ou une valeur non répertoriée ci-dessus, comme strawberry), le fichier existant est isolé, et le nouveau fichier n'est pas installé.
Indique si l'action permet à d'autres packages de fournir un fichier au même emplacement ou si elle fournit un fichier destiné à en recouvrir un autre. Cette fonctionnalité est destinée à être utilisée avec les fichiers de configuration qui ne participent à aucun auto-assemblage (par exemple, /etc/motd) et qui peuvent être remplacés en toute sécurité.
Si overlay n'est pas spécifié, plusieurs packages ne peuvent pas fournir des fichiers au même emplacement.
Si la valeur de overlay est allow, un autre package est autorisé à fournir un fichier au même emplacement. Cette valeur n'a aucun effet, sauf si l'attribut preserve est également défini.
Si la valeur de overlay est true, le fichier fourni par l'action remplace toute autre action qui a spécifié allow. Les modifications apportées au fichier installé sont conservées dans la valeur de l'attribut preserve du fichier de recouvrement. Lors de la suppression, le contenu du fichier est conservé si l'action en cours de recouvrement est toujours installée, que l'attribut preserve soit ou non spécifié. Seule une action peut en recouvrir une autre, et les attributs mode, owner et group doivent correspondre.
Les fichiers peuvent également être "goûtés" et, en fonction de leur saveur, posséder des attributs supplémentaires. Pour des fichiers ELF, les attributs suivants sont reconnus :
Architecture du fichier ELF. Il s'agit de la sortie de uname -p sur l'architecture pour laquelle le fichier est créé.
32 ou 64.
Hachage des sections ELF "intéressantes" dans le fichier. Ce sont les sections qui sont mises en correspondance dans la mémoire lorsque le fichier binaire est chargé. Il s'agit des seules sections à prendre en compte lorsqu'il s'agit de déterminer si le comportement exécutable de deux fichiers binaires diffère.
Cet attribut est utilisé pour traiter les fichiers modifiables passant d'un package à un autre ou d'un endroit à un autre, ou les deux. Il prend la forme du nom du package d'origine, suivi de deux-points et du chemin d'accès d'origine au fichier. Tout fichier supprimé est enregistré avec son package et son chemin, ou avec la valeur de l'attribut original_name s'il est spécifié. Tout fichier modifiable en cours d'installation, ayant l'attribut original_name configuré, utilise le fichier de ce nom s'il est supprimé dans le cadre de la même opération d'empaquetage.
Cet attribut est utilisé pour marquer les fichiers modifiables qui doivent être rétablis sous la forme d'un jeu. Vous pouvez spécifier plusieurs valeurs revert-tag. Le fichier redevient un manifeste lorsque pkg revert est appelé et que l'une de ces balises est spécifiée. Reportez-vous à pkg(1).
L'action dir est similaire à l'action file dans la mesure où elle représente un objet système de fichiers. L'action dir représente un répertoire au lieu d'un fichier ordinaire. L'action dir possède les mêmes quatre attributs standard que l'action file, et path constitue l'attribut clé.
Les répertoires sont des références comptées dans IPS. Lorsque le dernier package qui faisait explicitement ou implicitement référence à un répertoire ne le fait plus, ce répertoire est supprimé. Si ce répertoire contient des objets système de fichiers non empaquetés, ces éléments sont déplacés vers $IMAGE_META/lost+found. Reportez-vous à la section Fichiers pour plus d'informations sur $IMAGE_META.
Pour déplacer du contenu non empaqueté dans un nouveau répertoire, l'attribut suivant peut s'avérer utile :
Nomme un répertoire d'éléments récupérés. Un répertoire doté de cet attribut hérite lors de sa création du contenu du répertoire récupéré s'il existe.
L'action link représente un lien symbolique. L'action link possède les attributs standard suivants :
Chemin du système de fichiers où le lien symbolique est installé. C'est un attribut clé d'action link.
La cible du lien symbolique. L'objet système de fichiers associé à la résolution du lien.
Spécifie l'entrée dans l'espace de noms de médiation partagé par tous les noms de chemin faisant partie d'un groupe de médiation donné (par exemple, python ). La médiation de liens peut être effectuée en fonction de mediator-version et/ou mediator-implementation. Tous les liens de médiation d'un chemin donné doivent indiquer le même médiateur. Toutefois, toutes les versions et implémentations de médiateur ont besoin de fournir un lien à un chemin donné. Si une médiation ne fournit pas de lien, le lien est supprimé lorsque que la médiation est sélectionnée. Un attribut mediator, en combinaison avec une version spécifique et/ou une implémentation représente une médiation qui peut être sélectionnée en vue d'une utilisation par le système d'empaquetage.
Spécifie la version (exprimée sous la forme d'une séquence d'entiers non négatifs séparés par des points) de l'interface décrite par l'attribut mediator. Cet attribut est requis si mediator est spécifié et mediator-implementation ne l'est pas. Un administrateur système local peut définir la version à utiliser explicitement. La valeur indiquée doit généralement correspondre à la version d'un package fournissant le lien (par exemple, runtime/python-26 doit utiliser mediator-version=2.6), bien que ce ne soit pas nécessaire.
Spécifie l'implémentation du médiateur à utiliser en plus ou à la place de mediator-version. Les chaînes d'implémentation ne sont pas considérées comme étant ordonnées, et pkg (5) sélectionne une chaîne arbitrairement si celle-ci n'est pas explicitement spécifiée par un administrateur système.
La valeur peut être une chaîne de caractères de longueur arbitraire composée de caractères alphanumériques et d'espaces. Si l'implémentation peut contenir une version ou en possède une, la version doit être spécifiée à la fin de la chaîne, après un @ (exprimée sous la forme d'une séquence d'entiers non négatifs séparés par des points). Si plusieurs versions d'une implémentation existent, le comportement par défaut consiste à sélectionner l'implémentation avec la plus grande version.
Si une seule instance d'un lien de médiation d'implémentation est installée sur un système, dans un chemin particulier, alors c'est celle-ci qui est automatiquement sélectionnée. Si, plus tard, des liens sont installés dans ce chemin d'accès, le lien reste inchangé à moins qu'un fournisseur, un site, ou un remplacement local ne s'applique, ou que l'un des liens possède un médiateur de version.
Lors de la résolution des conflits dans les liens de médiation, pkg(5) choisit généralement le lien avec la plus grande valeur mediator-version ou basé sur mediator-implementation si ce n'est pas possible. Cet attribut est utilisé pour spécifier une valeur de remplacement pour le processus de résolution des conflits normal.
Si cet attribut n'est pas spécifié, la logique de sélection mediator par défaut est appliquée.
Si la valeur est vendor, ce lien est préféré à ceux qui ne disposent pas d'un attribut mediator-priority spécifié.
Si la valeur est site, le lien est préféré à ceux qui ont une valeur vendor ou qui ne disposent pas d'un attribut mediator-priority spécifié.
Un administrateur système local peut remplacer la logique de sélection décrite ci-dessus.
L'action hard link représente un lien physique. Elle possède les mêmes attributs que l'action link, et path est également son attribut clé.
L'action driver représente un pilote de périphérique. L'action driver ne fait pas référence à une charge utile. Les fichiers driver eux-mêmes doivent être installés comme les actions file. Les attributs suivants sont reconnus (reportez-vous à add_drv(1M) pour plus d'informations) :
Nom du pilote. Il s'agit généralement, mais pas toujours, du nom de fichier binaire de pilote. C'est un attribut clé d'action driver.
Alias pour le pilote. Un pilote donné peut avoir plusieurs attributs alias. Aucune règle de citation particulière n'est requise.
Représente une classe de pilote. Un pilote donné peut avoir plusieurs attributs class.
Autorisations du système de fichiers pour accéder aux noeuds de périphérique du pilote.
Autorisations du système de fichiers pour accéder aux noeuds mineurs du pilote clone de ce pilote.
Stratégie de sécurité supplémentaire pour le périphérique. Un pilote donné peut avoir plusieurs attributs policy, mais aucune spécification du périphérique mineur ne peut être présente dans plus d'un attribut.
Privilèges utilisés par le pilote. Un pilote donné peut avoir plusieurs attributs privs.
Entrée dans /etc/devlink.tab. La valeur correspond à la ligne exacte pour aller dans le fichier, avec des onglets représentés par \t. Reportez-vous à devlinks(1M) pour plus d'informations. Un pilote donné peut avoir plusieurs attributs devlink.
L'action depend représente une dépendance entre packages. Un package peut dépendre d'un autre package, en raison d'une fonctionnalité qu'il requiert pour son fonctionnement, voire son installation, et dont l'autre package dispose. Les dépendances peuvent être facultatives. Si une dépendance n'est pas satisfaite au moment de l'installation, le système d'empaquetage tente d'installer ou de mettre à jour le package dépendant vers une version suffisamment récente, en fonction d'autres contraintes.
Les attributs suivants sont reconnus :
FMRI du package dépendant. C'est un attribut clé d'action dependency. La valeur fmri ne doit pas inclure l'éditeur. Le nom du package est supposé être complet. Les dépendances de type require-any peuvent avoir plusieurs attributs fmri. La version est facultative sur la valeur du fmri, bien que pour certains types de dépendances, un fmri sans version n'a aucune signification.
Type de la dépendance.
Si la valeur est require, la dépendance est requise et doit avoir une version égale ou supérieure à la version spécifiée dans l'attribut fmri. Si la version n'est pas spécifiée, n'importe quelle version satisfait cette dépendance. Un package ne peut pas être installé si aucune des dépendances obligatoires ne peut être satisfaite.
Si la valeur est optional, la dépendance, le cas échéant, doit être au niveau de version spécifié ou supérieur.
Si la valeur est exclude, le package qui la contient ne peut pas être installé si la dépendance est présente au niveau de version spécifié ou supérieur. Si aucune version n'est spécifiée, le package dépendant ne peut pas être installé simultanément avec le package spécifiant la dépendance.
Si la valeur est incorporate, la dépendance est facultative, mais la version du package dépendant est limitée. Reportez-vous à la section Contraintes et figement ci-dessous.
Si la valeur est require-any, n'importe quel package dépendant spécifié par plusieurs attributs fmri peut satisfaire la dépendance, suivant les mêmes règles que pour le type de dépendance require.
Si la valeur est conditional, la dépendance est requise uniquement si le package défini par l'attribut predicate est présent sur le système.
Si la valeur est origin, la dépendance doit, le cas échéant, être sur la valeur spécifiée ou, au mieux, sur l'image à modifier avant l'installation. Si la valeur de l'attribut root-image est true, la dépendance doit être présente sur l'image root afin d'installer ce package.
Si la valeur est group, la dépendance est requise, sauf si le package est sur la liste avoid de l'image. Notez que les packages obsolètes satisfont silencieusement la dépendance du groupe. Reportez-vous à la sous-commande avoid dans pkg(1).
Si la valeur est parent, la dépendance est ignorée si l'image n'est pas une image enfant. Si l'image est une image enfant, la dépendance doit être présente dans l'image parent. La version du package correspondant à une dépendance parent est la même que celle utilisée pour les dépendances incorporate.
FMRI indiquant le prédicat pour les dépendances conditional.
N'a d'effet que pour les dépendances origin, comme mentionné ci-dessus.
L'action license représente un fichier licence ou d'autres fichiers d'informations associés au contenu du package. Un package peut fournir des licences, des exclusions de responsabilité ou d'autres conseils au programme d'installation via l'utilisation d'une action license.
La charge utile de l'action license est fournie dans le répertoire des métadonnées d'image associées au package, et doit contenir uniquement des données texte lisible par l'homme. Il ne doit pas contenir de balises HTML ou toute autre forme de balisage. Par le biais d'attributs, les actions license peuvent indiquer aux clients que la charge utile associée doit être affichée et/ou soumise à acceptation. La méthode d'affichage et/ou d'acceptation est à la discrétion des clients.
Les attributs suivants sont reconnus :
C'est un attribut clé d'action license. Cet attribut fournit une description précise de la licence qui aide les utilisateurs à déterminer le contenu sans lire le texte de la licence lui-même. Voici quelques exemples de valeurs :
ABC Co. Copyright Notice
ABC Co. Custom License
Common Development and Distribution License 1.0 (CDDL)
GNU General Public License 2.0 (GPL)
GNU General Public License 2.0 (GPL) Only
MIT License
Mozilla Public License 1.1 (MPL)
Simplified BSD License
La valeur license doit être unique au sein d'un package. Il est recommandé d'ajouter la version de la licence dans la description, comme illustré dans les exemples ci-dessus. Si un package comprend du code sous plusieurs licences, utilisez plusieurs actions license. La longueur maximale de la valeur d'attribut license est fixée à 64 caractères.
Si la valeur est true, cette licence doit être acceptée par un utilisateur pour que le package associé puisse être installé ou mis à jour. L'omission de cet attribut équivaut à une valeur false. La méthode d'acceptation (interactive ou basée sur la configuration, par exemple) est à la discrétion des clients.
Si la valeur est true, la charge utile de l'action doit être affichée par les clients pendant les opérations d'empaquetage. L'omission de cette valeur équivaut à une valeur false. Cet attribut ne doit pas être utilisé pour les mentions de copyright. Il ne peut servir qu'aux véritables licences ou à d'autres contenus qui doivent être affichés au cours des opérations. La méthode d'affichage est à la discrétion des clients.
L'action legacy représente les données de package utilisées par un système d'empaquetage hérité. Les attributs associés à cette action sont ajoutés aux bases de données du système hérité de sorte que les outils effectuant des requêtes dans ces bases de données peuvent fonctionner comme si le package hérité était installé. En particulier, elle doit suffire à convaincre le système hérité que le package nommé par l'attribut pkg est installé sur le système, de sorte que ce package peut être utilisé pour satisfaire les dépendances.
Les attributs suivants, nommés conformément aux paramètres de pkginfo(4), sont reconnus :
Valeur pour le paramètre CATEGORY. La valeur par défaut est system.
Valeur pour le paramètre DESC.
Valeur pour le paramètre HOTLINE.
Valeur pour le paramètre NAME. La valeur par défaut est none provided.
Abréviation du package en cours d'installation. La valeur par défaut est le nom du FMRI du package. C'est un attribut clé d'action legacy.
Valeur pour le paramètre VENDOR.
Valeur pour le paramètre VERSION. La valeur par défaut est la version issue du FMRI du package.
L'action set représente un attribut de niveau de package, ou des métadonnées, tel que la description du package.
Les attributs suivants sont reconnus :
Nom de l'attribut.
Valeur de l'attribut.
L'action set peut fournir n'importe quelles métadonnées choisies par l'auteur du package. Toutefois, il y a un certain nombre de noms d'attribut bien définis qui ont une signification particulière auprès du système d'empaquetage.
Reportez-vous à la section “FMRI et versions de packages” sous “Description”.
Un ou plusieurs jetons qu'un client pkg(5) peut utiliser pour classifier le package. La valeur doit avoir comporter schéma (tel que "org.opensolaris.category.2008" ou "org.acm.class.1998") et la classification réelle, par exemple "Applications/Games", séparés par deux-points (:).
Description détaillée du contenu et des fonctionnalités de ce package, en général de la longueur d'un paragraphe.
Si la valeur est true, le package est marqué comme obsolète. Un package obsolète peut n'avoir aucune autre action que des actions sur les ensembles, et ne doit pas être marqué comme renommé.
Si la valeur est true, le package a été renommé. Il doit exister dans le package une ou plusieurs actions depend qui pointent également vers les versions du package sur lesquelles ce package a été renommé. Un package ne peut pas être marqué à la fois comme renommé et obsolète, mais peut avoir n'importe quel nombre d'actions set.
Brève description du package sur une seule ligne.
L'action group définit un groupe UNIX tel que défini dansgroup(4). Les mots de passe de groupe ne sont pas pris en charge. Les groupes définis avec cette action ne présentent généralement pas de liste d'utilisateurs. Vous pouvez ajouter des utilisateurs avec l'action user. Les attributs suivants sont reconnus :
Valeur pour le nom du groupe.
ID numérique unique du groupe. La valeur par défaut est le premier groupe disponible sous 100.
L'action user définit un utilisateur UNIX tel que défini dans les fichiers /etc/passwd, /etc/shadow, /etc/group et /etc/ftpd/ftpusers. Pour les utilisateurs définis avec cet attribut, des entrées sont ajoutées aux fichiers appropriés.
Les attributs suivants sont reconnus :
Nom unique de l'utilisateur
Mot de passe chiffré de l'utilisateur. La valeur par défaut est *LK*. Reportez-vous à shadow(4).
UID unique de l'utilisateur. La valeur par défaut est la première valeur disponible sous 100.
Nom du groupe principal de l'utilisateur. Se trouve dans /etc/group.
La valeur du champ gcos dans /etc/passwd. La valeur par défaut est username.
Répertoire personnel de l'utilisateur. La valeur par défaut est /.
Le shell par défaut de l'utilisateur. La valeur par défaut est vide.
Groupes secondaires auxquels l'utilisateur appartient. Reportez-vous à group(4).
Peut être défini sur true ou false. La valeur par défaut de true indique que l'utilisateur est autorisé à se connecter via FTP. Reportez-vous à ftpusers(4).
Le nombre de jours entre le 1er janvier 1970 et la date à laquelle le mot de passe a été modifié pour la dernière fois. La valeur par défaut est vide. Reportez-vous à shadow(4).
Nombre minimum de jours requis entre les modifications de mot de passe. Ce champ doit être défini sur 0 ou plus pour activer le vieillissement du mot de passe. La valeur par défaut est vide. Reportez-vous à shadow(4).
Nombre maximal de jours pendant lesquels le mot de passe est valide. La valeur par défaut est vide. Reportez-vous à shadow(4).
Nombre de jours avant l'expiration du mot de passe où un avertissement signalant l'expiration est envoyé à l'utilisateur. Reportez-vous à shadow(4).
Nombre de jours d'inactivité autorisés pour cet utilisateur. Ce nombre est calculé par ordinateur. Les informations sur l'heure de la dernière connexion sont issues du fichier lastlog de l'ordinateur. Reportez-vous à shadow(4).
Date absolue exprimée sous la forme d'un nombre de jours écoulés depuis l'époque UNIX (1er janvier 1970). Lorsque cette valeur est atteinte, la connexion ne peut plus être utilisée. Par exemple, une valeur d'expiration de 13514 spécifie un délai d'expiration de connexion au 1er janvier 2007. Reportez-vous à shadow(4).
Défini sur empty. Reportez-vous à shadow(4).
Dans certains contextes, l'exécution d'autres opérations peut être appropriée en préparation à ou suite à l'introduction d'une action donnée. En général, ces opérations supplémentaires sont nécessaires uniquement sur une image du système actif et sont propres au système d'exploitation. Lorsque plusieurs actions impliquées dans l'installation ou le retrait d'un package ont les mêmes actionneurs, l'opération correspondant à la présence d'un actionneur est exécutée une fois pour cette installation ou ce retrait.
Les actionneurs non spécifiés correctement peuvent entraîner un échec de l'installation du package, notamment si l'actionneur ne peut pas déterminer un moyen de rendre sûre la progression de l'installation.
Les actionneurs suivants peuvent être définis :
Peut être défini sur true ou false. Pendant l'installation d'un package, si une action est installée ou mise à jour avec cet actionneur défini sur true, la transaction relative au package peut requérir une réinitialisation. Certaines implémentations client peuvent nécessiter des étapes supplémentaires, telles que l'exécution de toute opération d'empaquetage à l'aide d'un clone de l'image, dans le cas où l'image est une image du système actif.
Chacun de ces actionneurs prend la valeur d'un FMRI d'une instance de service sur laquelle fonctionner pendant l'installation ou le retrait du package. disable_fmri désactive le FMRI donné avant la suppression d'une action, par le biais de la sous-commande disable dans svcadm(1M). refresh_fmri et restart_fmri actualisent ou redémarrent le FMRI donné après l'installation, la mise à jour ou la suppression d'une action à l'aide des sous-commandes respectives de svcadm(1M). Enfin, suspend_fmri désactive temporairement le FMRI avant la phase d'installation de l'action, puis l'active au terme de cette phase.
La valeur peut contenir un modèle qui correspond à plusieurs instances de service. Toutefois, elle doit le faire explicitement à l'aide d'un glob accepté par svcs(1), au lieu de procéder implicitement en n'indiquant pas toutes les instances.
Les questions de savoir quand un package doit passer à une nouvelle version, quand il doit être ajouté ou supprimé du système, quelle version doit être sélectionnée et si la suppression est autorisée dépendent d'un grand nombre de contraintes imposées au package. Ces contraintes peuvent être définies par d'autres packages sous forme de dépendances, ou par l'administrateur sous forme de figements.
La forme de contrainte la plus commune est fournie par la dépendance require, comme décrit à la section Actions sur les dépendances ci-dessus. Ce type de restriction empêche le package d'être déclassé ou supprimé.
La plupart des parties du système d'exploitation sont encapsulées par packages appelés incorporations. Ces packages fournissent principalement des contraintes représentées par la dépendance incorporate.
Comme décrit ci-dessus, un package incorporé n'a pas besoin d'être présent sur le système, mais s'il s'y trouve, il spécifie à la fois une version minimum inclusive et une version maximum exclusive. Par exemple, si le FMRI dépendant porte la version 1.4.3, aucune version inférieure à 1.4.3 ne répond à la dépendance, pas plus qu'une version égale ou supérieure à 1.4.4. Cependant, les versions qui ne font qu'étendre la séquence (comme 1.4.3.7) sont autorisées.
Les incorporations sont utilisées pour forcer la mise à niveau simultanée de certaines parties du système. Pour certains composants, tels que la bibliothèque C et le noyau, il s'agit d'une condition de base. Pour d'autres, tels qu'un simple composant userland n'ayant aucune dépendance, la mise à niveau synchrone sert uniquement à fournir un ensemble de versions connu et testé d'un package auquel peut faire référence une version particulière de l'incorporation.
Puisqu'une incorporation constitue simplement un package, elle peut être supprimée, et toutes les contraintes qu'elle offre sont donc relâchées. Cependant, un grand nombre d'incorporations fournies par Oracle Solaris sont requises par les packages qu'elles intègrent, car le relâchement ne serait pas sûr.
Toute tentative de mise à niveau d'un package vers une version qui n'est pas autorisée par une incorporation installée échouera, et ne tentera pas de trouver une version plus récente de l'incorporation pour satisfaire la demande. Si la contrainte elle-même doit être déplacée, et si l'incorporation qui la spécifie ne peut pas être supprimée, l'incorporation doit être mise à niveau vers une version qui spécifie une version souhaitée de la contrainte. La mise à niveau d'une incorporation entraîne celle de tous les packages incorporés qui ne satisfont pas les contraintes fournies par la nouvelle version.
Un administrateur système peut contraindre un package à l'aide de la commande pkg freeze. Le package nommé est contraint à la version installée sur le système si aucune version n'est fournie. Si un package avec version est fourni, cette contrainte administrative, ou figement, agit comme si une dépendance incorporate était installée à l'endroit où l'attribut fmri possède la valeur de la version du package fournie.
Un gel n'est jamais annulé automatiquement par le système d'empaquetage. Pour relâcher une contrainte, utilisez la commande pkg unfreeze.
Comme expliqué ci-dessus, un éditeur est un simple nom que les clients du package utilisent pour identifier le fournisseur de packages. Les éditeurs peuvent distribuer les packages en utilisant les référentiels de packages et/ou archives de packages. Il y a deux types de référentiels actuellement pris en charge par le système de packages : référentiels d'origine et référentiels miroirs.
L'origine est un référentiel de packages qui contient toutes les métadonnées (catalogues, manifestes, et les index de recherche) et du contenu (fichiers) pour un ou plusieurs packages. Si plusieurs origines sont configurées pour un éditeur donné dans une image, l'API du client du package tente de choisir la meilleure origine à partir de laquelle extraire les données de package. Il s'agit du type de référentiel le plus courant, implicitement créé chaque fois que la commande pkgsend ou pkgrecv est utilisée sur un référentiel de packages.
Un miroir est un référentiel de package incluant uniquement le contenu d'un package (fichiers). Si un ou plusieurs miroirs sont configurés pour un éditeur dans une image, l'API du client préfère les miroirs pour l'extraction du contenu d'un package et tente de choisir le meilleur miroir à partir duquel extraire les données de package. Si le miroir est inaccessible, n'a pas le contenu requis, ou est plus lent, l'API du client extrait le contenu de n'importe quel référentiel d'origine configuré. Les miroirs sont conçus pour le partage de contenu dans un ensemble de clients de confiance en miroir avec la fonctionnalité de mise en miroir dynamique pkg.depotd(1M). Les miroirs sont également destinés à être utilisés pour authentifier l'accès aux métadonnées du package, mais ils distribuent le contenu du package sans authentification. Par exemple, un client peut être configuré avec une origine https requérant une paire clé/certificat SSL pour accéder aux ressources et un miroir http fournissant le contenu du package. De cette manière, seuls les clients autorisés peuvent installer ou mettre à jour les packages, et il est possible de faire l'économie du temps système nécessaire à l'authentification lors de l'extraction du contenu d'un package. Un miroir peut être créé par la suppression de tous les sous-répertoires d'un référentiel, à l'exception de ceux nommés file et à leurs parents. Un référentiel d'origine peut être également alloué en tant que miroir à l'aide du mode miroir de pkg.depotd(1M).
Les logiciels peuvent avoir des composants optionnels et des composants incompatibles. Les environnements linguistiques et la documentation sont des exemples de composants optionnels. Les binaires SPARC ou x86 et les binaires de débogage et de non-débogage sont des exemples de composants incompatibles.
Dans IPS, les composants optionnels sont appelés des facettes et les composants incompatibles sont appelés des variantes. Les facettes et les variantes sont spécifiées sous forme de repères sur les actions de package. Chaque repère de facette et de variante possède un nom et une valeur. Une seule action peut avoir plusieurs repères de facette et de variante. Parmi les exemples de composants incluant plusieurs repères de facette et de variante, il faut citer un fichier d'en-tête propre à l'architecture utilisé par les développeurs ou un composant réservé à une zone globale SPARC.
variant.arch=sparc est un exemple de repère de variante. Voici un exemple de repère de facette : facet.devel=true. Il est souvent fait référence aux facettes et variantes sans les faire précéder de facet. et variant..
Les facettes et les variantes sont des propriétés spéciales de l'image et ne peuvent pas être définies sur des packages individuels. Pour afficher les valeurs actuelles des facettes et variantes définies dans l'image, exécutez les commandes pkg facet et pkg variant, comme décrit à la page de manuel pkg(1). Pour modifier les valeurs des facettes et variantes définies dans l'image, exécutez les commandes pkg change-facet et pkg change-variant.
Les facettes sont booléennes : elles peuvent uniquement être définies sur true (activé) ou false (désactivé). Par défaut, toutes les facettes sont considérées comme définies sur true dans une image. Un repère de facette sur une action doit uniquement avoir la valeur true ; les autres valeurs ont des comportements indéterminés. Une facette définie sur l'image peut être une facette complète telle que doc.man ou un modèle tel que locale.*. L'intérêt de cette caractéristique est qu'elle vous permet de désactiver une partie de l'espace de noms d'une facette et de n'activer que des facettes individuelles en son sein. Par exemple, vous pouvez désactiver tous les environnements linguistiques, puis n'activer qu'un ou deux environnements linguistiques particuliers, comme illustré dans l'exemple suivant :
# pkg change-facet locale.*=false [output about packages being updated] # pkg change-facet locale.en_US=true [output about packages being updated]
La plupart des variantes peuvent avoir un nombre de valeurs quelconque. Par exemple, il est possible de définir la variante arch sur i386, sparc, ppc, arm ou une autre architecture prise en charge par la distribution. (Seules les valeurs i386 et sparc sont utilisées dans Oracle Solaris.) Les variantes debug constituent une exception. Il est possible de définir les variantes debug uniquement sur true ou false. Aucune autre valeur ne correspond à un comportement défini. Si une action sur un fichier présente à la fois des versions avec et sans débogage, il faut définir explicitement la variante debug pour les deux versions, comme illustré dans l'exemple suivant :
file group=sys mode=0644 overlay=allow owner=root \ path=etc/motd pkg.csize=115 pkg.size=103 preserve=true \ variant.debug.osnet=true file group=sys mode=0644 overlay=allow owner=root \ path=etc/motd pkg.csize=68 pkg.size=48 preserve=true \ variant.debug.osnet=false
Pour qu'un package utilisant une variante donnée puisse être installé, il faut que cette variante soit définie sur l'image. Les variantes arch et zone sont définies par le programme qui crée l'image et installe son contenu initial. Les variantes debug.* sont définies sur false dans l'image par défaut.
Les facettes et les variantes définies sur l'image déterminent si une action particulière est installée ou non.
Les actions sans repère de facette ou de variante sont toujours installées.
Les actions avec repères de facettes sont installées, sauf si toutes les facettes ou tous les modèles de facettes correspondant aux repères sont définis sur false dans l'image. Si une seule facette est définie sur true ou n'est pas explicitement définie (true est la valeur par défaut), l'action est installée.
Les actions avec repères de variantes sont uniquement installées si les valeurs des repères de variantes sont les mêmes que celles définies dans l'image.
Les actions comportant à la fois des repères de facettes et des repères de variantes sont installées si les facettes et les variantes autorisent l'installation des actions concernées.
Vous pouvez créer vos propres repères de facettes et de variantes. Les repères suivants sont couramment utilisés dans Oracle Solaris.
|
La liste suivante présente quelques exemples de repères de facettes utilisés dans Oracle Solaris :
facet.devel facet.doc facet.doc.html facet.doc.info facet.doc.man facet.doc.pdf facet.locale.de facet.locale.en_GB facet.locale.en_US facet.locale.fr facet.locale.ja_JP facet.locale.zh_CN
Les stratégies d'image sont définies par des propriétés de l'image avec des valeurs booléennes. Reportez-vous à la section “Propriétés de l'image” dans la page de manuel pkg(1) pour une descriptions des propriétés flush-content-cache-on-success et send-uuid ainsi que des informations sur l'affichage et la modification de leurs valeurs.
Les images pkg(5) peuvent être stockées arbitrairement dans un plus grand système de fichiers. De ce fait, le jeton $IMAGE_ROOT sert à distinguer les chemins d'accès relatifs. Pour une installation système standard, $IMAGE_ROOT équivaut à /.
Répertoire des métadonnées pour une image complète ou partielle.
Répertoire des métadonnées pour une image d'utilisateur.
Dans les métadonnées d'une image particulière, certains fichiers et répertoires contiennent des informations utiles lors de la réparation et de la récupération. Le jeton $IMAGE_META est utilisé pour désigner le répertoire de niveau supérieur qui contient les métadonnées. $IMAGE_META est en général l'un des deux chemins d'accès donnés ci-dessus.
Emplacement des répertoires entrant en conflit et fichiers déplacés au cours d'une opération sur les packages.
Contient un répertoire pour chaque éditeur. Chaque répertoire stocke des métadonnées spécifiques à l'éditeur.
D'autres chemins dans l'arborescence des répertoires $IMAGE_META sont privés et sujets à modification.
Reportez-vous à attributes(5) pour obtenir la description des attributs suivants :
|
pkg(1), pkgsend(1), pkg.depotd(1m), pkg.sysrepo(1m), svcs(1), svcadm(1M)
http://hub.opensolaris.org/bin/view/Project+pkg/
|