reklama

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 - Miroslav Šilhavý

Stran: [1] 2 3 ... 115
1
Software / Re:Nvidia driver vyžaduje Intel driver
« kdy: 17. 03. 2019, 19:59:36 »
spis nestracej cas doporucovanim nekomu W10 kdyz pise ze chce W7, clovek kdo si dava W7 vi proc je chce, nepovazuje je za mrtve... to ze W10 jsou "moderni/zive/aktualni/blabla" je sice hezke, ale kdyz by vyrobce meho jidla zacal prodavat zabalene l3jno taky by me nezajimalo ze je moderni a c00l ;-)

Ze ZAJDANOVA popisu to vypadá, že to není z jeho hlavy, jaký OS tam bude. V tom případě by si měl takové problémy vyžrat ten, kdo takto rozhoduje. Druhou alternativou je koupit model (třeba repasovaný), který má podporu Windows 7. Lámat to mezi sebou je prostě nevděčná práce.

Poměrně solidní alternativou pro případy, kdy je potřeba zachovat kompatibilitu a provozovat starší OS, je spustit současný OS a starší virtualizovat. Je to druhé straghtforward řešení.

Roubovat ovladače bych se snažil až naposledy a po pečlivém zvážení, že neexituje inteligentnější volba.

2
/dev/null / Re:Riesenie nerealistickych scenarov
« kdy: 17. 03. 2019, 18:11:34 »
Zhodnotíte rizika, náklady a pak stanovíte, co se řeší anebo ne. Testování aplikací typicky řeší právě různé méně pravděpodobné scénáře. Takže ano, do určité míry to řeší doufám každý.

Podle toho. Pokud je sestavený tým, tak se to obvykle řeší. Pokud je to malý projekt o jendom, dvou vývojářích, tak to bývá slabota. Testováním hledají chyby ve vlastní práci (a jejich opravu jim často nikdo nezaplatí), navíc trpí profesionální slepotou.

Prvotní je vždy mít dobře vytrénované vývojáře, kteří dodržují štábní kulturu a chybám předcházejí. Druhotné je mít rozpočet a sílu na testování - běžně testování a opravy chyb ztrojnásobí cenu projektu oproti tomu, když se na to kašle.

3
/dev/null / Re:Riesenie nerealistickych scenarov
« kdy: 17. 03. 2019, 17:50:32 »
Podle toho, co máte na mysli. Pokud se sestavují testy (scénáře), je nejdůležitejší prací navrhnou je správně, aby se otestovaly hraniční situace. Mnoho situací, které si myslíte, že jsou nerealistické, mohou za rok klidně nastat. Proto se staví "atomová elektrárna", aby systém nespadl např. paralelních přístupech, nebo na přetečení číselných řad atd. atd.

Setkal jsem se s případem shopu, který neměl práci v transakci. Číslo z číselné řady si vzal v jednu chvíli, ale datum zaznamenával až při uložení dokladu. A samozřejmě, v praxi se stalo, že vznikl doklad, který měl číselnou řadu z roku 2017, ale datum z roku 2018.

Pak nad tím systémem byla sada exportů do dalších systémů. A ty exporty programoval pokaždé někdo jiný. Jeden programátor vycházel z číselné řady, druhý z data na dokladu. Exporty se samozřejmě rozjely, protože v jednom exportu doklad byl (byl vzat ještě do roku 2017 podle číselné řad) a v druhém už nebyl, protože ten pracoval podle data.

Tím chci říct, že vymýšlet krajní situace není žádná atomová elektrárna, ale měli bychom se snaži to tak dělat vždy.

4
Software / Re:Nvidia driver vyžaduje Intel driver
« kdy: 17. 03. 2019, 17:42:14 »
ovladače z webu Aceru na tento konkrétní model jsou jen na Windows 8 a 10,ale mi tam dali 7...chceme je tam.

Tady je podle mě zásadní chyba vůbec ztrácet čas nad nepodporovanou konfigurací. Zejména laciní výrobci laptopů (Acer nevyjímaje) někdy dělají to, že upravují u hardwaru VID a PID, aby na ně nešly instalovat generické ovladače. Někdy mi přišlo, že je to jen primitivní naschválismus, jindy to byla reakce na bugy v hardwaru. Výrobce něco špatně navrhne, pak na to vymyslí přiohnutý ovladač (který chybu narovná), ale už by nebylo bezopečné, aby se chytaly generické ovladače.

Ovladače z Windows 8 často jde nainstalovat i na Windows 7. Někdy, pokud to nechce projít instalátorem, dají se instalační EXE / MSI rozbalit (např. 7zipem) a z nich vzít pouze INF a SYS soubory a ty nainstalovat bez instalátoru. Třeba tím nebudou dostupné všechny funkce, ale aspoň systém bude umět ovládat zařízení (např. powermanagement).

Ale jak už jsem psal, neztrácel bych tím čas a už vůbec ne s operačním systémem, který je dnes už mrtev.

5
Software / Re:Nvidia driver vyžaduje Intel driver
« kdy: 17. 03. 2019, 07:56:25 »
Ano, s touto úrovní znalostí můžu doporučit tři cesty:
a) pokud je na ntb recovery procedura na natažení předinstalace výrobce, využijte ji,
b) pokud není, stáhněte z Aceru všechny ovladače pro konkrétní model a nainstalujte je (intel ovladači se začíná),
c) pokud není k dispozici ani to, tak to dejte udělat někomu, kdo to zná, protože popsat všechny nuance správné instalace by bylo na velmi dlouho.

Ad c) Bývá zvykem nejprve instalovat ovladače čipsetu. Intel má na své stránce autodetekci, ale ta u straších modelů běžně nefunguje (nechtějí podporovat staré modely). Jako první se instaluje čipset, pak ovladač řadiče disků (ten může být v režimu SATA, RST, RSTe, RAID) - a je to o to komplikovanější, že tatáž technologie mění v čase jméno. Takže ovladač, který v době zakoupení notebooku měl nějaké označení, jeho nová verze se už může jmenovat jinak (nebo můžete použít starší verzi, ale proč?). Případně se doinstalovávají drobnosti typu řadiče USB a pod. (Např. pokud to má USB3).

Pak se instaluje ovladač zvukové karty.

Teprve pak ovladač grafiky (HDMI přenáší i zvuk, proto se instaluje až poté).

To je ale jen ve velmi, velmi hrubých rysech, abyste to vůbec rozběhal. Pokud chcete udělat opravdu dobrou instalaci, je to mnohdy složitější. Instalují se ovladače na kde co, např. na čtečky paměťových karet, aby měly správné ikony a skrývaly se, když není karta zasunuta, ovladače webcamu, myši (trackpadu), ...

Pokud chcete udělat instalaci dobrou, pak se z webu výrobce a ze správce zařízení sesbírají informace o jednotlivých kokponentách, ale ovladače se stáhnou přímo z webu jednotlivých dodavatelů komponent. Já doporučuji většinu obslužných programů neinstalovat, instalovat jen čisté drivery (nastavení pak řeší Windows, a ne nějaká aplikace třetí strany, která se po pár service packcích rozpadne).

Mnohem dál by Vás posunuly Windows 10, které mají velkou část ovladačů instalovanou přes Windows Update a opravdu v aktuálních verzích.

6
Sítě / Re:Shorewall 5.x a alias veřejné IP
« kdy: 13. 03. 2019, 15:11:29 »
Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.
Máte pro takové doporučení nějaké zdůvodnění? Případně vysvětlení, co by to v tomto konkrétním případě řešilo?

Má to několik pozitivních dopadů. Maska na druhotných IP stejného subnetu víceméně nedává smysl. První definice nastaví interface routu, která už při dalších IP adresách není potřeba nastavovat. (Např. na broadcasty bude vždy odpovídat ta prvotní IP adresa, takže i z tohoto důvodu je maska zbytečná). Linux si s tímto sice umí poradit, ale proč spoléhat na automagii, když se to dá nastavit správně?

Dalším důvodem je prevence chyb administrátora. Kdyby v důsledku nějaké chyby vyrušil primární IP adresu, tak s maskou /32 nenaskočí na její místo; většinou je vhodnější, aby systém přestal odpovídat, než aby z ničeho nic fungoval nepředpokladatelně.

Posledním důvodem je, že můžete mít kombinaci X adres na stejném interface, ale z různých subnetů, např.:

192.168.0.1/24
192.168.0.2/24
10.0.0.1/24
10.0.0.2/24

Všechny současné OS spolehlivě dosadí tu první ip adresu jako primární. Ta bude odpovídat na broadcasty, z ní budou defaultovat nová spojení. Ale co v případě subnetu 10.0.0.0/24? Tam jsou obě adresy v rovnocenné pozici a nelze spoléhat na to, že každá distribuce (a ostatně i každá verze jádra) upřednostní 10.0.0.1. Řešením proto je:

192.168.0.1/24
192.168.0.1/32
10.0.0.1/24
10.0.0.2/32

Tím dáte systému jasně na srozuměnou, které adresy jsou hlavní.

BTW i na FreeBSD funguje nastavení masek i pro sekundární IP adresy, ale nedoporučuje se to. V Linuxu toto není nikde moc zdokumentované, spíš se předpokládá, že admin rozumí obecné síťařině.

7
Sítě / Re:Shorewall 5.x a alias veřejné IP
« kdy: 12. 03. 2019, 22:04:21 »
Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Řešení Vašeho problému je SNAT - musíte si nastavit pravidla, za jakou adresu se jaké spojení schová.
MASQUERADE vybere tu první (hlavní) adresu na interfacu.

8
Sítě / Re:Zkušenosti se síťovými PowerLine adaptéry
« kdy: 11. 03. 2019, 08:00:59 »
Moje zkušenost je taky podobná. Někdy to jede svkěle, pak to zlobí a vypadává. Určitě to není řešení, na které se dá dokonale spoléhat. Tam, kde není jiná možnost, je to fajn.

Stejnou zkušenost mám s TP-Linkem i se Zyxelem.

Pokud je aspoň trochu reálná možnost natáhnout ethernet (a jen se Vám třeba nechce kvůli jendoduchosti), tak neváhejte, a natáhněte ethernet.

9
Odkladiště / Re:Email a Článek 13
« kdy: 07. 03. 2019, 22:36:34 »
Takovéto obavy vznikají, když laik začne číst právní normy. Zejména je průšvih, když je čte někdo technicky zaměřený - protože takový člověk chce každou větu podrobovat výrazové logice :).

Každá právní norma se vykládá v kontextu účelu, pro který vznikla. Samozřejmě je nemyslitelné aby zmíněná odpovědnost platila pro e-maily, už jen protože podléhají listovnímu tajemství. Pokud jdou dva právní předpisy do kolize, poměřuje se, který zájem je hoden většího chránění. Naprosto bez pochyb není účelem zavádět cenzuru soukromé pošty a bez pochyby je soukromí pošty chráněnější zájem. Účelem zmíněného návrhu je, aby se poskytovatelé systematicky nezříkali odpovědnosti s odůvodněním, že obsah nahrál uživatel. Je spousta služeb, které toho vysloveně zneužívají - např. ulozto.cz. Po zavedení nové normy bude na poskytovateli, aby prokázal, že zavedl přiměřená opatření a že vynakládá očekavatelné úsilí na to, aby nešířil a zejména znovu nešířil nelegální obsah.

Pak je zde měřítko přiměřenosti. Pokud někdo zneužije blog Sboru dobrovolných hasičů v Horní dolní k šíření závadného obsahu, lze očekávat, že hasiči nebudou vůbec popotahováni, a kdyby ano, že to stejně soud smete ze stolu. Pokud ovšem bude docházet k opakovaným incidentům, a hasiči nepodniknou žádný krok k nápravě, mohli by být odpovědni. Proti tomu takový Facebook, Google, ... nese odpovědnost plnou, protože práce s uživatelským obsahem je alfa a omega jejich podnikání. V jejich případě lze naopal očekávat, že soudy budou nalézat vysokou míru odpovědnosti, protože kdo jiný by měl umět vynakládat požadované úsilí, než tyto firmy.

10
Co chcete konkrétnějšího? StartSSL byl potrestán za porušení pravidel. Nikdo se ale nezabýval, že to porušení bylo ve skutečnosti dost okrajové.

Pravidla pro vydávání certifikátu = chráněný zájem.
Pravidla jsou dost volná (jak jste sám upozornil) = chráněný zájem není moc "chráněný".
Porušení StartSSL bylo víceméně formálního charakteru, protože ve faktické rovině do chráněného zájmu moc nezasáhlo.

Jinými slovy, StartSSL do té doby vydalo snad miliony certifikátů, včetně OV, ke kterým odváděli poměrně solidní práci (ověřovali totožnost, delegaci k úkonu, ...). Místo toho bylo ale (víceméně politicky) rozhodnuto, že mají zmizet. Zmizelé místo pak fakticky zaujal nejvíc Let's Ecnrypt, kterému, jako mnoha jiným, stačí k vydání DV certifikátu opravdu málo.

Tedy: mnohé certifikační autority sice formálně plní pravidla na 100 %, ale ve faktické rovině se snaží, aby urvaly co největší podíl trhu a laťku jen snižují.

11
Psal jste, že vás nezajímá, jak by to mělo být, ale zajímá vás současná realita. Takže jistě máte odkaz na průběžně aktualizovaný seznam e-mailových schránek, které si firmy musí pohlídat. Podělíte se o ten odkaz?

To právě neexistuje. Proto je pro firmy (a např. vládu USA) daleko zajímavější spolupracovat s jednou certifikační autoritou, ať už s ní existuje dohoda či ne, a mít tuto cestu pohlídanou.

V minulosti jsem se dost podivoval, proč se rozjela honba proti StartSSL, které sice porušilo zvyklosti ve vystavování certifikátů, ale ve skutečnosti to mělo daleko menší dopad, než uvolnění kriterií pro DV certifikáty.

Dnes je v podstatě na certifikační autoritě, kterému e-mailu bude věřit, že je dostatečný pro autorizaci požadavku. Bohužel, v marasmu, který dnes platí, nedá se očekávat, že by někdo někomu sebral důvěryhodnost kvůli špatnému vydávání DV certifikátů.

12
Já myslím, že jsem ve skutečnosti uváděl na pravou míru to, jak reálně certifikační autority validují vlastnictví domény. Nereálné představy, jak si teoreticky ohlídáte všechny e-maily, přes které je možné validovat doménu, jste tu psal vy.

No a jsme na začátku: DV certifikát je bezcenný: nic nezaručuje, jen si prostě "zašifrujeme" (co tedy "certifikuje", heh?). OV certifikát nedává smysl - není viditelný rozdíl od DV certifikátu, aspoň z pohledu koncového uživatele ne. EV certifikáty lidi taktéž nevnímají. Kdyby měla banka jeden den EV certifikát a druhý den jen DV, dovolím si tvrdit, že jen nepatrný zlomeček zákazníků by se obrátil na banku, jestli je to v pořádku.

Celý účel certifikátů, aby byly jen od toho že "jen budeme šifrovat" je uhozený. K tomu, abychom jen šifrovali, nepotřebujeme certifikovat. Pokud něco slovo "certifikace" znamená, tak to, že je někým ověřená nějaká skutečnost. U EV certifikátů je toho celý seznam, u OV certifikátů se ověřuje totožnost subjektu (a osoby, která jej zastupuje). U DV certifikátů je účelem ověřit, že se dostal do ruky toho, kdo má právo k doméně.

A jsme u toho, co to znamená "právo k doméně". Pokud to vyložíme extenzivně, můžeme dojít k tomu, že by se měl vystavit certifikát komukoliv kdo má na doméně e-mail.  ...Takže hledáme méně extenzivní způsob, jak ověřovat oprávněnost osoby a její spojitost s doménou.

Teď jde jen o to, jestli už dnes nejdeme moc vstříc tomu, aby DV certifikát získal kde kdo, třeba jen v důsledku chyby nějakého nastavení, nebo v důsledku toho, že už ve firmách nelze pohlídat přístup k e-mailům. Kdyby to nešlo uhlídat, jak píšete, lítaly by tu miliony certifikátů @seznam.cz, @gmail.com a dalších. Tyto firmy si naopak musí pohlídat všechny e-maily, přes které je možné certifikát získat.

13
ACME je rozšiřitelný protokol, vy píšete jen o variantě ověřování http-01. Já tuhle metodu používám k ověření dvou certifikátů, u kterých nemám přístup do DNS. Ve všech ostatních případech používám dns-01. Nemyslím si, že by si měl web server nebo poštovní server sám zařizovat certifikát – jejich správce má vytvořit privátní klíč a vygenerovat žádost a na konci nanejvýš stáhnout nový certifikát. Ale samotné vystavení certifikátu má zařizovat někdo jiný.

Navazoval jsem na Vaši poznámku o lokaci .well-known, takže ano, mluvím jen o http-01.

V praxi právě o certifikáty žádají samotné servery. Touto cestou jde doba a toto usnadnění je nezakrývaným záměrem LE. Opět, v praxi, těžko tomu kdo platí (zákazník, management) vysvětlíte, proč chcete certifikát řešit se správcem a s jasnou hodinovou dotací, když má každý pocit, že to může být zadarmo a samo.

Myslím, že příliš mluvíte o tom, jak by to mělo být, ale málo vnímáte, jak to ve skutečnosti je.

14
To samé v bledě modrém je s validací přes HTTP – díky Bohu za .well-known adresář, konečně je jasné, k jaké cestě nemá mít přístup žádný CMS ani nic podobného a má být výhradně pod správou administrátora serveru. Teď ještě aby se všechny CA do tohoto adresáře co nejrychleji přesunuly.

Podívejte se, jak vypadají ACME klienti v praxi. Velká část z nich definuje .well-known jako globální alias na webserveru a pro všechny virtualweby do stejného místa. Bohužel, lidská lenost je nekonečná a i možná dobře zamýšlený záměr dostane vždy v praxi přes kalhoty.

Druhým případem, kdy naopak .well-known nedostačuje je situace, kdy HTTPS provoz ochytává perverzní proxy, ale ostatní porty předává dál - např. mailserveru. Pak musíte řešit buďto distribuci certifikátu na jiný stroj, nebo nějakými (dost nesymslnými a nesystematickými) pravidly umožnit, aby .well-known byl nastaven jen jako "try", a v případě neúspěchu naopak předán dál na další stroj (aby i on si mohl získat certifikát).

ACME zdaleka není tak růžové. Má i svá proti.

15
V čem přesně je rozdíl, jestli připustíte vystavení certifikátu od DigiCertu, Let's Encrypt, GlobalSign nebo Buypass?

V tom, že mi admin, s přístupem na proxy server nemůže nechat vygenerovat certifikát jen ověřením ACME. U jmenovaných to bude muset být minimálně jedna z osob uvedených jako kontakt v registru domén (což už si opět dokážu jednodušeji pohlídat).

Stran: [1] 2 3 ... 115

reklama