NOM¶
systemd-imds, systemd-imds-import.service – Outil de
service de métadonnées d’instance d’infonuagique
(IMDS)
SYNOPSIS¶
systemd-imds-import.service
systemd-imds [OPTIONS...] [CLÉ]
DESCRIPTION¶
systemd-imds est un outil d’obtention des
données de service de métadonnées d’instance
(IMDS — Instance Metadata Service), telles que fournies dans
de nombreux environnements nuagiques. C’est un client de
systemd-imdsd@.service(8) et il fournit un accès aux
données IMDS à partir d’un environnement
d’interpréteur de commandes .
Cet outil peut opérer dans un des cinq modes
suivants :
•Sans arguments positionnels (et sans
l’option --well-known=) les données
générales de service IMDS et quelques champs notoires sont
affichés sous une forme humainement compréhensible.
•Avec un argument positionnel (et sans
l’option --well-known=) les données IMDS
référencées par la CLÉ indiquée sont
obtenues et écrites sur la sortie standard sous une forme non
traitée. Les CLÉs IMDS sont la partie de l’URL
IMDS d’obtention qui sont suffixées à l’URL de
base. Les clés IMDS doivent débuter par une barre oblique
(« / »). Notez que ces clés sont
classiquement spécifiques à
l’implémentation.
•Avec l’indication de l’option
--well-known= (voir ci-après), le champ well-known
indiqué est écrit sur la sortie standard sous une forme non
traitée. Le concept de champs well-known abstrait les
différences d’implémentation IMDS jusqu’à
un certain niveau, exposant une interface unifiée pour les champs IMDS
qui classiquement existent dans de nombreuses implémentations
différentes, mais sous des clés spécifiques à
l’implémentation.
•Si l’option --userdata est
spécifiée (voir ci-après), les
« userdata » fournies à l’aide de
IMDS sont écrites sur la sortie standard. Sous le capot c’est
similaire à --well-known=userdata-base,
--well-known=userdata ou --well-known=userdata-base64. Chacune
des trois options est essayée tour à tour (dans cet ordre) et la
première disponible est renvoyée. Pour l’option
--well-known=userdata-base l’item userdata
« systemd-userdata » est obligatoire. Pour
l’option --well-known=userdata-base64, les données
renvoyées sont automatiquement décodées en Base64.
•Si l’option --import est
indiquée, divers champs userdata et well-known sont importés
dans l’entrepôt local d’accréditations où
ils sont utilisés pour configurer et paramétrer le
système. Pour plus de détails, voir ci-après.
In addition, when invoked as a Varlink service (i.e. via socket
activation through systemd-imds-metrics.socket), systemd-imds acts as
an io.systemd.Metrics provider for systemd-report(1). It
exposes the detected cloud vendor and the well-known "hostname",
"region", "zone", "ipv4-public" and
"ipv6-public" fields as metrics in the
"io.systemd.InstanceMetadata." namespace. The data is acquired on
demand from systemd-imdsd@.service(8), benefiting from its local
cache.
OPTIONS ET COMMANDES¶
--well-known=, -K
Cette option prend une des valeurs suivantes :
« hostname »,
« region », « zone »,
« ipv4-public »,
« ipv6-public »,
« ssh-key »,
« userdata »,
« userdata-base »,
« userdata-base64 ». Elle obtient un champ
« well-known » spécifique de IMDS. Beaucoup
de ces champs sont communément pris en charge par diverses mises en
œuvre de IMDS, mais habituellement certains ne le sont pas. Notez que
si l’option
--well-known=userdata-base est utilisée, une
sous-clé supplémentaire doit être indiquée sous
forme d’argument positionnel, qui encode l’item userdata
spécifique à obtenir.
Ajouté dans la version 261.
--refresh=
Cette option prend en argument une durée en
secondes et indique la « fraîcheur » des
données requise dans le cas où des données en cache sont
utilisées.
Ajouté dans la version 261.
--cache=
Option booléenne. Si elle est définie
à « false », la mise en cache locale de
IMDS est désactivée et les données sont toujours obtenues
en temps réel du point de terminaison IMDS.
Ajouté dans la version 261.
--userdata, -u
Récupération des données utilisateur
IMDS de cette instance si disponible. Voir ci-avant pour les détails.
Ajouté dans la version 261.
--import
Récupération des données IMDS et
enregistrement des champs pertinents en tant qu’identifiants dans
/run/credstore/. Cela couvre actuellement les cas suivants :
•Si les données utilisateur IMDS
constituent un objet JSON valable contenant un champ
systemd.credentials (dont la valeur est un tableau JSON), elles sont
traitées en important les identifiants arbitraires
répertoriés dans le tableau. Chaque item du tableau doit
comporter un champ
name indiquant le nom d’identification. Il
peut exister un champ
text,
data ou
encrypted, contenant
les données d’identification. Si
text est utilisé,
la valeur doit être une chaîne littérale correspondant
à la valeur de l’identifiant. Si
data est utilisé,
la valeur peut être des données binaires arbitraires
encodées dans une chaîne Base64. Si
encrypted est
utilisé, la valeur doit être un identifiant chiffré
encodé en Base64. Voir
systemd.system-credentials(7) pour plus
d’informations sur les identifiants pouvant être importés
de cette manière.
•Si le champ well-known ssh-key est
disponible, sa valeur est importée dans l’identificateur
ssh.authorized_keys.root.
•Si le champ well-known hostname est
disponible, sa valeur est importée dans l’identificateur
firstboot.hostname.
Cette commande est invoquée par
systemd-imds-import.service à l’amorçage.
Ajouté dans la version 261.
-h, --help
Afficher un aide-mémoire succinct et
quitter.
--version
Afficher une information de version courte et
quitter.
CODE DE RETOUR¶
En cas de succès, 0 est renvoyé, autrement,
un code d'échec différent de zéro est
renvoyé.
TRADUCTION¶
La traduction française de cette page de manuel a
été créée par Jean-Paul Guillonneau
<guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez
vous reporter à la
GNU General
Public License version 3 concernant les conditions de copie et de
distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page
de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
