Ruční vytváření kontejneru pomocí jmenných prostorů:jmenný prostor UTS

Tento článek staví na mých předchozích článcích o jmenných prostorech, 7 nejpoužívanějších jmenných prostorech Linuxu a mé sérii o ručním vytváření kontejneru Linux pomocí jmenných prostorů, pomocí jmenného prostoru mount a pomocí jmenného prostoru PID. Tento článek popisuje jmenný prostor UTS a jeho vztah ke kontejnerům.

Náhodný pozorovatel často špatně chápe jmenný prostor Unix Timesharing System (UTS), především proto, že jeho název již neodpovídá jeho účelu. Navzdory svému názvu jmenný prostor UTS ve skutečnosti řídí název hostitele a doménu NIS. Zde je návod, jak manuálová stránka popisuje jmenný prostor UTS:

Tyto identifikátory se nastavují pomocí sethostname(2) a setdomainname(2) a lze je získat pomocí uname(2) , gethostname(2) a getdomainname(2) . Změny provedené v těchto identifikátorech jsou viditelné pro všechny ostatní procesy ve stejném jmenném prostoru UTS, ale nejsou viditelné pro procesy v jiných jmenných prostorech UTS.

To znamená, že některé moderní nástroje (systemd a další) nemusí způsobit změny, které očekáváte.

Jak si dokážete představit, může existovat několik případů použití, kdy budete chtít, aby procesy měly různé názvy hostitelů. Webové servery mají například tendenci vyvolat varování, pokud název hostitele neodpovídá certifikátu SSL, který obsluhují. Na druhou stranu některé procesy mohou připojit název hostitele k síťovému procesu. Nesprávný název hostitele může způsobit selhání nebo odmítnutí připojení nebo nesčetné množství dalších problémů.

Se vším, co bylo řečeno, pojďme se pustit do několika příkladů.

Prozkoumejte jmenný prostor UTS

Jmenný prostor UTS můžete vyvolat pomocí:

$ unshare --uts /bin/bash

Můžete si však všimnout, že jakmile budete v novém jmenném prostoru pomocí hostnamectl set-hostname nezmění název hostitele v novém jmenném prostoru.

# unshare --uts
# hostname
bastion.stratus.lab
# hostnamectl set-hostname tux
# hostname
bastion.stratus.lab

Pokud však otevřete nový shell, název hostitele se ve skutečnosti změnil:

[user@host ~]$ ssh root@bastion
Last login: Tue Dec 7 08:17:48 2021 from 192.168.99.198
[root@tux ~]# hostname
tux

Proč je to? Systemd nespustí sethostname systémové volání. Místo toho systemd dokončí úkol připojením k zásuvce. Vzhledem k tomu, že soket je spojen se starým jmenným prostorem, původní název hostitele jmenného prostoru je upraven, ale nikoli nový jmenný prostor.

Používání kořenových jmenných prostorů

V článku o jmenném prostoru připojení píšu:

Nyní, když jste v novém jmenném prostoru, možná neočekáváte, že uvidíte některý z původních přípojných bodů od hostitele. To však není tento případ. Důvodem je to, že systemd standardně rekurzivně sdílí přípojné body se všemi novými jmennými prostory.

Jak se stává, systemd odvozuje mnoho svých informací z /run , který je sdílen do jmenného prostoru, který jsem zde vytvořil.

V článku o jmenném prostoru připojení připojuji tmpfs do nového jmenného prostoru v adresáři, který nechci sdílet se starým jmenným prostorem.

Většinu volání systemd mohu zakázat připojením nového jmenného prostoru s následujícími možnostmi:

$ unshare --mount --uts /bin/bash

Poté znovu připojte /run :

$ mount -t tmpfs tmpfs /run

Celý proces vypadá takto:

# 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

Mohu to potvrdit otevřením nového shellu v krabici:

[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

Mohu najít vhodný jmenný prostor pomocí lsns příkaz:

[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

Poté mohu zadat jmenný prostor pomocí nsenter příkaz:

[root@bastion ~]# nsenter -t 11507 -a 
[root@tux /]#

Použití uživatelského jmenného prostoru

Ve svém článku o uživatelském jmenném prostoru zmiňuji některé další úvahy při vytváření jmenných prostorů jako neprivilegovaný uživatel:

Když vytvoříte nový uživatelský jmenný prostor, váš aktuální uživatel bude namapován na uživatele nikdo . Důvodem je, že ve výchozím nastavení neprobíhá žádné mapování ID uživatele. Pokud není definováno žádné mapování, jmenný prostor jednoduše používá pravidla vašeho systému k určení, jak zacházet s nedefinovaným uživatelem.

Další informace o mapování uživatelů naleznete v tomto článku. V tomto případě chci mít root uživatel mapován automaticky. Tímto způsobem mám „root“ v novém jmenném prostoru. (Diskuzi o jmenných prostorech a oprávněních najdete znovu v článku o jmenném prostoru uživatele).

Pokud uvedu své kombinované lekce do praxe na hostiteli CentOS Stream 9, pozoruji:

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.

Je to kvůli tomu, jak polkit je nakonfigurován na rodině distribucí RHEL. Jiné distribuce nemusí nutně způsobit tuto chybu. Arch Linux (bez speciálního polkit konfigurace), například stále umožňuje kontejneru změnit název hostitele. Proto bez ohledu na vaši distribuci je stále dobrým bezpečnostním postupem znovu připojit /run .

Je důležité si uvědomit, že výstup lsns může být snazší přečíst pomocí --fork při vytváření jmenných prostorů.

Takto to vypadá bez --fork příznak:

[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

A s --fork příznak:

[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

Zatímco --fork není v tomto scénáři nezbytně nutný, může být užitečný nebo dokonce vyžadován, pokud je vyžadován nový jmenný prostor PID (další informace viz můj článek o jmenném prostoru PID).

Koneckonců

Jmenný prostor UTS není nejsložitějším jmenným prostorem Linuxu. Je to však docela užitečné, zejména v kontextu kontejnerů.

Chcete-li co nejlépe využít jmenný prostor UTS, zkombinujte jej minimálně s jmenným prostorem mount, když používáte kořenový jmenný prostor a jmenný prostor mount a user při vytváření od neprivilegovaného uživatele.

[ Stáhněte si přechodný cheat pro Linux, abyste měli klíčové příkazy na dosah ruky. ]

V mém příštím článku se budu zabývat čistým jmenným prostorem a tím, jak jej použít k tomu, aby jmenné prostory měly vlastní IP a prostor portů.