abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 12:11 | Zajímavý článek

V Edici CZ.NIC vyšla kniha CyberSecurity věnovaná problematice kybernetické bezpečnosti, a to především jejím základním principům, které by měl respektovat každý, kdo využívá informační a komunikační technologie. Kniha je ke stažení zcela zdarma pod licenci Creative Commons (CC BY-ND 3.0 CZ) (pdf, epub, mobi).

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Nová verze

Byla vydána nová stabilní verze 0.92.4 a první alfa verze verze 1.0 svobodného multiplatformního vektorového grafického editoru Inkscape. Přehled novinek v poznámkách k vydání (0.92.4 a 1.0alpha0). Obě verze jsou k dispozici také jako balíčky ve formátu AppImage. Stačí je stáhnout, nastavit právo ke spuštění a spustit.

Ladislav Hagara | Komentářů: 5
včera 21:22 | Nová verze

Byla vydána verze 1.32 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 0
včera 15:44 | Komunita

V říjnu byla změněna licence u multiplatformní dokumentové databáze MongoDB z GNU AGPLv3 na SSPL (Server Side Public License). Dle právníku se nejedná o svobodnou licenci. Databáze MongoDB tak nebude obsažena ve Fedoře, v Red Hat Enterprise Linuxu ani například v Debianu.

Ladislav Hagara | Komentářů: 15
včera 02:22 | Nová verze

Byla vydána verze 2.0 svobodné aplikace určené pro fotografování a ovládání digitálních fotoaparátů z počítače Entangle. Kódové jméno této nejnovější verze je Sodium.

Ladislav Hagara | Komentářů: 2
včera 01:22 | Nová verze

Byla vydána verze 2.18 svobodného webového prohlížeče pracujícího v grafickém i textovém módu Links (Wikipedie). Přehled novinek v seznamu změn. Links letos slaví 20 let. První veřejná verze 0.80 byla zveřejněna 24. listopadu 1999.

Ladislav Hagara | Komentářů: 4
16.1. 16:55 | Zajímavý článek

Vývojáři postmarketOS (GitLab) hodnotí 600 dnů vývoje tohoto v květnu 2017 představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky [reddit].

Ladislav Hagara | Komentářů: 2
16.1. 15:55 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 284 bezpečnostních chyb. V Oracle Java SE je například opraveno 5 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 30 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace jsou 3 z nich.

Ladislav Hagara | Komentářů: 0
16.1. 15:44 | Komunita

Na YouTube byly zveřejněny komunitní videozáznamy přednášek z konference OpenAlt 2018. Letošní OpenAlt proběhne o víkendu 2. a 3. listopadu opět na FIT VUT v Brně.

Ladislav Hagara | Komentářů: 0
16.1. 10:33 | Komunita

Mozilla.cz informuje (en), že program Firefox Test Pilot se příští týden uzavře. Program sloužil téměř tři roky pro testování nových funkcí pro Firefox. Díky němu dnes máme stránku nového panelu, Screenshots pro vytváření snímků stránek, bezpečné sdílení souborů Send, doplněk pro lepší práci a přihlašování k více účtům nebo připravovaný správce hesel Lockbox. Tyto funkce pokračují dál, ale samotný Firefox Test Pilot bude 22. ledna 2019

… více »
Ladislav Hagara | Komentářů: 0
Používáte USB Type-C?
 (19%)
 (16%)
 (10%)
 (12%)
 (37%)
 (3%)
 (45%)
Celkem 393 hlasů
 Komentářů: 0
Rozcestník

Dotaz: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?

13.2.2018 16:20 xsouku04 | skóre: 7
náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Přečteno: 656×
Léta jsme používali vserver a později openvz. S openvz jsme plně spokojeni, ale jeho jádro začíná být příliš staré. Hledáme tedy něco co by nahradilo openvz s nejmenší námahou. Raději jen kontejnerovou virtualizaci, jsme na to zvyklí a také věřím že pro VoIP je lepší být blíže hardware.

Co se ale tak rozhlížíme tak nic podobně dobrého jako openvz nebo alespoň vserver není k dispozici? Nanašel jsem nic co by se blížilo tomu co umí openvz. Téma čím nahradit openvz nikdo neřeší? Nyní testujeme systemd-nspawn. Proti vserver i openvz se ale zdá konfigurace sítě složitá. Nestačí jen spustit virtuál s ip adresou, ale musíme upravit ručně i routování. Používáme macvlan. Nechceme žádné specialitky, jen na jednom fyzickém stroji chceme více kontejnerů a každý aby měl svoji veřejnou statickou ip adresu. Virtuály se mají vidět navzájem.

Vypadá jako by neexistoval jednoduchý způsob jak nastavit síť. Dokumentace pro nás špatně srozumitelná, jako by dnes už všichni používali docker nebo cloud od amazonu a tyto věci vůbec neřešili.

Je vůbec možné nastavit ip adresy zvenku při startu virtuálu,a by se nenastavovala uvnitř virtuálu? Vždyť je to bezpečnostní riziko. Kdyby se útočník zmocnil kontejneru, může si změnit ip adresu tak aby s něčím kolidovala a vyřadit tak z provozu i další služby.

Zatím to vypadá, že budeme muset šudlat s nastavením systemd konfiguráků, kdy bude nutné přidat skript při spuštění i vypnutí virtuálu aby změní routování. Tu ip adresu asi bude muset číst z nějakého místa, které si sami určíme. Jako kdyby to nikdo před námi neřešil.

Nebo jsme jen něco nepochopili?

Odpovědi

13.2.2018 16:37 DarkKnight | skóre: 26
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
LXC/LXD nevyhovuje? Existuji i navody na migraci OpenVZ kontejneru do LXC.
13.2.2018 17:04 ttt
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Na vpsfree to řeší. Moc tomu nerozumím, třeba odkazy pomohou: https://lists.vpsfree.cz/pipermail/community-list/2017-December/009315.html nebo https://github.com/vpsfreecz/vpsadminos.
Josef Kufner avatar 13.2.2018 17:07 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Výhoda systemd-nspawn je v tom, že pokud je na hostitelském systému i v kontejnerech systemd, nejlépe ve stejné/blízké verzi, je do kontejnerů hezky vidět a je to integrované dohromady. Přináší to trochu pohodlí při správě.
Hello world ! Segmentation fault (core dumped)
13.2.2018 18:15
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Když jsem to zkoušel, tak mi nějaké nastavování IP adresy v systemd-nspawn složité vůbec nepřipadalo. Naopak mi to přišlo úplně triviální. A ty jejich návody jsou, řekl bych, na dost vysoké úrovni.
19.2.2018 19:51 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Děkuji všem za rady. Chvilku mi trvalo, než jsem si vše přečtl. Opravdu to vypadá, že nejbližší a nejpoužívanější náhrada za OpenVZ je lxc.

systemd-nspawn jako by byl jen pro pár systemd nadšenců. On sice funguje relativně jednoduše out of the box, pokud vám nevadí, že ip adresa virtuálu bude za NATem a DHCP, které bude za tím účelem vytvořen a vy si pak můžete přesměrovat porty. Na jiné použití zdá se chybí dokumentace. Pravděpodobně má celý projekt řádově méně uživatelů než lxc. Tedy lxc nabízí lépe prošlapanou cestu navíc podobnější tomu na co jsme z OpenVZ zvyklí. A dokumentace se zdá být dost. Např. o síti: http://containerops.org/2013/11/19/lxc-networking/

Co jsem se díval tam zajímavě vypadá také projekt proxmox. Je to klikátko které umožňuje spravovat virtuály na jednom nebo více fyzických strojích se vším co s tím souvisí. Dříve podporovalo openVZ nyní přešlo na lxc.

U proxmox mne ale zaráží, že s každým novým containerem se vytvoří podivný soubor *.raw, který obsahuje celý virtuál v jediném souboru. Proč je to tak? Na co vytvářet další souborový systém v již existujícím souborovém systému? Tedy úplně zbytečnou abstrakci. Píší o tom zde. https://forum.proxmox.com/threads/proxmox-4-lxc-chroot-instead-of-raw-images.22881/ Co je vedlo k této podivnosti a plýtvání? Mám např. obavy kdo se postará o integritu souborového systému když dojde k výpadku elektřiny? Totiž hrozí, že vnitřní souborový systém bude poškozen jiným způsobem než kdyby běžel přímo na hardware. Jak moc je ale tohle nebezpečí běžné netuším.

Vypadá to, že by to mohl být důvod proč se proxmoxem rozloučit a zůstat jen u lxc + zfs. I když některé jeho postupy a skripty asi budou dobré.
19.2.2018 19:57 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Pokud jde o klikací správu, tak LXC umí spravovat libvirt a jde to naklikat ve virt-manageru.

Sám jsem si do LXC asi před dvěma měsíci přesunul Nextcloud, který mi předtím běžel v KVM, právě kvůli vnitřnímu filesystému a můžu tedy potvrdit, že vnitřek kontejneru lze nakonfigurovat tak, aby byl přímo na hostově filesystému.
Heron avatar 19.2.2018 21:25 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
systemd-nspawn jako by byl jen pro pár systemd nadšenců
Nejsem systemd nadšenec, ale nspawn používám několik let (i s veřejnými adresami) a nevidím problém.
pokud vám nevadí, že ip adresa virtuálu bude za NATem a DHCP
Proč to?
Na jiné použití zdá se chybí dokumentace.
Popis, jak v dané distribuci nastavit síť, snad existuje. Pokud používáte systemd-networkd (což bych pro nspawn kontejner doporučoval), tak máte pěknou dokumentaci přímo od autorů systemd.

Jinak to, že v některých projektech lze IP kontejneru (používám třeba i FreeBSD jaily) nastavit zvenčí, nepovažuji za bůh ví jakou výhodu. Pokud mám fyzický stroj nebo plnou virtualizaci, také nenastavuji IP "zvenčí". Proto nevidím u nspawn problém, naopak, sít nastavuji úplně stejně jako na fyzickém stroji nebo plné virtualizaci. V mém případě tedy pomocí systemd-networkd.
19.2.2018 22:33 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
U nás byl problém v tom, že aby se jednotlivé virtuální servery a hlavní stroj viděli mezi sebou na síti, muselo se změnit routování vždy po spuštění nějakého containaru. Na fyzickém stroji tak přidám routování příkazem "ip route add 192.168.2.136/32 dev macvlan0", který říká že s touto konkrétní ip adresou mám komunikovat přes rozhraní macvlan0, protože běží na stejném stroji a ne přes rozhraní směrem do internetu.

Jinak všechen provoz mezi virtuály navzájem nebo mezi virtuálem a hlavním strojem chodil přes výchozí bránu, protože stroje nevěděli, které ip adresy je třeba posílat lokálně a nikdo se v lokální síti k oné adrese nehlásil. A ne každá výchozí brána tuhle podivnost pochopí a pakety pošle zpět i když, jen se tím prodlužuje ping.

Tedy pokud jsme ručně přidali routovací pravidlo pomocí ip route add, vše fungovalo jak má. Kvůli špatné dokumentaci ale není zřejmé kam dát přidávání a odebrání pravidla tak, aby se přidalo/odebralo vždy po startu či vypnutí containaru. Že by se tohle řešilo také zevnitř virtuálu nějakým systemd způsobem? Nejspíš tedy ano. Pak ale nejspíš nebude problém ze vnitř virtuálu od sítě odpojit celý fyzický stroj a to třeba i omylem. Což není dvakrát moudrá vlastnost pokud jeden z hlavních důvodů proč dělám containery je kvůli bezpečnostnímu oddělení jednotlivých činností. Nebo má každý container vlastní routovací pravidla stejně jako má možnost mít vlastní firewall nastavovaný zevnitř?

Heron avatar 19.2.2018 23:09 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Nevím, zda jsem pochopil, v čem máte problém. Pokud mají mít kontejnery veřejnou ip a hostitel privátní ip (třeba z 192.168.0.0/16), tak tohle jednak může zařídit router (default gateway toho fyzického stroje i kontejnerů), ale já to raději řeším tak, že ten kontejner má více ip, veřejnou a tu privátní.

Z hlediska síťování je to jedno, ale já chci v konfiguraci uvést, že daný kontejner má krom adresy z lokální sítě, také ještě adresu veřejnou (na které je dostupný z internetu). Stačí mu sice jen ta veřejná (router to propustí i do lokální sítě), ale já rád explicitní konfiguraci.
macvlan0
Proč macvlan? Já používám veth (--network-veth, resp. VirtualEthernet=yes) a na hostitelském systému tu příslušnou veth síťovku jen strčím do bridge na příslušnou fyzickou síťovku. To mi umožňuje připojit daný kontejner do dané fyzické sítě, jen přiřazením do konkrétního bridge.

Tj konfig v /etc/systemd/nspawn/stroj.nspawn:
[Exec]
Boot=on

[Network]
VirtualEthernet=yes
Bridge=br0
Tohle je jediné nastavení kontejneru na straně hostitele a v kontejneru je jen nastavení sítě (systemd-nspawn) a je to.
Pak ale nejspíš nebude problém ze vnitř virtuálu od sítě odpojit celý fyzický stroj a to třeba i omylem.
Řekl bych, že podobný, jako z kteréhokoliv jiného stroje na síti. Rozhodně nemusíte kontejnery připojovat na stejnou fyzickou sít, na které máte adresu fyzického stroje. Případně fyzický stroj může mít servisní ip, která bude jiná (z jiného rozsahu), než ip pro komunikaci s kontejnery. Atp.
Nebo má každý container vlastní routovací pravidla stejně jako má možnost mít vlastní firewall nastavovaný zevnitř?
Ano, může mít vlastní routy.
19.2.2018 23:11 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Pokud se nebude používat macvlan a síťovky se strčí do bridge, tak kontejnery na sebe normálně uvidí bez jakéhokoliv nastavování na hostovi nebo někde jinde.
20.2.2018 17:42 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Vypadá to, že jediná špatně dokumentovaná finta je v tom, že je nutné fyzické síťovce adresu kterou měla doposud odejmout a místo toho ji dát té uměle záhadně vytvořeně bridgové, která se ať chcete nebo ne vždy vytvoří s novým bridgem.
Tedy alespoň to píší zde.
Vypadá to na univerzální podivnost linuxových bridgů, která se týká veškeré virtualizace co používá bridge. Stále mne nešlo totiž do hlavy proč bridge potřebuje mít ip adresu (i když někdo občas tvrdí, že ji nemá, nebo samé nuly a stejně mu to funguje). Bridge = switch na druhé vrstvě. Ten by mít ip adresu neměl. A přesto zdá se musí, aby to fungovalo. Zítra to otestujeme.
20.2.2018 17:45 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Bridge nemusí mít IP adresu, ale musí být up, to je možná to, co se s tím zaměňuje.
20.2.2018 17:47 Vantomas | skóre: 28 | Praha
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
A jinak ano, interfacy, které jsou v bridge na hostovi, nesmí mít žádnou IP adresu. Pokud nějakou IP adresu mají mít, tak se ta adresa musí nastavit na bridge.
20.2.2018 18:01 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Co se záhady se souborovým systémem proxmox, tak je má záhada vysvětlena. Proxmox používá zfs (čehož jsme si nevšimli) a ten řeší vše. S každým virtuálem je vytvořen ZFS volume, který jde vytvářet a měnit díky zfs bez problému kdykoli i během chodu. Tedy RAW image je tam jen jako berlička pro ty co odmítají použít zfs a že je to berlička nedokonalá nikoho moc trápit nemusí, protože naprostá většina jeden na zfs. Proxmox tedy vypadá na velmi dobré řešení, kde se dá vše naklikat ale má to příkazovou řádku. Je to postaveno na debianu a lxc.
21.2.2018 08:18 bukowski | skóre: 9
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Co používáte na správu LXC? Nejlépe webový.
21.2.2018 09:28 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Zatím dvě možnosti na které jsem narazil jsou proxmox - dlouhodobě existující a stabilní projekt s aktivním uživatelským fórem - hodně možností, nebo jak tady někdo zmiňuje výše libvirt s klikacím virt-managerem (nezkoušel jsem).
21.2.2018 17:23 xsouku04 | skóre: 7
Rozbalit Rozbalit vše Re: náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
Děkuji všem za příspěvky s inspirací, všechny problémy už jsou objasněny. Jsou to věci společné pro všechny virtualizace ne jen pro systemd-nspawn.

Pokusím se je shrnout pro sebe i ostatní, co byl náš problém a na čem jsem se "nachytal". Možná bude mít někdo tendenci udělat stejnou/podobnou chybu a tak mu to pomůže.

1) Důvod proč nám nefungoval obyčejný bridge byl ten, že pokud vytvořím bridge a dám do něj nějakou fyzickou síťovku, tato fyzická síťovka nesmí mít nastavenu ip adresu. S každým bridgem mi vznikne pojmenovaná virtuální síťovka na hlavním stroji právě pro tento účel. Tedy ip adresu fyzického stroje nenastavuji na fyzické síťovce (např. se jménem eth0) ale na virtuální síťovce (např. se jménem br0). Tohle jsem nechápal, protože přece bridge=switch vrstva 2 tak jakápak ip adresa? Ale prostě to tak je a je potřeba na to myslet.

2) Macvlan- Macvlan vytváří více virtuálních podsíťovek na jedné fyzické síťovce. Pokud přiřadím i fyzické síťovce ip adresu, tato ip adresa není přímo dostupná z podsíťovek, což je známá vlastnost macvlan. Nejlepší řešení asi bude hlavnímu stroji nekonfigurovat síťovku, ale jen virtuální podsíťovku, která je v režimu bridge (nejedná se o stejný bridge jako výše) dostupná i z virtuálních strojů. Jiné řešení může být přidávat obskurní routovací pravdla se spuštěním každého virtuálu, jak popisuji ve svých příspěvcích. Macvlan moc lidí nepoužívá, protože obyčejný bridge je univerzálnější a asi méně problémový a lépe laditelný, proto pro macvlan není tolik zmínek a návodů na internetu jako u obyčejného bridge. Bridge je zase tak jednoduchý, že o něm není skoro co psát a pokazit, snad kromě vysvětlení k čemu slouží jeho virtuálnímu síťovému rozhraní na které jsem bohužel nenarazil. Údajná výhoda macvlan je vyšší rychlost - menší zatížení procesoru.

Jinak nyní to vypadá, že budeme používat proxmox se zfs a v něm lxc virtualizaci. Na síťování bridge.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.