Cet article s'appuie sur mes articles précédents sur les espaces de noms, Les 7 espaces de noms Linux les plus utilisés et ma série sur la création manuelle d'un conteneur Linux à l'aide d'espaces de noms, l'utilisation de l'espace de noms de montage et l'utilisation de l'espace de noms PID. Cet article couvre l'espace de noms UTS et sa relation avec les conteneurs.
L'observateur occasionnel comprend souvent mal l'espace de noms Unix Timesharing System (UTS), en grande partie parce que son nom ne correspond plus à son objectif. Malgré son nom, l'espace de noms UTS contrôle en fait le nom d'hôte et le domaine NIS. Voici comment la page de manuel décrit l'espace de noms UTS :
Ces identifiants sont définis à l'aide de
sethostname(2)etsetdomainname(2), et peut être récupéré en utilisantuname(2),gethostname(2), etgetdomainname(2). Les modifications apportées à ces identifiants sont visibles pour tous les autres processus dans le même espace de noms UTS, mais ne sont pas visibles pour les processus dans d'autres espaces de noms UTS.
Cela signifie que certains outils modernes (systemd et autres) peuvent ne pas provoquer les changements que vous attendez.
Comme vous pouvez l'imaginer, il peut y avoir plusieurs cas d'utilisation dans lesquels vous pouvez souhaiter que les processus aient des noms d'hôte différents. Les serveurs Web, par exemple, ont tendance à lancer un avertissement si le nom d'hôte ne correspond pas au certificat SSL qu'ils servent. D'un autre côté, certains processus peuvent attacher le nom d'hôte à un processus réseau. Un nom d'hôte incorrect peut entraîner des connexions échouées ou refusées ou une myriade d'autres problèmes.
Cela dit, passons à quelques exemples.
Explorer l'espace de noms UTS
Vous pouvez invoquer l'espace de noms UTS avec :
$ unshare --uts /bin/bash
Cependant, vous remarquerez peut-être qu'une fois que vous êtes dans le nouvel espace de noms, en utilisant hostnamectl set-hostname ne modifie pas le nom d'hôte dans le nouvel espace de noms.
# unshare --uts
# hostname
bastion.stratus.lab
# hostnamectl set-hostname tux
# hostname
bastion.stratus.lab Si vous ouvrez un nouveau shell, cependant, le nom d'hôte a en fait changé :
[user@host ~]$ ssh root@bastion
Last login: Tue Dec 7 08:17:48 2021 from 192.168.99.198
[root@tux ~]# hostname
tux
Pourquoi est-ce? Systemd n'exécute pas le sethostname appel système. Au lieu de cela, systemd termine la tâche en se connectant à un socket. Étant donné que le socket est associé à l'ancien espace de noms, l'ancien nom d'hôte de l'espace de noms est ajusté, mais pas le nouvel espace de noms.
Utilisation des espaces de noms racine
Dans mon article sur l'espace de noms de montage, j'écris :
Maintenant que vous êtes à l'intérieur du nouvel espace de noms, vous ne vous attendez peut-être pas à voir les points de montage d'origine de l'hôte. Cependant, ce n'est pas le cas. La raison en est que systemd partage par défaut les points de montage de manière récursive avec tous les nouveaux espaces de noms.
En l'occurrence, systemd tire une grande partie de ses informations de /run , qui est partagé dans l'espace de noms que j'ai créé ici.
Dans l'article sur l'espace de noms de montage, je monte tmpfs dans le nouvel espace de noms sur un répertoire que je ne veux pas partager avec l'ancien espace de noms.
Je peux désactiver la plupart des appels systemd en montant le nouvel espace de noms avec les options suivantes :
$ unshare --mount --uts /bin/bash
Puis remontez /run :
$ mount -t tmpfs tmpfs /run L'ensemble du processus ressemble à ceci :
# unshare --fork --mount --uts /bin/bash
# mount -t tmpfs tmpfs /run
# hostnamectl set-hostname bastion.stratus.lab
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
# hostname tux
# hostname
tux Je peux le confirmer en ouvrant un nouveau shell à la boîte :
[user@host ~]$ ssh root@bastion
Last login: Tue Dec 7 08:33:04 2021 from 192.168.99.198
[root@bastion ~]# hostname
bastion.stratus.lab
Je peux trouver l'espace de noms approprié en utilisant le lsns commande :
[root@bastion ~]# lsns |grep uts
4026531838 uts 133 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 31
4026532250 uts 1 645 root /usr/lib/systemd/systemd-udevd
4026532405 uts 1 743 root /usr/lib/systemd/systemd-logind
4026532479 mnt 2 11507 root unshare --fork --mount --uts /bin/bash
4026532480 uts 2 11507 root unshare --fork --mount --uts /bin/bash
Je peux alors saisir l'espace de noms avec le nsenter commande :
[root@bastion ~]# nsenter -t 11507 -a
[root@tux /]# Utiliser un espace de noms d'utilisateur
Dans mon article sur l'espace de noms d'utilisateurs, je mentionne quelques considérations supplémentaires lors de la création d'espaces de noms en tant qu'utilisateur non privilégié :
Lorsque vous créez un nouvel espace de noms d'utilisateur, votre utilisateur actuel sera associé à l'utilisateur nobody . En effet, par défaut, aucun mappage d'ID utilisateur n'a lieu. Lorsqu'aucun mappage n'est défini, l'espace de noms utilise simplement les règles de votre système pour déterminer comment gérer un utilisateur non défini.
Reportez-vous à cet article pour en savoir plus sur le mappage des utilisateurs. Dans ce cas, je veux avoir la racine utilisateur mappé automatiquement. De cette façon, j'ai "root" dans le nouvel espace de noms. (Encore une fois, consultez l'article sur l'espace de noms d'utilisateurs pour une discussion sur les espaces de noms et les autorisations).
Si je mets en pratique mes leçons combinées sur un hôte CentOS Stream 9, j'observe :
ocp@bastion ~ $ unshare --map-root-user --user --mount --uts --fork /bin/bash
root@bastion ~ $ hostnamectl set-hostname tux
Could not set static hostname: Interactive authentication required.
C'est à cause de la façon dont polkit est configuré sur la famille de distributions RHEL. Les autres distributions ne génèrent pas nécessairement cette erreur. Arch Linux (sans polkit spécial configuration), par exemple, permet toujours au conteneur de modifier le nom d'hôte. Par conséquent, quelle que soit votre distribution, une bonne pratique de sécurité consiste toujours à remonter /run .
Il est important de noter que la sortie de lsns pourrait être plus facile à lire en utilisant --fork lors de la création d'espaces de noms.
Voici à quoi ça ressemble sans le --fork drapeau :
[root@bastion ~]# lsns |grep uts
4026531838 uts 135 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 31
4026532250 uts 1 645 root /usr/lib/systemd/systemd-udevd
4026532405 uts 1 743 root /usr/lib/systemd/systemd-logind
4026532414 uts 1 11962 ocp /bin/bash
Et avec le --fork drapeau :
[root@bastion ~]# lsns |grep uts
4026531838 uts 134 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 31
4026532250 uts 1 645 root /usr/lib/systemd/systemd-udevd
4026532405 uts 1 743 root /usr/lib/systemd/systemd-logind
4026532412 user 2 11939 ocp unshare --map-root-user --user --mount --uts --fork /bin/bash
Tant que --fork n'est pas strictement nécessaire dans ce scénario, il peut être utile ou même requis si un nouvel espace de noms PID est requis (voir mon article sur l'espace de noms PID pour plus d'informations).
Conclusion
L'espace de noms UTS n'est pas l'espace de noms Linux le plus compliqué. Il est cependant assez utile, notamment dans le cadre des conteneurs.
Pour tirer le meilleur parti de l'espace de noms UTS, combinez-le au minimum avec l'espace de noms de montage lorsque vous utilisez l'espace de noms racine et les espaces de noms de montage et d'utilisateur lors de la génération à partir d'un utilisateur non privilégié.
[ Téléchargez la feuille de triche Linux intermédiaire pour garder les commandes clés à portée de main. ]
Dans mon prochain article, je discuterai de l'espace de noms net et de la façon de l'utiliser pour permettre aux espaces de noms d'avoir leur propre espace IP et port.