Příspěvky

3256

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 15. 06. 2018, 14:27:22 »

Jak? Bez indexu se zmíněná data vejdou do jedné alokační jednotky na disku. Když použiji index, je potřeba načíst dvě alokační jednotky, což je pomalejší.

Jestli budou data tabulky na jedné alokační jednotce disku závisí na tom, jak budou na disku zapsaná. Záznamy mohou být nějak zarovnané, navíc 100 záznamů neznamená, že jsou jeden za druhým – může tam být např. prázdné místo po smazaných záznamech, nebo se prostě záznamy jedné tabulky nezapisují souvisle za sebou.

Když se použije index, je větší pravděpodobnost, že budou data u sebe v jedné alokační jednotce disku. A explicitně jsem psal o případu, kdy jsou požadovaná data v indexu – takže odpadá čtení dat z tabulky, které mlčky předpokládáte.

3257

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 15. 06. 2018, 13:43:37 »

Index se prakticky nikdy nenavrhuje pro jeden konkrétní dotaz, ale pro množinu očekávaných dotazů. Jestli se konkrétní index použije si databáze rozhodne sama. Pokud bude mít v nějaké tabulce 50 % záznamů hledanou hodnotu, ve většině případů se opravdu nevyplatí index použít. Ale i v takovém případě může být dotaz na tyto hodnoty, kdy se použití indexu vyplatí – třeba když se budu ptát jenom na počet záznamů, nebo když budu z té tabulky potřebovat jen údaje, které jsou v tom indexu.

Pokud mám tabulku, která má jen 100 záznamů, je otázka, jestli vůbec potřebuji databázi.

Ne tak docela. Pro 100 záznamů je index zbytečný, praktičtější je full-scan. Pokud tedy budu mít tabulku se sloupci ID a jméno, tak použiji primární index pro ID a hotovo. Jména mohu prohledávat sekvenčně, protože další index to neurychlí.

Záleží na konkrétním případě, ale obvykle by i v takové situaci index hledání urychlil.

3258

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 15. 06. 2018, 11:56:50 »

Vy to ale pořád píšete opačně. Index primárně slouží pro vyhledávání (a tudíž není unikátní). A s pomocí toho indexu se dá nastavit omezení na sloupci, aby byl unikátní, pro což se pak používá zkratka „unikátní index“. Samozřejmě, že pro vyhledávání je lepší mít index než ho nemít. A různé typy indexů mohou být pro určitý typ dat lepší než jiné – a unikátní index může být o něco efektivnější, než neunikátní. Což je ale jedno, protože unikátní index se nastavuje především kvůli tomu omezení unikátnosti dat.

3259

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 14. 06. 2018, 22:15:28 »

Tak. V tom případě se nejedná o index unikátní. I tak má příznivý vliv na rychlost selectů apod., které nad pojednaným sloupcem budete provádět.

Ono je to opačně – index se vytváří kvůli rychlému vyhledání určitého záznamu v tabulce, a když je potřeba zajistit unikátnost nějaké hodnoty, vytvoří se nad daným sloupcem index, protože vyhledávat danou hodnotu bude nutné při každém insertu a updatu.

složitosti log2n vyhledávání se mi rychleji najdou ty indexy, které dále ukazují na data v tabulce

Jsou různé druhy indexů, mají různou složitost pro vyhledávání i pro zápis, dokonce i různou složitost pro různé charakteristiky dat. Index je prostě struktura, která umožňuje rychlejší nalezení záznamů odpovídajících daným podmínkám. Index je česky rejstřík – a databázový rejstřík má úplně stejnou funkci, jako rejstřík v knize. Některá slova, o kterých se předpokládá, že je budete v knize hledat, máte vypsaná v rejstříku, spolu s odkazem na stránku v knize, kde se to slovo nalézá. A slova v rejstříku jsou seřazená abecedně, takže v tom seznamu požadované slovo rychle najdete. To, co je v knize napsané, se z rejstříku nedozvíte – jsou tam vypsaná jen některá slova, a navíc v abecedním pořadí, ne v pořadí, v jakém jsou ve větách, aby věty dávaly smysl. Když ale potřebujete najít, kde se nachází konkrétní slovo, najdete ho v rejstříku mnohem rychleji, než kdybyste četl knihu od začátku do konce. A k jedné knize můžete mít rejstříků několik – třeba jmenný rejstřík, rejstřík míst, věcný rejstřík.

Rozdíl knižního a databázového rejstříku je v tom, že kniha se nemění, tudíž ani rejstřík se nemění, takže je řazený abecedně, protože v tom se lidem snadno hledá. Databázový rejstřík počítá s tím, že se data mění, takže se musí měnit i rejstřík. kdybyste chtěl do abecedního rejstříku vložit nové slovo, musíte najít řádek, kam patří, a celý zbytek rejstříku od toho místa až do konce byste musel smazat a napsat znova, o řádek níž. Proto se v databázích používají jinak uspořádané rejstříky, ve kterých se docela snadno hledá, ale ani přidání nebo mazání není tak složitá operace. Třeba ty stromové indexy (např. různé varianty B-tree) fungují tak, že nezačínáte od kraje, ale zhruba uprostřed – takže by rejstřík začínal třeba „pokud slovo začíná od A–M, pokračujte na stránce 79, pokud začíná N–Ž, pokračujte na stránce 93“. Pokud budete hledat třeba slovo „KLÍČ“, budete pokračovat na stránce 79, a tam bude „pokud slovo začíná na A–G, pokračujte na stránce 85, pokud na H–M, pokračujte na 82“. A tak dále. Hledání v takovém stromu je pro počítač o něco obtížnější, než hledání v setříděném seznamu, ale úprava takového rejstříku je podstatně snazší – třeba při vkládání stačí přepsat nanejvýš jeden list, což je mnohem lepší, než kdybyste musel průměrně přepisovat půlku abecedního rejstříku.

3260

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 18:11:33 »

Patri k best practices, ze z VPNky nemam primy pristup na Internet, pouze do inside/interni DMZ kde je VPNka zakoncena...

Což je mimoběžné s naší debatou, protože já píšu o případu, kdy do VPN směřuje jen provoz, který tam jít musí, a internet je z klienta normálně dostupný přímo. Protože když VPN používám jenom jako způsob, jak obejít nedostatek veřejných IP adres, není důvod cpát do VPN veškerý provoz.

Každopádně k best practices patří nerozbíjet něco, co rozbité být nemusí. Takže není potřeba vyjmenovávat případy, kdy rozbité DNS nevadí, když pořád existují případy, kdy rozbité DNS vadí. A bude jich čím dál víc, protože DNSSEC a HTTPS tlačí na rušení různých lokálních domén a používání jen veřejného DNS stromu, zároveň HTTPS tlačí na používání DNS místo IP adres. A kvůli nedostatku IPv4 adres nejspíš bude narůstat používání VPN, takže problémy s různými DNS resolvery poskytujícími jiná data, než jsou ve veřejném DNS, budou narůstat.

3261

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 17:36:51 »

Tak dobře, řekněme že má dvě VPN současně – a chce se připojit na webmail.intranet.firma1.cz a zároveň webmail.intranet.firma2.cz. Obě doménová jména budou dostupná ve veřejném internetu a budou se překládat na privátní adresu 192.168.1.1. A jsme v koncích, stejně se k jedné ze dvou služeb nedostaneme.

Což není problém DNS, ale konfliktu používaných rozsahů privátních adres. Že takový konflikt může nastat neznamená, že musím preventivně rozbít i DNS.

Máte ověřeno, že tyhle služby privátní adresy v DNS odpovědích nefiltrují?

Jistě. Zkoušel jsem tedy jen IP adresy z 10.0.0.0/8 a 172.16.0.0/12, protože rozsah 192.168.0.0/16 nikde nepoužívám, ale nepředpokládám, že u něj by to bylo jinak.

3262

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 17:06:30 »

Pokud se pripojuji do VPN, tak pouzivam i prideleny DNS resolver z VPN
Pokud ne, tak je bud bordel v nastaveni VPN spojeni nebo mnou rozhazena konfigurace

Vždyť jsem to psal – radši než povolit privátní IP adresy na DNS resolveru, unesete všechny DNS dotazy. Chcete zabránit kosmetickému problému, tak radši vyrobíte problém skutečný. Výborné bude, když se bude o DNS resolver přetahovat několik VPN. Nebo když vám CDN přes to VPNkové DNS naservíruje obsah poblíž vyústění té VPN, ke kterému se budete dostávat nejlépe přes tranzit, zatímco dotyčná CDN má server i u vašeho ISP. Samá pozitiva a sociální jistoty.

Privatni IP adresy do verejneho internetu nepatri

Také je tam nikdo necpe.

3263

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 16:16:51 »

O prkotinu jde v každém případě. Jen si stojím za tím, že filtrování privátních adres přijatých v DNS odpovědích z veřejného internetu je správné výchozí nastavení. Lidé, kteří vědí, že takové privátní adresy jsou v síti jejich ISP používány by měli nastavení upravit, ne naopak. Protože těch případů, kdy z internetu přijde A záznam mířící do privátního prostoru, který bude dávat smysl, bude jistě daleko méně, než případů, kdy půjde o nějakou chybu.

Nejde přece o IP adresy v síti ISP, ale o IP adresy v lokální síti uživatele (nebo v síti, kam má přístup – třeba přes VPN). Podle mne je to špatné výchozí nastavení, protože třeba ty VPN jsou případ, kdy se může připojovat úplný laik, který neví vůbec nic o tom, že by si v DNS resolveru na svém routeru měl vypínat nějaké divné výchozí nastavení. Pak to akorát vede k tomu, že správce takové VPN bude klientům nutit u svůj DNS resolver. A nedej bože, aby se uživatel připojoval do více VPN současně.

Ono ale bude mnohem jednodušší, než dotyčnému vysvětlovat, kde tenhle filtr vypne, poradit mu, jak si DNS resolver nastaví na čtyři jedničky, osmičky nebo devítky, čímž bude uživatel definitivně ochráněn od všech škodlivých odpovědí jeho lokálního DNS resolveru.

Kdyby to filtrování aspoň mělo nějaký význam… Ale ten vektor útoku, že se nastaví A záznam ale nešlo by to samé udělat CNAME záznamem; zařízení, na které se útočí, je zabezpečené právě tak divně, že pro konfiguraci není potřeba přihlášení ale je potřeba CSRF token – to je tak prapodivná kombinace, a místo odstranění bezpečnostní díry to „řešit“ tak, že se odfiltrují některé DNS odpovědi…

Nicméně použití vhodného IP rozsahu mimo vyhrazené prefixy RFC 1918 tento problém efektivně eliminuje a mělo by být tím správným řešením pro CDN server před CGN.

Problém to eliminuje do té doby, než si někdo všimne, že děravé ADSL modemy mají IP z rozsahů mimo vyhrazené prefixy RFC 1918 a začne v DNS odpovědích filtrovat ty další rozsahy.

3264

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 14:02:01 »

Privatni IP adresy do verejneho DNS proste NEPATRI

„Prostě“ a tučné písmo jsou hodně slabé protiargumenty.

Co je podle vás „veřejné DNS“? Je „veřejné DNS“ privátní záznam, o kterém nikdo mimo vybraných uživatelů neví, že existuje?

kdo to blokuje, ten jen dela dobre

Proč? Čeho tím blokováním docílí?

Jinak tu řešíme prkotinu – kdo ve své síti privátní IP adresy a na ně směřující DNS záznamy používá, ten je na svém DNS resolveru povolí. Takže problém mohou mít akorát ti, kdo používají jiný DNS resolver, nejčastěji uživatelé připojení přes VPN – tak uživatelům VPN změníme DNS resolver, případně uneseme DNS dotazy, a problém je vyřešen. Já teda únosy DNS dotazů považuju za daleko větší problém, než privátní IP adresy v neveřejných DNS záznamech – jestli vy to máte opačně, je to váš problém.

3265

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 13:47:57 »

O to vůbec nejde. Jde o to, že ve veřejném DNS stromu, který je globálně dostupný, by měly být pouze globálně dostupné adresy. To nevylučuje použití veřejného DNS pro lokálně dostupné adresy, při kterém se takovéto DNS odpovědi nebudou šířit za hranu lokální sítě. A taková hrana logicky existuje i mezi sítí ISP a sítí zákazníka. Privátní adresy podle RFC 1918 navíc úplně jasně patří do sítě zákazníka, nikoli do sítě ISP, je tedy logické, že router zákazníka bude pokusy o průnik takových adres ze strany ISP blokovat.

To, že je nějaký DNS název globálně dostupný, přece vůbec nic neznamená. DNS název používá ten, kdo ho zná, a DNS vůbec nemá řešit, odkud se na to ptá. V té privátní síti můžu být přímo, můžu tam mít VPN spoj. Router zákazníka nemá pouštět do vnitřní sítě pakety, které mají jako zdrojovou nebo cílovou adresu privátní síť, ale vnitřek komunikace ho zajímat nemá.

Hloupý nápad to rozhodně není. Přeci nechcete, aby třeba Root.cz umístil do své domény A záznam s adresou 10.0.0.138 a během čtení článků nic netušícím čtenářům na pozadí AJAXem konfiguroval jejich ADSL modem.

Tohle je ale problém zabezpečení toho ADSL modemu. Pokud se to někdo pokouší řešit v DNS, je to kontraproduktivní, protože to žádné zabezpečení není. Ten modem může mít veřejnou IP adresu, můžu dát do DNS CNAME záznam na jeho A záznam – a nebo ten ADSL modem půjde prostě překonfigurovat jedním POST požadavkem na IP adresu, a že se útočná webová stránka nedozví výsledek je úplně jedno.

Nepoužívat ve veřejném DNS IP adresy z privátních rozsahů by mělo smysl, kdyby byl dostatek veřejných IP adres a privátní IP adresy se používaly jenom ve výjimečných případech, kde by to dávalo smysl. To ale dnes neplatí a privátní IP adresy se používají jako náhrada veřejných IP adres tam, kde nemusí být daná zařízení dostupná z celého internetu, ale stačí z vybraných sítí.

Kvůli DNSSEC nebo TLS certifikátům chceme mít jeden DNS strom, tak holt musíme umět do tohoto stromu k neveřejným DNS záznamům přidat privátní IP adresy, když nic jako „neveřejné“ IP adresy neexistuje. Je to nejmenší zlo – a je jedině dobře, pokud to někomu zabrání myslet si, že zákazem A záznamu na ADSL modem něco zabezpečil.

3266

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 12:36:07 »

Není to pitomé chování routeru. Privátní adresy by se ve veřejném DNS neměly vyskytovat už jenom z toho důvodu, že se k nim veřejným internetem nedá dostat.

Ale „veřejné“ DNS přece vůbec neznamená, že je ta adresa veřejná. Přece proto se zavádělo třeba NSEC3, aby nebylo možné DNS záznamy vypsat.

Privátní adresy taky vůbec nepatří do sítě ISP jakékoli velikosti, protože zde hrozí riziko konfliktu rozsahu s místem, kam privátní adresy patří, tedy koncovou sítí zákazníka.

To, že jsou v síti privátní IP adresy, přece neznamená, že se nebude používat DNS. A DNS předpokládá, že se bude používat jeden společný root, tedy veřejné DNS – provozovat privátní DNS stromy je sice možné, ale není to podporované, jsou s tím problémy a budou s tím čím dál větší problémy.

Stejnou ochranu má implicitně zapnutou i Unbound.

Což nic nemění na tom, že je to – slušně řečeno – hloupý nápad.

3267

Vývoj / Re:Docker image pro Spring + Tomcat + PostgreSQL

« kdy: 14. 06. 2018, 07:51:22 »

Alebo viete co, nechajte tak, nubudem vas trapit unikernelmi.

Nemusíte mít strach – fakt mne netrápí, že pořád melete o věcech, o kterých nic nevíte.

To akoze zoberiem ten linuxovy ELF binar JVMka zabaleny v Docker image, otocim to voci Windows kernelu a pojde to? No neviem, ja som bol v tom, ze aby siel Linuxovy image v Dockeri na Windowse, treba paravirtualizovat Linuxovy kernel cez Hyper-V. To mi teda nepripada ako nenarocna kontajnerova izolacia cez namespace a cgroupy, ale budiz.

Vy jste se ovšem ptal, jestli ten Linuxový image půjde provozovat i pod Windows. A to půjde, jak už jste sám zjistil – a třeba pro vývoj to výkonově bude stačit.

Dik za tip. Citali ste to vyssie? Co keby ste si vy nastudovali ako to funguje?

„Výše“ je předchozí část vašeho komentáře, o způsobu spouštění linuxových Docker kontejnerů na Windows? Tu jsem fakt nečetl dřív, než jste ji napsal. A jak funguje Docker vím a věděl jsem to i před tím, než vy jste začal googlit, abyste zjistil, proč Docker není virtualizace, ale že se jedná o kontejnery.

Vy akoze neupdatujete JRE, ci co?

Já ho updatuju. Ale lidé provozují i Javu i na počítačích, které nespravuju, a provozují tam i jiné aplikace, než ty moje.

Co musite mat pri jave zafixovane?

Třeba verzi JRE (např. kvůli vyhnutí se známým chybám), dodavatele JRE (Oracle/OpenJDK/IBM), ve starších verzí Security Policy, Java extensions, Java agents, národní prostředí, nativní knihovny používané přes JNI…

Neviete spustit java8 -jar app.jar alebo java9 -jar app.jar alebo random-java -jar app.jar?

Viem. A vy si takhle někdy zkuste spustit Maven – java-8 -jar mvn.sh. To se budete divit. Nebo si takhle zkuste spustit Java WebStart aplikaci.

Kvoli tomu potrebujete Docker?

Ne.

Mat JREcko v Dockri dava zmysel?

Ano, perfektní. Porovnejte si třeba instalaci Confluence v porovnání s docker run, porovnejte si instalaci Elasticsearch + LogStash + Kibana s docker-compose up. A pak si to porovnejte, když to budete spouštět na 16 serverech ručně a když to tam spustíte přes Kubernetes.

Spustit na jednom JRE 6 verzii jednej aplikacie nejde? Alebo aj 6 instancii 6 verzii jednej aplikacie na 3 roznych JRE? To je akoze TEN problem?

Docker neřeší nic, co by nešlo jinak. Akorát jsou některé věci podstatně jednodušší.

Navíc Docker podle mého názoru některé věci řeší ne zrovna nejlépe, radši mám třeba rkt. Ale tady šlo o něco úplně jiného –  o to, že jste nechápal, že Spring Boot slouží jenom pro snazší konfiguraci Spring frameworku a přidružených technologií; zatímco Docker slouží pro zabalení celého prostředí aplikace (nejen Javovské) do jednoho balíčku, který je pak možné distribuovat a spouštět na různých prostředích (ať už na bare metal, ve virtuálních strojích nebo v cloudu) a který na rozdíl od jiných způsobů (třeba virtualizace celého OS) řeší oddělení jednotlivých prostředí pouze pomocí linuxových jmenných prostorů, takže je tam minimální overhead (a na druhou stranu to oddělení není úplně dokonalé).

Vy pri buildovani JARka prekompilujete aj bytecode tretich stran ci co?

Ne. A víte vy vůbec, jak vypadá taková Java aplikace? Protože vaše odpověď je poněkud mimoběžná s námitkou, že pod JRE 8 nespustíte aplikaci s bajtkódem zkompilovaným pro Javu 10.

Alebo neviete, co si balite k vasej aplikaci?

Vím. Ale to že to vím nijak nepomáhá tomu, aby někdo spustil pod Javou 8 bajtkód pro Javu 10.

3268

Odkladiště / Re:K čemu slouží GPG key servery?

« kdy: 13. 06. 2018, 18:22:38 »

A taky když si s někým píšu pomocí PGP připadá mě hloupé že je dohledatelné veřejně že jsem této osobě někdy něco psal.

Nebo se pletu?

Pletete se, tohle na PGP keyserverech serverech dohledatelné není. Když někomu posíláte šifrovaný e-mail, ta informace se nikam neodesílá, stejně jako kdybyste posílal nešifrovaný e-mail.

3269

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 17:40:20 »

U routeru bude zásadnější packet rate, než propustnost pásma.

Což na věci vůbec nic nemění.

Pokud by se jednalo o gigabity, je jak otázka, tak zvažovaná řešení mimo mísu.

Proč? Otázka i zvažovaná řešení (až na ten návrat k NATu) jsou na objemu přenášených dat zcela nezávislá.

V takovém případě by si to opravdu žádalo zajistit si veřejné ip adresy a servery mít na takovém segmentu.

Vy to prostě přes ten router poženete za každou cenu, i když jsou klienti i server na stejném segmentu sítě.

aby člověk přemýšlel, kde je zadrátovaná IP adresa na pevno, jakou cestou se z jakého programu reslovuje atd.

IP adresa není zadrátovaná napevno nikde, z programu se resolvuje normální cestou systémového resolveru, tak jako ze všech ostatních programů na daném počítači a jako ze všech ostatních zařízení v dané síti.

Podle mě si nevyberete. Uznávám, že jsem tvrzení vzal moc zhurta, ono to bude asi prašť jako uhoď.

Já si teda vyberu, nějak mi chybí ta správná motivace nacpat NAT kamkoli, i když tam vůbec není potřeba.

3270

Sítě / Re:HTTPS na privátní adrese

« kdy: 13. 06. 2018, 17:15:22 »

Ano, ale "uzváldat" SNAT+DNAT na routeru, např. ve školní síti, není zas až tak nepřekonatelný problém. Podle mě bude existovat jen málo skutečných situací, kdy nemáte možnost mít veřejnou IP adresu a zároveň nemáte ani možnost "ustíhat" NAT. Když si představím hraniční router takové sítě, podle mě na conntracku NATU má takové množství spojení, že ještě nějaká navíc zpět do vlastní sítě už nemohou hrát tak velkou roli. To řešení má velkou výhodu v tom, že je pro síťaře dobře čitelné a chová se vypočitatelně. Ale jak píšete, za cenu ztraceného výkonu na routeru.

Akorát že vůbec nejde o počet spojení, ale o datový tok. Pokud má ta síť připojení do internetu 100 Mbit/s, musí ten router umět uNATovat 100 Mbit/s. Pokud bude mít server s 1 Gbit/s síťovkou, měl by ten router umět uNATovat 2 Gbit/s. To je sakra rozdíl.

Navíc na tom serveru nepoznáte, odkud ta spojení jdou, všechna budou z routeru – nemůžete dělat QoS, nic nepoznáte z logu.

Že je to řešení pro síťaře čitelné a chová se vypočitatelně je snad vtip. Porovnáváte přímé spojení přes switch se spojením dvakrát NATovaným na routeru. Nechcete snad tvrdit, že ten dvojitý NAT to zpřehlední a vylepší…