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

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]=1528… [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/patch… [8] https://vpsadminos.org/os/runlevels/ [9] https://vpsadminos.org/os/pools/#monitoring-import-progress Jakub