Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Hardware / Re:Šifrování disku a poruchy na 54TB oddílu
« Poslední příspěvek od Michal Šmucr kdy Dnes v 12:12:33 »
Kdyz pominu hodne zmrvenych FW, ktere dokazali leaknout heslo, tak nikde neni garance, ze tam vyrobce nema nejaky master heslo - protoze ten SED disk je v podstate to same jako LUKS key management, jen se nevi zda to uklada bezpecne, a zda to nema backdoor. Takze tomu SED blackboxu taky neverim.

Ano taky těmhle otevřeným variantám věřím víc, ale podobné riziko máš u blackboxu resp. uzavřeného firmware/OS vždycky. A můžeš tomu dát různou prioritu při rozhodování o konkrétním technickém řešení.
Za sebe bych řekl, že dost záleží na tom jestli si to děláš jen v malém víceméně pro sebe. Nebo jestli jde o nějakou větší organizaci, kde prostě s nějakou delegovanou důvěrou třeba v dodavatele po nějakém zvážení počítáš. Obecně ty systémy můžou být mnohem komplexnější, stejně tak rozhodovací kritéria, v provozu se pohybuje mnohem víc lidí atp.

Další věc pak je, že i kvůli tomu budeš spíš řešit nastavení celého systému a jak sladit tyhle technické prostředky (kde důvěřuješ dodavatelům) s těmi lidskými "soft" věcmi a postupy okolo. Protože je mnohem pravděpodobnější, že ti ta kritická data leaknou lidi. Ať už úmyslně nebo třeba kvůli šlendriánu, než že bude mít Mosad/CIA nebo i nějaký čičmunda tajný master key např. od Seagate.
A to už se vůbec nebavím o klasice :)

2
Server / Re:Jak řešíte emaily pro lidi ve firmách?
« Poslední příspěvek od František Ryšánek kdy Dnes v 11:38:34 »
BTW je docela řehole a čím dál víc známka punku, provozovat si svůj mailserver on premises na svém vlastním hardwaru. Zároveň je velká pohoda, když máte vlastní barák a dost místa v serverovně (třeba protože nesídlíte v Praze), takže neřešíte, jestli server zabere 1U nebo 4U, a nic Vás netlačí do vysokých GHz a velké spotřeby...
Ale ono popravdě i 1U někde v kvalitním venkovském telehousu může být velmi v pohodě cenově i "prostorově" pro provoz svého mailserveru.

Takže ohledně mailů neřešíte, jestli mailbox konkrétního jednotlivce zabere na disku 2 GB nebo 100 GB. Prostě jednou za čas vyměníte nebo přidáte disky. Zvolíte si IMAP démona a storage back-end takový, aby neměl sklon se zhroutit do sebe, aby škáloval přiměřeně velikosti firmy a dal se gramotně zálohovat...

A je asi čím dál větší vzácnost mít zaměstnavatele, který tuhle Vaši činnost ocení. A asi těžko si to obhájíte jako jedinou náplň práce :-(
3
Hardware / Re:Šifrování disku a poruchy na 54TB oddílu
« Poslední příspěvek od Michal Šmucr kdy Dnes v 11:25:49 »
... proto se musí tahle metadata zálohovat (při každé změně klíče).
Pokud mas zalohovany data tak proc?

Mam 4x full hdd luks (bez partysen) a nad tim btrfs v R5.

Protože jsem zmiňoval obecné charakteristiky LUKS a případných chyb hardwaru pod ním. Měl jsem pocit, že se i na tohle tazatel ptal.
A ano to je pravda, prakticky pokud máš kompletní zálohu dat, a při případném problému ten celý LUKS oddíl vytvoříš komplet znovu, klíče - neklíče, a data vrátíš ze zálohy, tak to samozřejmě nemusíš řešit.

Podobně pak v tom režimu, jako máš ty nebo RDa. Tzn. s RAIDem nad šifrovanými disky a situaci, kdy jeden z nich odejde.

I když mimo šifrování, osobně bych se spíš snažil vyhnout té jedné paritě (R5, RAIDZ1).

Citace
...umožní kombinovat šifrovaná i nešifrovaná data...
Jenze presne tohle ti veskery sifrovani rozbiji. Nikdy se ti nepovede zajistit garance toho, ze ta data co sifrovat chces taky sifrovana budou.

Teď úplně netuším jak jsi to myslel a proč by to mělo rozbíjet veškeré šifrování. Můžeš mít třeba větší sdílené úložiště a  dedikuješ jeho část pro šifrovaná data. Například uděláš zmíněný dataset, který vysdílíš a připojí si ho konkrétní klienti na jednom oddělení. Podobně pak můžeš mít šifrovaná data jen pro konkrétní virtuální servery.

Logicky je i tohle jen jeden z nástrojů pro zabezpečení, který je zaměřený jen na určitý druh možného úniku dat. Pro ty ostatní (např. to kde a jak budou šifrované i zálohy, jak budou zabezpečené klíče, jak budou delegovány pravomoce a zodpovědnosti jednotlivých osob, jak bude zaškolená obsluha, co se dá zabezpečit technicky a co už ne, všechna možná "co se stane, když") je mnohem komplexnější věc, kde máš pak modelování bezpečnostních hrozeb, analýzy všech těch faktorů atp.

Citace
A sifrovani disku bych neveril uz vubec. Tohle se nabizi uz roky, stejne jako ti pak vyrobce za par tisic Ecek nabizi, ze ten disk odemkne, kdyz se nemuzes dostat k datum ...

Zas zmínil jsem to jako jednu z možností, která má stoprocentně své klady i zápory.
To že ti to vendor na požádání a za pár tisíc EUR dešifruje bez klíče se mi zdá jako blbost, kdy by byli úplně sami proti sobě.
Ano byly určitě jednotlivé nalezené zranitelnosti, které se potencionálně daly využít třeba nějakými firmami, co se specializují na obnovu atp.
Pamatuju si třeba sedm let zpátky průšvih, který postihoval většinou ty základní řady SSD.
https://www.kb.cert.org/vuls/id/395981/
Každopádně je to vždy o nějaké elementární důvěře/nedůvěře k hw/sw vendorovi příp. certifikačním organizacím (FIPS), což platí pokaždé, když to nejsi schopen sám ověřit (já určitě ne :)).
Rozhodně si nemyslím, že je tahle SED technologie automaticky passé a jsou situace, kdy to může být rozumné nasadit, např. abys prošel nějakou celkovou certifikací, ale to si každý musí vyhodnotit sám.
Jinak pro určitou základní orientaci ohledně modulů s FIPS se jde mrknout i třeba na databázi NISTu.
https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules
4
Server / Re:ACME DNS challenge nevystaví certifikát
« Poslední příspěvek od Filip Jirsák kdy Dnes v 11:21:58 »
Obavam se, ze tohle ti bude spolehlive fungovat pouze a vyhradne v pripade, ze mas vlastni dns. Par vyjimek asi bude, ale i pokud pouzivas nejaky api, tak to ze ten zaznam zapises do nej neznamena, ze se v nejakym svepravnym case vystavi.
Já t oběžně používám, mimo jiné i s ClouDNS, a funguje to. Není důvod, proč by to nefungovalo – poskytovatel DNS obvykle má nějaký časový limit, do kterého záznamy vystaví. A TTL záznamů si obvykle nastavujete sám. A životnost DNS výzvy v ACME je podle mne několik dnů, takže rezerva je tam dostatečná.

Dalsi vec je ta, ze dost provozovatelu dnsek ti domenu namiri na nejaky svuj parkovaci web ... a pro ten si sami vystavujou cert, coz ti to muze rozbit taky.
ClouDNS vám do DNS sám žádné záznamy negeneruje. A i kdyby ano a vystavoval by pro to certifikát, těch TXT záznamů tam může být víc.
5
Server / Re:Jak řešíte emaily pro lidi ve firmách?
« Poslední příspěvek od František Ryšánek kdy Dnes v 11:20:29 »
Tak v DS ti taky vsechno smaznou po 3 mesicich zejo ... at chces nebo ne. Nejaka smlouva, stavebni povoleni, soudni rozhodnuti ... nac bys to jako potreboval.

V my bubline se obcas resi, co si kdo s kym mailoval pred 5+ lety.

Občas mě zahřeje u srdíčka, když se podívám do historie emailů, o čem jsem se kdy bavil s konkrétním člověkem/zákazníkem, nebo jestli jsem už někdy řešil konkrétní produkt / problém / téma... A je psina odpovědět na e-mail ve stylu "jasně, vy jste u nás před 15 lety koupil toto, takže s tím teď máte následující problém" nebo "ano Vás znám z téhle firmy, a řešili jsme spolu tohle... mezitím se technologie posunula a teď umíme tohle..." a je zajímavé pozorovat, jak se ti lidičkové většinou nemění, je na ně spoleh :-)
6
Server / Re:Žije OpenVZ? Má budoucnost?
« Poslední příspěvek od Jose D kdy Dnes v 11:00:26 »
Když se koukneš sem, https://download.openvz.org/kernel/, tak z těch verzí kernelu mám skoro nostalgický pocit, chci říci, 2.6.32 je z doby EL6, a my tu máme za dveřmi EL10.
7
Modifikace dotazu bez myši:
Citace: jauznevimco
shift+pravej klik.
Jde to plnohodnotné menu (shift - pravý klik) nějak provést jen s použitím klávesnice (aniž bych furt opakovaně musel lovit položku Více)? Ihned, bez prodlevy. (Pokud sem ještě nepřidal to zaklínadlo do registru)

bývalo zvykem, že kontextové menu šlo udělat přes shift F10, ale tušo probem, že Shift+Shift+F10 neprojde. Ledaže by by byl pravý a levý shift, ale to bych musel si nechat prodloužit prsty...
Lshift+Rshift+F10 nefunguje, ale pokud z klávesnice ještě někdo nevydloubl tu „kontextovou“ klávesu (tzv. „hamburger v boxu“ neboli ☰ ve čtverečku), co bývá na normálních klávesnicích mezi pravým AltGr a Ctrl, tak Shift+tahle klávesa dělá přesně to, co je požadováno. Na notebookách nebývá, no :-/ .
8
Bazar / Re:Darujem rôzne SCSI a HBA radiče
« Poslední příspěvek od František Ryšánek kdy Dnes v 10:35:11 »
hmmmm.... měl jsem svého času jako domácí počítač 486DX2/50 se serverovým motherboardem a EISA. Byly v tom asi 3 EISA karty vč. SCSI řadiče od Adaptecu. Dneska by to byl jednoznačně muzeální exponát... ale kdo to má skladovat. Šel do šrotu asi před 20 lety.

Ten Mylex DAC960 je podle mého košer HW RAID.

Jestli se mi po něčem nestejská, tak je to paralelní SCSI a jeho vakly v konektorech a kabelech, které se v průběhu let stárnutím materiálu postupně množily.
9
Distribuce / Re:Distribuce pro PC bez monitoru
« Poslední příspěvek od fanoush kdy Dnes v 10:30:20 »
pokud nepripojis tak se vyresetuje na nejaky 27" 4K LCD takze na LCD 24" FHD mam pak fialovej obraz ;-)
Mozna je to ten samy problem co jsem mel ja viz vyse? vic info o tehle vlastnosti
https://gist.github.com/RLovelett/171c374be1ad4f14eb22fe4e271b7eeb
10
Distribuce / Re:Distribuce pro PC bez monitoru
« Poslední příspěvek od František Ryšánek kdy Dnes v 10:25:18 »
Vnutit linuxovému kernelu (jeho Direct Rendering subsystému) aby držel konkrétní video port zapnutý, a dokonce v konkrétním rozlišení, lze poměrně triviálně argumentem video= na kernel command line, jak už psal @k3dAR. Akorát pořizovat lokální klon EDIDu mi přijde jako kanón na vrabce a potenciálně "more rope to hang yourself with", pokud si třeba pořídíte jinou televizi apod. Tento hodnotící soud je ale dost nejednoznačný, ještě se k tomu vrátím na konci.

Zmíněnému argumentu video= se dá nacpat prostě jenom žádané rozlišení a snímková obnovovací frekvence.

video=HDMI-A-2:1920x1080@50D

Řetězec HDMI-A-2 je jméno výstupního portu. V dnešním PC jich bývá na výběr víc. XWindows používá mírně jiná jména než linuxový kernel (DRM). Pro použití v kernel command line mohu např. doporučit, jednou na začátku při zprovozňování konfigurace přidat na kernel command line zaklínadlo drm.debug=0xe , a pak se podívat v dmesg, jaké výstupy si DRM subsystém sám automaticky našel a jak jim říká. A zvolený pak použít v zaklínadle video= .

50 za zavináčem znamená 50 Hz. Není přítomno "i", takže neprokládaných. A poslední písmenko D znamená "výstup natvrdo zapnout, ignorovat detekci připojeného monitoru a jet digitálně" (asi protože DVI-A umí alternativně analog VGA). Varianta od k3dARa má na konci "e", což znamená prakticky totéž = natvrdo zapnout výstup (a funguje i na analog VGA).

K tomu dokumentace: https://www.kernel.org/doc/Documentation/fb/modedb.txt

Následně XWindows mají svoji vlastní databázi režimů a režim z kernelu nepřevezmou. A dá se nacpat modeline do xorg.conf. Což je asi nakonec užitečné. Ona totiž geometrie videorežimu není jednoznačně daná rozlišením - a u full HD a UHD existují např. nuance mezi "počítačovým" videorežimem dle CVT a "Consumer Electronics" variantou téhož rozlišení... televize bude patrně preferovat CE režim. Použití "počítačové" CVT varianty videorežimu (nebo nějaké vlastní tvorby) může mít všelijaké důsledky. Třeba mně se občas cukalo přehrávání videa - asi jsem přesně netrefil pixel clock. Později jsem vygooglil modeline, která funguje bez cukání. Nebo (teoreticky) pokud tohle televize rozliší, mohla by na CE režim nasadit jinou sadu "vylepšovacích" filtrů, než na CVT režim (scale + crop, zvýraznění hran, zvýšení saturace barev). Zde bych zaslepil případnou odbočku na téma, "jak zabránit televizi ve vylepšování obrazu na vstupu od počítače".

Obecně mechanika videorežimu nechává autorovi v jistých mezích volnou ruku, kolik řádek a sloupců ponechá na "temné místo" a jakou přesně frekvenci použije na základní pixel clock. Typické geometrie CVT vs. CE (nebo třeba starobylé GTF) jsou jenom konkrétní standardní "souřadnice" v tom nepříliš jasně ohraničeném prostoru přípustných kombinací... Ve velmi obecné rovině "co je správně a co už je za čárou" posuzuje každý monitor či televize podle svého a výrobce zobrazovacího zařízení nemá podrobnosti nikde dokumentovány...

V této souvislosti, pokud Vám tahle bezbřehá svoboda nevyhovuje, tak použijte postup, který popsal @k3dAR: zazálohujte si EDID, který kernel koupil od Vaší reálné televize, a prostě ho vnuťte při bootu natvrdo ze souboru. Tohle by se mělo televizi přesně líbit. Taky by ten EDID s trochou štěstí mohly z kernelu zdědit Xwindows.
Nebo si vygooglete standardní CE modeline pro žádané televizní rozlišení - to by teoreticky mělo chutnat kterékoli televizi. Nebo zřejmě by se aktuální modeline měla dát i zjistit za jízdy (xrandr nebo tak něco).

Deníček z mých vlastních pokusů před pár lety: https://frr.g6.cz/htpc/htpc.htm#k-cmd

Řešil jsem tehdy, že počítače tíhnou spíš k 60Hz refreshi, což je cca soudělné s americkou TV normou NTSC, kdežto u nás PAL má tradičně 50i, tzn. pro přehrávání televize dává o měličko lepší smysl 50 Hz (i neprokládaných). Je mimochodem zábavné, že většina historického materiálu u nás je zaznamenána v PAL@50i, ale rozhodlo se, že HD streamy v rámci DVB-T2 budou u nás vysílány v 1080@50p. Přitom mnoho zemí a satelitních HD kanálů vysílá 1080@50i, a v době přechodu na T2 mnohé starší full HD televize 50p neuměly, resp. tuto schopnost neoznamovaly ve svých EDID - takže když člověk připojil STB, tak on převáděl 1080p zpátky na 1080i, aby ho mohl poslat televizi... Navazuje nekonečná debata o algoritmech správného deinterlacingu, kompenzaci pohybu, závěrky atd.

Reálně nejen v internetech, ale i v některých televizních pořadech (!) potkáte materiál, který byl někde cestou od kamery skrz záznam a prodej / předání do studia lajdácky konvertován mezi nesoudělnými snímkovými kmitočty a už mu nejde pomoct (cuká ale nezabere na něj IVTC apod.) A dnešní ploché televizní přijímače zcela rutinně materiál ve formátu 1920x1080 o pár procent natáhnou a oříznou, což je zvyk zděděný z dřívějších analogových dob, kdy těsně na hraně temného místa bylo přenášeno pár bajtů nějakých metadat, a bez ořezu se to vrtělo na prvním viditelném řádku nebo tak něco... takže tomu zcela zbytečnému ořezu jdou dnešní vysílací pracoviště "naproti" tím, že materiál předem o pár procent smrští, aby na obrazovku hezky pasoval... takže přesné rozlišení 1920x1080 nikdy nedosáhnete, obraz je naschvál mírně mázlý, aby ty několikanásobné nesoudělné konverze nebyly vidět... A televizní přijímače už poměrně dlouho umí všelijaké vylepšovače typu "inference ostrého rozlišení z pomalu se pohybující scény" (takže občas z té mazanice na okamžik "vyskočí obraz jako břitva") nebo TV interně umí poslat na stínítko násobek Hertzů co má materiál, a aby to vůbec k něčemu bylo, tak televize umí i nádherně interpolovat pohyb, takže se pak starý filmový materiál pohybuje jak čerstvý záznam z televizního studia nejmodernější technikou apod.
Stran: [1] 2 3 ... 10