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 01:00 | Komunita

Měsíc po Slackware slaví 25 let také Debian. Přesně před pětadvaceti lety, 16. srpna 1993, oznámil Ian Murdock vydání "Debian Linux Release".

Ladislav Hagara | Komentářů: 0
včera 06:00 | Nová verze

Byla vydána nová verze 1.26 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 21
včera 03:00 | Nová verze

Po více než 3 měsících vývoje od vydání verze 2.12.0 byla vydána nová verze 3.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 169 vývojářů. Provedeno bylo více než 2 300 commitů. Přehled úprav a nových vlastností v seznamu změn. Proč verze 3.0.0 a ne 2.13.0? Není to kvůli triskaidekafobii. QEMU letos v březnu slavilo 15 let od oznámení verze 0.1 a to je dle vývojářů dobrý důvod pro novou major verzi. Vývojáři mají v plánu zvyšovat major verzi jednou ročně, vždy s prvním vydáním v daném roce.

Ladislav Hagara | Komentářů: 3
14.8. 22:11 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00161) další bezpečnostní problém ve svých procesorech. Problém byl pojmenován L1 Terminal Fault aneb L1TF. Popis problému přímo od Intelu na YouTube. Jedná se o CVE-2018-3615 (SGX), CVE-2018-3620 (OS/SMM) a CVE-2018-3646 (VMM). Další informace na stránce Foreshadow nebo přímo v dnešním commitu do Linuxu.

Ladislav Hagara | Komentářů: 15
14.8. 12:33 | IT novinky

Po více než 4 letech bylo vydáno RFC 8446 popisující verzi 1.3 protokolu TLS (Transport Layer Security). Popis novinek i historie TLS například v příspěvku na blogu Cloudflare.

Ladislav Hagara | Komentářů: 0
14.8. 11:11 | Zajímavý software

V roce 1998 uvedla společnost Tiger Electronics na trh elektronickou hračku, malého chlupatého tvora s velkýma ušima, Furby. Furby patřil k nejžádanějším hračkám. Během tří let se jich prodalo více než 40 milionů. Furby již tenkrát reagoval na světlo, zvuk, polohu, doteky a přítomnost dalších Furby. Sám mluvil a pohyboval se. Firmware uvnitř simuloval postupný vývoj a učení. Zdrojový kód tohoto firmwaru byl zveřejněn na Internet Archive [Hacker News].

Ladislav Hagara | Komentářů: 20
14.8. 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
13.8. 21:00 | Zajímavý projekt

Cílem projektu DXVK bylo vytvořit vrstvu kompatibility mezi Direct3D 11 a Vulkanem a začlenění této vrstvy do Wine. Direct3D 10 nad Vulkanem bylo možné řešit mezikrokem pomocí vrstvy DXUP překládající Direct3D 10 na Direct3D 11. Vývojáři DXVK se rozhodli přímo podporovat Direct3D 10. Podpora byla začleněna do hlavní větve na GitHubu.

Ladislav Hagara | Komentářů: 4
13.8. 16:00 | Nová verze

Vyšla verze 3.10 přehrávače Audacious. Přináší oprav chyb a drobná vylepšení seznamů skladeb, vyhledávání či ikonek. Zároveň pokračují práce na novém uživatelském rozhraní využívajícím Qt namísto GTK+ – nejsou však hotovy, proto je vydání 3.10 pojmenováno „Not Quite There Yet“; až bude proces u konce, vyjde Audacious 4.

Fluttershy, yay! | Komentářů: 12
13.8. 02:00 | Nová verze

Linus Torvalds vydal Linux 4.18. Více o vývojovém cyklu v Jaderných novinách: začleňovací okno [1] a [2], statistiky. Finální přehled změn je k mání na webu Linux Kernel Newbies.

Fluttershy, yay! | Komentářů: 5
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (7%)
 (4%)
 (12%)
 (77%)
Celkem 181 hlasů
 Komentářů: 9, poslední 14.8. 21:03
    Rozcestník

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

    13.2. 16:20 xsouku04 | skóre: 6
    náhrada za openvz - kontejnerová virtualizace - systemd-nspawn?
    Přečteno: 620×
    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. 16:37 DarkKnight | skóre: 25
    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. 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. 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. 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. 19:51 xsouku04 | skóre: 6
    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. 19:57 Vantomas | skóre: 27 | 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. 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. 22:33 xsouku04 | skóre: 6
    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. 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. 23:11 Vantomas | skóre: 27 | 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. 17:42 xsouku04 | skóre: 6
    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. 17:45 Vantomas | skóre: 27 | 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. 17:47 Vantomas | skóre: 27 | 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. 18:01 xsouku04 | skóre: 6
    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. 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. 09:28 xsouku04 | skóre: 6
    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. 17:23 xsouku04 | skóre: 6
    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.