Příspěvky

136

Vývoj / Re:Existuje limit pro funkci CONCAT?

« kdy: 29. 09. 2014, 11:43:20 »

Popravdě řečeno to nebyl až tak zbytečný dotaz. Minimálně já jsem rád že po 10+ letech uživatelského používání Linuxu dokážu zkopírovat z MC texty, to jsem dříve nevěděl (nenapadlo mě googlit a myslel jsem spíše že to nejde - což byla očividně hloupost). Obdobně i k tomu kódu byly nějaké užitečné poznámky.

A přitom je to přímo v manuálu mc:

Mouse Support

...

If you are running the Midnight Commander with the mouse support, you can get the default mouse behavior (cutting and pasting text) by holding down the Shift key.

137

Server / Re:OpenVZ - jak to funguje?

« kdy: 29. 09. 2014, 11:27:13 »

- Jsou jakoby přímo namountované, jsou „vidět“. U plné virtualizace se ten disk musí nejdřív namountovat. Nemyslím si ale, že by ten jeden příkaz mount dělal nějaký rozdíl v bezpečnosti.

Příkaz mount v bezpečnosti rozdíl neudělá, ale pokud má virtuálka vlastní blokové zařízení (a na něm až oddíly a fs), tak si to blokové zařízení může šifrovat. Dělá se to. Při každém bootu potom admin zadá heslo ("lokálně" přes konzoli, nebo nějak vzdáleně přes boot time ssh).

138

Vývoj / Re:Existuje limit pro funkci CONCAT?

« kdy: 28. 09. 2014, 18:25:43 »

Mylis se, to co popisujes funguje pouze v terminalu, pokud otevres mc a pouzijes F4 a editujes nejaky soubor (primo v editoru mc), tak ta tvoje vychytavka nefunguje.
Kdyz se zeptam netere, ktera ma 3 roky, co mela k obedu, tak me neodpovi, ze venku sviti slunko. Bylo by fajn, kdyby si byl alespon na jeji urovni a kdyz se na neco zeptam, bud odpovedel na mou otazku nebo muj dotaz ignoroval...

Koukám, že kromě toho, že neumíte vybrat databázi, programovat, tak dokonce ani neumíte ovládat nástroje, pomocí kterých tvoříte. Z MC samozřejmě lze kopírovat věci pomocí myši. Jen se to (logicky) dělá nepatrně jinak, než pouhým označením myši a přetažením, protože mc je program napsaný v ncurses (a to už jsem napověděl víc, než jsem chtěl).

139

Server / Re:SSH a bezpečnost hesel

« kdy: 04. 09. 2014, 10:04:07 »

Hlavně je třeba si uvědomit, že přihlašování heslem a přihlašování pomocí klíčů jsou dva zcela odlišné mechanismy, které nelze moc srovnávat.

Zatímco při přihlašování heslem se posílá ono heslo po zabezpečeném kanále (který se před tím musí nějak pomocí DH vytvořit), předá se pam a to potom dle záznamu v shadow (nebo třeba ldapu) ono heslo (ne)přímo porovná (posolená hash - jak moc dobrá je ta funkce? není prolomená jako md5 nebo skoro prolomená sha1?), tak při přihlašování pomocí klíčů se nic neposílá, pouze si pomocí asymetrické kryptografie obě strany vymění klíč pro další symetricky šifrovanou komunikaci.

Tedy dost dobře nelze nahradit klíč heslem, byť by měl stejnou entropii, a myslet si, že je to totéž. Není. Otisk hesla musí být někde uložen v nějaké podobě a potom se s ním něco porovnává. Zatímco klíče patří ke kompletně jinému principu asymetrické kryptografie.

Nehledě na to, že 24 znakové heslo o dostatečné entropii (112b) si stejně asi nikdo nezapamatuje, tak silnější 4kb RSA klíč může mít třeba na čipovce (takže si nic pamatovat nemusí, maximálně 112b passfrázi).

140

Odkladiště / Re:Pravidla pro sdílení připojení do víc bytů

« kdy: 22. 08. 2014, 11:27:00 »

V § 115 občanského zákoníku je uveden definice domácnosti: Domácnost tvoří fyzické osoby, které spolu trvale žijí a společně uhrazují náklady na své potřeby.

Zajímavá definice  Podle této definice v jednom bytě může existovat několik domácností a stejně tak může být jedna domácnost v několika bytech.

141

Odkladiště / Re:Soukromí na internetu

« kdy: 08. 08. 2014, 10:31:40 »

No já nevím.
Já osobně bych byl rád, aby policajti byli schopni odposlouchávat (potenciální*) grázly, pokud jim to na základě závažného podezření povolí soud (nebo jak by přesně měl být ten postup).

*) Ano, tady je to možné riziko.

"Byl bych rád".

Ano. O tom to je. Problém je, že v praxi je to úplně jinak. V 90 letech se zaváděly kamery. Prý pro snížení kriminality. Kamery ve skutečnosti k žádnému snížení kriminality, ani dopadení pachatelů neslouží, jejich efektivita je mizivá a i dnes, v roce 2014 jsou snímky z kamer nepoužitelné k identifikaci čehokoliv (každý může mít v mobilu fullhd kameru, ale pro boj s kriminalitou se používá technika kvalitativně srovnatelná s filmem před 100 lety). O pachatele tedy nejde, jde jen o zisk z provozu těch systémů.

Odposlechy telefonů. Policie občas vydá zprávu o tom, kolik telefonů bylo odposloucháváno, ale už nevydá zprávu o tom, kolik pachatelů bylo skutečně soudem odsouzeno na základě těchto dat. Opět je to zanedbatelné procento (z toho co uniklo). Na co se to používá? Vydírání mezi podnikateli a politiky.

Špehování internetu. Opět, boj proti teroristům, bla bla bla. Ve skutečnosti se metadata o síťovém provozu používají výhradně na "boj proti internetovému pirátství". Tedy čistě soukromý zájem několika zahraničních majitelů způsobuje špehování veškeré komunikace všech lidí.

Nic z toho, co jsem napsal neslouží ke snížení kriminality, naopak to vždy slouží komerčnímu zájmu.

Takže já bych naopak byl velmi nerad, kdyby se do rukou policie dostal jakýkoliv další nástroj pro ochranu komerčního zájmu nějaké třetí strany.

142

Vývoj / Re:Staré zdrojáky - hříchy mládí

« kdy: 22. 07. 2014, 10:00:33 »

Ze to napsal clovek, ktery pred 6 lety mel takove sebevedomi, ze sve dilo zverejnil, i kdyz jeho znalosti prace s db v php byly temer nulove, to docela dost vypovida (pokud je tedy pravda to, co zde uvedli diskutujici).

Jednou jsem měl na pohovoru zájemce o zaměstnání (ing.), k diplomové práci psal program v PHP a MySQL (?!?!? - no ale to teď nechám stranou). Prostě LAMPa

Když jsme se ho ptali (protože se hlásil na místo technika), na takové věci, jak se MySQL instaluje, provozuje a zálohuje, nebyl schopen odpovědět. Stejně tak neznal vůbec žádný systém správy verzí. Nevěděl, jak se nastavuje Apache. Neveděl vlastně nic.

Přiznám se, že mi to leží v hlavně dodnes. Jak vůbec může takový člověk dostat akademický titul? Tohle běžně zvládají středoškoláci.

Takže to, že autor článku na zdrojáku neví nic o tématu článku by se tak nějak dalo pochopit. Co ale nelze pochopit vůbec je fakt, že mu ten článek někdo otiskl.

143

Hardware / Re:Formatování 4TB disku, nizká užitná hodnota

« kdy: 21. 07. 2014, 13:18:02 »

Nikoli, v IT se odjakziva pocita ve 2^X a to naprosto vse a vsude.

Ano, například v rychlostech sítí (100Mb/s ethernet za sekundu přenese 104857600 bitů), v taktovací frekvenci procesorů (16MHz procesor za sekundu vykoná 16777216 tiků) nebo při zpracování digitálních signálů (44,1kS/s nahrávka má každou sekundu 45158,4 samplu). Nesmíme zapomenout ani na to, že taková WiFi pracuje v pásmu 2,4 GHz, tedy 2576980400 Hertzů, a její vlnová délka tak není 125 mm, jak se mylně uvádí, nýbrž jenom 117 mm, což je mimochodem 117/1024 = 0.114 metru.

OT: když jsou rozměry diskety uváděny v centimetrech, přepočte se to na metry vynásobením 2^−(10*2/3)? Chápu správně, že k tomu potřebuju umět floaty?

+1

Koukám, žes byl rychlejší 

144

Hardware / Re:Formatování 4TB disku, nizká užitná hodnota

« kdy: 21. 07. 2014, 13:14:02 »

Nikoli, v IT se odjakziva pocita ve 2^X a to naprosto vse a vsude.

Není pravda, že se tak počítá vše. Přenosová rychlost se počítá v b a používají se standardní desítkové násobky. Velikost dat na disku se počítá v B a používají se dvojkové násobky.

Takže, když máme konstatní rychlost zápisu 1Mb/s a velikost zařízení je 200GB, jak dlouho bude trvat, než bude plné? A najednou se ti v tom vzorci začnou míchat M = 1000 000 a G = 1073741824, což je moc fajn, že. Už snad na základní škole se učí zkracování, takže G/M = k. Ehm. Bude to k mít hodnotu 1000 nebo 1024? Ani jedno, že. Bude mít hodnotu 1073.741824. Opravdu je moc fajn, že se takto počítá odjakživa. 

Na počátku to ještě bylo dobře. k bylo 1000 a K bylo 1024. To ještě šlo. Potom to ale nějaký pitomec rozšířil i na ostatní prefixy SI a na bordel bylo zaděláno.

Proto jediná možnost je dodržovat standardní desítkové násobky tak, jak jsou definovány už 200 let. Pokud IT potřebuje počítat jinak, musí si zavést vlastní prefixy. Což se stalo.

145

Hardware / Re:Formatování 4TB disku, nizká užitná hodnota

« kdy: 21. 07. 2014, 10:35:41 »

Ani, ne. 1 TB podle markeťáků je 1000^4.

Nikoliv podle markeťáků, ale podle standardu.

146

Sítě / Re: Jak správně uložit pravidla iptables

« kdy: 04. 07. 2014, 13:13:46 »

No dobrá. Nakonec jsem si vybral skript /sbin/SuSEfirewall2 a do něj jsem na konec vložil

Kód: [Vybrat]

iptables-restore < /sbin/mojepravidla

Funguje to dobře, tak to tak nechám. Jinak to štelování těch konfiguračních souborů je docela komplikované. Já potřebuju jenom jednoduše načíst při startu mojepravidla pomocí iptables-restore.

Ještě je dobré se zamyslel nad tím, co se stane, když nějaký update nahradí ten pozměněný soubor /sbin/SuSEfirewall2 za nový z updatovaného balíčku.

147

Distribuce / Re:budoucnost distribucí pro velké firmy

« kdy: 27. 06. 2014, 11:40:12 »

Zajímalo by mě, jak se větší firmy dívaji na roztříštěnost distribucí

Především je vhodné si uvědomit, že to, co se s hanlivým nádechem označuje jako roztříštěnost je ve skutečnost výber, možnost výběru, svoboda výběru. Ona roztříštěnost, vede k tomu, že je k disposici tolik svobodného software pro různé činnosti. Jinými slovy je to výhoda, nikoliv negativum.

Pokud to vezmu naopak, tak "neroztříštěnost" znamená, že není nic na výběr, je jen jedna možnost. Nelze si vybrat efektivnější způsob pro konkrétní nasazení. To je špatné a nejdražší řešení.

K tomu zbytku:

Nasazuje se většinou to, co je potřeba pro konkrétní nasazení. Servery se stejně konfigurují jinak než pracovní stanice a desktopy. Nemá smysl tam nasazovat to samé a přidělávat si práci tím, že se budou hledat workaroundy tak, aby ti lidé nebo ty servery mohly pracovat. Někde se hodí CentOS, někde se koupí RedHat, někde Debian a někde FreeBSD a někde třeba QNX. Všechno má své zlaté místo, kde je zrovna toto řešení nejefektivnější a nejlevnější.

Pokud chceš, existují i pokusy udělat centrální konfiguraci různých systémů. Já osobně je nemám rád, podle mě by admin měl vědět co dělá. Udělat puppet apply xxx umí každý debil. Ovšem, pokud se to porouchá, tak tento de... už bude v koncích. Stejně je ten admin potřeba.

Takže moje rada je, vykašli se na konkrétní distro a snaž se naučit používat všechna. Ve skutečnosti jsou ty rozdíly minimální. (V praci spravuji x set CentOSů, doma x jednotek debianů, nějak v tom nevidím rozdíl. On ten apache nebo postgres je prostě všude stejnej.)

148

Vývoj / Re:MySQL databáze nad 500 MB

« kdy: 14. 06. 2014, 21:21:30 »

ale insert s automatickym orezem urcite projde...

Jo jo, moc hezká vlastnost:

http://www.soom.cz/clanky/1145--SQL-Truncation-Attack-aneb-jak-hacknout-SOOMcz

149

Vývoj / Re:MySQL databáze nad 500 MB

« kdy: 13. 06. 2014, 12:10:11 »

To je ale implementace v PostgreSQL. Navíc i tam by v tomhle případě asi šlo bez problémů použít bytea. Tazatel ale píše o MySQL, kde jsou BLOBy normální datový typ.

Fajn, z rychlého přeletění dokumentace MySQL (5.5) to vypadá, že (long)blob je u mysql podobný typ jako bytea v psql. Potom tedy ano.

Mě MySQL nesmí do domu už nějakých pár let, takže tohle mi uniklo.

150

Vývoj / Re:MySQL databáze nad 500 MB

« kdy: 13. 06. 2014, 11:36:41 »

Proč by u BLOBů nešlo zajistit referenční integritu? Když budu mít v DB např. článek a u něj seznam obrázků, tak cizí klíč na ID obrázku a NOT NULL na BLOBu docela dobře zajistí, že obrázek odkazovaný z článku v databázi také mám. Pokud budu mít v DB jen cestu k souboru, nikde nemám zaručeno, že takový soubor na disku skutečně existuje.

O blobech více Tomáš Vondra: http://www.fuzzy.cz/cs/clanky/ukladani-souboru-do-postgresql-databaze/

Co na BLOBech není pěkného? Neexistuje referenční integrita - můžete klidně smazat BLOB který je stále odkazován z tabulky. Můžete sice vytvořit AFTER UPDATE a AFTER DELETE triggery pro odstranění osiřelých BLOBů, nebo můžete použít  "lo" contrib balíček. Každopádně žádné z těchto řešení nevynucuje referenční integritu takže vám nějaký blbeček klidně může umazat BLOBy přímo

Při vytvoření blobu máte pouze oid (číslo blobu) a funkce na práci s ním, které mají jako argument právě oid. To, že je někde v katalogu systémová tabulka pg_largeobject je sice hezké, ale vám to moc nepomůže (rozhodně by se nepokoušel dělat nějaké hacky s katalogem, to se při nejbližší příležitosti (například obnovení dumpu po havárii) vymstí).

Jak použitelné je to inkrementální zálohování u PostgreSQL? Výhoda zálohování dumpu databáze je v tom, že snadno vezmu jeden soubor a obnovím ho kdekoli jinde.

Psal jsem o tom článek (http://www.heronovo.cz/zalohovani-obnova-postgresql-metodou-pitr-point-time-recovery/). Ano, není to tak snadné jako udělat pg_dump, na druhou stranu, když se to nastaví, je možné provést obnovu k jakémukoliv času (point in time), pokud vím, že transakce v 9:00 rozmlátila DB (delete bez where apod), tak jsem shopen obnovit stav k 8:59 (případně přímo ke konkrétnímu číslu transakce, ale to se málokdy ví).

Dále, pokud je db velká, tak klasické dumpy ztrácejí na efektivitě. PostgreSQL, na rozdím od MySQL s MYISAM, při dumpu neblokuje provoz, db je normálně použitelná, ale pochopitelně to žere (nejen) diskový výkon. Klasické dumpy nelze moc dobře skladovat inkrementálně (malinkatá 10GB DB při každodenním dumpu za 1 měsíc sežere 300GB na zálohovacím stroji).

Každá věc má pro a proti a je na adminovi, aby to zvážil.