Příspěvky

91

Vývoj / Re:SHA 512 dostačující?

« kdy: 09. 07. 2015, 10:41:26 »

Ano, dostačující. Teda, jestli ti nebude vadit, že tuhle funkci vytvořila NSA.

Tuhle funkci nevytvořila NSA, byla vybrána ve veřejné mezinárodní soutěži NISTu. Tj trochu rozdíl i když obě organizace začínají na stejné písmenko.

92

Vývoj / Re:SHA 512 dostačující?

« kdy: 09. 07. 2015, 10:29:32 »

Ale podle veřejně dostupných informací si "jakýkoli orgán" ještě docela dlouho neporadí s SHA-256/RSA1024/AES128, což odpovídá heslu výše uvedeného typu o délce cca. 20 znaků...

Tady bych byl opatrnější. Na SHA2 se našlo oslabení už před hodně roky. Zatím se to maskuje zkráceným výstupu fce SHA512 na požadovanou velikost, takže SHA256 je vlastně SHA 512/256.

RSA 1024b se už nedoporučuje min. od roku 2010.

O AES nemám info, obecně se ale dnes používá 256, i když 128 by zatím stačilo.

U hesla záleží na množině znaků, za dostatečné se považuje 24 znaků anglické abecedy + číslice. Pokud by do toho někdo zahrnul celý unicode, tak se mu to zkrátí (i když by se tím heslem pravděpodobně už nikdy nepřihlásil).

93

Server / Re:Obnova přepsaných souborů

« kdy: 22. 06. 2015, 15:33:45 »

Velmi záleží na tom jakým způsobem to přepsal. Pokud otevřel původní soubor, udělal truncate a zapsal tam nový obsah, tak je naděje na obnovení malá (prostě část souboru přepsal na místě). Pokud to ale dělá způsobem vytvoření souboru stejného jména (unlink a mv), tak je docela slušná šance, že jsou původní data nedotčená. Jako pravděpodobnější bych viděl druhou variantu, tam by měl photorec zafungovat.

Příště ale důkladně zálohovat. Je to snadnější než to složitě obnovovat. 

94

Server / Re:Sdílení výkonu dvou serverů

« kdy: 13. 04. 2015, 16:42:54 »

Na i7 pri pouziti 8 jader ve VM jsem mel benchmark 6500 klicu/s u i5 tipuji polovinu u Core2Duo jsem mel 2100. Pokud mas takove heslo tak ti ho nikdy necracknu, ale ja uprime nikdy nevidel na wifi heslu neco jineho nez cisla a pismena a vetsinou se drzeli minima 8 znaku a s tim uz se da pracovat.

Dobře, čísla + znaky, 8 znaků. Budeme si fandit a dáme si výkon 16K klíčů / s.

8 znaků z čísel a znaků to máme nějakých 41b, od toho odečteme 16K tedy 14b = 41-14 = 27. Potřebujeme tedy 2^27 sekund. To jsou 4 roky a nějaké drobné. Pokud budeme mít štěstí, tak se to najde klidně v první sekundě, pokud budeme mít smůlu, tak v té poslední. Průměr 2 roky.

(Pokud jsem se někde sekl, opravte mě.  )

Mě osobně wifi ap vygenerovalo heslo dlouhé 16 znaků. Pokud není chyba v generátoru náhody, tak tj 18*10^12 let, tedy asi tak 1500x déle než je dosavadní stáří vesmíru.

95

Vývoj / Re:Git prompt? Abych nemusel opakovat "git" v git checkout ...

« kdy: 18. 03. 2015, 14:49:25 »

Můžeš přece přímo ve Vimu použít

Kód: [Vybrat]

:Git cherry-pick 1234

popřípadě si to ":Git " strčit pod nějakou funkční klávesu.

To spíš :!git (! je volání externího příkazu). Vim interní příkaz Git nezná, možná tam máš nějaký plugin. Jinak ano, volání !git si může namapovat na nějaké klávesové zkratky.

96

O serveru Root.cz / Re:Budoucnost fór na Rootu

« kdy: 13. 02. 2015, 12:45:34 »

Opakuji se, ale mě se líbí tvrdě moderovaná fóra například na diskuse.elektrika.cz. Otázky jsou pouze k věci, odpovědi jsou k věci a také správné (většinou opatřené odkazem na nějakou normu). Je radost to číst.

Také už tam prakticky nikdo, oproti dřívějšku, kromě starousedlíků nechodí, 3/4 "diskuze" je generována strojově jako reklama na články.

Jestli ono to není taky proto, že je relativně hodně témat vyřešených a stačí je najít a přečíst si odpovědi. Ty generované diskuse nejsou reklama na články, to jsou diskuse k těm článkům (pod články žádná diskuse není, využívají k tomu fórum).

97

O serveru Root.cz / Re:Budoucnost fór na Rootu

« kdy: 13. 02. 2015, 11:37:22 »

Někdy mám pocit jako JmJ. Tady by se přednesenej problém dal často vyřešit hned v první reakci, ale místo toho se z člověka, kterej přišel požádat o pomoc, udělá nejdřív blbec, pak neschopnej blbec, pak blbec, kterej neumí popsat svůj problém a až když začne téma mít druhou stranu, tak se možná někdo uvolí k tomu, že se začne věnovat tématu.

Dřív to tu bylo všeobecně vstřícnější...

Ptát se také musí umět. Pokud je z otázky patrné, že tazatel nevěnoval vůbec žádné úsilí k vyřešení problému, nebo je to dokonce zakuklená otázka typu "vyřešte za mě domácí úkol", tak je reakce okolí asi celkem pochopitelná a současně i žádoucí (proč věnovat úsilí někomu, kdo do toho sám nic nedal).

98

O serveru Root.cz / Re:Budoucnost fór na Rootu

« kdy: 13. 02. 2015, 11:25:29 »

Druhou variantou je zavedení tvrdé moderace, výběr „vhodných“ příspěvků a mazání těch „nevhodných“. Ale to asi nechce žádná strana.

Já třeba jo. Opakuji se, ale mě se líbí tvrdě moderovaná fóra například na diskuse.elektrika.cz. Otázky jsou pouze k věci, odpovědi jsou k věci a také správné (většinou opatřené odkazem na nějakou normu). Je radost to číst.

Kdo se chce bavit jako hulvát a publikovat své nepodložené domněnky, má k tomu na internetu hromadu možností.

99

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 11. 02. 2015, 18:33:56 »

OK, du vysvetlit zakaznikum, ze ty statisice za UPSky sou vlastne vyhozeny prachy ... pisou to na rootu, tak to musi bejt pravda...

A co teprve ty miliony za licence na (konzitentni) zalohovani ...

Statisíce a miliony nejsou zárukou ničeho. Viděl jsem projekty 60x předražené a prachy vyhozené na věci, které byly naprosto k ničemu a nakonec vlastně nepoužité. A viděl jsem, jak dotyčný se ani vteřinu nezamyslel a chystal se vypláznout dalšího čtvrt mega za další nesmysl, který šel řešit jen jiným uspořádáním již existujícího systému. V podstatě by to šlo jen do kapsy dodavateli, za nic.

100

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 11. 02. 2015, 17:54:59 »

Nezaruci, nemuze. Databaze vubec netusi, jestli ta data uz na disku skutecne jsou. A tusit nemuze. Zapis na disk resi OS, a ani ten v realu nevi, zda data uz sou zapsana, nebo zda jsou v nejake cache. Prave proto se vsechny tyhle veci pripojujou na UPSky, a diskovy systemy maji zcela bezne jeste vlastni baterie - prave pro cache radice/disku.

Boha jeho 

Samozřejmě, že zaručí. DB klient pošle commit, db udělá zápisy co potřebuje a vydá směrem k fs příkaz fsync, fs pošle data na disk a vydá směrem k disku příkaz flush, disk zapíše potvrdí zápis, os potvrdí fsync a db potvrdí commit. (Zjednodušeně řečeno.)

Cache řadiče držená zvláštní baterkou s předchozím schématem má společného jen tolik, že se data neukládájí přímo na disk (což je samozřejmně pomalé), ale do paměťi řadiče a ten to až potom asynchronně zapíše na disk. Baterku to má proto, aby když vypadne proud a disky přestanou komunikovat, tak si ta data podrží v paměti a při další power on je zapíšou na ty disky.

Problém nastává v případech, kdy nějaký krok selže, tedy pokud disk potvrdí zapsání dat dřív, než je skutečně zapíše.  Nebo kdy DB potvrdí klientovi commit dřív, než dostane odpověď od OS apod. Pokud ale ty jednotlivé vrstvy pracují jak mají, je vše ok a v případě výpadku napájení se nic nestane. UPSky slouží spíše ke korektnímu vypnutí služeb a korektnímu ohlášení okolním systémům, že se jde vypnout.

101

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 11. 02. 2015, 10:29:42 »

ACID. Clovek ma zalohu suborov tak, ako by ich videl, keby v tom momente vypadol prud (to sa tiez nestihne flushnut alebo dokoncit transakcie).
Z toho by sa slusna databaza s transakciami mala spamatat bez nejakych nekonzistencii.

Až na to, že MySQL není ACID. Pokud nějaká databáze používá výhradně InnoDB, tak se možná dá uvažovat o tom, že tato konkrétní db v rámci serveru acid splňuje, ale MySQL jako celek ne. Už jen proto, že nelze vypnout MYISAM, která je na (nejen) systémové věci prostě povinná.

102

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 10. 02. 2015, 16:26:16 »

No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.

Ano, to že to JÁ mám blbě nastavené už jsem slyšel. Víte, problém je jinde. U MySQL všichni berou jako normální, že se o tu mysql musíte starat, neustále kontrolovat konzistenci, neustále něco řešit a když to neděláte, je to VÁŠ problém.

Ne, ten software se o ty data má postarat sám, od toho je. A má k tomu úplně všechno, co k tomu potřebuje. Viz následující příklad:

* mysqldump blokuje aplikace (protože zámky)
* Na to někdo vymyslí geniální řešení: tak to replikuj a dumpuj slave
* Super, tak se to replikuje a dumpuje slave, slave se rozbije a reakce je: tvoje chyba měl jsi kontrolovat konzistenci.

JAK? Tím že zastavím klienty na masteru a udělám dump? :-D

Takže abych se vyhnul downtime při zálohování, tak udělám downtime při kontrole replikace. Jako fakt super řešení by the mysql way... A přesně těchto pastí je to plné a lidem okolo to vůbec nevadí. Takže sorry, ale této věci svoje data fakt nedám. ;-)

103

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 10. 02. 2015, 16:14:40 »

No to podle me akorat znamena, ze mas blbe nastaveny binlog-format, nemas zadnej monitoring logu (hlasky "Statement may not be safe to log in statement format") a downtime Ti nedela problem. Nevychvaluju MySQL, ale neprijde mi to jako jeho chyba.

Ano, to že to JÁ mám blbě nastavené už jsem slyšel. Víte, problém je jinde. U MySQL všichni berou jako normální, že se o tu mysql musíte starat, neustále kontrolovat konzistenci, neustále něco řešit a když to neděláte, je to VÁŠ

104

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 10. 02. 2015, 16:12:32 »

a k druhé části mého dotazu... jaký filesystem byste doporučovali ?
předpokládám, že v mém případě to je jedno, nicméně jaký je váš názor na volbu ?

Ext3/4, XFS, BTRFS. Prostě si vyber to, co znáš, co umíš otestovat / opravit a s čím máš zkušeností. U této minimální zátěže je to fakt jedno, takže neřešit. U větší zátěže je možné všechny fs nastavit s ohledem na počty souborů a vybrat v testu ten nejlepší.

105

Server / Re:Postfix - mailbox nebo maildir?

« kdy: 10. 02. 2015, 15:52:39 »

Je to asi jako zalohovat MySQL kopirovanim souboru s tabulkama z masteru misto master-slave-mysqldump.

Jo jasně. A potom zjistíte, že ten dump je nekonzistentní, protože replikace se uráčila replikovat by the mysql way a ne s ohledem na konzistenci dat a budete víte kde. Pokud už někdo musí používat tuhle .... věc, tak je lepší to občas vypnout a odzálohovat ty soubory (nebo alespoň zabránit přístupu klientům a udělat pořádný dump, který ta db za běhu taky neumí).