Příspěvky

721

Hardware / Re:DYI Plicní ventilátor

« kdy: 07. 04. 2020, 19:17:33 »

Nevím, jestli už to někdo výše nepsal, ale ČVUT dalo zdarma k dispozici návrh plicního ventilátoru a už se snad podnikají i kroky k produkci: https://ventilation.fbmi.cvut.cz/

722

Server / Re:Restart určité služby, když je RAM využita na 90%

« kdy: 07. 04. 2020, 15:24:34 »

Jste zoufalý? Tak tady je skript pro zoufalce (13 let stary, ale bude fungovat i ted):

Aneb jak udělat z velkého problému ještě větší

723

Server / Re:web proxy a atlassian apache mod_rewrite

« kdy: 07. 04. 2020, 14:00:47 »

Podle mě to není řešitelné, aby se Jiře dynamicky měnila base.
Reverzní proxy se nastavuje na pevno v server.xml: https://confluence.atlassian.com/kb/proxying-atlassian-server-applications-with-apache-http-server-mod_proxy_http-806032611.html

724

Server / Re:Restart určité služby, když je RAM využita na 90%

« kdy: 06. 04. 2020, 12:44:13 »

Efektivně toto uděláte blbě, protože nejprve si musíte říct, co to vlastně znamená "RAM využita na 90 %", protože typy využití se liší.

Pokud jde o nějakou službu, která sežere RAM, asi by se to mělo řešit jejími limity a o svoje zdraví by se měla postarat sama. Externě (nad službou) to nebude fungovat dobře, to je milionkrát ověřeno v praxi.

725

Software / Re:Firefox neprojde přes HTTPS login MikroTiku

« kdy: 06. 04. 2020, 11:11:02 »

Pokud nejsi ochotný věnovat čas učení, požádej někoho kdo se tím živí.

Pan kolega se právě učí, netřeba ho stírat.

Firefox by měl hlásit kód chyby, z něj se dá vyjít. Může to být např.:
SSL_ERROR_NO_CYPHER_OVERLAP
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

Z hlavy mě napadá, jestli nemůže mít certifikát na routeru špatný datum. Pokud neměl router nastavený správně čas, může být certifikát exspirovaný nebo naopak v budoucnosti.

726

Studium a uplatnění / Re:SQL - literatura

« kdy: 05. 04. 2020, 20:48:44 »

celé se to dá vysvětlit za hodinu (...) K základům patří umět spojovat tabulky a používat agregační funkce.

Naprosto souhlasím, vstoupit do vod SQL je opravdu jednoduché.
Co je složitější, je umět tvořit komplikovanější dotazy. Chce píli, trénink a fištróna. S tím knížky nepomohou, jedině praxe.

Programátorům radím jedno pravidlo: pokud vytáhnete data ze SQL (SELECT), něco s nimi provedete v aplikaci a vrátíte do SQL jiná data (INSERT, UPDATE), v 95 % případů lze tu samou operaci jednodušeji, spolehlivěji a rychleji napsat pomocí SQL příkazu.

727

Odkladiště / Re:Falešní majitelé domény

« kdy: 04. 04. 2020, 21:25:22 »

Přečti si podmínky registrace domén https://www.nic.cz/files/documents/20180525_Pravidla_registrace_CZ_final.pdf, najdi si bod 16.1.2 a pak po jeho přečtení prostě pošli teplej bonz na cz.nic.

16.1. Sdružení CZ.NIC je oprávněno dle svého uvážení zrušit registraci Jména domény, pokud

A to je právě to, že v praxi se do toho nehrnou, rizik je příliš mnoho.

728

Odkladiště / Re:Falešní majitelé domény

« kdy: 02. 04. 2020, 12:32:45 »

v minulosti se to řešilo, nevím jak je to dnes. Kontakt na podporu je tu, https://www.nic.cz/page/357/, měl jsem dojem, že drobná kriminalita českých internetových subjektů je řešená a řešitelná.

Nějaké menší možnosti mají. Např. zablokovat (dočasně) doménu, pokud porušuje pravidla. Nebo, samozřejmě, na příkaz soudu. (Nevím, jestli mohou konat i na základě nějakého předběžného opatření). Ale každopádně se do toho moc nehrnou, to už musí být opravdu závažné případy, kdy hrozí škody z prodlení. Nějaké spamy tak závažné nejsou.

729

Odkladiště / Re:Falešní majitelé domény

« kdy: 02. 04. 2020, 11:48:31 »

V podstatě nijak. CZ.NIC nemá žádný nástroj, kterým by na 100% mohl zjistit, že majitel je falešný. Obdobně domény drží i firmy, které už jsou zlikvidovány a vymazány z OR. Nebylo by ani možné, aby něco konal. Popíšu modelové situace:

1. Majitel zemřel (před léty) - tj. dnes je to neexistující osoba. Doména může být předmětem dědického řízení a případných následných sporů.
2. Majitel změnil jméno (ze zákonných důvodů).
3. Majitel je cizinec (třeba i s českým jménem) a jen žije na neznámém místě v ČR (přesto existuje).

CZ.NIC nemůže nijak odlišit, jestli je osoba smyšlená, nebo nastala některá z jiných možných situací. Kdyby něco konal a udělal by chybu (např. zrušil doménu), byl by CZ.NIC odpovědný za vzniklou škodu.

Proto CZ.NIC nic nekoná.

730

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 01. 04. 2020, 18:05:47 »

Ale k otazke zo zaciatku tohoto vlakna: tak trochu som predpokladal, ze to dopadne presne ako to dopadlo. Ani jeden clovek tu nenapisal, ze si preveril aspon jednu OSS aplikaciu a s kludnym svedomim moze spavat:) - jasne, ked je spravne nakonfigurovany firewall, riziko je blizke nule ale minimalne podla tohoto vlakna zistujem, ze pocit bezpecia z OSS (typu "musi to byt bezpecne, ved je to OSS a urcite sa niekto nasiel, kto ten kod overil") je len fatamorgana - aj ked pocet citatelov vlakna asi nebude dostatocna reprezentativna vzorka.

Fata morgana . Moje zjištění v této oblasti je, že existuje víc typů příznivců OSS. Jedni mají na OSS střízlivý náhled. Chápou jeho výhody a vidí i nevýhody. Ti dost často sahají i ke komerčním produktům, protože si spočítají, že někde se vyplatí víc. Pak jsou druzí, kteří v komerčním SW vidí zkázu lidstva a raději budou vždy podporovat OSS před ním. Takový přístup je taky v pořádku, jen někdy mi vadí, že mám pocit, že to platí někdo jiný - např. zaměstnavatel. A třetí skupina jsou laikové, či začátečníci, kteří se čistě pocitově přikloní k OSS - neb jeho ideje vypadají v magazínech vzletně. Do toho se přidávají další dva fenomény: zkratkovité rozhodnutí "je to zdarma" = "je to levnější" a taky to, že o komerčním SW se tolik nepíše (není proč o něm psát a nebudí takové kontroverze).

Moje zkušenost je, že když spočítáte TCO u komečního SW a u OSS, tak velmi často vyjde líp komerční SW. Výjimek není mnoho, ale existují. Např. Apache web server, Nginx, Tomcat, některé distribuce Linuxu a FreeBSD, které jsou už tak masově používané, že jejich správa a zabezpečení je reálná relativně levně. (Najde se jich samozřejmě víc, to jen pro příklad).

Docker je kapitola sama pro sebe. Je to koncept, který od počátku popřel po dekády budovaný bezpečnostní koncept. Distribuce intenzivně řeší bezpečnost, (zmíněné) projekty taky. A pak přijde nějaký jouda, zabalí to do kontejneru a masy to začnou používat v produkci. Když přijde na otázku bezpečnosti, tak se většinou neřeší, protože se zjistí, že veškerá výhoda Dockeru je fuč, pokud se má udržovat aktuální a bezpečný.

A děravý firewall? Nojo, to se samozřejmě děje, dokonce některé "díry" jsou by design, např. při použití NATU a aplikačních helperů. Vysvětlujte ale lidem, že (jeden) firewall != bezpečnostní řešení.

731

Odkladiště / Re:Bezpečnosť Dockeru, KeePass a OSS obecne

« kdy: 01. 04. 2020, 15:36:47 »

urcite si rozumieme. Ja tu neriesim pripad komunikcie "odpovode na pozadavek z venku". stale sa bavime o desktope a nie serveri, ktory je na internete. tam by samozrejme tomcat nebezal napriamo ale za apachom, kdezto na devel stanici na to nevidim dovod (ak odhliadnem od testovania) z pohladu bezpecnosti. ta "nebezpecna aplikacia" je bindovana iba na localhost, takze z vonku nedostupna.

Na devel stanici bych udělal něco hodně podobného.
1. Firewall output => reject (kvůli timeoutům je to vhodnější než drop)
2. Firewall output user=[můj pracovní účet] => accept (osobně bych preferoval i pro svého usera proxy)
3. Aplikaci povolit přístup ven jen přes (dopřednou) proxy (a toto bych měl i na produkci)

732

Sítě / Re:Reklamace WiFi routeru

« kdy: 31. 03. 2020, 20:56:01 »

Pokud tedy vydá router s již známou zranitelností, jedná se o výrobní vadu. A tedy tato zranitelnost umožňuje aby router, napaden útočníkem, přestal fungovat, tedy plnit svoji funkci. Tak ten router musí být reklamovatelný.

Ano, přesně tak.

Následně se však ještě hodnotí, o jak velkou vadu se jedná. Některé vady nelze opravit, ale nejsou ani nijak závažné - např. kdy se čas od času zaseklo admin rozhraní. Na tuto možnost pamatuje OZ, aby reklamace nebyly výrazně nepřiměřené ve prospěch spotřebitele. Jako příklad lze uvést automobil, kterému nebude svítit jedna čtecí lampička v interiéru (a nepůjde nijak opravit). V tu chvíli nemá kupující nárok na vrácení kupní ceny auta, ale jen na slevu na přiměřenou slevu.

733

Sítě / Re:Reklamace WiFi routeru

« kdy: 31. 03. 2020, 19:44:51 »

Musím mít prvně v ruce konkétní vadu/chybu, která způsobí problém a žádat její odstranění.

Dokonce ta vada se musí v praxi projevovat. Navíc výrobce nenese odpovědnost za "vady", o kterých v době prodeje nemohl vědět. Např. za neznámé bezpečnostní chyby. Taková záruka by už byla předmětem nějaké služby, nikoliv odpovědnost výrobce za zboží.

Domácí router není bezpečnostní zařízení. Jeho hlavním účelem je směrovat provoz, firewall je jen přidružená funkcionalita. Pokud se najde chyba v něm, v praxi se projevuje, a výrobce o ní mohl / měl vědět už v době prodeje, tak je za ni odpovědný. Nicméně, hlavní funkce zařízení dál pracuje správně, takže na místě by bylo posoudit jaká je intenzita chyby vzhledem k celku, a jestli vůbec, nebo na jaký nárok na slevu pak zakládá.

Obdobně je to např. s doživotní zárukou aktualizací (např. map v navigacích). Výrobce má v tu chvíli povinnost dát Vám aktualizace zdarma, pokud nějaké vyrobí. Ale už se s touto zárukou nezavazuje, že bude nějaké vůbec vyrábět. Když budou, máte je zdarma. Když nebudou, máte smůlu, slovo dodržel.

734

Sítě / Re:Reklamace WiFi routeru

« kdy: 31. 03. 2020, 18:39:24 »

Add placený support, ani placený suppoort v řádech MKč/ročně neznamená, že mám vyhráno nebo budou opraveny chyby, co najdu a reklamuji, pokud na ni neupozorní i někdo větší, kdo platí support v ještě větších řádech (přesněji od té big US company mimo záznam bylo zmíněno, dokud to nebude reklamovat minimálně i Ruská národní banka). Dneska se už tomu musím jen smát....

Jenže v korporacích nejde o skutečnou efektivitu, ale hmatatelný důkaz, že jsem pro to udělal maximum. Pokud selže renomovaný dodavatel, jen se pokrčí rameny. Když selže (a třeba i méně) vlastní vývoj, je z toho velký problém.

Dotaz pana tazatele byl na záruky, a ty zkrátka nejsou. V "malém" segmentu je důležitější obecná zkušenost, než certifikace.

735

Sítě / Re:Mikrotik - NAT Log

« kdy: 31. 03. 2020, 17:28:21 »

Nejde o chybu.
Pokud chcete vidět in/out pohromadě, odlogujte si to na forwardu.