Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 [2] 3 4 ... 384
16
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 16:59:08 »
Použití PostgreSQL rozhodně doporučuju, chová se to prostě jako normální databáze. Použít pak btrfs snapshoty a spustit databázi nad starším snapshotem je pak triviální (když to máte správně připravené), jak popisuje třeba Heron v BTRFS v praxi po 5 letech: PostgreSQL. Nebo je to popsané přímo v dokumentaci PostgreSQL: File System Level Backup.

17
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 10:48:49 »
docela snadno, stačí třeba v systemd službě mít TimeoutStopSec>0 (či obdobu v dockeru) a vypnutý fast shutdown, pak se nemusí vše řádně stihnout. Mít starší verzi mariadb s O_DSYNC, kde to dělalo občas problémy a fsync se při vypnutí nevolal. Stejně tak mít O_DIRECT a vypnutý innodb_use_native_aio (což kvůli bugům je automaticky na některých kernelech, ikdyž ho v configu zapneš), pak nezapsaná data zůstávají v innodb bufferech. Mariadb ještě docela nedávno neuměla oddělit fsync metadat a dat, takže volala obě najednou, což je drahé a tak se tím šetřilo. Takže pozor na to, je to občas docela alchymie. Teď to celé strč do kombinace s nějakým overlayfs, protože ti přišlo skvělé to spustit v dockeru.

Povinná metadatová databáze "mysql" je v myisam enginu, to k tomu nepoužívání, pokud jí změníš na innodb, což lze, tak občas něco nepěkně selže. Mariadb je neskutečně zákeřná tím, že má řadu archaických částí a kódů. BACKUP STAGE je dobrá funkce, řeší to právě řadu těch problémů, o kterých jsem psal. Nepřitomnost oficiálního nastroje na fyzický backup, strohá oficiální dokumentace je něco, co by ti mělo spustit v hlavě červenou kontrolku, že tady je něco špatně.
Pokud nedokážete databázi korektně vypnout, máte problém tak jako tak. Narazíte na něj minimálně při aktualizaci jádra a restartu systému, nebo při nutnosti vypnout server (třeba při výpadku napájení). Takže já bych nejprve vyřešil to, jak korektně vypnout databázi, a pak už můžete použít snapshoty nebo kopii datových souborů.

18
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 08:38:11 »
Pokud máte k dispozici souborový systém se snapshoty, použil bych vytvoření snapshotu. Ten samozřejmě musíte dělat v okamžiku, kdy jsou data na disku konzistentní – tedy buď při zastavené databázi, nebo se dodělávala podpora (obecně do OS a aplikací) pro to, že můžete databázi říct, že teď má všechna data zapsat na disk, databáze pak pošle signál, že je vše zapsané a dál nezapisuje, pak se udělá snapshot a pak se databáze odemkne pro další zápis. Tj. dá se udělat konzistentní snapshot i za běhu databáze. Ale nevím, zda MariaDB tuhle funkcionalitu podporuje.
Pozor také na to, že dříve byly problémy s výkonem databází na CoW systémech – protože databáze byly optimalizované pro systémy, které data na disku přepisují. Jednak už se to asi zlepšilo, je možné, že se databáze umí trochu přizpůsobit CoW systému. Ale hlavně u té vaší databáze nepředpokládám nějaké extra velké nároky na výkon.
Když už máte udělaný konzistentní snapshot, můžete si s ním dělat, co chcete – třeba nad ním spustit jinou instanci databáze, ověřovat konzistenci nebo vyexportovat data a připravit je pro import do souborového systému s jinou velikostí bloků, tedy cokoli z toho, co by chtěl _Tomas_ (a vy pravděpodobně nechcete, protože chcete mít jen zálohu dat pro případnou obnovu na tomtéž stroji a souborovém systému).

19
Server / Re:Bitbucket - read-only user len na webe?
« kdy: 04. 03. 2024, 16:44:33 »
Aby měl někdo read-only přístup je možné, to už jste sám napsal. Aby měl přístup jen přes web nedává smysl, což plyne už z toho, že není jasné, co tím vlastně myslíte. Má mít přístup jen přes webové rozhraní pro prohlížeč? Nebo i přes API? Nebo může i klonovat přes HTTP? Tak jako tak, i ve webovém rozhraní jen pro prohlížeč může vidět všechno, takže nedává smysl to omezovat – stejně by měl přístup k celému repository, jenom trochu komplikovanější.

20
Windows a jiné systémy / Re:Podepisování aplikačního kódu
« kdy: 03. 03. 2024, 16:56:42 »
Oni pak ale utahli srouby a dali si podminku, ze ke klici je potreba koupit i jejich HW klic a to uz na me bylo drahy.
Není to náhodou už podmínka Microsoftu pro všechny code signing certifikáty, že privátní klíč musí být neexportovatelný a uložený na certifikovaném zařízení? Mám pocit, že na tokeny nebo čipové karty pro code signing certifikáty přecházely všechny certifikační autority.

21
Windows a jiné systémy / Re:Podepisování aplikačního kódu
« kdy: 03. 03. 2024, 11:37:04 »
DNS certifikáty se dají zautomatizovat, stačí nějak prokázat držení domény – záznamem v DNS, vystavením souboru na webu na dané doméně, třeba i reakcí na e-mail zaslaný na danou doménu.

Code signing certifikáty ale ověřují osobu nebo firmu, tam zatím žádná automatizace udělat nejde. A když to nemůže být automatizované, nedá se to udělat tak levně, aby to utáhli jen sponzoři, jako v případě Let's Encrypt.

22
Windows a jiné systémy / Re:Podepisování aplikačního kódu
« kdy: 01. 03. 2024, 14:23:42 »
Ty služby elektronické identifikace zajišťují identitu z pohledu práva v EU. Nevím o žádné certifikační autoritě, která by s touto identitou pracovala mimo legislativní prostor EU. Uznávané certifikační autority mají svoje postupy, jak identitu ověřovat, které jsou zpravidla podstatně starší, než eIDAS. I kdyby nějaká autorita uměla použít eIDAS identitu, pravděpodobně kvůli tomu ten certifikát nezlevní. Tj. je potřeba některá důvěryhodná CA poskytující Code signing certifikáty. Jsou i přeprodejci v ČR, třeba SSL Market od Zoneru. SSLmentor nabízí nejlevnější code signing certifikát hodně levně  –ale nemám s nimi žádnou zkušenost, jen to na mne teď vypadlo z Google.

23
Software / Re:Doba archivace historie systemd journald
« kdy: 29. 02. 2024, 13:54:22 »
Na co chcete odpověď, když jste nenapsal žádnou otázku? Jestli se ptáte na to, zda je potřeba journald nakonfigurovat, když chcete, aby vyhovoval vašim potřebám – pak ano, je to potřeba. Číst myšlenky zatím journald neumí. Pokud jde o zachování logů, můžete si nakonfigurovat to, co je běžné u logovacích souborů – maximální velikost logů, maximální stáří logů, maximální velikost souboru, maximální množství souborů.

24
Nemusí nutně jít o doménové jméno. Třeba QR kódy pro aktivaci TOTP autentikátorů mají formát:

Kód: [Vybrat]
otpauth://TYPE/LABEL?PARAMETERS
[/quote]
To je založené na tom, že je to URL se specifickým protokolem. Jenže aby to fungovalo, je potřeba mít v systému zaregistrovanou aplikaci pro konkrétní protokol. Na Androidu takových aplikací může být víc, uživatel pak dostane na výběr. Na desktopu je k tomu jako výchozí zaregistrována maximálně jedna aplikace. Uživateli, který by žádnou takovou aplikaci neměl, by to bylo k ničemu. Proto by za mne byla lepší varianta s https URL, které se dá normálně otevřít ve webovém prohlížeči a není potřeba k tomu mít žádnou speciální aplikaci.

Navíc QR Platby jsou věc specifická pro ČR, jinde se používají jiné formáty. Kdyby si takhle bez registrace každý začal používat protokol pay:, ale s různými formáty, bude v tom pěkný zmatek.

25
Na mobilu se registrovat může - na https mi mobil nabídne výběr prohlížečů, na pdf soubor čtečky pdf, na GPS polohu výběr mapových aplikací.. úplně stejně může nabízet bankovní aplikace? Jen na webu to nedává smysl - je třeba skenovat QR rovnou z aplikace.
Nic z toho ale nedokazuje, že se aplikace může zaregistrovat k cizí webové URL. To, co jste popsal, jsou jen protokoly či MIME typy. Jde o to, zda se k obsluze adresy třeba https://www.facebook.com/* může přihlásit třeba i aplikace Google Plus+ (kdo ji pamatuje). Teď jsem se díval, a Mapy.cz na Androidu nejsou napojené na https://maps.google.com nebo https://www.google.com/map, takže nevím, zda to jde napojit se na cizí URL.

Právě že na webu by to smysl dávalo – kód QR platby by obsahoval URL, zároveň by ten QR kód fungoval jako odkaz na to URL. Takže ať byste na to v mobilním prohlížeči kliknul nebo QR kód v mobilním prohlížeči naskenoval, v obou případech byste dostal na výběr, kterou bankovní aplikaci chcete spustit.

26
Ja pochybujem ze niekoho zaujima nejaky QR kod ked je na desktope a nie mobile.
Problém je to i na tom mobilu, kde musíte uživatele speciálně instruovat „tenhle QR kód neotvírejte v aplikaci, kde normálně otvíráte QR kódy, ale v bankovní aplikaci“. Porovnejte to s pohodlností třeba Qerka – když máte aplikaci, klidně naskenujete QR kód v ní. Ale kdo tu aplikaci nemá, naskenuje QR kód jak je zvyklý, a nakonec také zaplatí.

Ja sa bavim len o odkaze ktory proste presmeruje na **uzivatelovu** banku a tam len potvrdi platbu ktora si prave z odkazu len vezme moj iban, ciastku a nejaky variabilny symbol. Dnes sa to riesi tymi bankovymi tlacidlami, co je fajn, ale problem je stale ten isty - ja musim mat kompletny zoznam vsetkych bank z ktorych si uzivatel moze vybrat tu svoju. No a prave ma zaujima ci sa kvoli tejto novej smernici o instantnych bankovych prevodoch nieco v tomto smere riesi, to je cele.
Řeší se to, ne v souvislosti se směrnicí ale už déle. A neřeší se to formou odkazu ale formou platebního API, jak jsem psal v prvním komentáři.

27
Je velká škoda, že tyhle standardy nekódují informace ve formátu URL. Jako uživatel bych čekal, že když načtu platební QR kód obecnou čtečkou, telefon se mě zeptá, kterou aplikací ho chci otevřít a rovnou nabídne všechny bankovní aplikace, které se zaregistrovaly k odběru dané URL.

Místo toho když takový kód načtu normální čtečkou, dostanu jen podivný textový řetězec a musím to být já, kdo aktivně otevře bankovní aplikaci, najde v ní funkci čtení QR kódů a teprve touhle čtečkou the kód načte.

Kdyby platební kód existoval ve formátu URL, tohle by krásně řěšilo i problém nakupování přímo na mobilu: místo skenování QR kódu by prostě stačilo kliknout na odkaz.

Naprosto souhlasím. Nicméně je to pochopitelné – QR platby jsou udělané tak, že jsou jednotlivé banky naprosto nezávislé na jiných subjektech. Kdyby na to existovalo společné URL, musel by být nějaký subjekt, který by provozoval příslušnou doménu s webem (to mohly být ČBA, ale nejsem si jist, zda QR platby nešly platby mimo ně), tam by musel být rozcestník bank, tj. banky by se k tomu musely nějak registrovat. Na mobilech by to bylo ještě horší – nevím, zda se mohou aplikace zaregistrovat k cizímu URL, a jestli se k němu může zaregistrovat více aplikací. Pokud ne, musela by vzniknou nějaká aplikace QR platba, která by fungovala jako rozcestník. (Ale asi to možné je, aplikace Mapy.cz myslím reaguje na URL Google Map.)

28
Vývoj / Re:API a šetření přenosu odkazem na objekt
« kdy: 27. 02. 2024, 10:34:38 »
Myslim, ze sa tostandardne robi cez $ref a $id, ale otazne je kolko parserov to zvladne.
Ano, podobně to používá třeba OpenAPI – v $ref je cesta k objektu, který se má použít. Tj. ten identifikátor není jednoduché ID, ale celá cesta – tudíž je to univerzálnější a v jedné struktuře mohou být odkazované různé typy objektů. Obávám se ale, že v případě, který byl uveden tazatelem, by to ID mohlo být podobně dlouhé, jako samotná data – takže úspora dat by tam nemusela být žádná.

Tenhle princip se hodí v případě, kdy potřebujete zrekonstruovat na cílové straně tu strukturu objektů – třeba jak psal Tomas-T, že se třeba seznam autorů zároveň použil pro naplnění nějakého číselníku.

29
Vývoj / Re:Zkrácení haše pro identifikaci
« kdy: 26. 02. 2024, 20:23:43 »
Jenže losování v loterii a hledání kolizí je jiná úloha.
Za prvé, jestli je to stejná nebo jiná úloha je úplně jedno. V obou případech máme na konci pravděpodobnost, zda se najde kolize / bude vylosováno správné číslo. Takže jenom porovnáváme dvě pravděpodobnosti, tedy dvě bezrozměrná čísla v rozsahu <0; 1>.

Ale vstupy pro hashe jsou neomezená množina, protože není specifikovaná délka řetězce a může to  být dlouhá jak prsa ženy afrického kmenu. Věc druhá je ,že hash nabývá 2^N hodnot
Nemůžete počítat s neomezenou množinou vstupů, protože pokud bude počet vstupů 2N+1 a více, pravděpodobnost, že dojde ke kolizi, je 1.

Ve skutečnosti se počítá s tím, kolik máte různých vstupů. Třeba u gitu je to počet commitů v repository. Když nemáte konkrétní repository, uděláte odhad – kolik by tak nějaké obří repository mohlo mít commitů. Vtip je v tom, že na určení počtu commitů v repository vlastně nezáleží, pokud to bude nějaká myslitelná hodnota. Protože to pořád vede na tak nízkou pravděpodobnost, že nemá smysl se tím zabývat. Když budete počítat, že na git repository (s SHA-1) bude pracovat milion programátorů, kteří každý vyprodukují milion commitů denně a budou to dělat milion dnů (tj. přes 2700 let), pořád bude na konci pravděpodobnost kolize v řádu 10-13. Pravděpodobnost výhry hlavního tahu ve sportce je někde v řádu 10-8. Mimochodem, linuxové jádro mělo milion commitů před necelými třemi roky. Pravděpodobnost, že by v repository s milionem commitů byla kolize, je v řádu 10-37. Takže je pořád podstatně pravděpodobnější, že vyhrajete hlavní tah Sportky čtyřikrát, než že bude (neúmyslná!) kolize mezi hashi commitů zdrojů linuxového jádra.

Proto to celé nabourá jenom situace, kdy dojde k prolomení hashovací funkce a útočník dokáže generovat kolize záměrně v historicky krátké době (tj. v řádu dejme tomu měsíců a méně). Jako už se to stalo s SHA-1 (proto se přestala používat v kryptografii).

Stran: 1 [2] 3 4 ... 384