Fórum Root.cz
Hlavní témata => Server => Téma založeno: a1 02. 07. 2014, 10:02:54
-
Existuje nejaký spôsob ako free/opensource virtualizácie na Ubuntu 14.04 Server pre dalšiu/dalšie inštalácie Ubuntu 14.04 Server (prípadne iné distro). Ide mi o to vytvoriť na hlavnom systéme sandboxy (kde by bežal napríklad webserver, FTP server, Samba a podobne), pre prípad, že sa nejaké nastavenie rozhádže aby to nezasiahlo hlavnú inštaláciu.
Ideálne pokiaľ by virtualizácia tvorila jeden súbor ako je v prípade VMWare a ten by sa zálohoval v nejakých intervaloch aby sa dali obnoviť aj sandboxy.
-
ahoj,
skus http://wiki.ubuntu.cz/virtualizace/virtualbox
-
Kvm. V Ubuntu to jsou balíčky jako qemu, qemu-kvm, qemu-system, virt-manager (stačí začít instalovat tyhle a "dotáhnou" se zbylé potřebné.) Akorát ne úplně triviální bude nastavení sítě, protože bude zřejmě potřeba síťovky guestů připojit bridgovaně. Xen v případě starého procesoru (musel by být starší než cca 6 let). VirtualBox je taky dobrá volba, je potřeba zajistit automatické spuštění po startu.
-
Už na konci instalace se Ubuntu server ptá "Choose software to install:". Vyberu "OpenSSH server" a "Virtual Machine host" a je to. Na nastavení sítě atd. používám Zentyal, který instaluji do Ubuntu (pouze s minimem modulů, a jen s webovým rozhraním).
Pro dodatečnou instalaci v Ubuntu server je možné místo vybírání jednotlivých balíků použít tasksel a vybrat ten "Virtual Machine host".
-
Tak dnes je trend docker http://docs.docker.com/installation/ubuntulinux/. Mně tedy moc k srdci nepřirostl, i hostitel se musí zálohovat, takže nemám problém zazálohovat konfigy jednotlivých služeb v /etc a provozovat to na jednom stroji. Ale samozřejmě virtualizace (např. dockerem v případě jednotlivých aplikací) má svůj význam...
-
pokud vis, ze nad tim zase pojede ubuntu tak by nemusela byt spatna varianta openvz, což?
-
Pokud jde jen o separaci serveru (sluzeb) ktere jinak bezi na stejnem systemu, pak bych doporucil OS-level virtualizaci (OpenVZ, Linux-Vservers, LXC, atd). Je to mene narocne na pamet, kdyz vsechno bezi na jednom kernelu...
-
Kvm. V Ubuntu to jsou balíčky jako qemu, qemu-kvm, qemu-system, virt-manager (stačí začít instalovat tyhle a "dotáhnou" se zbylé potřebné.) Akorát ne úplně triviální bude nastavení sítě, protože bude zřejmě potřeba síťovky guestů připojit bridgovaně. Xen v případě starého procesoru (musel by být starší než cca 6 let). VirtualBox je taky dobrá volba, je potřeba zajistit automatické spuštění po startu.
Proc Xen pouze v pripade 6+yr stareho CPU ?
-
Proc Xen pouze v pripade 6+yr stareho CPU ?
Xen jako takový samozřejmě funguje pořád, ale na starých CPU nebyla jiná možnost. (Nejde plná virtualizace, což vyžaduje kvm.) A pak ... Linus Torvalds nezařazoval podporu pro Xen do vanilla jádra, tak jsem myslel dnes bezproblémovější běh. (Distribuce si ale jádra doupravují, takže stejně většinou funguje všechno.)
-
Já bych ti také doporučil docker... tady je krátký interaktivní tutoriál jak se to ovládá.. http://www.docker.com/tryit/ podporuje to novej RHEL, pro vývoj ideální. Na co přesně to chceš používat?
-
Docker je asi nejsnadnější možnost, ale doporučoval bych širokým obloukem se vyhnout přehajpovaným článkům, které tvrdí nesmysly a hlavně před nasazením opravdu pochopit, jak to funguje (tj. ne jaké má docker příkazy, ale co přesně ty příkazy dělají - kam co zapisují, co kde spustí, co jak konfigurují) - a potom střízlivě, přízemně a selským rozumem zhodnotit, jestli je to opravdu to, co potřebuješ, a jestli ti nebudou vadit limitace Dockeru (např. jednoznačná orientace na izolaci právě jedné služby, nemožnost změnit podvozek bez rebuildu celého odvozeného řetězce atd.).
Taky je potřeba si uvědomit, že Docker je pluginovatelný, takže např. někde používá AUFS, někde BTRFS, což má taky svoje důsledky žejo... :)
Pro zorientování na začátek bych doporučil https://www.youtube.com/watch?v=zeVUoxjRTMY&index=6&list=PLofm6RaC_O5pdHU4kIuV1dSmW7X5I4OG6 - střídmá přednáška o historii a typech virtualizace. Výborná profylaxe před hajpizací Dockerem ;)
-
Pozor na Docker ako virtualizaciu - ked sa nedavno nasla bezpecnostna chyba umoznujuca pristup mimo Dockeru, tak to bolo niektorymi ludmi komentovane tak, ze Docker nie je riesenie bezpecnosti.
Why is this assumed a problem.
CONTAINERS DO NOT CONTAIN. Root inside the container == Root outside
the container.
This is true in both libvirt-sandbox/libvirt-lxc and docker.
We have a long way to go before we can run anything within a container
without this rule.
User Namespace, SELinux or other MAC are all required to get us near the
point where Container Contain.
People who run services within a container should continue to drop privs
in the services and run them as UID!=0
K uceniu sa Dockeru - skus si spravit par vlastnych dockerfile-ov s nejakymi sietovymi sluzbami (aj ked sa da dockerfile stiahnut) a zistis, co tam asi ako funguje.
-
User Namespace, SELinux or other MAC are all required to get us near the
point where Container Contain.
RH teď na Docker hype taky naskočil a integruje ho s OpenStackem, který měl SELinux AFAIK od začátku. Takže se asi dá očekávat, že se to do Dockeru taky nějak promítne...
-
odporucat docker niekomu, kto nie je schopny si sam zistit taku trivialnu vec, je... (kazdy nech si doplni sam)
-
RH teď na Docker hype taky naskočil a integruje ho s OpenStackem, který měl SELinux AFAIK od začátku. Takže se asi dá očekávat, že se to do Dockeru taky nějak promítne...
Mozno niekedy ano. Ale teraz tu je neocakavana featura, ktora oficialne ani nie je zranitelnostou (nedavaju sa na to CVE) a treba si na to davat pozor. Zvlast ked to na prvy pohlad vyzera, ze to obsah kontaineru izoluje a prirovnava sa to k virtualizacii.
-
odporucat docker niekomu, kto nie je schopny si sam zistit taku trivialnu vec, je... (kazdy nech si doplni sam)
Právěže Docker je pro lamy ideální. Akorát lama musí vědět že je lama a nemyslet si, že když umí zadat jeden z webu obsaný příkaz, který jí automagicky rozjede na serveru apache, tak že je z ní kdovíjaký sysadmin a ze všech adminů, kteří se tím živí, může mít srandu :)
(tohle myslím bez urážky pro tazatele - všichni jsme nějak začínali a něco nevědět není vůbec žádná ostuda)
Mozno niekedy ano. Ale teraz tu je neocakavana featura, ktora oficialne ani nie je zranitelnostou (nedavaju sa na to CVE) a treba si na to davat pozor. Zvlast ked to na prvy pohlad vyzera, ze to obsah kontaineru izoluje a prirovnava sa to k virtualizacii.
Tady nevím, jestli to píšeš úplně dobře - ve virtualizaci na Linuxu se úplně detailně nevyznám, takže možná dám špatný příklad: pokud se v LXC najde chyba, která umožní rootovi uniknout z kontejneru (tak, jako se to dá za nějakých okolností z chrootu), tak to samozřejmě je bezpečnostní chyba a určitě to je důvod vydat CVE. Zároveň ale každý, kdo jakoukoli OS-level virtualizaci používá, musí vědět, že principielně tohle riziko prostě vždycky hrozí - narozdíl od plné virtualizace, kde tímhle způsobem není z principu možné tohle udělat.
Nic nového pod sluncem, každý software prostě obsahuje chyby a operační systémy, které měly kontejnery když ještě Linux vypadal takhle (http://www.tuxradar.com/files/LXF1.roundup.definite-1.png)
;) tohle samozřejmě taky řešily - např. http://www.freebsd.org/security/advisories/FreeBSD-SA-04:03.jail.asc
MAC na tom nic principielně nemění, v něm taky může být chyba, jenom přidává další level ochrany - pásek a kšandy...
-
pokud se v LXC najde chyba, která umožní rootovi uniknout z kontejneru (tak, jako se to dá za nějakých okolností z chrootu), tak to samozřejmě je bezpečnostní chyba a určitě to je důvod vydat CVE. Zároveň ale každý, kdo jakoukoli OS-level virtualizaci používá, musí vědět, že principielně tohle riziko prostě vždycky hrozí - narozdíl od plné virtualizace, kde tímhle způsobem není z principu možné tohle udělat.
Upozornujem na to prave preto, lebo je to ako odporucat chroot na virtualizaciu. Je trochu rozdiel, ci nieco len hrozi (napr hrozi, ze mi na PC vzdalene niekto spusti kod) alebo sa o chybach uz vie a nie su opravene. Kym prve sa mimo mission-critical systemy toleruje (neda sa proti tomu dost dobre bojovat), druhemu sa ludia snazia zo vsetkych sil vyhybat alebo to nejak osetrovat.
Dovod nepriradovania CVE opisoval Daniel Walsh v inom maili:
My point being that any process on a Linux System that has lots of linux capabilities (DAC*, SYS_ADMIN, and many others) can not be contained.
I think it is premature to treat breakouts against Docker Containers with CVE's because of this. If people stop making claims about the security of a docker process with privs being isolated from the host system, we can prevent the flood of CVE's, that are likely to come.
(uz len osetrenie roznych ioctl bude na dlho)
-
Dovod nepriradovania CVE opisoval Daniel Walsh v inom maili:
Aha. Pokud to chapu spravne, doporucuje nevydavat CVEs na veci, o kterych si nekdo mysli, ze by je Docker mel umet, ale neumi a nikdo nikdy netvrdil, ze umi. Tak to je legitimni.
Dobra poznamka, diky za tu informaci. Mne osobne se to netyka, ale kolegy by to mohlo (melo ;) zajimat.
-
Dobra poznamka, diky za tu informaci. Mne osobne se to netyka, ale kolegy by to mohlo (melo ;) zajimat.
Nicmene jeste by to chtelo doplnit o informaci, jak je na tom v tomhle ohledu OpenVZ. Ja Linuxove capabilities vubec neznam, natoz jejich vztah k virtualizaci, takze pro me je to spanelska vesnice :) a nazor nekoho kovanyho by se hodil...
-
odporucat docker niekomu, kto nie je schopny si sam zistit taku trivialnu vec, je... (kazdy nech si doplni sam)
Právěže Docker je pro lamy ideální. Akorát lama musí vědět že je lama a nemyslet si, že když umí zadat jeden z webu obsaný příkaz, který jí automagicky rozjede na serveru apache, tak že je z ní kdovíjaký sysadmin a ze všech adminů, kteří se tím živí, může mít srandu :)
takze si vlastne nepriamo odporujes :)
podla mna pre lamu, ktora chce len virtualizovat (v zmysle nainstalujem hypervizora, nainstalujem guesta a idem), je idealny virtualbox, kde v podstate netraba nic vediet, kdezto by kazdom inom sposobe virtualizacie/kontajnerizacie uz tomu treba hlbsie rozumiet...
-
podla mna pre lamu, ktora chce len virtualizovat (v zmysle nainstalujem hypervizora, nainstalujem guesta a idem), je idealny virtualbox, kde v podstate netraba nic vediet, kdezto by kazdom inom sposobe virtualizacie/kontajnerizacie uz tomu treba hlbsie rozumiet...
Docker je pro lamy lepší v tom smyslu, že jedním příkazem rozjedou konkrétní službu. Toho prostě s VBoxem nedosáhneš, musíš si vzít k ruce minimálně Vagrant.
Samozřejmě čím jednodušší nasazení, tím větší nebezpečí, že se každá lama bude provozovat vlastní wordpress na vlastní VPSce za dvě stovky měsíčně a crackeři budou mít žně.
To jsou dvě strany jedné mince, nijak si to neodporuje - nůž je taky supr nástroj, akorát se s ním můžeš pořezat...
-
Nicmene jeste by to chtelo doplnit o informaci, jak je na tom v tomhle ohledu OpenVZ. Ja Linuxove capabilities vubec neznam, natoz jejich vztah k virtualizaci, takze pro me je to spanelska vesnice :) a nazor nekoho kovanyho by se hodil...
Nie som velmi "kovany", ale zda sa, ze OpenVZ trpi podobnymi chybami (mozno je cast uz zaplatana - neviem). Tam je tvrdenie "containers contain" priznavana featura, tak sa na to CVE prideluju. Napr. nedavne CVE-2014-3519, ktore vyzera ako dosledok oznamenia podobnej chyby v Dockeri, kde nebolo pridelene CVE.
===POZOR! Velmi zjednoduseny opis===
Ku capabilities v kratkosti - ide o rozdrobenie uzivatelskych prav na uroven skupin akcii. Vdaka tomu prakticky neexistuje "plny root", ale existuju len skupiny akcii, ktore moze uzivatel vykonavat. Root ma napriklad bezne capabilitu, ktora mu umoznuje ignorovat prava pri pristupe k suborom. Dobre je, ze mozeme pouzivat len cast capabilit, cim zmensime riziko uspesneho napadnutia systemu. Program moze mat pravo pouzivat raw sockety (napr. ping) bez prav pristupovat k lubovolnym suborom.
S "virtualizaciou" (namespaces) to ma spolocne to, ze praca s nimi, rovnako ako praca s chrootom, su tiez len capability. Konkretne praca a pristup do namespaces casto vyzaduje dost siroku capabilitu CAP_SYS_ADMIN, ktoru vyzaduju aj niektore privilegovane ioctl, praca s driverami atd. Tak je moznost fungovat so CAP_SYS_ADMIN a ludia sa dostanu na neosetrenych miestach z kontainera alebo bez toho a ludom nieco nebude fungovat.
Da sa to riesit tak, ze budeme vsade pri capabilitach kontrolovat aj to, ci dotycny nie je v namespace, z ktoreho by sa nemal dostat von. Uprava celeho kernelu na tento styl ale nie je vec 1 dna.
===/POZOR! Velmi zjednoduseny opis===
-
Jo, tak na téhle úrovni je mi to celkem jasný, spíš jsem myslel, že neumím posoudit, jak moc závažný problém to je, jak moc běžné distribuce na capabilities spoléhají atd. Prostě jestli se jedná o věc, která hrozí být masovně zneužitelná, nebo to spíš může být překvapení pro někoho, kdo si myslí, že na zabezbečení spešl zapracoval a ona to byla marná snaha a spadne do defaultu :) A kromě šířky taky o jakou jde hloubku - pokud se s velkou pravděpodobností* bude jednat o nebezpečí, že si někdo bude moct poslat packet z iface, na který by neměl mít přístup, tak je to zas něco jinýho než když získá roota na hostovi žejo :)
* protože kritičtější části kódu už někdo pečlivě prověřil
-
Prostě jestli se jedná o věc, která hrozí být masovně zneužitelná, nebo to spíš může být překvapení pro někoho, kdo si myslí, že na zabezbečení spešl zapracoval a ona to byla marná snaha a spadne do defaultu :)
Default je este docela dobry, lebo ludia maju pred rootom respekt a nepustia pod nim vsetko. Root v Dockeri a nasledny root mimo Docker uz taky dobry nie je.
A kromě šířky taky o jakou jde hloubku - pokud se s velkou pravděpodobností* bude jednat o nebezpečí, že si někdo bude moct poslat packet z iface, na který by neměl mít přístup, tak je to zas něco jinýho než když získá roota na hostovi žejo :)
* protože kritičtější části kódu už někdo pečlivě prověřil
Spominane CVE bolo z bugu, kde mohol uzivatel zvnutra kontajneru pristupovat k lubovolnym suborom mimo kontajner, co prakticky znamena roota. O viacerych takych CVE neviem, rovnako ako neviem o viacerych hlaseniach pre Docker, z ktorych by tieto bugy mohli vzniknut. Preto tazko povedat, kde su hlavne bugy.
-
Zkus tohle http://www.proxmox.com/cs/ (http://www.proxmox.com/cs/). Používám spoustu let, rychlé, spolehlivé, jednoduché... Prostě nic lepšího neznám!
-
pouzivam virtualbox ke vsi spokejenosti , existuji mozna i lepsi , ale virtualbox mi fakt staci na vse