[vpsFree.cz: community-list] vpsAdminOS: AppArmor pro Docker a snap, FUSE, mknod, runlevely a boot OS

[Jakub Skokan]

Ahoj,

pokud jste na stagingu zkoušeli Docker a při startu kontejnerů jste 
narazili na chyby ala permission denied při nějakém mountu, bylo to 
kvůli AppArmoru. Prošli jsme logy z AppArmoru a povolili několik 
zakázaných mountů, což by vám mělo pomoci. Pokud by stále někomu něco 
nešlo, napište prosím na podporu nebo IRC. Potřebujeme vědět: chybovou 
hlášku, ID VPS a jak to reprodukovat.

Důležitým posunem vpřed je je podpora pro AppArmor namespaces. Každé VPS 
nyní běží ve svém AppArmor namespace, kde si může spravovat vlastní 
profily, ale stále je omezeno nadřazeným profilem z nodu, ze kterého 
nemůže utéct. To nám umožnilo zprovoznit snap [1] a už není potřeba 
upravovat službu pro Docker [2]. Aby všechno fungovalo, bylo potřeba do 
našeho kernelu doplnit patche pro AppArmor, které se zatím nedostaly do 
upstreamu [3]. Návod na instalaci snapu v Ubuntu viz KB:

   https://kb.vpsfree.cz/navody/vps/vpsadminos/snap

snap ve VPS vyžaduje squashfuse, což je možné díky tomu, že jsme 
aktualizovali na Linux 4.18, který podporuje FUSE v user namespace. Tím 
pádem fungují i další souborové systémy využívající FUSE, např. sshfs.

Linux 4.18 přinesl změnu v chování `mknod` v user namespace. Do verze 
4.18 `mknod` v user namespace nebyl povolen, takže se všechny zařízení v 
`/dev` ve VPS musely bind-mountovat z nodu. Linux 4.18 `mknod` v user 
namespace povoluje, ale trochu zvláštně [4]. `mknod` je povolen nad 
souborovými systémy, které patří do user namespace volajícího procesu 
(např. když si mountnete tmpfs), ale pak s těmi zařízeními nejde 
pracovat, a to vůbec. `open()` skončí s "permission denied". Je to 
zpětně nekompatibilní změna, která rozbíjí userspace [5, 6]. Nemohli 
jsme to takto nasadit, protože by přestaly fungovat systemd služby 
využívající `PrivateDevices`. Rozhodli jsme se `mknod` ve VPS povolit 
[7] na libovolném souborovém systému a současně umožnit s takto 
vytvořenými zařízeními pracovat. Můžeme si to dovolit, protože přistup k 
zařízením ve všech VPS hlídá `devices` cgroupa. Teď jsme dosáhli 
stejného chování jako na OpenVZ: vytvořit jde jakékoli zařízení, 
používat lze jen ty, u kterých to node povolí. Takže např. není problém 
ve VPS rozbalit nebo vytvořit libovolný archiv nějakého systému 
obsahující jakékoli zařízení, to do teď nebylo možné.

vpsAdminOS dostal runlevely [8], zatím máme dva: `default` a `single`. V 
`default` naskočí všechny služby a startují VPS, v `single` se spustí 
jen getty pro login. Výchozí runlevel se vybere buď při sestavení OS, 
nebo při bootu v zavaděči. Runlevel `single` bude důležitý zejména při 
řešení problémů a manuálním zásahům na nodech.

No a nakonec jsem pracoval na několika potřebných optimalizacích při 
bootu OS. Na OpenVZ nodech jsou v bootovacím procesu následující 
problémy: při importu ZFS poolů a připojování datasetů se nejde do 
systému přihlásit a neukazuje se žádný postup. VPS se začnou startovat 
až když jsou všechny datasety připojeny, což na velkém a delším dobu 
používaném poolu může trvat 5, 10 nebo i 15 minut. Během této doby 
nemáte tušení, jestli se pool importuje, datasety připojují, nebo jestli 
se to na něčem zaseklo a nic se neděje... Reboot do single user režimu, 
kde si pool importneme svépomocí, pak zbytečně prodlužuje dobu výpadku.

Ve vpsAdminOS to řešíme mnohem lépe. Za prvé, ZFS pooly se importují 
paralelně se spouštěním ostatních služeb a neblokují tak přihlášení do 
systému. Na konzoli se jde přihlásit hned a spustí se i SSH. Postup 
importu a připojování datasetů pak jde sledovat v syslogu [9], takže 
admin má přehled co se děje a jak dlouho to ještě může trvat. Za druhé, 
nepřipojujeme všechny datasety najednou, ale postupně až když jsou 
potřeba pro start VPS. VPS se startují hned po importu poolu a každé pak 
čeká jen na připojení svého vlastního datasetu a ne na datasety všech 
ostatních VPS na nodu. Tyto změny nám mohou ušetřit až desítky minut při 
výpadcích.

[1] https://snapcraft.io

[2] 
https://kb.vpsfree.cz/navody/vps/vpsadminos/docker?do=diff&rev2[0]=1528743860&rev2[1]=1537454266&difftype=sidebyside

[3] https://gitlab.com/apparmor/apparmor/tree/master/kernel-patches

[4] https://patchwork.kernel.org/patch/10422495/

[5] https://patchwork.kernel.org/patch/10509655/

[6] https://github.com/systemd/systemd/pull/9483

[7] 
https://github.com/vpsfreecz/vpsadminos/blob/master/os/packages/linux/patches/010-allow_mknod.patch

[8] https://vpsadminos.org/os/runlevels/

[9] https://vpsadminos.org/os/pools/#monitoring-import-progress

Jakub