Příspěvky

91

Odkladiště / Re:Odpočet DPH z auta

« kdy: 05. 08. 2021, 14:52:55 »

Adolf: Tak asi dostali na FÚ faktury za toaleťák a nelíbila se jim cena a nemuseli nikam chodit. :-)
U nás například vloni v rámci kontroly kontrolovali jak se zachází s náklady na kávu (české sro se sídlem v okresním městě kde chcípl pes, cca 60 lidí, 3 pobočky, 4 kávovary, obrat v řádu nějaká stovka MKč). S tím, že pokud náklady na kafe překročí nějakou hranici, tak budou chtít, že to má jít zaměstancům do příjmu. Účetní skákala radostí do vzduchu, že by měla evidovat počet kafí vydaných obchodním partnerům a kolik zaměstnancům a počítat z toho průměrný počet kafí na zaměstnaneckou hlavu. :-)

92

Odkladiště / Re:Odpočet DPH z auta

« kdy: 05. 08. 2021, 13:15:05 »

tralala5: Sorry, zaspal jsi cca 15 let postupné realizace. Informaci o tom, zda auto s danou RZ a kdy překročilo státní hranici je dostupná už tak 10 let (i finančáku). Za poslední 2 roky dosti pokročila realizace a zahušťování systému JSDI (jednotný systém dopravních informací). Z toho jde velmi slušně vytahat, kdy, kde jaká RZ byla. A až se i obtočí obměňovací kolečko místních info radarů o funkci rozpoznávání RZ a NB-IoT, tak pokud nebudeš opravdu jezdit jen kolem svého komína, tak z toho můžou jít "vybraným složkám státní moci" moc hezké sestavy. Veřejnost z toho aspoň má informace o průjezdnosti/rychlosti/zácpách jednotlivých úseků silnic.
Ano, můžeme být rádi, že finančáci do toho obvykle moc nerejpou, dokud je člověk něčím moc nenasere.

93

Sítě / Re:Bouře a ethernet

« kdy: 26. 07. 2021, 17:15:53 »

Tak si je třeba uvědomit, že primárná příčinou nemusí být přepětí naindukované v tom Ethernet kabelu, ale přepětová špička, co dorazila domů přes rozvod elektriky, přes to se to dokáže šířit lépe a na větší vzdálenosti. Pokud tomu pak ještě pomůžu tím, že mám vtipně/blbej souběh rozvodu elektriky a Ethernetu, tak tím hůře (v takovém případě nemusí pomoci ani napájecí zásuvka/pes s přepěťovou ochranou, protože se mi to naindukuje přes ten souběh vedení). A pokud mám doma třífáz, každá část sítě je napájena z jiné fáze a přepětí přiběhne po jedné fázi, a to pak může být dost na odpálení něčeho citlivějšího.
Ty jednoduché přepěťové ochrany na Ethernet neublíží, mohou dost věci pochytat. Pokud mám stíněné Ethernet kabely, co jdou ven, tak bych je držel dál od těch, co mám uvnitř a všechny co nejdál od napájení. Pořešil bych na straně toho switche pospojování FTP zemí kabeláže a přitažení na zem domu. Toto dokáže ochránit před naidukovaným přepětím. Teprve v dalším kole za to mohu řešit přepěťovku pro Ethernet třeba i formu patch panelu, několik modulů vedle sebe na DIN lištu nebo APC dělalo přepěťoky na 4 porty a z nich jít do switche (to chrání před tím, co přijde po vnitřních vodičích) a teprve odtud jít do switche. Případně nějaký ten pes s přepěťovkou na napájení, co stojí také rozumný peníz.

94

Server / Re:Housing minerů

« kdy: 13. 07. 2021, 22:56:32 »

Vyloženě housing minerů nabízelo TPC v Písku, ale dle stavu toho jejich webu kryptohosting.cz to spíše vypadá, že řeší otázky Policie ohledně nějakých dotací a kam zmizelo 200 MKč. A pak vlastně i v Písku byl cryptohousing.cz což byla nějaká výhodně pořízená rozpadající se fabrika i s tlustou levnou elekrickou přípojkou. Ale také si nejsem jist, zda provozovatel spíše neřeší nějaké "dodatečné dotační otázky" za pár set MKč. :-(

95

Sítě / Re:Provoz přes VPN na Mikrotik

« kdy: 13. 07. 2021, 22:39:03 »

Jenže on má chata/wan segment 192.168.1.0/24 a doma/lan má také 192.168.1.0/24. Což na chatě komplikuje routování, zda má jít provoz do VPN nebo do WAN.
Nastavit to na Mikrotiku jde (pomocí VRF), ale pokud nemám pistoli u hlavy, tak bych řešil přeadresování buď doma/lan nebo té chata/wan (to je nějaký LTE router nebo co, snad ani garážoví trotlové už ve svých CGNAT sítích nepoužívájí 192.168...), protože ta konfigurace bude výrazně jendodušší, zvláště pokud nejsem v sítích moc kován....

96

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 24. 06. 2021, 17:00:08 »

A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).

Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.

Ano, když je dat málo, cpu vše do jedné DB, co mám rád/umím. Když jich je hodně, tak víc různých řešení. K tomu tam byl zmíněn ten Ignite jako možnost, jak to řešit - to mi dovolí mít data v různých databázích a mít k nim jednotný přístup a klidně naráz můžu přistupovat pomocí NoSQL key/value interface nebo pomocí SQL ke stejným datům, ať to v pozadí je SQL nebo NoSQL. V podstatě s trochou víc násilí jde udělat to, že do ignite pošlu "select cas,a,b,c,d from ... where ..." a zpět dostanu tabulku, kde sloupec A je vytažen z PostgreSQL, sloupec B je z InfluxDB, sloupec C vyčten z binárních souborů uložených v přílohách v CouchDB a sloupec D jsou data z Cassandry (ale až takový slepenec bych nechtěl mít na krku :-) ). A pokud do toho pošlu set/insert/update, tak to skrz Ignite doteče do těch cílových DB a Ignite si drží cache nejpoužívanějších dat v RAM pro urychlení přístupu.

Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?

Jde, používáme, že do PgSQL mlátíme přes jsonb sloupce a i ukládáme časové řady, částečně přes array. Jde to dělat, ale čistý Postgres používat jako timeseries není úplně ono (jak to přeleze pár set giga řádků), to chce asi TimescaleDB nadstavbu (ta půjde do testu).  Používáme pro timeseries i InfluxDB historicky, ale nějak se krabatí čelo nad některými změnami v 2.x.
U PgSQL vidím jako problém u nás spíše v tom, že to nemá úplně nejjendodušší řešení pro clustering už i jen těch možností pro master-slave HA setup je požehnaně, pokud si člověk třeba zvykl na multimaster u Cassandy nebo CouchDB. :-(

97

Vývoj / Re:Rada při návrhu db tabulek

« kdy: 22. 06. 2021, 21:58:29 »

A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)

98

Sítě / Re:IPv6 v klientské síti

« kdy: 17. 06. 2021, 13:35:53 »

Tak ono půjde o to, co umí ten switch, blokovat komunikaci mezi klienty můžete na něm, pokud to umí nějak rozumně nastavit až na L3 vrstvu. A slušné switche už umí poznat, jaké adresy si přidělil klient a pak dle toho filtrovat/reportovat (v podstatě právě sledují tu komunikaci na link local adresách a poznají sekvenci, co klient má dělat při stanovení si a přidělení si adresy).

K tomu DNS, minimálně Windows klienti si umí aktualizovat DNS záznam v DNS na AD.

99

Sítě / Re:ipv6 a klientske site

« kdy: 17. 06. 2021, 12:45:20 »

ad 2) Aby si klient nepřidělil globální IPv6 adresu dle SLAAC, tak to musí ohlašovat správně router, že chcete  jen managed konfiguraci (aka stavové DHCPv6) a vedle toho nesmí ohlašovat prefixy jako Autonomous. Pokud má ohlašovaný prefix nastaven flag autonomous, tak ho klient použije pro přidělení IPv6 pomocí autokonfigurace (takže router musí ohlašovat použití managed konfigurace a zároveň žádný ohlašovaný prefix nemí mít flag autonomous, pak se klient bude konfigurovat jen pomocí stavového DHCPv6, pokud to podporuje).
U IPv6 musí být funkční link local adresy, bez nich nefunguje řada mechanismů v tom protokolu.

100

Sítě / Re:Napadený Mikrotik (klientská jednotka) ISP

« kdy: 17. 06. 2021, 07:56:42 »

V podstatě, pokud nemám IPv6 balíček aktivován a ten router bude fungovat i jako bridge, tak mohou přes bridge IPv6 (a jiné pakety) procházet. Pokud budu mít IPv6 modul nahozne a všude bude dropování i na L2,  tak ho to odstřelí. Ale pokud chci už tak poctivě to řešit, tak mám samozřejmě aplikovaný L2 firewall, který vysloveně propouští jen pakety s IPv4 a vše ostatní dropuje, aby si někdo nechtěl přes mé zařízení zkoušet posílat jakýkoliv jiný obskurní protokol. :-)

101

Sítě / Re:Existuje ethernetový kábel s vypínačom?

« kdy: 17. 06. 2021, 07:50:48 »

RDa: Tak ono je třeba také zvážit škody z případného neoprávněného odepření služby, že se to bezpečnostní zařízení porouchá. I ten aku s přepínači chcípne, tak když to chcípne tak, že to neumožní oprávněný  přenos, tak to bude nějaká škoda a jde o posouzení, co víc bude bolet.
Kdysi jsme podobně řešili napájení nějakého specifického měřícího zařízení, co mělo 3 akumulátory, z jednoho to jelo, druhý se dobíjel a třetí byl horká záloha, kde se relátkově přepínaly akumulátory z pozic pracovní/záložní/dobíjené a dlouhodobě to byl dost porod. :-(
Dají se dneska sehnat i programovatelné časové relé, co mají dle "atom norem" certifikace pro zařízení třídy A / BT1 (komponenta, která když selže, tak to bude příčinou vzniku jaderné havárie), takového bych se nebál v té fabrice použít.
Chápu, že u výrobní linky je to problém, když se to posere, tak dohledáš, co se stalo. U atomky mám výhodu, že když se to opravdu posere hodně, tak nikdo 100+ let se nepůjde podívat, zda to relátko ne/seplo, to už budu mrtvej a budu mít klid. :-)
Ano, používají se "pasivní systémy" bezpečnosti, kde se dá dokázat funkčnost - např. zjedodušeně, mám bazén vody nad reaktorem, rupne trubka u hlavního cirkulačního čerpadla, tím pádem klesne v reaktoru tlak a pokud v té chvíli někdo nepředělá gravitační zákony, tak voda pro nouzové chlazení poteče z bazénu celkem spolehlivě, u IT světa k takovým věcem se bude muset teprve postupně dospět...

102

Sítě / Re:Existuje ethernetový kábel s vypínačom?

« kdy: 16. 06. 2021, 23:52:19 »

Já bych to ještě vylepšil o PANIC BUTTON, krásný červený fyzický čudlík, který když uživatel zmáčkne, tak se připojí na tu baterku 230V a zařízení se vypaří 

Vidíš, někde to červené tlačíko usilovně budují. :-(
Takový SI (směnový inženýr) v Dukovanech/Temelíně měl pravomoc a dneska už i bude mít konečně své "červené tlačítko", aby při pocitu/náznaku od podpůrných systémů, že se něco děje špatně a má to vztah k IT komunikacím, tak při jeho aktivaci dojde k úplnému odpojení od řídícího systému všech podružných komunikací a systémů, co nejsou nezbytně nutné minimum pro bezpečný provoz/odstavení/udržení na výkonu. A pak se bude dodatečně zkoumat, že se se jen blbě vyspal nebo se doopravdy něco dělo. :-)

103

Sítě / Re:Napadený Mikrotik (klientská jednotka) ISP

« kdy: 11. 06. 2021, 21:39:04 »

Ale proč se divíš tomu ISP, že to měl na háku? Papírově ten stav byl na 99% tak, že to byla z pohledu světa tvoje chyba, že tam je zavirovaná krabice. Problém neměl ISP, ale ty.
Ptal jsem se tě, kde je předávací rozhranní mezi sítí ISP a tebou. Chápu, že jde o bezdrátvého ISP, který ti zapůjčil bezdrátový router, ten ti dal na barák ty jsi si za něj dal další vlastní. Celá pointa je v tom, zda předávací rozhranní je bezdrátový signál, pak je ten wifi router koncové zařízení veřejné sítě, které je provozováno již na tvoji odpovědnost (i když je fakticky zapůjčeno a na dálku spravováno daným ISP) - ty neseš odpovědnost za to, že je to v pořádku a jen jen na tobě, jak máš nastavenu podrobně smlouvu s ISP (nebo jakýmkoliv jiným subjektem), že se ti o něj má dobře starat. Pokud je to takto a štoural ses do toho, tak ty nápady o nějakém zasahování do veřejné telko sítě jsou liché. Pokud je předávací rozhranní až za tím bezdrátovým routerem - na kabelu mezi ním a tvým routerem, tak ta krabička je ještě součástí veřejné sítě operátora a zasahováí do ní i z dobré vůle je v rozporu se zákonem. A vtipné je, že i v takovém případě je ISPík relativně z obliga, legislativa je nastavena tak, že je dost omezena jeho odpovědnost za to, co dělá jeho síť, pokud to neudělal úmyslně nebo hrubě neporušil svoje povinnosti, což bude třeba nějak dokázat. Takže opět je relativně v klidu, pokud to není jak doložit a mlčíš. Takže takhle je vidět, že ISPíkovi to netrhalo žíly, neměl důvod se vzrušovat, dokud mu síť nějak funguje. :-(
Samozřejmě je v takovém případě nejlepší odchod jinam a doufat, že jinde to bude lepší...

104

Sítě / Re:IPv6 + firewall a identifikace klientů

« kdy: 10. 06. 2021, 22:09:25 »

Pokud byste chtěl IP adresu řešit v pravidlech také, tak se nabízí pevné přiřazení, nebo DHCPv6. Pro filtrování provozu směrem ven to ale není moc účelné. Kdokoliv sedící u interního zařízení může IP adresu podvrhnout (narozdíl od VLAN, kterou 802.1X pohlídá). Takže takové zabezpečení je poměrně k prdu, spíš bych to nenazýval zabezpečením, jako spíš jakousi nevynutitelnou sanitizací provozu.

Tak slušnější switch nemá problém hlídat i tu IP adresu. V podstatě 802.1x ověří klienta, tím se zamče jeho MAC adresa, proběhne DHCP a switch se naučí, jakou adresu klient dostal a hlídá, aby si ji samovolně nezměnil (nebo je statikcá přidělené IP k portu nebo ji switch dostane v Radius datech). Novější kusy to umí v určité míře řešit i pro IPv6. Pak na routeru mohu v klidu filtrovat dle IP adres, pokud je cesta od switche k routeru důvěryhodná (kd eúplně nneí, nastupuje MACsec vázaný na 802.1x).
Ale to jsem už asi dost mimo SOHO segment...

105

Sítě / Re:IPv6 + firewall a identifikace klientů

« kdy: 10. 06. 2021, 22:03:05 »

Mikrotikem

Takže vlastně k ničemu, když potřebuji komunikovat s NAS bez přístupu do internetu připojeným pomocí 2.5 GbE do sítě a počítačem s interní (vlastní) 2.5 GbE a Wi-Fi 6, které opět jede o něco málo rychleji než 2.5 GbE, protože to prostě neuroutuji.

Navíc bych měl velký, složitý a hnusný paskvil.

Jestli není lepší stávající stav, v laciné krabičce na DHCP nastavíš rezervace a ve firewallu nastavíš, jestli daná adresa může nebo nemůže na internetu.

Nu, 2,5 Gbps LAN je stále trochu mimo běžné SOHO. Ale pokud mám na 2,5 Gbps, tak ten switch bude mít aspoň jeden 10 Gbps SFP+ uplink a budu mít i 4 kKč třeba na Mikrotika RB4011 a ten ti s rozumným firewallem to uroutuje s prstem v nose.
A pokud je ten switch slušnější, tak možná vše co potřebuješ se dá udělat v něm a bude ti také filtrovat na wire speed a nemusíš ho ani prznit VLANama na víc podsítí, pokud nechceš...
A pak stále máš tu možnost, že pokud věřím MAC adrese, tak filtrovat dle ni a síť v LAN nechat switchovat divoce a volně.