Příspěvky

421

Server / Re:Ověření certifikátu selhalo - OpenVPN na Synology

« kdy: 01. 10. 2021, 15:54:27 »

viz https://www.root.cz/zpravicky/vyprsel-korenovy-certifikat-dst-root-ca-pouzivany-autoritou-let-s-encrypt/, v diskuzi pak máš i nějaké návody.

422

Sítě / Re:Možnost výběru VPN tun/tap neomezená?

« kdy: 30. 09. 2021, 00:27:55 »

TAP se chová jako L2 switch, proto kohoutek, přeposílá všechno co na něj jde i druhé straně.

Osobně mám raději také TAP, protože mi dovoluje se chovat jako, když jsou klienti na stejné síti (fungují síťové tiskárny,airplay,dhcp atd.).

TUN je zase vhodnější na sítě s vysokou latencí nebo s omezeným limitem, logicky, přenáší jen to co je určené druhé straně.

423

Vývoj / Re:Agregace velkého množství streamovaných dat

« kdy: 23. 09. 2021, 09:07:26 »

a Kafka Streams a inkrementální agregace ti nestačí?

Základem je co nejvíce metrik převést na inkrementální (stejný problém řeší např. GoodData), poté počítání v paměti je snadné. Ne vše držet v paměti jednoho procesu, lepší je využít nějakou databázi, např. redis v tomhle poslouží dobře.

Tenhle problém v enterprise často řešíme buď různými obskurně dranými Oracle/SAP nástroji nebo to kluci programují přes spark streams.

Clickhouse není vhodný na příliš mnoho insertů a potřebuje data v bulku, jinak moc dobře s tím nepracuje.

424

Odkladiště / Re:Trávíte korporátní byrokracií víc času než prací?

« kdy: 02. 09. 2021, 16:27:40 »

jdi do těch korporátů externě přes agenturu, hromada věcí ti odpadne, protože atmosféra je pohodovější a zároveň si budeš moci hrát se spoustou technologií.

425

Vývoj / Re:První webové frameworky a knihovny

« kdy: 30. 06. 2021, 17:10:10 »

proč se ptáš?

Jak vidím v archivu, první css knihovny se v mých projektech začaly objevovat kolem roku 2000, do té doby se používaly max. resetovací pravidla a vše se kontrolovalo ACID testy (v té době ještě sotva v první verzi). Vidím věci jako blueprintcss (https://web.archive.org/web/20080828031438/http://blueprintcss.org/), https://960.gs (mrkni na historii na webarchivu; k němu byla i šablona do photoshopu, kolem mě docela oblíbený), pak tam byly perly jako YUI (a z něho postupně vznikl celý JS framework Ext JS), první boostrap css od Twitteru se objevil až několik let poté.

Weby se vesměs kontroloval v jednom prohlížeči, styly se psaly přímo a předávaly se z projektu na projekt, vesměs to byla doba, kdy se spousta layoutů dělala jako tabulka a pozicování blokových elementů bylo v plenkách.

426

Odkladiště / Re:KB - ověření všech odchozích plateb KB klíčem

« kdy: 10. 04. 2021, 02:07:52 »

technicky to dělat banka může, ale bohužel je svázána podmínkami karetních sítí a PSD2 SCA. Volba ověření (3D Secure) je na bráně a nelze to vynutit ze strany banky. Banka má možnost danou platbu pouze zamítnout, což uživatelsky není pěkné, tohle platí pro 3D Secure 1.

PSD2 SCA přidává podmínku druhého faktoru při potvrzení transakce a "otisk" prstu je dostatečné ověření, stejně tak použití mobilního telefonu. 3D Secure 2 je standard od Visa/Master Card a je koncipován tak, aby splnil podmínky PSD2 SCA a povoluje potvrzení platební transakce také otiskem prstu, takže si to banky trochu ulehčili. Pořád ale platí, že za zneužití při použití otisku prstů nesou riziko oni. Zároveň pořád je ponechána možnost, aby brána nepodporovala žádná 2FA a transakce i tak prošla, platí ještě nějaké výjimky či co.

3D Secure 2 ale bance dává možnost vyhodnocovat rizika (frictionless flow) a případně vynutit ověření zákazníka. Proti první verze je tentokrát odpovědnost i na bance ta se může rozhodnout. KB 3D Secure 2 podporuje a má implementovaný bezpečnostní mechanismus na vynucení potvrzení při podezření, bohužel parametry nejsou veřejně (a ani interně) známy a těžko říct, jak to vlastně mají nastavené. Neříkají pravdu, že to je věcí obchodníka a je to spíše nedostatečným informováním lidí na podpoře.

Režimy Google Pay a těhle mobilních plateb jsou pak na další povídání.

427

Server / Re:MariaDB - Galera - multimaster

« kdy: 09. 04. 2021, 10:54:56 »

To je vtip?

Vykon - oproti osttanym databazam rozhodne nie.
Transakcie - su feikove.
Cudzie kluce - pozri na akom engine musis vyuzivat galeru.
Strata dat - s tym mam bohate skunosti.

Ja viem, ze dnes je v mode tvorit aplikacie co funguju, len pokial fuka spravny vietor, ale preco sa taym este chvalit a vychvalovat to ako spravne riesnie?

Můžeš být konkrétní? Srovnávat výkon je vždy diskutabilní, ale innodb poskytuje poměrně solidní rovnováhu, ve srovnání s Oracle DB nebo SQL Serverem na stejném HW poskytuje často lehce vyšší výkon pro operace, které podporuje, určitě není pozadu, u většiny nasazení ale člověk nejde na dřeň a každá databáze má konstrukce, které jí sednou a které jí nesednou. Podpora sql funkcí, procedur a divné chování jsou jiné úvahy.

Co znamená, že transakce jsou fejkové? Můžeš být konkrétní? Mariadb s Galerou deklaruje repeatable read, což dovoluje hodně ojedinělý výskyt Phantom chyb, viz specifikace ANSI SQL-92. Myisam engine nemá transakce a tam jsou opravdu fejkové, ale to není varianta, o které se bavíme, galera podporuje pouze innodb.

Opět, co znamená ztráta dat? Při jaké nastavení? Mariadb a innodb používá double write buffer ve výchozím nastavení, to dovoluje se dostat z nesprávně zapsaný page do datového souboru i v případě okamžitého pádu serveru. Zároveň veškeré transakce jsou v binlogu, pokud se poškodí datový soubor, je možné ho rekonstruovat, v případě použití galera clusteru (o tom je tohle vlákno), dochází k synchronní replikaci na jiný stroj. Poškození datových souborů kvůli chybě HW či OS se může vyskytovat, za to ale nemůže databáze samotná a od toho jsou zálohy případně právě použití clusteru. Ano, již několikrát jsem musel obnovovat datové soubory z odvařených serverů, díky kontrolním součtům u binlogu není ztráta většinou tak velká.

O kterých verzích Mariadb a galery mluvíš? Netvrdím, že Mariadb a galera je bezchybná a nejlepší cesta. Provozuji různorodé databáze od devadesátých let, nevím, co je dneska moderní, už jedu ve svých kolejích a snažím se doporučovat variantu, která je pro dané použití vhodná. Ztráty dat jsem řešil snad na všech velkých databázích (pamatuješ předloni dvoudenní výpadek Alzy?), zpravidla to je souhra spousty různých vnějších okolností a nikoliv pouze chyba databáze. Innodb je v tomhle poměrně spolehlivé a bouřlivé chyby s neplatnými checksumy, které se občas objevily v počátku již dvacet nepotkávám. Stejně tak je innodb relativně odolné proti chybám operační paměti (bez použití ECC), ale doporučené použití je s ECC, stejně to platí u ostatních. Nebavím se tady o malých projektech, na mariadb běží slevomat, rohlik.cz, kosik.cz, pilulka, používá jí v kritické části Equa Bank, KB, Česká spořitelna a nespočet dalších projektů.

428

Server / Re:MariaDB - Galera - multimaster

« kdy: 08. 04. 2021, 23:37:55 »

Sice tomu povies "begin transaction" a ono odpovie "OK", ale nic sa nestane, rovnako s cudzimi klucmi, niektorimi indexami.... Ak chce clovek prist o data nie je lepsia volba.

A co jiného čekáš od begin transaction? Jaké problémy máš s cizími klíčemi v galeře a které nefungují správně? Přijít o data? Mariadb s innodb patří k velice spolehlivé databázi pokud jde o ztrátu dat, těch kritických nasazení v ČR jsem dělal několik.

Stejne tak si uzijes s deadlocky. Jakmile delas zapisy na ruzne servery, budes se potkavat a casto na ne narazis. Jo a jeste tu je read gap - ale to se tyka i master-slave pouziti v galere. Galera je near-sync, commitnes data na jednom serveru a existuje (sice kratka, ale je tam) mezera, kdy data jeste nemas na slave. Tedy idealne musis zajistit, ze select after insert jde na stejny server (coz je jeste v pohode), ale napr i GET after POST by ti mel jit na stejny. A to uz muze byt obcas orisek.

read gap s two phase commit? Mluvíš nejspíš o asynchronní replikaci přes nativní mariadb cluster a nikoliv synchronní v Galeře, tam probíhá two phase commit, server na který zapisuješ potvrze zápis jako poslední, dirty reads se v praxi dějí hodně ojediněle. GET po POSTu v galeře vychází vždy stejný, opravdu nejspíš mluvíš o asynchronní replikaci, takovéhle zpoždění se v galeře nedějí.

od Galera 4.0 existuje funkce wsrep_sync_wait_upto_gtid(), kam můžeš předat gtip transakce a tím zajistit, že tvoje proběhne až po jiné. V distribuovaném módu totiž neexistuje globální lineární serializace, ale každý master má vlastní serializaci a poté se řeší opakování při konfliktech (to lze nastavit na automatické na pozadí).

Ano, Mariadb s Galerou "nepodporují" paralelní zápis stejných dat na více masterů, globální locky mají experimentálně jen v posledních verzích. Mimochodem tohle je obecný problém distribuovaných databází a každá má určitá specifika, kterým se musíš přizpůsobit. I Oracle s RACem má stejné problémy a musí se to také řešit lokalitou zápisu.

Mariadb s Galerou v ČR provozuje na řadě kritických projektů a je to poměrně solidní databáze, má sice spousty bolístek, ale patří mezi těm jednodušším na správu. Další varianta je použití Postgresql, ale master-master replikace tam není sranda, BDR extenze podporuje pouze async, Bucardo je jen pro Pg 12 a běží jako další služba, PostgreSQL-XC či přímo EnterpriseDB mají vlastní forknutou verzi PostgresSQL. Je s tím obecně daleko více práce. V open source SQL databázích s tímhle končíme, více toho není nebo to je příliš zabugované.

429

Software / Re:Aký softvér na správu tímových projektov?

« kdy: 08. 04. 2021, 17:45:47 »

znám povedený activecollab.com, není ale open source, to jsou třeba phproject.org, https://github.com/nafiesl/free-pmo

430

Sítě / Re:WireGuard - nejde internet přes tunel

« kdy: 08. 04. 2021, 10:18:11 »

A ono to je místo toho jedno pravidlo (maškaráda), u IPv6 (bez maškarády) dokonce 0 pravidel. A pak se teda může hodit zakázat forward „tím špatným směrem“ pokud nechceš aby ti lidi zvenku mohli lézt do VPN, tak to je další pravidlo.

Takhle jednoduchý to nebude. Ať dělám, co dělám, tak to prostě nefunguje.
Odkládám to na dobu neurčitou- po osmi hodinách všech možných pokusů už mi to ani nemyslí.

pošli výpis iptables. Těžko radit, správné nastavení sítí a forwardování není vždy jednoduché, ale my co to děláme pravidelně a už dlouho to považujeme za snadné, návody nemusí pokrýt všechny případy. Občas je lepší čas věnovat nastudování manuálů a naučení se principů jak to funguje než zkoušení a zkoušení než to dopadne, z toho si pak nic neodneseš.

431

Server / Re:MariaDB - Galera - multimaster

« kdy: 07. 04. 2021, 17:44:07 »

mysli na to, že odolné to je jen tehdy, když se ti klient umí v případě výpadku připojit na jiný master a tam transakci udělat znovu. Dále nezapomeň, že galera podporuje jen tzv. optimistic locking, kdy nemá globální locky, ale pouze lokální pro danou instanci, je tedy vhodné řešit lokalitu zápisu, kdy nemůže zároveň zapisovat stejná data na více masterů zároveň, ale je to dobré určitý master preferovat k zápisu určitých dat, to si musíš dělat sám.

Asi ti nezbývá než si toho poměrně dost nastudovat a načíst si oficiální dokumentaci, je to tam dobře popsané, měl bys vědět jak to funguje a jak se o to starat.

V praxi používáme multimaster u mariadb, ale chováme se k tomu jako k active-standby, kdy proxy upřednostňuje zápis pouze na první funkční instanci (číst je možné ze všech, teda pokud neděláš něco jako select for update). Dobře funguje proxySQL jako balancer nebo obyčený haproxy s jeho nativními checky. Díky zápisu vždy pouze na jeden master se udrží poměrně vysoká kompatibilita s klienty.

Jako omezení bych vyzdvihnul:

• nutnost mít všude primary key, bez nich to je tenký led
• zapomeň na auto increment sloupce, případně se dá řešit varianta s dírami, kdy každý má svoji řadu - sudá/lichá či máš increment 3 u tří masterů atd.
• triggery na insert hodnot jsou problém, raději se vyhnout úplně použití procedůr a triggerů na databázi
• podpora je pouze pro row based replication (statement snad umí jen poslední verze, takže bych neriskoval), takže jakýkoliv update celého sloupce může udělat pěknou melu v replikaci
• bude tě trápit velikost transance, nepočítej s tím, že při importu do eshopu budeš moci tisíce updatů strčit do jediné transakce
• nepodporuje to myisam, interní tabulka mysql, kde jsou struktury, uživatelé, procedůry, granty je myisam, takže buď jí převedeš na innodb nebo musíš veškeré tyhle změny aplikovat na všechny instanci. Je tady určitá možnost to nechat projít replikačním protokolem, ale není to spolehlivé, raději se při deploymentu připoj na všechny a zajistit změny na všech masterech
• při alterech tabulek si prostuduj rozdíj mezi RSU a TOI, nauč se používat správnou variantu ve správnou dobu

432

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 01. 04. 2021, 10:56:05 »

nejde ale o problém ztráty jednoho řádku, ale ztráty celých datových souborů se spoustami řádků, nikdo pak nedokáže říct, co tam vlastně bylo a jak. Stejně tak při poškození ti to může vracet jiné hodnoty. MyIsam používá takovou divnou binární strukturu, kdy v souboru .frm je uvedena struktura tabulky, jednotlivé sloupce mají své flagy, poté v .myd jsou je uveden flag sloupce a poté binární obsah a takhle pořád dokola. Pokud se něco poškodí, část dat zmizí nebo tam vznikne jiná chyba, nemáš moc záchytných bodů jak poznat od sebe samotná binární data a struktury. Je možné se tím snažit ručně nějak projít a najít bod, kdy se to začalo rozbíjet, ale je to obrovsky těžké, už u desítek společností jsem se snažil z toho vydobít kritická data. Dělej zálohy a nespoléhej na to, že se to nerozbije. U dlouho běžících systémů bez ECC lze pozorovat i chyby, které způsobují chyby paměti.

433

Server / Re:Přechod z ext4 na ZFS - podstatné snížení rychlosti databázové aplikace

« kdy: 31. 03. 2021, 12:02:14 »

My používáme stále zastaralou myIsam, který zdá se má jedinou podstatnou nevýhodu v tom, že jeden select může někdy zamčít celou tabulku. To řešíme tak, že náročnější, ale méně důležité čtení provádíme z clonů.

hlavně myIsam má podstatnou nevýhodu v neexistující kontrole integrity dat, nemožnosti z některých poruch tabulku rekonstruovat. Neměla by v ní být data, která nemám nikde jinde a o která nechci přijít.

434

Software / Re:Todo list system

« kdy: 26. 03. 2021, 09:34:53 »

trello, je v tom dost přímočarý a funguje dobře na mobilu.

Jinak já používám klasický poznámky u emailu, za ty roky jsem si na textovou podobu zvyk a vyhovuje mi daleko více než kdejaký nástroj.

435

Sítě / Re:T-Mobile - slovenská GeoIP

« kdy: 24. 03. 2021, 12:14:53 »

Proč se k tomu vyjadřujete, když o tom nic nevíte? U Teamspeaku to funguje velmi specificky. Někdo si vyhlédne váš server ve veřejném seznamu, připojí se, pošle všem zprávu "Pojďte všichni k nám, IP 1.2.3.4" a na dvě minuty to ucpe jednoduchým DDoS, takže to lidem spadne. Při hraní hry to ty lidi naštve a opravdu k němu odejdou. Pokud se tam ten člověk vůbec nepřipojí, nemá smysl, aby prováděl deny. Rozdíl při aplikování této "hloupé ochrany", která je tak strašně špatná je, že to nyní nepadá, pokud to vypnu, zase to bude padat dvakrát denně. Uznávám, pěkné to není, ale řeší to problém, takže místo smutných uživatelů jsou šťastní uživatelé. Chápete ten rozdíl?

a jak souvisí tvůj teamspeak serverů k T-mobilu a "slovenskými" IP? Ok, pokud provozuješ teamspeak pro uzavřenou komunitu a chceš cílit pouze na cz trh hráčů, klidně si to blokuj jak chceš , tohle asi nebude velký byznys a nejspíš to tedy provozuješ zdarma.