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 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 4
včera 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 5
včera 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 0
včera 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 15
včera 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 2
18.10. 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
18.10. 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 2
18.10. 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
18.10. 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (74%)
 (13%)
Celkem 115 hlasů
 Komentářů: 7, poslední včera 23:06
    Rozcestník

    Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6

    1. 8. 2011 | Jirka Bourek | Jaderné noviny | 4280×

    Aktuiální verze jádra: 3.0 ještě nevyšlo. Citáty týdne: Paul McKenney, Thomas Gleixner. Garrett: Bootování s EFI. Návrat realtime stromu. NAT v IPv6. Jak Linusovi zkazit dovolenou. RLIMIT_NPROC and setuid().

    Obsah

    Aktuální verze jádra: 3.0 ještě nevyšlo

    link

    Jádro 3.0 ještě vydáno nebylo, alespoň ne v době psaní tohoto článku. Záludné chyby, první ve VFS (vizte níže), druhá v RCU zpozdily vydání, které je jinak již připraveno: historie naznačuje, že k vydání dojde okamžitě po zveřejnění článku.

    Stabilní aktualizace: během minulého týdne žádné nevyšly a žádné se ani nerevidují.

    Citáty týdne: Paul McKenney, Thomas Gleixner

    link

    Tato sada patchů obsahuje opravy pro průšvih týkající se RCU, plánovače a obsluhy přerušení ve vláknech. Průšvih spočíval v tom, že RCU špatně chránilo jedno ze svých bitových polí, používání RCU plánovačem v místech v irq_exit(), kde in_irq() vracelo false, RCU používalo plánovač tak, že to kolidovalo s plánovačem používajícím RCU, obsluhy přerušení ve vláknech způsobovaly problémy v irq_exit() mnohem častěji a tak dále.

    -- Paul McKenney vysvětluje, proč (ještě) nemůžeme mít hezké 3.0

    Jinak řečeno bavte se a ujistěte se, že budete mít po ruce hasičák, když tohle budete používat!

    -- Thomas Gleixner

    Garrett: Bootování s EFI

    link

    Matthew Garrett zkoumá záludnosti bootování Linuxu s EFI. Výrobci hardwaru se opět krátkozrace zaměřují na Windows. Jak jsme mnohokrát viděli v minulosti, jediná věc, kterou si výrobci hardwaru zkontrolují, je, jestli Windows bootují správně. Což znamená, že vůbec není překvapením, když zjistíte, že některé systémy podle všeho ignorují bootovací proměnné EFI a místo toho prostě hledají záložní zavaděč [fallback bootloader]. Záložní zavaděč nemá jmenné prostory, což garantuje kolize, pokud je na stejném stroji nainstalováno několik operačních systémů [...] Mohlo by to být horší. Pokud tam již zavaděč je, Windows ho nepřepíší, takže věci jsou o něco málo lepší než ve dnech MBR. Zavaděč Windows ale Linux nenabootuje, takže pokud tam jsou Windows první, stále máme problém.

    link

    Ti, kteří sledují sadu patchů pro preempci v reálném čase, ví, že se na nějaký čas zasekla u 2.6.33. S vydáním nového patche založeném na 3.0-rc7 nám Thomas Gleixner řekl proč: celá sada patchů byla přepracována a pročištěna, bylo implementováno nové řešení problému proměnných specifických pro CPU a vydání založené na 2.6.38 pozdržela ošklivá chyba. Ta potvora trvala na tom, že bude ničit souborové systémy. Reprodukovat ji trvalo celé dny a naprosto odmítala odhalit alespoň malinkatý náznak toho, kde je příčina. Koukat několik měsíců do naprosto zbytečných výpisů není příliš zábavná činnost. Verze 3.0-rc7 naštěstí žádné takové chování nevykazuje.

    NAT v IPv6

    link

    napsal Jonathan Corbet, 20. července 2011

    Jedna z hezkých věcí, kterou měl protokol IPv6 zajistit, bylo odstranění potřeby překladu síťových adres (NAT). Adresový prostor je dost velký na to, aby motivace pro použití NATu (nedostatek adres, nutnost přečíslovat sítě při změně poskytovatele) zmizela. NAT se často považuje za hack, který rozbil architekturu Internetu, takže není málo lidí, kteří ho rádi uvidí zmizet. Přechod na IPv6 často vypadal jako příležitost to zajistit.

    Není tedy překvapující, že když Terry Moës zaslal implementaci IPv6 NATu pro Linux, první odpovědi byly méně než příznivé. Každý, kdo chce vidět konec NATu, jenom těžko přivítá implementaci, která může sloužit jenom k jeho prodloužení po přechodu na IPv6. Smutný fakt ale je, že NAT tu podle všeho zůstane. David Miller to vyjádřil typicky přímo:

    Lidé chtějí skrýt detaily topologie svých interních sítí, takže budeme mít NAT v ipv6 bez ohledu na to, co si myslíme nebo chceme.

    Všichni to musí přestat popírat, teď.

    Ať se nám to líbí nebo ne, s NATem se budeme potýkat navždy. Ti, které zajímá, jak by mohl fungovat v Linuxu, mohou najít Terryho implementaci na SourceForge společně s pojednáním o návrhu kódu. Podporován je bezestavový (RFC 6296) i stavový NAT.

    Jak Linusovi zkazit dovolenou

    link

    napsal Jonathan Corbet, 19. července 2011

    Za všecho může Hugh.

    Linus už se chystal vydat finální verzi jádra 3.0, když se objevil Hugh Dickins s malým problémem: čas od času kompletní kopie stromu zdrojových kódu jádra selže, protože jeden ze souborů dočasně zmizí. Následovalo odhodlané cvičení v honu na chyby, které ukazuje, jak citlivý a záludný je základní kód. Problém byl nalezen a zlikvidován, ale mohou být i další.

    K lepšímu porozumění toho, co se zde stalo, by mohlo pomoci nějaké pozadí. Vydání 2.6.38 obsahovalo patche škálovatelnosti dcache; kód používá spoustu triků k tomu, aby při vyhledávání jmen souborů nemusel zabírat zámky. Pro správnou zátěž metoda „procházky RCU“ [RCU walk] poskytuje významné zlepšení výkonu. To ale funguje jenom v případě, že veškeré relevantní struktury se záznamem o adresáři [directory entry, „dentry“] jsou v dentry cache jádra a při vyhledávání nedojde k souběhu s dalšími CPU, které se pokouší stejnou cestu změnit. Když se narazí na takovou situaci, vyhledávání se vrátí ke staršímu a pomalejšímu algoritmu, který vyžaduje zamknutí každé dentry.

    Dentry cache (dcache) je velmi dynamická datová struktura, jednotlivé záznamy nepřetržitě přichází a mizí. Jedno CPU tedy může odstranit dentry ve stejnou chvíli, kdy se ho jiné pokouší použít k vyhledání jména. Chaosu se předchází používáním mechanismu čtení-kopírování-aktualizace [read-copy-update, RCU], který se stará o odstraňování dentry záznamu; záznam je možné odstranit z cache, ale pokud vlákno, které tuto dentry používá, získalo odkaz před jeho odstraněním, struktura samotná bude existovat do doby, dokud ji nějaké vlákno potřebuje. To samé by mělo platit pro strukturu inode spojenou s touto dentry.

    Hugh vysledoval problém v kousku kódu v walk_component():

    err = do_lookup(nd, name, path, &inode);
    /* ... */
    if (!inode) {
            path_to_nameidata(path, nd);
            terminate_walk(nd);
            return -ENOENT;
    }

    Pokud do_lookup() vrátí nulový ukazatel na inode, walk_component() předpokládá, že se narazilo na „negativní dentry“. Negativní dentry se v dentry cache ukládají a ukazují na fakt, že specifické jméno neexistuje; to je významná vlastnost linuxové vrstvy virtuálního souborového systému, která zvyšuje výkonnost. Jestli chcete vidět příklad, spusťte jakkoliv jednoduchý program pod strace a podívejte se, kolik systémových volání vrátí ENOENT; k vyhledávání neexistujících souborů dochází často. Hugh zjistil, že tento ukazatel na inode se občas vrací nulový i v případě, že soubor existuje, což kód vede k domněnce, že se narazilo na negativní dentry; to vedlo k „dočasnému zmizení souboru“.

    Hugh se na tento kód musel dívat dlouho předtím, než došel k závěru, že jádro odstraňuje dentry z dcache ve špatný čas při vyhledávání. Jak bylo popsáno výše, dentry jako taková existuje i po odstranění z cache, ale to neznamená, že se nemůže změnit: odstranění nastaví ukazatel d_inode na NULL. (Stojí za to poznamenat, že toto chování jde proti obvykle praxi používání RCU, která říká, že by se struktura neměla měnit, dokud není jisté, že i poslední odkaz zmizel.) Hugh došel k závěru, že tento nulový ukazatel je později přečten při vyhledávání cesty, takže walk_component() si myslí, že soubor neexistuje, přičemž ve skutečnosti došlo pouze k odstranění dentry z cache. Hlášení o problému obsahovalo patch, který zajistil, že si kód vyhledávání lépe ověřil, že soubor skutečně neexistuje, když se mu vrátilo NULL.

    Linus problém potvrdil, ale oprava se mu nelíbila, protože podle něj byla příliš specifická pro jednu konkrétní situaci. Navrhl alternativu: prostě nenastavit d_inode na NULL; ukazatel na inode by pak takovou hodnotou později nemohl nic zmást. Al Viro zaslal alternativní opravu, která měnila chování dcache méně záludněji, měl obavu ze zavedení dalších divných chyb:

    Za prvé nejsem úplně přesvědčen o tom, že je dobrá optimalizace (pravděpodobně je, ale vážně mě děsí složitost, kterou tu již máme) a opravdu mě nelákají vyhlídky na řešení jakéhokoliv záludného svinstva, na které můžeme přijít s Linusovým patchem. Ještě jednou, dcache v současnosti není v příliš zdravém stavu; v tomto bodě je podle mě hloupé a přímočaré lepší než záludné věci, které by mohly šlápnout na nohu divnému kódu, který tu máme...

    Jakmile uděláme audit kódu, fajn, nemám problém s tím, když se ->d_inode bude zachovávat, dokud se dentry neuvolní. Jakýkoliv kód, který závisí na tom, že ta věc bude vynulována, si koleduje o problémy a měl by být přepsán tak jako tak. Samozřejmě je háček v tom, že než ho přepíšeme, tak ho musíme najít...

    Linusovi se Alova oprava nelíbila; hrozila tím, že zpomalí pomalé vyhledávání, když se bude jednat o negativní dentry. Diskuze o patchích trvala nějakou dobu; jak se snažili najít nejbezpečnější opravu chyby, oba účastníci diskuze pomalu přišli na to, že ve skutečnosti neví, co se děje. Když se na věc Linus podíval zblízka, mávnul rukama a přiznal, že je nechápe:

    Takže jak vůbec může nastat Hughův NULLový inode? I u současných zdrojáků? Když se teď dívám na detaily, všechno podle mě vypadá dobře.

    Jak se stává, Linusova interpretace byla dostatečná k tomu, aby Hugha nasměrovala na skutečný problém. Když je proces procházení specifickou dentry téměř hotov, do_lookup() volá __follow_mount_rcu(), která má proces vyhledávání přesměrovat, pokud se prochází přípojným bodem [mount point]. Ukazatel na inode je __follow_mount_rcu() předán samostatně; Hugh si všiml, že funkce dělá následující:

    *inode = path->dentry->d_inode;

    Jinými slovy se ukazatel na inode znovu načte ze struktury dentry; k tomuto přiřazení dojde bez ohledu na to, jestli dentry reprezentuje přípojný bod. To je skutečným zdrojem problému: jestliže byla dentry odstraněna z dcache poté, co proces vyhledávání získal odkaz, d_inode bude NULL. __follow_mount_rcu() vynuluje ukazatel, který ukazoval na platný inode, takže si následující kód myslí, že soubor vůbec neexistuje.

    Linus zaslal opravu skutečného problému společně s nyní slavným příspěvkem na Google+, ve kterém píše, že pro jistotu zpozdí vydání 3.0 o jeden den.

    Máme patch, chápeme problém a vypadá to JasněSprávně(tm), ale nemyslím si, že chci 3.0 vydat jenom pár hodin po jeho aplikaci.

    Linus vydání zpozdil i přes nepříhodnou skutečnost, že to začleňovací okno 3.1 posune do jeho plánované dovolené. Z jeho strany to nicméně byla opatrnost na správném místě: JasněSprávný(tm) patch měl ZaseDalšíZáludnouChybu(tm). Opravená verze patche již existuje a tato konkrétní chyba by měla v tuto chvíli být historií.

    Z této epizody je nicméně potřeba vzít si ponaučení nutící k zamyšlení. Chování dentry cache je v tomto okamžiku tak citlivé, že i kombinovaná síla mozků vývojářů, jako je Linus, Al a Hugh, jen tak tak stačila na to zjistit, co se dělo. Stejní vývojáři jsou zjevně nervózní ze změn v této části jádra. Naše přístupné a snadno programovatelné jádro postupem času zesložitělo a je stále těžší ho pochopit. Z velké části se tomu nedá vyhnout; prostředí, ve kterém jádro běží, je samo o sobě za posledních 20 let složitější a složitější. Jestliže se ale dostaneme do bodu, kde téměř nikdo nebude schopen pochopit, revidovat nebo opravit nějakou část základního kódu, budeme si zadělávat na dlouhodobé problémy.

    Mezi tím bychom si měli být schopni užít vydání 3.0 (a aktualizaci 2.6.39) bez záhadně mizících souborů. Jeden potenciální krátkodobý problém nicméně zůstává: vzhledem k tomu, že další začleňovací okno se protáhne do Linusovy dovolené, je tu šance, že bude více než obvykle nabručený na správce, kteří zašlou své požadavky na přetažení [pull request] pozdě. Až se začleňovací okno otevře, moudří správci subsystému by měli být připraveni ke startu.

    RLIMIT_NPROC and setuid()

    link

    napsal Jake Edge, 20. července 2011

    Systémové volání setuid() v Linuxu (a dalších Unixových systémech) vždy představovalo bezpečnostní problém. Má podivné interakce s bezpečnostními a dalšími vlastnostmi jádra (např. nešťastně pojmenovaná chyba sendmailu a kvalifikací [capabilities]) a v programech se často používá chybně. Je to ale součásti unixového dědictví a bude s námi pravděpodobně přinejmenším do doby, než chyba roku 2038 ukončí trápení unixových systémů. Nedávný patch od Vasilije Kulikova pravděpodobně ukazuje tyto problémy v akci: podivné interakce omezení zdrojů a špatného používání systémového volání setuid().

    Problém, který se Vasilij pokouší řešit, má poměrně historické pozadí. Roku 2003 se programy používající setuid() k přepnutí na jiného uživatele, než je root, mohly vyhnout limitu na počet procesů, které administrátor pro daného uživatele nastavil (tj. RLIMIT_PROC). To ale opravil patch Neila Browna, který způsobil, že volání setuid() selže, když je nový uživatel nad limitem.

    Bohužel mnoho programů návratovou hodnotu setuid(), které má omezit jejich práva, nekontroluje. To je ve skutečnosti chyba, na kterou narazil sendmail, když byly zavedeny kvalifikace, protože nekontroloval, jestli přepnutí na nové UID opravdu uspělo. Chybné programy, které nekontrolují návratovou hodnotu, mohou způsobit poměrně závažné bezpečnostní problémy, protože předpokládají, že jejich činnost je omezena omezenými privilegii nového uživatele; ve skutečnosti přitom běží se zvýšenými privilegii (často pod rootem), se kterými byly spuštěny. Změna z roku 2003 tedy útočníkům přidala způsob, jak zajistit, aby setuid() selhalo, když se použilo RLIMIT_PROC.

    Vasilij problém popsal v červnu a poznamenal, že to není chyba v Linuxu, ale umožňuje zachybovaným privilegovaným programům napáchat chaos:

    Nemám za to, že kontrola RLIMIT_NPROC v setuid() je chyba (chybějící kontroly návratových hodnot systémových chování jsou skutečnou chybou), ale přilévá to olej do ohně programům, které mají špatně napsané zahození privilegií. Věřím, že situaci by bylo možné zlepšit relativně malými změnami ABI, které by neměly být viditelné pro běžné programy.

    Ve svém příspěvku navrhl dvě možná řešení problému. Prvním je přesunout kontrolu RLIMIT_NPROCset_user() (pomocná funkce setuid()) do execve(), protože většina programů návratovou hodnotu tohoto volání kontroluje (a když ne, nezpůsobí to problémy). Další návrh je ten, který roku 2006 přišel od Alexandera Peslyaka (též znám jako Solar Designer), aby selhání volání setuid() zaslalo procesu SIGSEGV, což by špatně se chovající programy ukončilo.

    První řešení není kompletní, protože by to stále uživatelům umožnilo překročit limit na počet procesů tím, že by používali setuid(), které by nebylo následováno execve(), ale to je dostatečně vzácný případ na to, aby se to nepovažovalo za významný problém. Alexanderovo řešení bylo v době, kdy bylo navrženo, považováno za příliš velkou palici, obzvláště kvůli programům, které kontrolují návratovou hodnotu setuid() a takový případ mají ošetřený.

    Na první pokus nedostal Vasilij žádné odpovědi, ale když s tímto tématem přišel znovu 6. července, byl příjemně překvapen kladným postojem Linuse Torvaldse:

    Moje reakce je: „prostě tu bláznivou kontrolu z set_user() vyndejme úplně“. Pokud má někdo oprávnění změnit uživatele, rozhodně má také oprávnění ignorovat RLIMIT_NPROC; jak říkáš, selhání je větší bezpečnostní riziko než úspěch.

    Důvodem pro RLIMIT_NPROC je snaha vyhnout se fork bombám. Pokud limit překročíme kvůli jinému důvodu, který je pod kontrolou superuživatele, koho to zajímá?

    To vedlo k patchi, který mění do_execve_common(), aby vrátilo chybu (EAGAIN), pokud je proces přes limit, a kontrola v set_user() byla odstraněna. Patch byl přijat dobře, ale někteří komentátoři nebyli přesvědčeni, že by měl jít už do -rc 3.0, jak navrhl Linus. Když se Neil na patch podíval, viděl problém, který je možná potřeba řešit:

    Všimněte si, že je tu prostor pro souběh, který by měl nezamýšlené důsledky.

    Mezi 'setuid(běžný-uživatel)' a následujícím 'exit()' poté, co execve() selhalo, by v každém procesu vlastněném stejným uživatelem (a v danou chvíli víme, že jich je hodně), selhalo execve() tam, kde by nemělo.

    Zjednodušeně je problém v tom, že přepnutí procesu pod jiného uživatele by mohl způsobit překročení limitu, ale tento limit by nebyl vynucen do volání execve() (jehož selhání by pravděpodobně způsobilo ukončení procesu). Mezitím by jakékoliv execve() v jiném z procesů daného uživatele selhalo. Není jasné, jak velký problém to je, ale rozhodně by to vedlo k neočekávanému chování. Neil navrhl patch, který by problém řešil přidáním příznaku procesu (PF_NPROC_EXCEEDED), který by se nastavil v setuid(), pokud by byl překročen limit, a následně by se kontroloval v do_execve_common() Tak by execve() selhalo jenom v procesu, který překročení limitu způsobil.

    Vasilijovi i Alexanderovi se tento přístup líbil, i když Alexander není přesvědčen, že oproti Vasilijovu původnímu patchi má nějakou výhodu navíc. Také upozornil na to, že mezi setuid() a execve() může být předem neznámý interval, takže by se test na RLIMIT_NPROC měl opakovat, když se volá execve(): Bylo by trochu překvapení zjistit, že proces selhal na execve() kvůli RLIMIT_NPROC, když tento limit byl překročen před několika dny a v době volání execve() již překročen není.

    Neil zatím novou verzi patche s přidaným testem nezaslal. Je tu také otázka, jestli problém, ze kterého má Neil obavu, je vůbec potřeba řešit a jestli to stojí za to přidat další bit pro příznak procesu (v současnosti zbývají pouze tři). Vzhledem k tomu, že Linus má zájem odzbrojit špatné programy, nějaká oprava se pravděpodobně dostane do 3.1. Není jasné, který přístup vyhraje, ale každopádně setuid() přestane selhávat kvůli překročení povoleného počtu procesů.

    Jak poznamenal Vasilij a další, rozhodně to není chyba v jádře, co se tu opravuje. Je to ale dostatečně častá chyba v programech v uživatelském prostoru – často se závažnými důsledky – že stojí za to opravit ji v rámci proaktivního bezpečnostního opatření. Alexander vyjmenoval několik nedávných bezpečnostních problémů způsobených programy, které nekontrolují návratovou hodnotu setuid(). Také poznamenal, že problém není omezen na setuid-root programy, protože i jiné programy, které se pokouší přepnout na méně – jinak – privilegovaného uživatele, mohou také způsobit problémy, když se setuid() použije chybně.

    Dopad změny je relativně malý a špatně napsaných programů v uživatelském prostoru – i těch, které mají běžet s nějakými oprávněními – je hojnost, takže je změna přijatelnější než jiné proaktivní opravy. Jak jsme viděli dříve, setuid() je zákeřná funkce a snadno se rozzlobí; může u ní docházet k překvapujícím interakcím s jinými zdánlivě přímočarými bezpečnostními opatřeními. Uzavřít díru v setuid(), i když problém žije v uživatelském prostoru, rozhodně vylepší celkovou bezpečnost Linuxu.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

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

    Komentáře

    Vložit další komentář

    Jendа avatar 1.8.2011 02:48 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    NAT v IPv6
    Ffffuuuuuu
    Lidé chtějí skrýt detaily topologie svých interních sítí, takže budeme mít NAT v ipv6 bez ohledu na to, co si myslíme nebo chceme.
    To je ale škoda, že k tomuto NAT neslouží…
    1.8.2011 03:41 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Už jsem se tu na to ptal jednou, pořádnou odpověď jsem nedostal. Takže to opět nadhodím jako argument :-)

    Řekněme, že mám malou síť (5PC), které jsou ovšem závislé na internetu (třeba eshop, co já vim). Tak si ten vlastník řekne, koupim si dvě linky k internetu, třeba ADSL+nějakou WiFi. Když nepůjde jedno, půjde snad druhé, každopádně si tím zvýší spolehlivost velmi výrazně. A vše co k tomu potřebuje je privátní rozsah a jeho NATování na zrovna používanou adresu.

    Jak tohle udělám u IPv6? Samozřejmě nepředpokládám, že bych dostal svůj vlastní rozsah a dělal si BGP a spol. Takže dejme tomu, že od obou poskytovatelů dostanu /64. Jak jsem se dozvěděl minule, můžu použít site-specific adresy pro lokální provoz a počítače budou dostávat druhou adresu podle toho, která linka zrovna jede. Jedinej problém je, že všechny mechanismy, jak zjistit svojí IPv6 adresu jsou směrem klient->server, takže klient musí aktivně něco udělat, aby mu "internet zase začal chodit".

    Přitom přímo ideální varianta je zjednodušený NAT, dokonce už jsem viděl takový experimentální modul do iptables*, který prostě udělá přepis prefixu. Při směru dovnitř jedním směrem, při směru ven druhým směrem. Není potřeba si držet stav (ikdyž by to možná mohlo k něčemu pomoct), prostě přepíšu prvních x bitů adresy podle zadaného mapování. Zvenku jsem pořád dostupný na všech adresách, ven lezu přes tu zrovna používanou, vše to funguje poměrně ideálně.

    Prostě lidi musí pochopit, že NAT vzniknul jako hack, možná rozbil internet, ale má i svá pozitiva a ty se mu nedají upřít ani propagandistickými obrázky :-)

    *) xt_RAWNAT z http://xtables-addons.sourceforge.net/modules.php/
    Jendа avatar 1.8.2011 04:16 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jak jsem se dozvěděl minule, můžu použít site-specific adresy pro lokální provoz a počítače budou dostávat druhou adresu podle toho, která linka zrovna jede.
    Ano, přesně takhle se to dělá. Možná je lepší, aby počítače měly adresy od obou ISP trvale a přehazovala se jenom default route, respektive její priorita.
    Jedinej problém je, že všechny mechanismy, jak zjistit svojí IPv6 adresu jsou směrem klient->server, takže klient musí aktivně něco udělat, aby mu "internet zase začal chodit".
    Tohle jsem nějak nepochopil… Normálně pošleš do sítě router advertisement a klienti se podle toho aktualizují, ne? A failover zvenku se řeší na úrovni DNS.
    Zvenku jsem pořád dostupný na všech adresách, ven lezu přes tu zrovna používanou, vše to funguje poměrně ideálně.
    Dokud se někdo nepokusí na klientovu adresu zvenku připojit…
    ale má i svá pozitiva
    No…
    a ty se mu nedají upřít ani propagandistickými obrázky
    FFUUUU používám jako obecný výraz pro zděšení :-).
    1.8.2011 07:08 Jiří J. | skóre: 34 | blog: Poutník | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Dokud se někdo nepokusí na klientovu adresu zvenku připojit

    Pokud by se o to někdo pokusil, nevidím důvod, proč by tomu NAT měl bránit. Pokud jsem původní příspěvek pochopil dobře, jde o statický/bezstavový překlad JEN horních 64bitů podle současně použitého "venkovního" poskytovatele. Tedy o překlad adresy autorovy sítě. Samotné adresy jednotlivých počítačů v ní (spodních 64 bitů) zůstanou neměnné.

    V podstatě jde o takovou zvláštní formu 1:1 NATu.

    Víra je firma si myslela, že něco je pravdivé. LMAO -- “zlehčovat mého osla”
    Jendа avatar 1.8.2011 07:12 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Protože nevím svoji „vnější“ adresu, tak nemůžu říct protistraně, kam se má připojit.
    Jendа avatar 1.8.2011 07:15 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Neboli potřebují společníka, na kterého si pingnou, a on jim řekne jejich adresu. A pak se najednou udělá failover, klienti o něm ale *nevědí* (na rozdíl od řešení s RA, kde uvidí, že jim přišel nový RA, a můžou hned zareaovat), takže jim nečekaně přestanou protékat pakety, počkají na timeout, pingnou si na společníka znova, zjistí, že se jim „veřejná“ adresa změnila, a tak pořád dokola.
    1.8.2011 10:34 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Neodpověděl sis už o pár příspěvků výš tímhle?
    A failover zvenku se řeší na úrovni DNS.
    Jendа avatar 1.8.2011 18:47 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Stále se klienti nijak nedozví, že došlo k failoveru a musí si znova přeložit svá jména.
    1.8.2011 22:43 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jojo... hodila by se podpora pro SRV záznamy u HTTP (tj. implementace v prohlížečích). Stará a smutná píseň...
    [:wq]
    pavlix avatar 2.8.2011 16:54 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Heron avatar 3.8.2011 12:23 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    +1
    3.8.2011 12:15 j
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    No a kdyz jim DNS vrati IPcka obe, tak ani nic prekladat nemusi, jednoduse zkusi nejdriv tu druhou, navic to rozlozi zatez na obe linky.
    1.8.2011 11:02 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Vaši vnější adresu protistrana zná, je to zdrojová adresa spojení mezi vámi.
    Jendа avatar 1.8.2011 18:49 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ano, ale to znamená, že spojení musím navazovat já. A co když se chtějí spojit dva klienti, kteří jsou oba dva za tímhle?
    2.8.2011 10:10 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Úplně stejně, jako když za "tímhle" nejsou a mají dynamicky přidělené adresy, které vzájemně neznají.
    Jendа avatar 2.8.2011 18:29 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Skutečně? Já když mám dynamickou adresu, tak ji zjistím tak, že se zeptám jádra (IP stacku) svého OS. Při „tomhle“ si ale musím pingnout někam ven.
    2.8.2011 18:36 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To jo, jenže jádra už se nezeptáš, jako adresu má druhá strana, takže se nikam stejně nepřipojíš.
    Quando omni flunkus moritati
    pavlix avatar 2.8.2011 20:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Můžu ji publikovat.
    2.8.2011 21:18 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Takže jsi ve stejné situaci jako lidi za tím 1:1 NATem - potřebuješ externí službu, aby se k tobě mohl někdo připojit.
    Quando omni flunkus moritati
    pavlix avatar 2.8.2011 22:33 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Takže jsi ve stejné situaci jako lidi za tím 1:1 NATem
    Nastesti nejsem.
    pavlix avatar 2.8.2011 16:55 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Při symetrické situaci žádné takové spojení není, protože ani nevznikne :).
    pavlix avatar 2.8.2011 16:53 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    V podstatě jde o takovou zvláštní formu 1:1 NATu.
    Spíše úplně obyčejnou. NAT má své problémy i svá použití.
    1.8.2011 09:32 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Možná je lepší, aby počítače měly adresy od obou ISP trvale a přehazovala se jenom default route, respektive její priorita.

    Problem je ze volba zdrojove adresy nezavisi na route. Takze kdyz by jeden spoj nefungoval, pocitace by stale mohly volit prislusnou zdrojovou adresu, ktera by odpovedi vedla na nefunkcni spoj.
    Jendа avatar 1.8.2011 18:52 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Fakt? Já měl za to, že když mám adresy 2001::1/64 a 2002::1/64 a routu via 2002::2, tak se automaticky jako odchozí adresa zvolí ta, která je ve stejné podsíti jako gateway. Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal.
    1.8.2011 19:57 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Narozdil od IPv4, kde to bylo dost jednoduche, se u IPv6 voli zdrojova adresa na zaklade pomerne sloziteho algoritmu (popsaneho v RFC 3484), ktery bere v potaz napr. shodu se scope vuci destination adrese (takze pri komunikaci cilenou na ULA adresu se take pouzije ULA adresa, zatimco pri komunikaci na verejnou se pouzije verejna, nejsem si jist, ale myslim ze obdobne pri komunikaci na 6to4 cil se pouzije 6to4 zdrojova na zaklade nektereho pravidla). Vetsina techto pravidel ale bere v potaz cilovou adresu a nikoliv gateway.

    Ono taky v obecnem pripade u dvou nezavislych uplinku a klientu to vypada tak, ze mam adresy z dvou normalnich prefixu 2001:X::/64 a 2001:Y::/64 a dve (potencialni) defaultni routy smerovane na fe80::/64 (RA routy se standardne smeruji na link-local adresu routeru). Ty jednotlive default routy maji s prislusnyma prefixama spolecne pouze to, ze prisly ze stejneho RA, ale pokud vim, tak tento vztah jadro nedrzi (nebo ho aspon neprezentuje) a minimalne to RFC 3484 nerika, ze by se podle toho mely routy volit.
    1.8.2011 20:15 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6

    Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal. Minimálně Linux pokud nemá zapnuté ip_forward, tak by se z té 2001::1/64 podle mě na 2002::2 ani nedostal.

    Tuhle poznamku nechapu. ip_forward se (AFAIK) tyka pouze forwardovanych paketu, nikoliv lokalne generovanych paketu. Pokud mas pocitac se dvema rozhranima, na jednom 192.168.1.1/24 a na druhem 192.168.2.1/24 a k prvnimu je pripojeny soused s 192.168.1.2/24, ten ma routu 192.168.2.0/24 via 192.168.1.1, tvuj pocitac ma vypnuty ip_forward a nejaky program z nej komunikuje s 192.168.1.2 ale vynuti si zdrojovou IP 192.168.2.1, tak komunikace funguje.
    1.8.2011 19:03 Sten
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Pokud máte více rout s různými prioritami a ke všem IP adresy, zvolí se ta IP adresa, která patří routě s nejvyšší prioritou (pokud si to teda aplikace nevynutí jinak). Proto se taky při komunikaci s 2001::/8 nikdy nevolí adresa fe80::/8, i když by dle vás měly mít obě stejnou šanci na zvolení.
    1.8.2011 20:02 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Viz ma vyse uvedena odpovet Jendovi. Volba zdrojove adresy podle typu cilove adresy (jak uvadis v prikladu) je neco uplne jineho nez volba zdrojove adresy podle routy.

    AFAIK vazba 'adresa patri k route' tam prave neni. Pokud tvrdite ze ano, kde se ten vztah da vylistovat? Ktere RFC rika, ze by se tak klienti meli chovat (protoze kdyby to v Linuxu opravdu tak bylo jako linuxova specialita (ac myslim ze neni), tak by to celkem moc uzitecne nebylo, kdyz by se ostatni klienti chovali jinak)?
    1.8.2011 11:45 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Normálně pošleš do sítě router advertisement a klienti se podle toho aktualizují, ne?
    A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?
    Dokud se někdo nepokusí na klientovu adresu zvenku připojit…
    Co si budem nalhávat, lidem jde většinou o to, aby se oni mohli připojit někam. Ale jinak je to samozřejmě problém, který je ovšem na současné úrovni neřešitelný. Pokud se připojí nějaká síť, která je (výrazně) menší než prefix vhodný pro účastnění se routování, pak pokud je 100% závislá na svém ISP.
    ale má i svá pozitiva
    No…
    a ty se mu nedají upřít ani propagandistickými obrázky
    FFUUUU používám jako obecný výraz pro zděšení :-).
    Tohle je u mně 0 informační hodnota. Argumenty, protiargumenty, připomínky, že něco říkám špatně beru, ale tohle neobsahuje nic z toho...
    1.8.2011 11:51 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?

    Defaultni routu prepnou (ta se neridi DHCPv6), adresy neprepnou (kdyz je prideluje DHCPv6). Stejne tak je neprepnou staticky konfigurovane servery.

    A o adresy jde predevsim, prepinani defaultni routy je trivialita a casto ani neni potreba (pokud napr. obe linky k ISP jsou smerovane pres jeden router).
    Jendа avatar 1.8.2011 18:55 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A tohle opravdu zafunguje tak, ze všichni klienti se okamžitě přepnou? I když používaji DHCPv6?
    No mně se aktualizují adresy i routy okamžitě po přijetí RA.
    Co si budem nalhávat, lidem jde většinou o to, aby se oni mohli připojit někam. Ale jinak je to samozřejmě problém, který je ovšem na současné úrovni neřešitelný. Pokud se připojí nějaká síť, která je (výrazně) menší než prefix vhodný pro účastnění se routování, pak pokud je 100% závislá na svém ISP.
    Takže si můžeme vybrat buď řešení NATem, které znemožní plnohodnotnou obousměrnou komunikaci, a řešení přepínáním adres/rout, které tímto problémem netrpí. Já bych si vybral to druhé(, kdybych měl dvě přípojky).
    Tohle je u mně 0 informační hodnota. Argumenty, protiargumenty, připomínky, že něco říkám špatně beru, ale tohle neobsahuje nic z toho...
    Tak ukaž nějaká pozitiva NATu…
    Heron avatar 1.8.2011 07:41 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jak tohle udělám u IPv6? Samozřejmě nepředpokládám, že bych dostal svůj vlastní rozsah a dělal si BGP a spol. Takže dejme tomu, že od obou poskytovatelů dostanu /64.

    Jednoduše. Počítačům přidělíte IP z obou rozsahů (pomocí RA se přidělí samo) a síť bude mít dva routery. Přes RA budou ohlašovat i svoje priority, takže pokud jedna z linek (všimně te si, že jich tam můžete mít neomezeně) vypadne, tak stačí zvýšit prioritu další preferované lince ven. Klientům se změní preferovaná default routa a jede se dál.

    Toto řešení je (IHMO) daleko elegatnější, než nějaký NAT.

    1.8.2011 08:25 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Počítačům přidělíte IP z obou rozsahů (pomocí RA se přidělí samo) a síť bude mít dva routery.
    IMO je lepší mít jeden připojený k oběma ISP, nicméně předpokládám, že to jde udělat taky.
    Quando omni flunkus moritati
    1.8.2011 09:37 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jenze zmena default routy nezmeni pouzite zdrojove adresy.
    1.8.2011 19:04 Sten
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Právě že změní. Zkuste si to ;-)
    1.8.2011 23:40 Kvakor
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Změní se, jen pokud onen router dělá zároveň i NAT.
    1.8.2011 11:49 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Přiznám se, že se RA jsem ještě neexperimentoval. Ale co jsem nastudoval, tak jsem měl pocit, že to funguje nějak ve stylu, že se klient zapne a zeptá se "hej hola, tak jak tady ta síť vypadá?", něco si podle toho nastaví nebo použije DHCPv6, pokud to v tom advertismentu je, ale dál, že je to na libovůli toho klienta, aby zjišťoval, že se něco změnilo a případně na to reagoval...
    1.8.2011 11:54 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    RA obecne rozesila router a klienti na ne reaguji i kdyz jsou nevyzadane. Klient si pri pusteni muze vyzadat RA (posle RS), aby nemusel cekat na to, kdy router sam posle RA.
    1.8.2011 12:32 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Díky, budu si s tím muset pohrát :-)
    1.8.2011 14:30 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ješte filozoficko/rýpavá otázka :-) I v článku je zmíněno, že NAT rozbil Internet. Ovšem k tomu, aby mi chodilo to přepínání, jak je tu naznačeno, tak potřebuju site-specific adresy pro přístup k lokálním strojům. A to je něco, co je dosažitelné jen z nějaké části sítě, to není "rozbití Internetu"?
    1.8.2011 15:18 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    No, to asi neni otazka na mne. Ja si myslim, ze NAT a firewally sice rozbily Internet, ale ze IPv6 uz to nespravi, a je treba s 'rozbitym' Internetem pocitat.
    1.8.2011 15:55 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ne, to bylo tak nějak všeobecně do diskuze :-) U toho NATu to jeětě chápu, i když nesouhlasím, ale ten firewall, ten mně překvapil :-) Resp. jak firewall (počítejme bez NATu) rozbil Internet?
    1.8.2011 17:59 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Firewall (rekneme stavovy, propoustejici nova spojeni 'ven' ale ne 'dovnitr', jaky se casto navrhuje jako default pro koncove krabicky) rozbiji end to end konektivitu prakticky stejne jako NAT.
    1.8.2011 21:20 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    rozbiji end to end konektivitu prakticky stejne jako NAT.

    To není pravda. U firewallu je to rozbíjení řízený proces a jde to vypnout, u NATu ne - to není stejně.
    Quando omni flunkus moritati
    1.8.2011 23:41 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To je vcelku jedno. Programator ptp aplikace (treba VOIP) urcene pro bezne uzivatele tezko muze pocitat s tim, ze si uzivatel bude schopen prenastavit firewall.
    2.8.2011 00:27 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Není. I u té routovací krabičky nakonec určitě bude nějaké zaškrtávátko typu "povolit telefonování po internetu". U NATu ho neuděláš.
    Quando omni flunkus moritati
    2.8.2011 11:36 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    No, to mozna u znamych a vseobecne rozsirenych programu/protokolu. Pro programatora vyvijejiciho nove ptp programy/protokoly to nehraje roli.
    2.8.2011 12:38 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ten zásadní rozdíl je, že to tlačítko udělat jde.
    Quando omni flunkus moritati
    2.8.2011 22:30 l0gik | skóre: 22
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    UPnP?
    Jendа avatar 1.8.2011 18:58 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    I v rámci sítě můžeš komunikovat po těch globálních adresách.
    Heron avatar 1.8.2011 19:22 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Spíše lokal. Globální adresy se mohou často měnit (zastánci NATu mění poskytovatele co hodinu a argumentují tím, že s NATem si mohou nechat stále stejné adresy, zatímco bez NATu by to museli neustále měnit). Uzel může mít globálních měnících se adres kolik chce a k tomu může mít kolik chce i lokálních adres. Nakonec, stejně jako ve světě IPv4. A úplně nakonec, je to jedno, máme DNS.
    1.8.2011 20:03 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A úplně nakonec, je to jedno, máme DNS.
    Ano máme DNS. jenže DNS má TTL a jiné věci a ještě jsem neviděl moc klientů, kteří bez problému přehodí aktivní spojení na nový pár IP adres ve chvíli, kdy to změnim v DNS :-)

    Vtip celého je v tom:

    Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

    Vy: "Jo, ale nemáte NAT!"

    Zákazník: "Cože? Aničko, najděte mi číslo na někoho jiného..."
    Heron avatar 1.8.2011 20:39 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Já jsem reagoval na něco jiného ;-)

    Ženeš to ad absurdum. To co popisuješ se umí a potřebuješ na to ospf (záložní linka) nebo lépe bgp (více nezávislých konektivit).

    Navíc bych chtěl opravdu vidět, jak bys to, co popisuješ, dosahoval v prostředí za NATem. Spojení popadají tak jako tak. Pro všechna spojení z venku se ti změní adresa té tvé sítě (ip wan routeru). Budeš muset řešit totéž.

    2.8.2011 00:01 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ne já pořád popisuju to samé. Vnější konektivita popadat může, ale nesmí to ovlivnit funkce na vnitřní síti. A pořád se bavím o malých sítích, kde i kdyby šlo dělat BGP a OSPF, je to overkill*. Reaguju na příspěvek, že můžu použít globální adresy i v rámci vnitřní sítě, řikám ano, ale pak musí celá síť mít pořád všechny globální prefixy i v případě, kdy linka toho prefixu nefunguje.

    Jinak, kdybych chtěl dosáhnout vyšší spolehlivosti s těmi vnějšími spojeními, pak použiju tunely někam na páteř. Prostě zdegraduju linky od poskytovetelů na obyč transportní vrstvu a problém s dostupností IP na páteři přenechám našemu páteřnímu ISP. Stačí jako popis, jak to udělat?

    Opravdu mně zatím nikdo nepřesvědčil, co je tak špatného na použití site specific adres a jejich mapování na routeru, říkejme tomu třeba PRS (prefix remapping scheme) :-) Žádné stavy, žádne maskování x adres za jednu, jen prostě pravidla if prefix=něco then prefix=něco jiného.

    *) reálný příklad: Realitní kancelář, má asistentku, tři makléře, kteří jsou většinu času někde v terénu. Mají celkem 5 PC a jeden server, kde na sambě mají věci a tiskárny. Mají ADSL a většinu času je v kanceláři jen asistenka, která řeší emaily. Ale v 9 ráno si potřebujou natáhnout z nějakého relaitního serveru poptávky a když to nezvládnou, tak najednou mají půl dne volna, protože ostatní už ty lidi obvolali. Makléři mají mobílní internet, třeba Ufon či co já vim. A mají představu, že když jim v kanceláři nejde net, tak seberou jednomu makléři Ufona, připojí ho k routeru, někde něco kliknou a tradá.
    Jendа avatar 2.8.2011 00:10 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    ale pak musí celá síť mít pořád všechny globální prefixy i v případě, kdy linka toho prefixu nefunguje
    A to vadí?
    3.8.2011 12:29 j
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Opravdu tu neustele melete z cesty aniz tusite jak snadno a krasne to funguje - jednoduse mate N routeru, kazdy posila do site svuj prefix, vnitrni komunikace neni NIJAK ovlivnena JAKYMKOLI vypadkem konektivity ven a pokud to mate dobre nastaveno (= DNS odpovida adresami ze vsech prefixu), tak si klient prelozi jednou a pouzije libovolnou z tech adres (maximalne nekde pocka na timeout). Kdyz vam padne linka, tak se spojeni rozpadne zcela v zavislosti na schopnostech protokolu a s IP vrstvou to nema nic spolecneho.

    A ano, kazdy do ma vice nez 1 linek ven by mel provozovat nejaky routovaci protokol a kazdy kdo ho pripojuje by mu to mel umoznit.

    Ad ten "realny" pripad - chci videt jak bude nekdo neco stahovat na 256kbit (realne) lince.
    Jendа avatar 1.8.2011 20:51 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Vtip celého je v tom:

    Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

    Vy: "Jo, ale nemáte NAT!"

    Zákazník: "Cože? Aničko, najděte mi číslo na někoho jiného..."
    Při přepínání konektivity ven ti nic nebrání si staré adresy ještě chvíli podržet, než se dokončí všechna spojení uvnitř sítě.
    2.8.2011 00:08 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Při přepínání konektivity ven ti nic nebrání si staré adresy ještě chvíli podržet, než se dokončí všechna spojení uvnitř sítě.
    Ne, nebrání. jenže jak dlouho si je mám podržet? Co já vím, jestli s nima jěště někdo někde komunikuje nebo nedej bože plánuje komunikovat? Alespoň nevím o mechanismu, kdy na celé sítí zjistím "hele, pánové, neplanujete ještě někdo ty starý adresy používat? Ne? Tak já je utnu..." Takže ideální řešení, podržet si je na vždy, tedy mít pořád všechny prefixy na všech strojích. A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční. A jak píšu výše, to už se mi víc líbí řešení, kdy každý klient má jednu (kromě link-specific) adresu a na rozhraních mnou spravované sítě to mapuju z/na funkční rozsah(y).
    Jendа avatar 2.8.2011 00:16 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ne, nebrání. jenže jak dlouho si je mám podržet?
    Každá stanice si je drží tak dlouho, dokud je po nich navázané nějaké TCP spojení. Úplně stejně, jako při používání Piracy Extensions.
    Co já vím, jestli s nima jěště někdo někde komunikuje
    Tobě jako adminovi je tohle totálně fuk. Ty prostě pošleš do sítě RA, které říká, že pro nová spojení se mají používat nové adresy/nový router. Stará spojení uvnitř sítě ještě doběhnou po starých adresách a klienti je pak zahodí.
    A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční.
    A já nevím, co se ti na tom nelíbí. Mně přijde normální, že má jeden počítač víc adres. Třeba můj domácí router jich má momentálně 7 a desktop 3.
    2.8.2011 00:35 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Každá stanice si je drží tak dlouho, dokud je po nich navázané nějaké TCP spojení.
    To samozřejmě nestačí, protože hodně protokolů si tu IP adresu někde uloží a otvírá nové spojení. Třeba takový poštovní klient, jednou za čas udělá resolv mail-internal.firma.cz a pak se na to IP do kolečka připojuje. Nebo se mu zadá server přímo pomocí IP.
    Stará spojení uvnitř sítě ještě doběhnou po starých adresách a klienti je pak zahodí.
    To opravdu ve všech OS funguje tak, že pokud se to IP, na které už nedostávám RA, samo po nějaké době nečiností zahodí?
    A já nevím, co se ti na tom nelíbí. Mně přijde normální, že má jeden počítač víc adres. Třeba můj domácí router jich má momentálně 7 a desktop 3.
    Třeba už jen myšlenka "keep it simple". Jeden klient, jedno IP. Žádné řešení, proč ten klient zase používá jinou IP, než by měl? A himbajs, pustí mně ten firewall z tohohle IP nebo z jiného?

    Pokud se budem trumfovat, tak můj nejbližší router má adres 12 a kámošův kámoš má router, který má dokonce 15 :-) Každopádně já mám rád v síti přehled a pořádek, takže preferuju mnou zmíněnou variantu. Čistě subjektivní preference...
    2.8.2011 11:21 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A himbajs, pustí mně ten firewall z tohohle IP nebo z jiného?

    Tak nevím, tohle už mi přijde jako argument typu "jsem blbec a neumím si to nastavit"...
    Quando omni flunkus moritati
    2.8.2011 22:44 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    I tak je možné se na to dívat. A pro ty z nás, kteří nenosí (nebo nechtějí nosit) v hlavě hafo IP adres je vhodná varianta udržet to jednoduché :-) "Pořádek je pro blbce, inteligent zvládne chaos". Já už jsem dávno zjistil, že to zvládnutí chaosu je leckdy zbytečně namáhavé a je lehčí použít tu první část...
    3.8.2011 12:32 j
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Pro ty znas, kteri to maji v hlave vporadku, je tu DNS.
    pavlix avatar 2.8.2011 17:02 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To samozřejmě nestačí, protože hodně protokolů si tu IP adresu někde uloží a otvírá nové spojení. Třeba takový poštovní klient, jednou za čas udělá resolv mail-internal.firma.cz a pak se na to IP do kolečka připojuje. Nebo se mu zadá server přímo pomocí IP.
    Takový poštovní klient poštu normálně odešle, i když je stará adresa už zrušená, v čem je tedy problém?
    2.8.2011 22:33 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A jak to udělá? Zavolá fuknci na otevření socketu a předá jí "mail-internal.firma.cosi", protože resolvovací knihovna OS tento dotaz již před chvílí dělala, nemusí ho udělat znovu a vráti nějakou IP z cache, tedy tu starou. OS se dále na tuto adresu zkusí připojit a zjistí, že to nejde, protože server už tu adresu nemá. Ano bude to fungovat v případě, kdy serveru ta adresa zůstane a nebude mu vadit, že klient se nyní připojuje z jiné IP.
    pavlix avatar 2.8.2011 22:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Nedostatek invence.
    2.8.2011 22:46 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Přebytek sebevědomí.
    3.8.2011 12:02 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Zbytečná "diskuze"... :-(
    Quando omni flunkus moritati
    pavlix avatar 2.8.2011 17:00 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Zákazník: "Jsem přepnul ten internet na záložní linku, jenže mi popadalo spojení na server, tiskárna vytiskla půl stránky a to video z kamery musím posílat znova..."

    Vy: "Jo, ale nemáte NAT!"
    Jsem navážkách, jestli ještě píšeš z neznalosti nebo už trolluješ. Máš pocit, že přenatování na jiné vnější adresy spojení snad nepřeruší?
    2.8.2011 22:29 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jestli troluju, tak v míře povolené uměleckou licencí. A už jsem psal, že je jasné, že vnější spojení přenatování zruší (pokud se to nějak neobejde), stejně tak jako to, že vnitřní spojení budou fungovat. Co jsem ovšem psal je:

    "Pokud použiju globální adresy od jednoho prefixu na vnitřní spojení" a zároveň "pokud tento prefix přestane fungovat, můžu tyto adresy po chvíli zmastit (a dokonce se to udělá samo)", tak to pravda není.
    pavlix avatar 2.8.2011 22:36 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Da se ledacos.
    2.8.2011 22:56 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A ledaccos se nedá. Myslím, že tuto část debaty můžeme uzavřít, neboť už jsme u neplodných výkřiků...
    pavlix avatar 3.8.2011 01:23 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Myslím, že tuto část debaty můžeme uzavřít, neboť už jsme u neplodných
    Čtu je se zájmem.
    1.8.2011 19:59 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To můžu, ale budu závislý na tom, že v síti vůbec jsou. T.j. buď bude mít každý klient (a server) pořád všechny adresy ze všech rozsahů bez ohledu na to, jestli fungují, nebo budu mít problém. Při vší uctě mi připadá jednodušší, aby každý klient měl jednu IP adresu, která platí v rámci organizace a na hraničních routerech se s touto adresou něco dělo.
    pavlix avatar 2.8.2011 17:04 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Při vší úctě tvůj názor není pro ostatní zase tak důležitý. Zvlášť, když je typickou ukázkou „kdo chce, hledá řešení, kdo nechce, hledá výmluvy“.
    2.8.2011 22:25 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To je samozřejmě pravda. Ani tvůj názor není pro ostatní zase tak důležitý. Ani když je typickou ukázkou toho "když já něco chci, tak je to jediné správné a možnosti, jak udělat něco jiného jsou špatně".

    A proto si myslím, že takovéhle diskuze jsou, protože přispívají k většímu pochopení těch ostatních, což ve finále vede k lepšímu pochopení problematiky z více stran, což každý soudný člověk rád udělá.
    pavlix avatar 2.8.2011 22:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To je samozřejmě pravda. Ani tvůj názor není pro ostatní zase tak důležitý.
    Muj nazor v teto oblasti zpravidla jini ocenuji, protoze jim umim rict, co udelat jde a jak to jde udelat.
    Ani když je typickou ukázkou toho "když já něco chci, tak je to jediné správné a možnosti, jak udělat něco jiného jsou špatně".
    Timto problemem nastesti narozdil od tebe netrpim, cos ale zrejme sam dobre vis, takze nema zadny smysl se o tom dohadovat.
    2.8.2011 23:06 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Muj nazor v teto oblasti zpravidla jini ocenuji, protoze jim umim rict, co udelat jde a jak to jde udelat.
    A tak to má být. Ja bohužel patřím k těm lidem, které ostatní neoceňují, protože jim neumím říct, zda něco jde a případně jak.
    Timto problemem nastesti narozdil od tebe netrpim
    Tady poprosim o link, kde tvrdím, že mnou prosazované řešení je jediné správné nebo že jiná jsou špatně. Vždy maximálně tvrdím, že se mi takové řešení nelíbí nebo líbí. Koneckonců o pár příspěvků výše tvrdím, že
    A to je to, co pořád říkám, že se mi moc nelíbí, ikdyž to asi ve finále bude funkční
    pavlix avatar 3.8.2011 01:24 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Tady poprosim o link, kde tvrdím, že mnou prosazované řešení je jediné správné nebo že jiná jsou špatně.
    Předpokládal jsem, že mě hodnotíš metodou „podle sebe soudím tebe“, jinak si tvoji reakci neumím vysvětlit.
    3.8.2011 02:48 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Zajímavý předpoklad, můžeš ho rozepsat? Sbírám myšlenkové pochody a tenhle ve sbírce ještě nemám :-)

    Ale bez ironie, tohle už jsou netechnické téměř invektivy založené na pár příspěvcích, zkusme to vrátit na technickou rovinu. Já tvrdím toto a poprosím o komentář, co je podle tebe špatně:

    * Pokud budu správně rozesílat RA a klienti si zvládnou rozumně rychle přehodit priority a budou správně vybírat odchozí adresu a to i relativně hloupí klienti typu tiskáren, SIP krabiček/telefonů, Windows, mobilů s WiFi, tak si to dovedu představit jako funkční řešení

    * Na vnitřní komunikaci budu potřebovat buď site specific adresy nebo budou muset mít všechny uzly v sítí všechny globální adresy a to ideálně pořád.

    * jiná možnost, která také bude fungovat, je použít pouze site specific adresy a na hraničním routeru (routerech) dělat nějaký NAT 1:1, který nemusí být stavový

    * Dala by se použít varianta stavového mapování n:m, kdy bych měl k dispozici třeba jen /64 od ISP, ale v síti bych používal několik rozsahů /64. Pořád by to bylo jedna vnitřní pro jednu vnější, jen bych využíval toho, že obsazenost těch /64 je cca 2^(-60)%. A při použit EUI64 je i dokonce poměrně nepravděpodobná kolize dvou adres bez prefixu.

    pavlix avatar 3.8.2011 20:18 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Já si nezačal. Technická rovina mě baví víc :). Takže to s tebou ještě jednou zkusím, ale dost možná naposledy.

    Na ty body ani není třeba odpovídat jednotlivě. Všechny úvahy a možnosti už známe, všechny nějakým lepším či horším způsobem fungují.

    V podstatě se dají rozumná řešení rozložit mezi tři kategorie:

    1) bez překladů a elegantní, jejichž jedinou nevýhodou je nutnost spolupráce ISP, tedy dynamický routing

    2) bez překladů a méně elegantní, bez podpory ISP, tedy dynamické přepínání a použití několika záznamů na jedno jméno v DNS (ať už dynamicky pomocí výměny adres nebo staticky, kdy je nastaveno několik adres zároveň)

    3) S 1:1 překladem adres či rozsahů

    Vtip je v tom, že každé řešení má své nevýhody, což znamená, že se na žádném neshodneme jako na nejlepším bez pečlivého zvážení situace.

    Ve všech případech lze zařídit, aby nová spojení naběhla po výpadku téměř okamžitě. Pokud vím, tak jen v prvním případě lze pokračovat bez ztráty spojení.

    Třetí možnost nevyžaduje ty několikanásobné adresy, ale je velké riziko, že bude ve světě IPv6 používaná v zanedbatelné míře, což znamená, že s tím aplikace nebudou počítat a nebudou fungovat. NAT věci rozbíjí, aplikace je musejí napravovat. Pokud je napravovat nebudou, tak nebudou s NATem fungovat.
    4.8.2011 12:06 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    1) bez překladů a elegantní, jejichž jedinou nevýhodou je nutnost spolupráce ISP, tedy dynamický routing

    No, nejde jenom o spolupraci s ISP, ale take je treba ziskat PI adresy, nebo se sam stat LIRem (tady clenstvi v RIPE). Obe varianty jsou spojene s nemalymi rocnimi poplatky.
    4.8.2011 12:59 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Nebo si obě linky obstarat od jednoho providera (tedy samozřejmě s tím, že obě linky budou nezávislé)... což samozřejmě je také dražší, než internet od ufouna. na druhou stranu, pokud nefunkční internet způsobuje finančí ztráty za miliony a konektivita je přivedena ADSLkem za 3 stovky, tak si snad ani nic jiného nezaslouží...
    4.8.2011 18:41 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    No, mit dve linky od stejneho poskytovatele je z hlediska zajisteni spolehlivosti dost zbytecne, nebot ve vetsine pripadu je vypadek nekde v siti poskytovatele, ne pouze na lince k nemu.
    4.8.2011 21:50 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Samozřejmě nezávislostí byl myšlen případ, kdy obě trasy jsou nezávislé (resp. nikde se nesbíhají do stejného místa)...
    5.8.2011 07:50 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    To bude dokonce jednodušší zajistit u jednoho ISP, kde se to dá ošetřit smluvně. U dvou ISP taky hrozí, že budou mít oba pronajatá vlákna v jednom kabelu, a ošetřit to smluvně by bylo dost náročné (ISP by si museli říct, jaké mají trasy a konzultovat každou změnu).
    pavlix avatar 5.8.2011 21:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    2.8.2011 00:18 Kvakor
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Problém je v tom, že IP adresa (ať v4 nebo "běžná" v6) není identifikací samotného počítače, ale spíš cesty, jak se k počítači skrz síť dostat. Takže pokud chceme, aby se dal k jednomu stroj směřovat provoz z více míst, musí mít onen stroj buďto více adres, nebo sice může mít jedinou adresu, ale musí existovat mechanismus, který nějak zařídí směrování z těch ostatních. U IPv4 se používá v rámci protokolu NAT a mimo něj rozličné IP tunely typu VPN.

    IPv6 má ale i Mobilní IPv6, který alespoň na první pohled tento problém řeší. Na druhý pohled, ono to vlasně je "jakoby" NAT 1:1 (v jednom směru) a IP tunel, jen s tím rozdílem, že do dělá přímo protokol (tudíž nikdo nemusí nikoho balamutit ohledně skutečných adres) a že umí roaming bez zráty otevřených spojení. Talže je otázka, jak to nakonec dopadne, protože to, že má něco několik let existující hotovou specifikaci a RFCčka, bohužel neznamená, že se to bude i používat.
    pavlix avatar 2.8.2011 16:52 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Dodej odkaz, kde ses ptal. Matně si pamatuju, že jsem ti ochotně a pečlivě na vše odpovídal, takže bych se rád podíval, jestli jsi tak nevděčný, jak to vypadá :). Dodej odkaz :).
    2.8.2011 22:22 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Odkaz se dodává špatně. A to proto, že poslední bylo, bude to někdy v článku - konkrétně to přepínání adres. A zatím jsem to v článku neviděl a to jsem ty o IPv6 od tebe přečetl všechny...
    pavlix avatar 2.8.2011 22:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Bohuzel jsem se k pokracovani zatim nedostal, zabere mi to dost casu. Ale jakmile mi bude zbyvat cas, venuju tomu, co muzu.
    Luboš Doležel (Doli) avatar 1.8.2011 14:51 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Součástí tohoto NATu není maškaráda (jestli mi něco neuniklo), tak to není až takový průšvih. Aspoň, že tak.
    1.8.2011 08:27 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše překlepy
    Zdá se, že po dešti nerostou jen houby, ale i překlepy: týdné, ujistite se, ingorují, zjistíe, implmentaci, methoda, struktry, smaotná, svinsvta, stuečnosti, v této části jára, kvlůi.
    1.8.2011 08:40 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: překlepy
    Hm, že bych zapomněl na spellchecker?
    Quando omni flunkus moritati
    Luboš Doležel (Doli) avatar 1.8.2011 13:09 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: překlepy
    Bylo jich tam dost, ale všechno jsem neodchytil :-(
    1.8.2011 10:21 fík
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    smaotná, svinsvta, stuečnosti
    1.8.2011 10:55 donny
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    zrojáků ;)
    1.8.2011 13:07 kip | skóre: 8 | blog: kip | Nový Jičín
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    A ještě "používáním mechanismus".
    Petr Tomášek avatar 1.8.2011 11:16 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše NAT v IPv6
    Jediná dobrá zpráva za poslední dobu ;-)

    Třeba to IPv6 bude jednou i použitelné :-D
    1.8.2011 12:48 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: NAT v IPv6
    jo a internet je už navždy v prdeli :)
    Petr Tomášek avatar 1.8.2011 15:09 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: NAT v IPv6
    To zůstane i bez NATu, možná ještě víc, anžto pod diktátem fanatiků... :)
    1.8.2011 20:19 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: NAT v IPv6
    jojo, pod diktátem fanatiků, kteří bez NATu nedokážou ani žít a byli by snad schopni obětovat každý týden jednu pannu jenom proto, aby jim ten NAT na IPv6 fungoval :)
    1.8.2011 23:31 Kvakor
    Rozbalit Rozbalit vše Re: NAT v IPv6
    Tolik panen by určitě nesehnali :-)
    2.8.2011 15:23 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: NAT v IPv6
    No jo, oni vlastně kvůli tomu i draci vychcípali hlady :)
    Grunt avatar 1.8.2011 19:11 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ať se nám to líbí nebo ne, s NATem se budeme potýkat navždy.
    Super. A multipathu na jedno spojení se nedočkáme už nikdy. Na to stačí říct už jen jediné: FAKT DÍKY!.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    1.8.2011 19:39 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Standardni multipath 'odjakziva' rozdeluje pakety podle toku (tedy pakety z jednoho spojeni a tedy i z jednoho toku pujdou na multipath route stejnym smerem) a to zcela nezavisle na NATu, dela se to AFAIK zejmena kvuli flow control.
    Grunt avatar 1.8.2011 20:25 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jo, to jo, ale někde není psané že je to pravidlo (doufám). Teoreticky je možné napsat více rout jedním směrem a pakety přepínat na jeden a druhý podle toho jak jdou ( Nejlépe ještě s nějakým komunikačním řídícím protokolem a nebo vnitřním mechanismem, který by zátěž rozkládal podle kapacity linky – v koutku duše jsem doufal, že když už vznikla taková spousta nových mechanismů v případě IPv6, tak tohle bude jeden z nich). TCP a UDP je na to připraveno a původní návrh vojenské sítě s tím také počítal. Bohužel v případě použití NATu tato volba automaticky odpadá, protože pokud započne někdo na nějakém portu komunikaci s cílovým serverem, těžko se bude server bavit pokud bude pokračovat úplně tu samou komunikaci (i když bude sedět ACK sekvence) z jiné zdrojové adresy (teda teoreticky by to šlo, al…).
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    1.8.2011 20:33 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Jo, to jo, ale někde není psané že je to pravidlo (doufám). Teoreticky je možné napsat více rout jedním směrem a pakety přepínat na jeden a druhý podle toho jak jdou
    Volit smer per-packet by sice slo, ale moc by to nepomohlo, protoze bys takhle vyuzival dohromady pouze odchozi smer. V opacnem smeru (download) by to vzdy slo jen jednou z tech linek, podle toho, jakou jsi zvolil zdrojovou adresu.
    Grunt avatar 1.8.2011 20:39 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Spíš jde o to, že tohle už je v routerech a pro cíl (pro zdroj skoro také, ale tomu to může být jedno) je to plně transparentní. Router u kterého se to slévá, to zas pro změnu může rozdělovat podle toho jak to šlo opačným směrem (podobně jako multicast) a nebo by se musel ještě dodělat nějaký mechanismus (např mnohem lepší tahat čtyři adresy routerů navíc v případě multipath než čtyři adresy navíc v případě source-routingu). Osobně bych byl teda pro nějaký promakanější mechanismu (třeba jako směrovací protokoly (RIPv6?), které by si předávaly také informaci o vytíženosti linek a podle toho by také pakety rozdělovaly – nebo něco podobně promakaného).
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Grunt avatar 1.8.2011 21:14 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    dodělat nějaký mechanismus
    A když si to tak vezmu, tak vlastně ani ne. I druhým směrem by na některém z hopů muselo dojít k rozhodnutí kudy pakety cpát v případě dvou a více cest (v dnešní podobě Internetu pravděpodobně někde poblíž NIXu), tak se holt nevezme jedna routa, ale dvě a dělit se bude podle toho jak do které linky se budou cpát. Teda samozřejmě v případě existence opravdu jedné celosvětově unikátní adresy. Dnešní internet je spíš více podobný spojovaným okruhům než opravdu přepínané službě, což ale nikdy nebylo cílem.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Bedňa avatar 2.8.2011 23:55 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Hehe je tu dosť živo, tak myslím že na mojej prednáške NAT RULEZ! bude plno :-)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    pavlix avatar 3.8.2011 01:25 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    <joke>To přeju hodně štěstí, aspoň se budou mít lamy kde sejít ;).</joke>
    Bedňa avatar 3.8.2011 01:49 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Ale to si len robím prdel, prečítaj si diskusiu a napíš niečo rozumné, to sa nedá :-)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    pavlix avatar 3.8.2011 20:18 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Tobě psát něco rozumného je jak házet perly sviním :).
    Bedňa avatar 3.8.2011 23:21 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Dík že si sa ma zastal náčelníku :-)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    3.8.2011 09:37 SPM | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Posledně si sliboval transparent a pak prd :)
    Bedňa avatar 3.8.2011 11:28 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 7. 2011: Co zpozdilo Linux 3.0 a NAT v IPv6
    Nemal som čas :-)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/

    Založit nové vláknoNahoru

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