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 ... 116
1
Server / Re:Pokročilejší automatizovaná záloha
« kdy: 04. 04. 2019, 15:54:00 »
Ahoj, pouzivame klient server reseni, `Bacula` je to zdarma, opensource a super vcetne weboveho klikatka v novejsi verzi. Vyhodou je, ze nebastlis reseni na koleni, spolehlivy system zaloh, ktery je siroce konfigurovatelny, nevyhodou je trochu delsi nastaveni a nez tomu clovek zacne naplno rozumet a orientovat se.

Pokud zmiňujete Baculu, tak pak bych asi doporučil na jejího pokračovatele, Bareos (www.bareos.org).

Bohužel, jak Bacula, tak Bareos trpí spoustou neduhů a jedná se o zastaralý systém. Zejména chybí možnost deduplikace. Systém záloh na "volumes" odpovídá zálohování na pásky. Ten, kdo používá pásky a changer, to ocení; ti, kdo zálohují na disk, pro ně je to jen komplikace.

2
Naopak bych to nikde nehlásil. Toto je výhoda pro Vás.
Kdykoliv se Vám něco nebude hodit do krámu, napadnete před soudem systém jako takový a lehce prokážete, že nebyla zajištěna jeho bezpečnost.

3
Server / Re:Pokročilejší automatizovaná záloha
« kdy: 02. 04. 2019, 17:02:36 »
Velmi příjemně se pracuje s: https://borgbackup.readthedocs.io/en/stable/, ale vyžaduje to nainstalovanou podporu i na straně serveru (tj. nehodí se to pro neznámá úložiště bez další podpory).

Dříve jsem uvažoval i o: https://restic.net/.

Jejich srovnání: https://stickleback.dk/borg-or-restic/.

4
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.

5
/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.

6
/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.

7
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.

8
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.

9
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ě.

10
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.

11
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.

12
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.

13
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í.

14
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ů.

15
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.

Stran: [1] 2 3 ... 116

reklama