Vserver
A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(→vserver: mégis van saját init a vserverben, csak konfigurálni kell hozzá) |
a (→Mikor nem lehet/érdemes használni?: typo fix) |
||
(egy szerkesztő 5 közbeeső változata nincs mutatva) | |||
1. sor: | 1. sor: | ||
− | == Áttekintés == |
+ | A vserver egy pehelysúlyú oprendszerszintű virtualizációs megoldás, amellyel Linuxon tudunk egymás mellett, egymástól elszigetelve sok virtuális szervert futtatni. |
− | * Izoláció, nem virtualizáció |
+ | == Mit tud? == |
− | * Pehelysúlyú megoldás |
||
− | ** Egy virtuális gépben futó apache pontosan ugyanannyi erőforrást igényel, mintha a hosztgépen futna |
||
− | ** A vserverek hardlinkek segítségével osztozhatnak a fájlokon (így a második ugyanolyan már szinte ingyen van) |
||
− | *** De: a hardlinkek normális fájlokká válnak, ha a vservert módosítjuk, tehát lehet önállóan upgrade-elni |
||
− | *** Aztán újra összehardlinkelhetjük, ha megint megegyeznek a fájlok |
||
− | *** A hardlinkelés miatt a cache-ben is csak egy példányban lesz benne ugyanaz a libc6, nem annyiszor, ahány vserverünk van |
||
− | * Csak egy kernel fut |
||
− | ** De a virtuális gépek mindegyikében lehet pl. más disztribúció |
||
− | ** Sőt, 64 bites hoszton futtathatunk 32 bites disztribúciót guestként |
||
− | * A hoszt elvileg teljesen el van szigetelve a vserverektől, a feltört vserver nem okoz gondot máshol |
||
− | ** Ráadásul a hoszt segítségével biztonságosan megvizsgálhatjuk, mi változott benne (így pl. honeypotnak is jó) |
||
− | * Könnyű migrálni, mivel egy vserverben semmi gépspecifikus konfiguráció (pl. fstab) nincs |
||
− | == Felhasználási lehetőségek == |
+ | * A vserverben futó program és a natívan futó program sebessége között nincs mérhető eltérés. |
+ | * Lényegében nincs overhead: egy vserverben futó apache pontosan annyi erőforrásba kerül, mintha a hoszton futtatnánk. |
||
+ | ** (A hoszton is betöltött shared libraryk memóriafoglalását leszámítva.) |
||
+ | * A vserverek nem látják más vserverek ill. a hosztgép |
||
+ | ** fájlrendszerét, |
||
+ | ** processzeit, |
||
+ | ** SysV IPC objektumait, |
||
+ | ** hálózati csomagjait, |
||
+ | ** IP-címeit, |
||
+ | ** hardvereszközeit. |
||
+ | * (De a hoszt routing-bejegyzéseit egyelőre igen.) |
||
+ | * A vserverekben futó folyamatok még rootjoggal sem tudnak |
||
+ | ** fájlrendszert mountolni, |
||
+ | ** hálózati interfészt konfigurálni, |
||
+ | ** tűzfalszabályokat beállítani, |
||
+ | ** device node-ot létrehozni, |
||
+ | ** routingbejegyzéseket módosítani/létrehozni/törölni, |
||
+ | ** fájlrendszert átméretezni (sajnos). |
||
+ | ** Ezeket és más hasonló jogokat viszonylag rugalmasan kioszthatunk bizonyos vservereknek egy capability-rendszer segítségével. |
||
+ | * Ha több vserver / ill. /usr fájlrendszerét ugyanazon a hoszt-fájlrendszeren tartjuk, akkor |
||
+ | ** az azonos tartalmú fájlokat automatikusan össze tudjuk hardlinkelni, így |
||
+ | ** egyrészt kevesebb helyet foglalnak a diszken, de - és ez a fontosabb -, |
||
+ | ** a cache-ben és a memóriában is: 20 db. libc6-példány helyett csak egy lesz a memóriában. |
||
+ | ** Egy vserver továbbra sem írhatja felül egy másik fájljait, mert |
||
+ | ** a kernel ezeket a hardlinkeket a fájlok módosítása esetén eltöri, |
||
+ | ** és abban a vserverben, amelyik írásra nyitotta meg a fájlt, létrejön egy új példány, ami már csak az övé. |
||
+ | ** Bajok ezzel a megoldással: |
||
+ | *** Nem tudja megkülönböztetni a vserveren belüli és a vserveren kívüli hardlinkeket. |
||
+ | *** xfs-en egyelőre nem működik a linkek eltörése; a létrejövő új példány csupa nullát tartalmaz, vagyis |
||
+ | **** vserverek olyan fájlrendszereit, ahol a hardlinkelést érdemes alkalmazni, ne xfs-en tartsuk (hanem pl. jfs-en). |
||
+ | * Csak egy kernel fut, |
||
+ | ** de a virtuális gépek mindegyikében lehet pl. más disztribúció; |
||
+ | ** sőt, 64 bites hoszton futtathatunk 32 bites disztribúciót guestként, ami |
||
+ | *** pl. akkor jön jól, ha 64bites gépet desktopnak is szeretnénk használni (a 64bites desktop egyelőre kicsit szívás). |
||
+ | * A hoszt elvileg teljesen el van szigetelve a vserverektől, a feltört vserver nem okoz gondot máshol, |
||
+ | ** ráadásul a hoszt segítségével biztonságosan megvizsgálhatjuk, mi változott benne (így pl. honeypotnak is jó lehet). |
||
+ | * Könnyű migrálni, mivel egy vserverben semmi gépspecifikus konfiguráció (pl. fstab) nincs; |
||
+ | ** mi magunk is törekedjünk rá, hogy a vserver saját IP-jét ne írjuk bele configfájlokba stb. |
||
− | * Főként a "Gép, Ami Sokmindent Csinál" problémájára megoldás |
+ | == Mikor érdemes használni? == |
− | * De: az egyik vserver rootjelszavát akár meg is mondhatjuk a kollégának |
+ | |
− | * Úgyhogy akár kereskedelmi hosztingra is jó (használják is) |
+ | * Főként a "Gép, Ami Sokmindent Csinál" problémájára megoldás. |
− | ** (Az OpenVZ lehet, hogy erre jobb) |
+ | * Egy funkció - egy vserver. Pl. külön vserverben lehet: |
− | * Rollback - jobb, mint az LVM: |
+ | ** az Internet felé néző, reverse proxyként működő apache, benne SSL támogatással; |
− | *# Éles szervert leállítjuk ("egy pillanatra") |
+ | ** a php-s apache; |
− | *# Klónozzuk (gyorsan megy) |
+ | ** a trac- és svn-szerver (ebben két apache-példány is van); |
− | *# Éles szervert újraindítjuk |
+ | ** a MySQL; |
− | *# Klónt upgrade-eljük |
+ | ** a PostgreSQL; |
− | *# Éles szervert leállítjuk |
+ | ** a Squid; |
− | *# Upgrade-elt klónt elindítjuk |
+ | ** a Samba; |
− | *# Ha kell, csiki-csukizunk |
+ | ** a fájlcserélő; |
− | * Sőt, ha LVM-ünk is van, akkor az éles szervert a klónozáshoz le se kell állítani - egy LVM snapshot lehet a klón. |
+ | ** a DNS-szerver; |
− | ** (Régebbi kernelekkel óvatosan: 2.6.11.9+xfs+lvm snapshot -> adatvesztés) |
+ | ** a Tomcat; |
+ | ** az IRC-szerver; |
||
+ | ** a Jabber-szerver; |
||
+ | ** a céges Nethack-szerver; |
||
+ | ** a backupokért felelős dirvish; |
||
+ | ** az a Debian Sarge, amiben az elvileg sarge-on is működő csomagjainkat fordítjuk és teszteljük; |
||
+ | ** az a Fedora, amiben ...; |
||
+ | ** a Lotus Domino (2.6-os kernellel, 64 bites hoszton futó 32 bites Debian sid vserverben, hogy a support örüljön :). |
||
+ | * Elvileg kereskedelmi hosztingra is jó lehet, mert egy-egy vserver rootjelszavát megadhatjuk ügyfélnek is, de |
||
+ | ** az OpenVZ lehet, hogy erre jobb, amikor épp működik. |
||
* Játék: Ki szeretnénk próbálni a legújabb, rendkívül divatos disztribúciót |
* Játék: Ki szeretnénk próbálni a legújabb, rendkívül divatos disztribúciót |
||
− | * "Dual Seat": egy gép, két egér, két billentyűzet, két X, "két Linux" |
+ | ** (a hozzá adott telepítőt viszont valószínűleg nem fogjuk tudni használni). |
+ | * "Dual Seat": egy gép, két monitor, két egér, két billentyűzet, két X, "két Linux". |
||
+ | * Akár bérelt virtuális gépen belül is, ha el tudjuk érni, hogy vserveres kernelt kapjunk. |
||
− | == Fogalmak == |
+ | == Mikor nem lehet/érdemes használni? == |
− | * "context" |
+ | * Ha ügyfeleknek olyan virtuális gépeket akarunk adni, amikben akár kernelt is cserélhetnek; |
− | ** context0: a hoszt |
+ | * ha több különböző operációs rendszert akarunk futtatni egyszerre; |
− | ** context1: "spectator" context |
+ | * ha a virtuális gépeken belülről saját tűzfalszabályokat akarunk beállítani; |
− | *** <tt>chcontext --xid 1 -- ps axfu</tt> mutatja az összes processzt, a guestekben futókat is; a hoszt kontextusában ezek nem látszanak |
+ | * ha virtuális hálózatot szeretnénk létrehozni; |
− | * "namespace" |
+ | * ha cél a buzzword compliance; |
− | ** Minden vserver automatikusan kap sajátot |
+ | * ha valamilyen alkalmazást (pl. Oracle, Domino, DB2, ...) mindenképpen támogatott platformon kell futtatnunk. |
− | ** Amit az egyikben mountolunk, az a másikban nincs mountolva |
||
− | ** Így pl. a hosztgép /proc/mounts fájlja nincs tele a vserverekben mountolt /proc-példányokkal (kozmetika) |
||
− | *** Egyelőre (2006. december) minden mount, amit a vserverekhez tartozó fstab-ban adunk meg, megkapja a <tt>nodev</tt> opciót, így nem praktikus a vserver root fájlrendszerét is az ő namespace-ében mountolni (pl. nem fog tudni írni a <tt>/dev/null</tt>-ba), de ezt elvileg hamarosan kijavítják |
||
− | ** A biztonságot is javítja: a vserverben a / egy rbind mount lesz ("<tt>mount --rbind /var/lib/vserver/foo /</tt>" jelleggel), így még nehezebb kijönni belőle (bár a barrier is elég) |
||
− | == Telepítés == |
+ | == Fogalmak == |
− | Szakácskönyv itt: [http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6 http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6] - mi csak összefoglaljuk. |
+ | Egy vserver elindításakor különféle "kernel-objektumok" jönnek létre. |
− | * Kernelforrás+patch (http://linux-vserver.org/Downloads - kísérleti patchek itt: http://vserver.13thfloor.at/Experimental/) |
+ | * Mindegyiknek van egy sorszáma, de fontos tudni, hogy igazából nincs közöttük összefüggés annak ellenére, hogy az <tt>util-vserver</tt> egy adott vserverhez mindegyikből az azonos sorszámút rendeli. |
− | ** Van olyan verzió is, amibe integrálták a grsecurity-t |
||
− | ** 2006. december 22-én az ajánlott verzió a [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.1.tar.bz2 2.6.19.1-es kernel] a [http://ftp.linux-vserver.org/pub/kernel/vs2.2/testing/patch-2.6.19.1-vs2.2.0-rc6.diff 2.2.0-rc6-os vserver patch]-csel |
||
− | * Vagy: <tt>apt-get install linux-image-2.6.18-3-vserver-k7</tt> (bár tegnap kijött a 2.6.19, hol késnek? :) |
||
− | ** Van <tt>linux-image-2.6.18-3-xen-vserver-686.deb</tt> is |
||
− | * <tt>apt-get install util-vserver</tt> (Ubuntu feisty és edgy bugos, Debian sidből érdemes) |
||
− | === A kernel beállítása === |
+ | Ezek az "objektumok" a következők: |
− | * <tt>CONFIG_VSERVER_PROC_SECURE</tt> |
+ | # security context |
− | ** Ha beállítjuk, a <tt>/proc</tt> egyes részeit elrejthetjük a vserverek elől |
+ | #* A futó kernel "partíciói"; csak az egy kontextusban futó processzek látják egymást. |
− | * <tt>CONFIG_VSERVER_HARDCPU</tt> |
+ | #* Egy kontextustól el lehet venni capabilityket (mint pl. a mountolás képességét). |
− | ** Ha egy context elhasználja a CPU-tokenjeit, nem kap több CPU-t, amíg össze nem gyűlik neki megint néhány (enélkül az opció nélkül csak a prioritása lesz alacsony) |
+ | #** Az <tt>util-vserver</tt> alapértelmezés szerint is erősen csökkentett capability-halmazzal indítja a vservereket. |
− | * <tt>CONFIG_VSERVER_COWBL</tt> |
+ | #* Két speciális kontextus van, ezek már bootkor létrejönnek: |
− | ** Ha immutable+iunlink egy fájl, akkor felülírható, és felülíráskor másolat jön létre róla, amely már sem immutable, sem iunlink attribútummal nem rendelkezik majd. Ha szeretnénk az azonos tartalmú fájlokat megosztani a vservereink között, kapcsoljuk be. |
+ | #** context0: a hoszt processzei ebben futnak |
− | * <tt>CONFIG_BLK_DEV_VROOT</tt> |
+ | #** context1: "spectator" context, minden PID-t lát |
− | ** Lehetővé teszi a virtuális szerverek számára, hogy saját fájlrendszer-kvótákat használjanak. |
+ | #** <tt>chcontext --xid 1 -- ps axfu</tt> vagy egyszerűen <tt>vps axfu</tt> mutatja az összes processzt, a guestekben futókat is; a hoszt kontextusában ezek nem látszanak |
+ | #* A többi kontextus akkor jön létre, amikor az adott context ID-jű vservert elindítjuk. |
||
+ | # mount/filesystem namespace |
||
+ | #* A mountolt fájlrendszerek listája, kontextusonként külön |
||
+ | #** (igazából ez nem vserver featúra, a vaníliás kernel is tudja; lehetséges házi feladat: <tt>pam_namespace</tt>). |
||
+ | #* Minden kontextus, amikor létrehozzuk, kap egy mount namespace-t; |
||
+ | #** ebben azok a fájlrendszerek szerepelnek, amelyek a hoszton mountolva vannak az adott pillanatban ("örökli" a hoszttól). |
||
+ | #** Ezután újabbakat mountolhatunk alá; ezek a hoszt namespace-ében már nem jelennek meg. |
||
+ | #** Ha a hoszton mountolunk később más fájlrendszereket, azok pedig a guest namespace-ében nem jelennek meg, ami csak akkor baj, ha utólag akarnánk őket a guestben bind mountolni. |
||
+ | #** A guestben futó folyamatok chrootolva vannak a guest gyökérkönyvtárába, |
||
+ | #** így pl. a hosztgép /proc/mounts fájlja nincs tele a vserverekben mountolt /proc-példányokkal (kozmetika) |
||
+ | #** A biztonságot is javítja: a vserverben a / egy rbind mount lesz ("<tt>mount --rbind /var/lib/vserver/foo /</tt>" jelleggel), így még nehezebb kijönni belőle (bár a barrier is elég) |
||
+ | #** Egy vserver indításakor bind mountolhatjuk a hoszt egyes fájlrendszereit, így azokat a guestben is elérjük. |
||
+ | #* Egy futó vserverben a <tt>/proc/mounts</tt> fájlban csak az adott vserver fájlrendszereit látjuk, de ez a namespace és a chroot együttes műve: |
||
+ | #** a kernel kiszűri azokat a fájlrendszereket, amiket nem látunk, mert nem az aktuális root alatt vannak, és |
||
+ | #** átírja a mount-pontokat úgy, hogy az aktuális roothoz legyenek relatívak. |
||
+ | # uts namespace |
||
+ | #* nagyjából a gép nevét tartalmazza (nyilván minden vservert hívhatnak másképp, mint a hosztot) |
||
+ | # ipc namespace |
||
+ | #* SysV IPC-mechanizmusok izolációjára |
||
+ | # network context |
||
+ | #* IP-címek és hálózati interfészek izolációjára |
||
+ | #* Vigyázat: a hoszton 0.0.0.0-ra bindolt szolgáltatások fogják a portot a vserverben indított szolgáltatások elől. |
||
+ | # hamarosan várható: |
||
+ | #* pid namespace (több vserverben is lehet egyszerre 42-es PID-jű processz) |
||
+ | #* network namespace (alighanem routing-bejegyzések izolációja végett) |
||
− | === A /proc kezelése === |
+ | Nézzünk példát filesystem namespace-re! |
− | |||
− | * Információ szivároghat a hosztból a vserverekbe |
||
− | * Megoldás: <tt>CONFIG_VSERVER_PROC_SECURE</tt>+<tt>setattr</tt> |
||
− | * Minden /proc bejegyzéshez van három jelzőbit: admin, watch, hide. |
||
− | ** Ha a hide nincs beállítva, az adott /proc-bejegyzés minden vserverben látszik |
||
− | ** Ha a hide be van állítva, az adott /proc-bejegyzés nem látszik a vserverekben |
||
− | *** Ha az admin be van állítva, akkor a context0-ban azért látszik |
||
− | *** Ha a watch be van állítva, akkor a context1-ben azért látszik |
||
− | *** Ha se az admin, se a watch nincs beállítva, akkor az adott bejegyzést teljesen eltüntettük |
||
− | |||
− | == Konfiguráció == |
||
− | |||
− | A vserverhez kapcsolódó config-fájlok a /etc/vservers könyvtárban laknak. |
||
− | |||
− | === Globális konfiguráció === |
||
− | |||
− | A /etc/vservers/.defaults könyvtárban lehet egy csomó mindent állítani: |
||
<pre> |
<pre> |
||
− | vservers/.defaults# ls -la |
+ | # vserver-stat |
− | total 16 |
+ | CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME |
− | drwxr-xr-x 4 root root 4096 Nov 29 16:57 . |
+ | 17 12 270.8M 57.9M 2h00m17 11m31s22 90d23h03 plonesandbox |
− | drwxr-xr-x 4 root root 4096 Nov 29 16:57 .. |
+ | 21 73 249.1M 54.8M 3h06m30 1h03m55 90d23h03 webfrontend |
− | drwxr-xr-x 3 root root 4096 Nov 29 16:57 apps |
+ | # cat /proc/mounts |
− | lrwxrwxrwx 1 root root 19 Nov 29 16:57 cachebase -> /var/cache/vservers |
+ | rootfs / rootfs rw 0 0 |
− | drwxr-xr-x 2 root root 4096 Nov 28 11:52 files |
+ | /dev/root / xfs rw 0 0 |
− | lrwxrwxrwx 1 root root 21 Nov 29 16:57 run.rev -> /var/run/vservers.rev |
+ | tmpfs /lib/init/rw tmpfs rw,nosuid 0 0 |
− | lrwxrwxrwx 1 root root 17 Nov 29 16:57 vdirbase -> /var/lib/vservers |
+ | proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 |
+ | sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 |
||
+ | tmpfs /dev tmpfs rw 0 0 |
||
+ | tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 |
||
+ | devpts /dev/pts devpts rw,nosuid,noexec 0 0 |
||
+ | /dev/raid5-1/var /var xfs rw,nosuid,nodev 0 0 |
||
+ | /dev/raid5-1/var_log_sv /var/log/sv xfs rw,nosuid,nodev,noexec 0 0 |
||
+ | /dev/raid5-1/tmp /tmp xfs rw,nosuid,nodev 0 0 |
||
+ | /dev/crypt5-1/vservers /var/lib/vservers jfs rw 0 0 |
||
+ | /dev/crypt5-1/shared_tmp /shared/tmp xfs rw,nosuid,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var /shared/var xfs rw,noatime,nosuid,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var_log_sv /shared/var_log_sv xfs rw,noatime,nosuid,nodev,noexec 0 0 |
||
+ | /dev/crypt5-1/shared_webapps /shared/webapps jfs rw,noatime,nosuid,nodev,noexec 0 0 |
||
+ | /dev/crypt5-1/shared_home /shared/home jfs rw,noatime,nosuid,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var_backups /shared/var_backups jfs rw,noatime,nosuid,nodev 0 0 |
||
+ | # ls /vservers/webfrontend/proc |
||
+ | # |
||
</pre> |
</pre> |
||
− | + | Tehát a "webfrontend" vserver /proc könyvtárát a hoszt namespace-éből üresnek látjuk. Nézzük meg a webfrontend vserver namespace-éből: |
|
− | Ebből a <tt>run.rev</tt> csak a 2.4-es kernelekhez kellett. |
||
− | |||
− | A <tt>vdirbase</tt> symlink mondja meg a <tt>vserver</tt> parancsnak, hogy mi a vserverek gyökérkönyvtárai fölötti könyvtár. Nem biztos, hogy elég itt átírni, állítólag a kódba néhány helyen be van drótozva - a fejlesztők szerint talán ez már elmúlt :) |
||
− | |||
− | (To be continued...) |
||
− | |||
− | === Egyes vserverek konfigurációja === |
||
− | |||
− | * /etc/vservers/''vservernév''/apps/init/cmd.start: a vserver "elindításakor" a vserver kontextusában lefuttatandó program. Ez "helyettesíti" az initet. |
||
− | * /etc/vservers/''vservernév''/apps/init/cmd.stop: a vserver leállításakor a vserver kontextusában lefuttatandó program. Ennek kell leállítania a vserverben futó programokat. |
||
− | |||
− | (To be continued...) |
||
− | |||
− | == Segédprogramok == |
||
− | |||
− | * /usr/sbin/lsxid: megmutatja, melyik kontextushoz tartoznak a fájlok |
||
− | * /usr/sbin/chxid: egy kontextus tulajdonába helyezi a fájlokat |
||
− | * /usr/sbin/vps: olyan ps, ami mutatja az összes kontextus összes processzét, és azt is, melyik melyik kontextusban fut |
||
− | * /usr/sbin/showattr: a setattr által beállított attribútumokat mutatja meg (l. később) |
||
− | * /usr/sbin/reducecap: gyermekfolyamatot indít csökkentett capability-készlettel |
||
− | * /usr/sbin/vattribute: capabilityket lehet vele elvenni a vserverektől (?) |
||
− | * és még sok másik, amit sajnos nem volt időm megnézni. :( |
||
− | |||
− | === setattr === |
||
− | |||
− | Speciális fájlrendszer-attribútumokat állít. |
||
− | |||
− | <tt>setattr [-Rx] [--[~](iunlink|admin|watch|hide|barrier|iunlink-but-not-immutable)]* [--] <file></tt> |
||
− | |||
− | * -R: rekurzív |
||
− | * -x: nem lép át másik fs-re |
||
− | * ~ negálja a flaget |
||
− | * flagek: |
||
− | ** iunlink: invertálja az unlink() szemantikáját; ha a file immutable és iunlink, akkor unlinkelhető, ha csak iunlink, akkor nem. Alapértelmezés szerint az immutable flaget is beállítja. |
||
− | *** Azért jó, mert így a több vserver számára megosztott fájlokat az immutable attribútum miatt nem lehet módosítani, de letörölni le lehet, úgyhogy lehet pl. upgrade-elni. |
||
− | ** barrier: chroot-védelem; a chroot feletti directoryra beállítva megakadályozza a chrootból való kiszökést, de csak xid > 0 esetén |
||
− | ** admin, watch, hide: l. a /proc-nál; csak a proc filerendszeren állítható |
||
− | ** iunlink-but-not-immutable: csak az iunlink flaget állítja be, az immutable-t nem. |
||
− | |||
− | === vnamespace === |
||
− | |||
<pre> |
<pre> |
||
− | # váltsunk a myserver namespace-ébe: |
+ | # vnamespace -e 21 ls -l /vservers/webfrontend/proc |
− | vnamespace -e myvserver bash |
+ | total 0 |
− | + | dr-xr-xr-x 5 root root 0 Dec 6 23:29 1 |
|
− | # vagy mountoljunk be ide egy új fájlrendszert (xid=0, mindent látunk): |
+ | dr-xr-xr-x 5 root root 0 Dec 6 23:29 10 |
− | vnamespace -e myvserver mount /dev/somenode /path/to/mount/point |
+ | [...] |
− | + | dr-xr-xr-x 5 root root 0 Dec 6 23:29 992 |
|
− | # vagy umountoljunk valamit: |
+ | dr-xr-xr-x 5 root root 0 Dec 6 23:29 acpi |
− | vnamespace -e myserver umount /path/to/mount/point |
||
− | |||
− | # vagy nézzük meg, mi van ide bemountolva: |
||
− | vnamespace -e myvserver cat /proc/mounts |
||
− | </pre> |
||
− | |||
− | === vserver === |
||
− | |||
− | Ez a "fő" eszköz. |
||
− | |||
− | A következő műveleteket tudja: |
||
− | |||
− | * build, start, stop, enter, status, ... |
||
− | |||
− | * <tt>vserver</tt> szervernév <tt>build -m <method> [options] [cfg-options] [--] [method-args]</tt> |
||
− | ** Csinál egy új vservert; tartalommal is megtölti |
||
− | ** Pár lehetséges method: |
||
− | *** rsync: a megadott helyről (pl. a hosztról) másolja a file-okat |
||
− | *** apt-rpm, yum, rpm: rpm-alapú disztribúciók bootstrapeléséhez |
||
− | *** skeleton: csak minimális fájlrendszert csinál |
||
− | *** debootstrap: Debiant (vagy Ubuntut) csinál |
||
− | |||
− | Pl: |
||
− | |||
− | <pre> |
||
− | # We build a guest named "DebianSid", and use the debootstrap method to set it up. |
||
− | # Everything after the first -- is an argument for the debootstrap method, not for build itself. |
||
− | # So we tell it that we want the sid distribution, and it should use ftp.at.debian.org |
||
− | # as mirror, instead of the default one. |
||
− | # Everything after the second -- is interpreted as an argument to debootstrap itself. |
||
− | # --resolve-deps is required to directly bootstrap testing and unstable those days. |
||
− | |||
− | vserver proba build -m debootstrap -- -d sid -m ftp://ftp.hu.debian.org/debian/ -- --resolve-deps |
||
− | # A --resolve-deps már a debootstrapnek szóló opció |
||
− | </pre> |
||
− | |||
− | Takarítsuk ki, ami nem kell bele: |
||
− | |||
− | <pre> |
||
− | ln -s /var/lib/vservers / |
||
− | cd /vservers/proba/etc/rc0.d |
||
− | rm K20makedev K25hwclock.sh S30urandom S31umountnfs.sh S35networking S36ifupdown S40umountfs S90halt K89klogd |
||
− | |||
− | cd /vservers/proba/etc/rc6.d |
||
− | rm K20makedev K25hwclock.sh S30urandom S31umountnfs.sh S35networking S36ifupdown S40umountfs S90reboot K89klogd |
||
− | |||
− | cd /vservers/proba/etc/rcS.d |
||
− | rm S05keymap.sh S48console-screen.sh S50hwclock.sh S40networking S45mountnfs.sh S10checkroot.sh S02mountvirtfs |
||
− | rm S30procps.sh S35mountall.sh S36mountvirtfs S39ifupdown S30checkfs.sh S18ifupdown-clean S18hwclockfirst.sh |
||
− | |||
− | cd /vservers/proba/etc/rc2.d |
||
− | rm S20makedev S11klogd |
||
− | |||
− | # esetleg chroottal: |
||
− | chroot /vservers/proba |
||
− | update-rc.d -f klogd remove |
||
[...] |
[...] |
||
− | exit |
+ | -r--r--r-- 1 root root 0 Dec 6 23:29 zoneinfo |
+ | # vnamespace -e 21 cat /vservers/webfrontend/proc/mounts |
||
+ | rootfs / rootfs rw 0 0 |
||
+ | /dev/root / xfs rw 0 0 |
||
+ | proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 |
||
+ | tmpfs /dev tmpfs rw 0 0 |
||
+ | /dev/root /dev/.static/dev xfs rw 0 0 |
||
+ | tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 |
||
+ | devpts /dev/pts devpts rw,nosuid,noexec 0 0 |
||
+ | /dev/raid5-1/var /var xfs rw,nosuid,nodev 0 0 |
||
+ | /dev/crypt5-1/vservers /var/lib/vservers xfs rw 0 0 |
||
+ | /dev/raid5-1/tmp /tmp xfs rw,nosuid,nodev 0 0 |
||
+ | none /var/lib/vservers/webfrontend/proc proc rw,nodiratime,nodev 0 0 |
||
+ | none /var/lib/vservers/webfrontend/dev/pts devpts rw 0 0 |
||
+ | /dev/crypt5-1/shared_var /var/lib/vservers/webfrontend/var xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_tmp /var/lib/vservers/webfrontend/tmp xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var_log_sv /var/lib/vservers/webfrontend/var/log/sv xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_home /var/lib/vservers/webfrontend/home jfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/vservers / jfs rw,nodev 0 0 |
||
+ | none /proc proc rw,nodiratime,nodev 0 0 |
||
+ | none /dev/pts devpts rw 0 0 |
||
+ | /dev/crypt5-1/shared_var /var xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var_log_sv /var/log/sv xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_tmp /tmp xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_home /home jfs rw,nodev 0 0 |
||
</pre> |
</pre> |
||
− | + | Így még látjuk a hoszt fájlrendszereit is; igazából akár a /proc/mounts-ot is kilistázhattam volna, ugyanez lett volna benne. |
|
− | Ennek a <tt>proba</tt> nevű vservernek nem adtunk hálókártyát; másoljuk le <tt>proba2</tt> néven, és kapjon hálózatot is: |
+ | Most nézzük meg úgy, hogy chrootolunk is: |
− | |||
<pre> |
<pre> |
||
− | # vserver proba2 build -m rsync -n proba2 --interface proba2=eth0:1.2.3.4/32 --hostname proba2 --netdev eth0 --context 3 -- --source /vservers/proba |
+ | # vnamespace -e 21 chroot /vservers/webfrontend cat /proc/mounts |
+ | rootfs / rootfs rw 0 0 |
||
+ | /dev/crypt5-1/vservers /var/lib/vservers xfs rw 0 0 |
||
+ | none /proc proc rw,nodiratime,nodev 0 0 |
||
+ | none /dev/pts devpts rw 0 0 |
||
+ | /dev/crypt5-1/shared_var /var xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_tmp /tmp xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_var_log_sv /var/log/sv xfs rw,nodev 0 0 |
||
+ | /dev/crypt5-1/shared_home /home jfs rw,nodev 0 0 |
||
</pre> |
</pre> |
||
− | + | Ez még mindig nem teljes kép; nézzük meg, mi tartozik ehhez a guest fstab fájljában! |
|
− | Indítsuk el: |
||
− | |||
<pre> |
<pre> |
||
− | # vserver proba2 start |
+ | # cat /etc/vservers/webfrontend/fstab |
+ | none /proc proc defaults 0 0 |
||
+ | none /dev/pts devpts gid=5,mode=620 0 0 |
||
+ | /shared/var/webfrontend /var none bind 0 0 |
||
+ | /shared/tmp/webfrontend /tmp none bind 0 0 |
||
+ | /shared/var_log_sv/webfrontend /var/log/sv none bind 0 0 |
||
+ | /shared/home /home none bind 0 0 |
||
</pre> |
</pre> |
||
− | Váltsunk bele: |
+ | == Hogyan érdemes vservert csinálni? == |
− | |||
− | <pre> |
||
− | # vserver proba2 enter |
||
− | </pre> |
||
− | Ekkor mondjuk egy <tt>ps fuxa</tt> csak az adott contextben futó processzeket listázza, és az initnek 1-es PID-je, úgyhogy örülhetünk - amíg rá nem jövünk, hogy a vserverben nem fut saját init, és az 1-es PID, amit látunk, a hosztgép init folyamatáé. |
+ | # Döntsük el, hogyan szeretnénk kezelni a fájlrendszereit. Nagyjából a következő lehetőségeink vannak: |
+ | #* Mindenből legyen neki saját, külön logikai köteten (ez a xenhez szokott rendszergazda reflexe). |
||
+ | #** Előnyök: |
||
+ | #*** teljes szeparáció; |
||
+ | #*** nem kell kvóta ahhoz, hogy az egyik vserver ne használhassa el a másik elől a helyet. |
||
+ | #** Hátrányok: |
||
+ | #*** sok vserver esetén rengeteg logikai kötetünk lesz (nehezen áttekinthető); |
||
+ | #*** nem tudjuk összehardlinkelni a sok azonos /usr-t és /lib-et; |
||
+ | #*** ha a köteteket csak az egyes vserverekben mountoljuk be, körülményes a megnövelésük (readonly mountolt xfs esetén egyelőre nem is lehetséges); |
||
+ | #*** ha a hoszton is, belefulladunk egy <tt>df</tt> kimenetébe. |
||
+ | #* Minden legyen egyben, a <tt>/vservers</tt> alatt (esetleg a hoszt rootjával közös köteten). Ez a desktoplinuxos reflexe. |
||
+ | #** Előnyök, hátrányok értelemszerűek. |
||
+ | #* A <tt>/vservers</tt> legyen közös, de legyen külön /var, /usr, /tmp mindegyiknek. |
||
+ | #** Előnyök, hátrányok értelemszerűek. |
||
+ | #* Legyen a hoszton néhány nagy közös kötet, és mindegyik alatt minden vservernek egy alkönyvtár (ilyen felállás látható fentebb). |
||
+ | #** Persze ilyenkor is lehet egy-egy vservernek olyan fájlrendszere, ami csak az övé... |
||
+ | # Döntsük el, hogyan lesz elérhető a hálózatról! |
||
+ | #* A hosztnak van egy eth0-ja, azon egy darab IP; ezt odaadjuk a vservernek is. |
||
+ | #** Előnye: egyszerű. |
||
+ | #** Hátrányok: |
||
+ | #*** Nincs izoláció: |
||
+ | #**** a vserver is látja a teljes hálózati forgalmat (bár sniffelni nem tud, ha nem adtunk neki olyan capabilityt); |
||
+ | #**** az egyik vserver elhappolhat portot a másik elől; |
||
+ | #**** ha mindegyikbe akarunk tudni ssh-zni, mindegyikben más porton kell futtatnunk az sshd-t. |
||
+ | #*** Ha óvatlanok vagyunk, egy vserver leállításakor leszedhetjük az IP-t az eth0-ról. |
||
+ | #* A hoszt eth0-jára húzatunk fel a vserverek számára új IP-ket. |
||
+ | #** Hátrány: sok globálisan egyedi IP kell hozzá. |
||
+ | #* A hoszton csinálunk egy (vagy egy-egy) dummy interfészt a vservereknek, és NATtal írjuk át a nyilvános IP-re érkező kéréseket úgy, hogy a megfelelő vserver kapja meg. |
||
+ | #** Hátrány: connection tracking és tűzfalkonfiguráció kell hozzá. |
||
− | A vserverben futó szolgáltatásokat alapértelmezés szerint nem a saját initje indítja el, hanem a cmd.startban megadott program, vagy, ha az nincs kitöltve, akkor egy szimulált System V init-szerű bootfolyamat (lényegében <tt>/etc/init.d/rc 2</tt>). Az "InitStyle" beállításával választhatunk más módszert is, ezek egész jól le vannak írva a [http://linux-vserver.org/util-vserver:InitStyles] oldalon. A "plain" InitStyle-lal saját, 1-es PIDdel futó initet kapunk a vserverben a fejlesztők állítása szerint. Én még nem próbáltam, de hamarosan... |
+ | (folyt. köv.) |
== Ajánlott irodalom == |
== Ajánlott irodalom == |
A lap jelenlegi, 2009. július 29., 00:19-kori változata
A vserver egy pehelysúlyú oprendszerszintű virtualizációs megoldás, amellyel Linuxon tudunk egymás mellett, egymástól elszigetelve sok virtuális szervert futtatni.
Tartalomjegyzék |
[szerkesztés] 1 Mit tud?
- A vserverben futó program és a natívan futó program sebessége között nincs mérhető eltérés.
- Lényegében nincs overhead: egy vserverben futó apache pontosan annyi erőforrásba kerül, mintha a hoszton futtatnánk.
- (A hoszton is betöltött shared libraryk memóriafoglalását leszámítva.)
- A vserverek nem látják más vserverek ill. a hosztgép
- fájlrendszerét,
- processzeit,
- SysV IPC objektumait,
- hálózati csomagjait,
- IP-címeit,
- hardvereszközeit.
- (De a hoszt routing-bejegyzéseit egyelőre igen.)
- A vserverekben futó folyamatok még rootjoggal sem tudnak
- fájlrendszert mountolni,
- hálózati interfészt konfigurálni,
- tűzfalszabályokat beállítani,
- device node-ot létrehozni,
- routingbejegyzéseket módosítani/létrehozni/törölni,
- fájlrendszert átméretezni (sajnos).
- Ezeket és más hasonló jogokat viszonylag rugalmasan kioszthatunk bizonyos vservereknek egy capability-rendszer segítségével.
- Ha több vserver / ill. /usr fájlrendszerét ugyanazon a hoszt-fájlrendszeren tartjuk, akkor
- az azonos tartalmú fájlokat automatikusan össze tudjuk hardlinkelni, így
- egyrészt kevesebb helyet foglalnak a diszken, de - és ez a fontosabb -,
- a cache-ben és a memóriában is: 20 db. libc6-példány helyett csak egy lesz a memóriában.
- Egy vserver továbbra sem írhatja felül egy másik fájljait, mert
- a kernel ezeket a hardlinkeket a fájlok módosítása esetén eltöri,
- és abban a vserverben, amelyik írásra nyitotta meg a fájlt, létrejön egy új példány, ami már csak az övé.
- Bajok ezzel a megoldással:
- Nem tudja megkülönböztetni a vserveren belüli és a vserveren kívüli hardlinkeket.
- xfs-en egyelőre nem működik a linkek eltörése; a létrejövő új példány csupa nullát tartalmaz, vagyis
- vserverek olyan fájlrendszereit, ahol a hardlinkelést érdemes alkalmazni, ne xfs-en tartsuk (hanem pl. jfs-en).
- Csak egy kernel fut,
- de a virtuális gépek mindegyikében lehet pl. más disztribúció;
- sőt, 64 bites hoszton futtathatunk 32 bites disztribúciót guestként, ami
- pl. akkor jön jól, ha 64bites gépet desktopnak is szeretnénk használni (a 64bites desktop egyelőre kicsit szívás).
- A hoszt elvileg teljesen el van szigetelve a vserverektől, a feltört vserver nem okoz gondot máshol,
- ráadásul a hoszt segítségével biztonságosan megvizsgálhatjuk, mi változott benne (így pl. honeypotnak is jó lehet).
- Könnyű migrálni, mivel egy vserverben semmi gépspecifikus konfiguráció (pl. fstab) nincs;
- mi magunk is törekedjünk rá, hogy a vserver saját IP-jét ne írjuk bele configfájlokba stb.
[szerkesztés] 2 Mikor érdemes használni?
- Főként a "Gép, Ami Sokmindent Csinál" problémájára megoldás.
- Egy funkció - egy vserver. Pl. külön vserverben lehet:
- az Internet felé néző, reverse proxyként működő apache, benne SSL támogatással;
- a php-s apache;
- a trac- és svn-szerver (ebben két apache-példány is van);
- a MySQL;
- a PostgreSQL;
- a Squid;
- a Samba;
- a fájlcserélő;
- a DNS-szerver;
- a Tomcat;
- az IRC-szerver;
- a Jabber-szerver;
- a céges Nethack-szerver;
- a backupokért felelős dirvish;
- az a Debian Sarge, amiben az elvileg sarge-on is működő csomagjainkat fordítjuk és teszteljük;
- az a Fedora, amiben ...;
- a Lotus Domino (2.6-os kernellel, 64 bites hoszton futó 32 bites Debian sid vserverben, hogy a support örüljön :).
- Elvileg kereskedelmi hosztingra is jó lehet, mert egy-egy vserver rootjelszavát megadhatjuk ügyfélnek is, de
- az OpenVZ lehet, hogy erre jobb, amikor épp működik.
- Játék: Ki szeretnénk próbálni a legújabb, rendkívül divatos disztribúciót
- (a hozzá adott telepítőt viszont valószínűleg nem fogjuk tudni használni).
- "Dual Seat": egy gép, két monitor, két egér, két billentyűzet, két X, "két Linux".
- Akár bérelt virtuális gépen belül is, ha el tudjuk érni, hogy vserveres kernelt kapjunk.
[szerkesztés] 3 Mikor nem lehet/érdemes használni?
- Ha ügyfeleknek olyan virtuális gépeket akarunk adni, amikben akár kernelt is cserélhetnek;
- ha több különböző operációs rendszert akarunk futtatni egyszerre;
- ha a virtuális gépeken belülről saját tűzfalszabályokat akarunk beállítani;
- ha virtuális hálózatot szeretnénk létrehozni;
- ha cél a buzzword compliance;
- ha valamilyen alkalmazást (pl. Oracle, Domino, DB2, ...) mindenképpen támogatott platformon kell futtatnunk.
[szerkesztés] 4 Fogalmak
Egy vserver elindításakor különféle "kernel-objektumok" jönnek létre.
- Mindegyiknek van egy sorszáma, de fontos tudni, hogy igazából nincs közöttük összefüggés annak ellenére, hogy az util-vserver egy adott vserverhez mindegyikből az azonos sorszámút rendeli.
Ezek az "objektumok" a következők:
- security context
- A futó kernel "partíciói"; csak az egy kontextusban futó processzek látják egymást.
- Egy kontextustól el lehet venni capabilityket (mint pl. a mountolás képességét).
- Az util-vserver alapértelmezés szerint is erősen csökkentett capability-halmazzal indítja a vservereket.
- Két speciális kontextus van, ezek már bootkor létrejönnek:
- context0: a hoszt processzei ebben futnak
- context1: "spectator" context, minden PID-t lát
- chcontext --xid 1 -- ps axfu vagy egyszerűen vps axfu mutatja az összes processzt, a guestekben futókat is; a hoszt kontextusában ezek nem látszanak
- A többi kontextus akkor jön létre, amikor az adott context ID-jű vservert elindítjuk.
- mount/filesystem namespace
- A mountolt fájlrendszerek listája, kontextusonként külön
- (igazából ez nem vserver featúra, a vaníliás kernel is tudja; lehetséges házi feladat: pam_namespace).
- Minden kontextus, amikor létrehozzuk, kap egy mount namespace-t;
- ebben azok a fájlrendszerek szerepelnek, amelyek a hoszton mountolva vannak az adott pillanatban ("örökli" a hoszttól).
- Ezután újabbakat mountolhatunk alá; ezek a hoszt namespace-ében már nem jelennek meg.
- Ha a hoszton mountolunk később más fájlrendszereket, azok pedig a guest namespace-ében nem jelennek meg, ami csak akkor baj, ha utólag akarnánk őket a guestben bind mountolni.
- A guestben futó folyamatok chrootolva vannak a guest gyökérkönyvtárába,
- így pl. a hosztgép /proc/mounts fájlja nincs tele a vserverekben mountolt /proc-példányokkal (kozmetika)
- A biztonságot is javítja: a vserverben a / egy rbind mount lesz ("mount --rbind /var/lib/vserver/foo /" jelleggel), így még nehezebb kijönni belőle (bár a barrier is elég)
- Egy vserver indításakor bind mountolhatjuk a hoszt egyes fájlrendszereit, így azokat a guestben is elérjük.
- Egy futó vserverben a /proc/mounts fájlban csak az adott vserver fájlrendszereit látjuk, de ez a namespace és a chroot együttes műve:
- a kernel kiszűri azokat a fájlrendszereket, amiket nem látunk, mert nem az aktuális root alatt vannak, és
- átírja a mount-pontokat úgy, hogy az aktuális roothoz legyenek relatívak.
- A mountolt fájlrendszerek listája, kontextusonként külön
- uts namespace
- nagyjából a gép nevét tartalmazza (nyilván minden vservert hívhatnak másképp, mint a hosztot)
- ipc namespace
- SysV IPC-mechanizmusok izolációjára
- network context
- IP-címek és hálózati interfészek izolációjára
- Vigyázat: a hoszton 0.0.0.0-ra bindolt szolgáltatások fogják a portot a vserverben indított szolgáltatások elől.
- hamarosan várható:
- pid namespace (több vserverben is lehet egyszerre 42-es PID-jű processz)
- network namespace (alighanem routing-bejegyzések izolációja végett)
Nézzünk példát filesystem namespace-re!
# vserver-stat CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 17 12 270.8M 57.9M 2h00m17 11m31s22 90d23h03 plonesandbox 21 73 249.1M 54.8M 3h06m30 1h03m55 90d23h03 webfrontend # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / xfs rw 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid 0 0 proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 tmpfs /dev tmpfs rw 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/raid5-1/var /var xfs rw,nosuid,nodev 0 0 /dev/raid5-1/var_log_sv /var/log/sv xfs rw,nosuid,nodev,noexec 0 0 /dev/raid5-1/tmp /tmp xfs rw,nosuid,nodev 0 0 /dev/crypt5-1/vservers /var/lib/vservers jfs rw 0 0 /dev/crypt5-1/shared_tmp /shared/tmp xfs rw,nosuid,nodev 0 0 /dev/crypt5-1/shared_var /shared/var xfs rw,noatime,nosuid,nodev 0 0 /dev/crypt5-1/shared_var_log_sv /shared/var_log_sv xfs rw,noatime,nosuid,nodev,noexec 0 0 /dev/crypt5-1/shared_webapps /shared/webapps jfs rw,noatime,nosuid,nodev,noexec 0 0 /dev/crypt5-1/shared_home /shared/home jfs rw,noatime,nosuid,nodev 0 0 /dev/crypt5-1/shared_var_backups /shared/var_backups jfs rw,noatime,nosuid,nodev 0 0 # ls /vservers/webfrontend/proc #
Tehát a "webfrontend" vserver /proc könyvtárát a hoszt namespace-éből üresnek látjuk. Nézzük meg a webfrontend vserver namespace-éből:
# vnamespace -e 21 ls -l /vservers/webfrontend/proc total 0 dr-xr-xr-x 5 root root 0 Dec 6 23:29 1 dr-xr-xr-x 5 root root 0 Dec 6 23:29 10 [...] dr-xr-xr-x 5 root root 0 Dec 6 23:29 992 dr-xr-xr-x 5 root root 0 Dec 6 23:29 acpi [...] -r--r--r-- 1 root root 0 Dec 6 23:29 zoneinfo # vnamespace -e 21 cat /vservers/webfrontend/proc/mounts rootfs / rootfs rw 0 0 /dev/root / xfs rw 0 0 proc /proc proc rw,nodiratime,nosuid,nodev,noexec 0 0 tmpfs /dev tmpfs rw 0 0 /dev/root /dev/.static/dev xfs rw 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/raid5-1/var /var xfs rw,nosuid,nodev 0 0 /dev/crypt5-1/vservers /var/lib/vservers xfs rw 0 0 /dev/raid5-1/tmp /tmp xfs rw,nosuid,nodev 0 0 none /var/lib/vservers/webfrontend/proc proc rw,nodiratime,nodev 0 0 none /var/lib/vservers/webfrontend/dev/pts devpts rw 0 0 /dev/crypt5-1/shared_var /var/lib/vservers/webfrontend/var xfs rw,nodev 0 0 /dev/crypt5-1/shared_tmp /var/lib/vservers/webfrontend/tmp xfs rw,nodev 0 0 /dev/crypt5-1/shared_var_log_sv /var/lib/vservers/webfrontend/var/log/sv xfs rw,nodev 0 0 /dev/crypt5-1/shared_home /var/lib/vservers/webfrontend/home jfs rw,nodev 0 0 /dev/crypt5-1/vservers / jfs rw,nodev 0 0 none /proc proc rw,nodiratime,nodev 0 0 none /dev/pts devpts rw 0 0 /dev/crypt5-1/shared_var /var xfs rw,nodev 0 0 /dev/crypt5-1/shared_var_log_sv /var/log/sv xfs rw,nodev 0 0 /dev/crypt5-1/shared_tmp /tmp xfs rw,nodev 0 0 /dev/crypt5-1/shared_home /home jfs rw,nodev 0 0
Így még látjuk a hoszt fájlrendszereit is; igazából akár a /proc/mounts-ot is kilistázhattam volna, ugyanez lett volna benne. Most nézzük meg úgy, hogy chrootolunk is:
# vnamespace -e 21 chroot /vservers/webfrontend cat /proc/mounts rootfs / rootfs rw 0 0 /dev/crypt5-1/vservers /var/lib/vservers xfs rw 0 0 none /proc proc rw,nodiratime,nodev 0 0 none /dev/pts devpts rw 0 0 /dev/crypt5-1/shared_var /var xfs rw,nodev 0 0 /dev/crypt5-1/shared_tmp /tmp xfs rw,nodev 0 0 /dev/crypt5-1/shared_var_log_sv /var/log/sv xfs rw,nodev 0 0 /dev/crypt5-1/shared_home /home jfs rw,nodev 0 0
Ez még mindig nem teljes kép; nézzük meg, mi tartozik ehhez a guest fstab fájljában!
# cat /etc/vservers/webfrontend/fstab none /proc proc defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 /shared/var/webfrontend /var none bind 0 0 /shared/tmp/webfrontend /tmp none bind 0 0 /shared/var_log_sv/webfrontend /var/log/sv none bind 0 0 /shared/home /home none bind 0 0
[szerkesztés] 5 Hogyan érdemes vservert csinálni?
- Döntsük el, hogyan szeretnénk kezelni a fájlrendszereit. Nagyjából a következő lehetőségeink vannak:
- Mindenből legyen neki saját, külön logikai köteten (ez a xenhez szokott rendszergazda reflexe).
- Előnyök:
- teljes szeparáció;
- nem kell kvóta ahhoz, hogy az egyik vserver ne használhassa el a másik elől a helyet.
- Hátrányok:
- sok vserver esetén rengeteg logikai kötetünk lesz (nehezen áttekinthető);
- nem tudjuk összehardlinkelni a sok azonos /usr-t és /lib-et;
- ha a köteteket csak az egyes vserverekben mountoljuk be, körülményes a megnövelésük (readonly mountolt xfs esetén egyelőre nem is lehetséges);
- ha a hoszton is, belefulladunk egy df kimenetébe.
- Előnyök:
- Minden legyen egyben, a /vservers alatt (esetleg a hoszt rootjával közös köteten). Ez a desktoplinuxos reflexe.
- Előnyök, hátrányok értelemszerűek.
- A /vservers legyen közös, de legyen külön /var, /usr, /tmp mindegyiknek.
- Előnyök, hátrányok értelemszerűek.
- Legyen a hoszton néhány nagy közös kötet, és mindegyik alatt minden vservernek egy alkönyvtár (ilyen felállás látható fentebb).
- Persze ilyenkor is lehet egy-egy vservernek olyan fájlrendszere, ami csak az övé...
- Mindenből legyen neki saját, külön logikai köteten (ez a xenhez szokott rendszergazda reflexe).
- Döntsük el, hogyan lesz elérhető a hálózatról!
- A hosztnak van egy eth0-ja, azon egy darab IP; ezt odaadjuk a vservernek is.
- Előnye: egyszerű.
- Hátrányok:
- Nincs izoláció:
- a vserver is látja a teljes hálózati forgalmat (bár sniffelni nem tud, ha nem adtunk neki olyan capabilityt);
- az egyik vserver elhappolhat portot a másik elől;
- ha mindegyikbe akarunk tudni ssh-zni, mindegyikben más porton kell futtatnunk az sshd-t.
- Ha óvatlanok vagyunk, egy vserver leállításakor leszedhetjük az IP-t az eth0-ról.
- Nincs izoláció:
- A hoszt eth0-jára húzatunk fel a vserverek számára új IP-ket.
- Hátrány: sok globálisan egyedi IP kell hozzá.
- A hoszton csinálunk egy (vagy egy-egy) dummy interfészt a vservereknek, és NATtal írjuk át a nyilvános IP-re érkező kéréseket úgy, hogy a megfelelő vserver kapja meg.
- Hátrány: connection tracking és tűzfalkonfiguráció kell hozzá.
- A hosztnak van egy eth0-ja, azon egy darab IP; ezt odaadjuk a vservernek is.
(folyt. köv.)
[szerkesztés] 6 Ajánlott irodalom
- Secure chroot Barrier: A barrier flag leírása és néhány chroot-elkerülő módszer bemutatása
- Namespaces: leírás a namespace-rendszerről
- Virtualizing for Fun & Profit: Kicsit régi szakácskönyv egy meglevő gép vserveresítéséhez
- http://people.linux-vserver.org/~dhozac/p/uv/experimental/configuration.html: A /etc/vservers könyvtár (nem túl bőbeszédű) leírása