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 14:00 | Nová verze

Komunita kolem Linuxu From Scratch (LFS) vydala Linux Linux From Scratch 8.0 a Linux From Scratch 8.0 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází především s Glibc 2.25 a GCC 6.3.0. Současně bylo oznámeno vydání verze 8.0 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.

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

Byla vydána verze 0.10.0 webového prohlížeče qutebrowser (Wikipedie). Přehled novinek v příspěvku na blogu. Vývojáři qutebrowseru kladou důraz na ovladatelnost pomocí klávesnice a minimální GUI. Inspirovali se prohlížečem dwb a rozšířeními pro Firefox Vimperator a Pentadactyl. Prohlížeč qutebrowser je naprogramován v Pythonu a využívá PyQt5. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU GPL 3.

Ladislav Hagara | Komentářů: 4
včera 16:22 | Nová verze

Po pěti měsících od vydání Waylandu a Westonu 1.12.0 oznámil Bryce Harrington (Samsung) vydání Waylandu 1.13.0 a Westonu 2.0.0.

Ladislav Hagara | Komentářů: 0
24.2. 13:37 | Bezpečnostní upozornění

Společnost Cloudflare (Wikipedie) na svém blogu potvrdila bezpečnostní problém s její službou. V požadovaných odpovědích od reverzní proxy byla odesílána také data z neinicializované paměti. Útočník tak mohl získat cookies, autentizační tokeny, data posílaná přes HTTP POST a další citlivé informace. Jednalo se o chybu v parsování HTML. Zneužitelná byla od 22. září 2016 do 18. února 2017. Seznam webů, kterých se bezpečnostní problém potenciálně týká na GitHubu.

Ladislav Hagara | Komentářů: 1
24.2. 08:22 | Nová verze

Byla vydána první beta verze Ubuntu 17.04 s kódovým názvem Zesty Zapus. Ke stažení jsou obrazy Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio a Xubuntu. Dle plánu by Ubuntu 17.04 mělo vyjít 13. dubna 2017.

Ladislav Hagara | Komentářů: 46
23.2. 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 37
23.2. 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 12
23.2. 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
23.2. 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 8
22.2. 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 8
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 712 hlasů
 Komentářů: 66, poslední 22.2. 18:57
    Rozcestník

    Dotaz: propojeni virtualni a realne site

    18.1.2014 18:32 LAGer
    propojeni virtualni a realne site
    Přečteno: 499×
    Ahoj,

    snazim se propojit realnou a virtualni sit. Jedna se o soucast BP, ktera se zabyva aplikaci na simulaci site, ktera ma byt schopna komunikovat do internetu. Zkousel jsem reseni pomoci vde(http://vde.sourceforge.net/), komunikace mezi virtualnimi rozhranimi funguje, nicmene vse se odehrava na fyzickem stroji, nikam dal komunikace neprojde.

    Dalsi reseni, ktere se snazim zprovoznit je pomoci zbridgovani vsech vytvorenych portu. Veskere informace, ktere jsem prozatim o problemu sehnal indikuji, ze by melo vse fungovat podle mych predstav - virtualni rozhrani pro aplikaci a fyzicke rozhrani pc si budou moci bez problemu predavat data. Prozatim se mi vsak vubec nepovedlo nasimulovat ani komunikaci simulatoru s hostitelskym pc.

    Mam za to, ze problem je v tom, ze stav obou virtualnich rozhrani(tap0 a tap1), ktere jsou soucasti bridge je disabled - viz vypisy nize.
    kernel: [22221.120869] ADDRCONF(NETDEV_CHANGE): tap0: link becomes ready
    kernel: [22221.120930] br0: port 2(tap0) entering forwarding state
    kernel: [22221.120940] br0: port 2(tap0) entering forwarding state
    kernel: [22221.123169] br0: port 2(tap0) entering forwarding state
    kernel: [22221.123405] br0: port 2(tap0) entering disabled state
    
    br0
     bridge id		8000.60eb692c7e94
     designated root	8000.60eb692c7e94
     root port		   0			path cost		   0
     max age		  20.00			bridge max age		  20.00
     hello time		   2.00			bridge hello time	   2.00
     forward delay		   0.00			bridge forward delay	   0.00
     ageing time		 300.01
     hello timer		   0.96			tcn timer		   0.00
     topology change timer	   0.00			gc timer		  30.00
     flags			
    
    
    eth0 (1)
     port id		8001			state		     forwarding
     designated root	8000.60eb692c7e94	path cost		   4
     designated bridge	8000.60eb692c7e94	message age timer	   0.00
     designated port	8001			forward delay timer	   0.00
     designated cost	   0			hold timer		   0.00
     flags			
    
    tap0 (2)
     port id		8002			state		       disabled
     designated root	8000.60eb692c7e94	path cost		 100
     designated bridge	8000.60eb692c7e94	message age timer	   0.00
     designated port	8002			forward delay timer	   0.00
     designated cost	   0			hold timer		   0.00
     flags			
    
    tap1 (3)
     port id		8003			state		       disabled
     designated root	8000.60eb692c7e94	path cost		 100
     designated bridge	8000.60eb692c7e94	message age timer	   0.00
     designated port	8003			forward delay timer	   0.00
     designated cost	   0			hold timer		   0.00
     flags			
    
    
    bridge name	bridge id		STP enabled	interfaces
    br0		8000.60eb692c7e94	no		eth0
    							tap0
    							tap1
    
    cely most by mel byt smerovan do internetu pomoci eth0, neni dulezite jake dalsi virtualni rozhrani budou uvnitr, prozatim jde o funkcnost.

    jedina ma domenka prozatim je, ze na konci tap0 a tap1 chybi nejake "pripojene zarizeni", kdyz jsem odpojil kabel od eth0, port eth0 v bridgi se taktez dostal do stavu disabled.

    budu vdecny za jakekoliv rady, ikdyby se melo jednat o programovani nejake c aplikace, ktera by mela simulovat zarizeni na konci.

    Odpovědi

    18.1.2014 19:07 NN
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site
    Co je BP?
    18.1.2014 19:24 LAGer
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site
    BP - Bakalarska prace

    jeste dodam, ze mac adresy jsou takto nastaveny schvalne - eth0 a br0 ma stejnou
    19.1.2014 08:20 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site

    Jestli to správně chápu, mají spolu komunikovat virtuální stroje na různých fyzických strojích, jako by byly na jednom ethernetovém switchi. To znamená, že je potřeba umět tunelovat vrstvu 2 skrz vrstvu 3. To znamená, že se dá použít gretap.

    Otázka je, jestli je opravdu nutné mít pro všechny virtuální stroje jeden virtuální switch a jestli by se komunikace nedala zajistit například běžným IP routingem. Řešení s gretap je výhodné pro případ, že mají fyzické stroje tvořit cloud a tedy podporovat migraci virtuálních strojů za provozu, která zachová konfiguraci sítě a dokonce i TCP spojení, protože migrovaný virtuální stroj je v podstatě stále připojený k témuž ethernetovému switchi. Pokud ale prostředí live migraci nepodporuje nebo nepotřebuje, routing je skoro vždy lepší nápad.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    19.1.2014 12:55 LAGer
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site
    Mam 1 fyzicky stroj a v nem aplikaci, ktera interne simululuje sit(vse je virtualni, ale generovany provoz odpovida realnemu). Pozadavek je takovy, ze provoz nemusi probihat jen v ramci aplikace, ale muze byt smerovan i do internetu. Ikdyz by bylo asi mozne realizovat toto jinym zpusobem, pokouset se o propojeni prave timto zpusobem mi pripada nejschudnejsi(aplikace ma pripravene rozhrani .. ).

    Snad je to takhle jasnejsi.
    19.1.2014 21:47 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site

    Pak může být řešení celkem triviální.

    První (a podle mě lepší možnost) je routování. Virtuální síť bude mít nějaký prefix adres a fyzický stroj musí být v okolní síti (v celé síti, tedy včetně nějakého modemu či přístupového bodu) známý jako router do tohoto prefixu. (Prefix by neměl být podmnožinou adres normálně používaných v domácí síti; měl by se zkrátka lišit, aby bylo jasné, kudy se routuje.)

    Druhá možnost je mít adresy ve virtuální síti se stejným prefixem jako ve zbytku domácí sítě. Pak se musí do bridge, který propojuje všechna virtuální rozhraní, přidat ještě i fyzické rozhraní. Fyzickým strojům na síti se pak virtuální stroje budou jevit jako na lokálním switchi, tj. komunikace s nimi bude založená na 2. vrstvě, ne na 3. vrstvě, narozdíl od routování.

    Třetí možnost je podobná té první, ale v lecčem trochu horší a odpovídá nastavení, které vytvářejí automaticky virtualizační frameworky typu virt-manager + libvirt. Zaprvé většinou podporují jenom IPv4, což je samo o sobě hodně hloupé, ale zadruhé nastavují virtuální podsíť jako NAT. Pak fyzický stroj slouží jako NAT router. To znamená, že virtuální stroje se mohou připojovat do Internetu téměř neomezeně (až na to, že prostě nebudou moct používat protokoly, které nejsou založené na TCP ani UDP), zatímco přímé spojení zvenku (tedy mimo fyzický server) do virtuálních strojů není možné. (Je to zkrátka NAT — co víc k tomu dodat.)

    Klíčové je nezapomenout nastavit některé detaily v sysctl — například nezapomenout povolit routování (packet forwarding), v případě bridge zkusit na něm pro jistotu povolit STP a tak podobně. No a pak je taky třeba přidělovat IP adresy správným rozhraním, tj. například pokud fyzický stroj funguje jako bridge, jeho IP adresy se nastavují na bridge rozhraní, nikoliv na některých „členech“ toho bridge.

    Mimochodem, stačí si přece nainstalovat libvirt a virt-manager. Tam je automaticky nastavená a zprovozněná síť a virtuální stroje se můžou připojovat k Internetu, má-li fyzický stroj správně nastavený přístup a povolený packet forwarding. Taková možnost se pak dá snadno rozšířit drobnou úpravou iptables pravidel tak, aby (například) požadavky do Internetu mimo domácí sít šly přes NAT, zatímco požadavky směrované do domácí sítě a zpátky z domácí sítě by se naprosto normálně routovaly. Stačí jen příslušné příslušné pravidlo typu SNAT trochu tweaknout, aby fungovalo jen pro některé odesilatele a příjemce.

    U všech tří řešení se občas stávají nějaké velmi dobře známé chyby, které je třeba prověřit — zakázaný packet forwarding, špatně nastavené prefixy (takže stroje nevědí, že je třeba routovat, a hledají protějšky na lokálním switchi), špatně nastavený bridge (zakázaný STP a několik mostů v dosahu, IP adresy nastavené na rozhraních v bridgi, ale ne na bridgi samotném), špatně použitý IPv4 NAT (buď v kombinaci s nekompatibilními dalšími pravidly firewallu, která všechno zablokují, nebo se zkrátka NATuje úplně všechno, včetně komunikace, která má směřovat do lokální sítě) a konečně všechny možné typy softwarových firewallů, které vyrobí tak složité nastavení iptables, že se v tom nedá vyznat a půlka sítě pak nefunguje. Posledně jmenovaný problém zpočátku není vůbec poznat, protože pro běžné služby typu web, Jabber nebo SSH se zdá být vše v pořádku.

    Základem asi bude spustit si na fyzickém stroji tcpdump a podívat se, jaké pakety tam chodí a proč se asi ztrácejí. Třeba bude jenom někde špatně nastavený default gateway a tak podobně.

    Když narazím na problémy tohoto typu, ještě rychlejším řešením než experimenty s tcpdump leckdy bývá IPv6 — ten velmi rychle odhalí, zda se jedná o problém s NATem (který u něj zatím naštěstí nikdo a nic implicitně nezapíná) nebo s nesprávně nastavenými délkami prefixů (proti čemuž je IPv6 mnohem odolnější, protože nemá žádnou „broadcast“ adresu a NDP funguje i mezi stroji s různými nastaveními délek prefixů, pokud se prefixy shodují až do konce toho delšího) a tak dále. Pokud ani IPv6 nefunguje, dojde na tcpdump.

    Takže tolik tipy pro diagnostiku. :-)

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    20.1.2014 23:49 LAGer
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site
    Bohuzel asi nerozumim tomu, jak by mi cokoliv z toho mohlo pomoct.

    podarilo se mi bridge dostat do stavu, kdy spolu tap1 a tap0(pouzil jsem dva interfacy dve a propojil je a zaroven je pridal do bridge) v bridgi dokazi komunikovat, ale nejakym zahadnym zpusobem nekdo generuje multicastove pakety, ktere prijimaji obe rozhrani. Diky mnozstvi paketu je naprosto nemozne cokoliv delat, protoze cpu je vytocene na max.

    jeste dodam, ze se jedna o tuto aplikaci http://code.google.com/p/psimulator/, pracuji sice se trochu upravenou verzi, ale zadny zasadni vliv by me upravy mit nemely, pokud by to chtel nekdo ozkouset, tak budu jen rad.
    21.1.2014 00:13 Andrej | skóre: 43 | blog: Republic of Mordor | Zürich
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site

    Maximální zatížení CPU může znamenat, že je tam cyklus, ať už mezi routery, mezi mosty, nebo nějakou záhadnou kombinací obojího. Má bridge zapnutý STP? Jsou interfacy v bridge spojené ještě jinou cestou? Problém se záplavou paketů může nastat při vypnutém STP, pokud existuje cyklus mezi mosty.

    ǑǦŹǓǕǙǞǺǨȞȬḔḦḰḾṊṎṸẄẌỖ
    21.1.2014 08:31 LAGer
    Rozbalit Rozbalit vše Re: propojeni virtualni a realne site
    STP je v ramci meho bridge v pc vyple, na eth0 z realne site chodi. Kdyz jsem ho zkousel zapnout, eth0 je ihned odpojeno od internetu vzhledem k bezpecnostni politice. Dalo by se to nejak filtrovat v ramci pc?

    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.