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

Stran: 1 ... 12 13 [14] 15 16 ... 22
196
Studium a uplatnění / Re:DevOps uplatnění v zahraničí
« kdy: 14. 01. 2021, 18:06:06 »
nehalem: Ono to bude dost o oboru. Řikal mi před časem známej fungující v drážním businessu, že u  drah jsou poslední rok trochu paranoidnější.... Remote i šlo, dokonce i remote od dodavatelů. Než se stala nepříjemnost s jedním devopsem, co se spletl a vysledkem byl generální stop trati na úrovni kraje, aspoň si ten digitál pořádně vyzkoušeli (v TV večer podáno, že Arriva zase blokuje tratě a nic nemůže jet, přitom jen vzorně stála na stopce). Od dalšího dne stop všem remote akcím, což hlavně nepotěšilo dodavatele. Prý aby jim bylo jasné, zda jsou u ostrého systému nebo si u sebe něco kutí na devel/test systému...
A přitom taková blbost, kamarád se také jako novic u dodavatele pro vodníky před roky sekl s jedním automatem a nebýt náhodou všímavého hrázného, co ten start nouzového vypouštění stopl, tak v Praze měli Staroměstkou lagunu a nikdo z toho nestřílel. Jen všichni kroutili hlavou, že by to vůbec nemělo jít odpálit a dneska se to už jede vše dálkově ze Štěchovic (pravda, dálkový přístup k tomu byl poslední rok pro všechny dost osekán). :-)
A vidím jen přitvrzování v tom, jak remote začíná vypadat zejména v oblastech, kde do toho začíná mluvit NÚKIB. Po 15-ti letech full remote začíná být těžko...

197
Server / Apache ZooKeeper a ACL dle x509?
« kdy: 10. 01. 2021, 10:09:05 »
Prosím, nemáte někdo v provozu Apache ZooKeeper a ideálně používáte ACL vázané na certifikát klienta? Marně se snažím přijít na to, jak vytvořit správně formátovaný ACL záznam, aby to ZK sežral a nevracel "milovanou" hlášku ZINVALIDACL = -114, /*!< Invalid ACL specified */
Nedaří se ručně pomocí zkCli:
Kód: [Vybrat]
setAcl /test/abc x509:CN=hostname,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown:crwdaa úplně stejně dopadnu, pokud to zkusím v kusu kódu v C:
Kód: [Vybrat]
        struct ACL ACLS[] = {
                {ZOO_PERM_ALL, {"auth", ""}},
                {ZOO_PERM_ALL, {"ip", "10.84.0.0/16"}},
                {ZOO_PERM_ALL, {"digest", "pokuston:wyEc72aaKNw9SXjCYLYECn9YWvg="}},
                {ZOO_PERM_ALL, {"x509", "CN=hostname,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"}},
                {ZOO_PERM_READ, {"world", "anyone"}}

        };
        struct ACL_vector ACL_VEC = {5, ACLS};

        if ((rc=zoo_create(zh,"/xyz","value", 5, &ACL_VEC, 0, b, sizeof(b)-1))!=ZOK) {
                fprintf(stderr, "zoo_create() failed... %d\n", rc);
                return 4;
        }
Legenda (tady dokumentace) říká, že u schématu x509 se použije "x509 uses the client X500 Principal as an ACL ID identity", ale nikde jsem nenašel funkční příklad. Jen pár zoufalců řešících, jak to zadat. Jednu zmínku, že zkCli je rozbitý a nejde to zadat, tak pokus nativně v C dopadne stejně ( https://mchesnavsky.tech/zookeeper-x509-certificates-acl/ ).
Klient se přihlásí, server si zaloguje, že automaticky vytvořil x509 identitu na základě certifikátu klienta (takže klient nemusí explicitně volat addauth), ale jak udělat ACL, kde je to použito... Pokud z logu okopíruju tu x509 identitu, tak to také nesežere volání pro nastavení ACL:
Kód: [Vybrat]
Authenticated Id '1.2.840.113549.1.9.1=#160c61646d696e407465732e6575,CN=klient,OU=I,O=FIRMA,L=Mesto,C=CZ' for Scheme 'x509'Použití schémat ip/digest/world funguje OK. Zkoušeno na ZK 3.5.6 a ověřen stejný výsledek na posledním 3.6.2.

198
Hardware / Re:NAS hardware pro cca 56TB (TrueNAS)
« kdy: 03. 01. 2021, 21:42:34 »
Tak ono to přání hasičů na to, že mají být servery a vše s nimi zavřené v racku také plyne z obvyklého napájení přes UPS. Protože při požáru dochází k vypínání přívodu elektriky do baráku (nebo jen u zasažených částí, při větším požáru se vypíná i vše v okolí) a výstupy UPS zůstanou pod napětím dále, což není úplně ono pro zdraví při hašení vodou. Takže to chtějí mít schováno a zavřeno odděleně od okolí. Sice i běžní hasiči si s tím umí poradit a hasit vodou za určitých podmínek v případě nouze pod napětím (do 400 V, speciálové do 150 kV), ale snaží se tomu vyhýbat.
Pokud budu mít barák padající do kategorie se zvýšeným požárním rizikem, tak budu muset mít zpracované postupy a systémy pro dálkové vypnutí UPS systémů uvnitř.

199
Sítě / Re:CETIN a jeho "modem"
« kdy: 24. 12. 2020, 10:12:37 »
Hm, moc jezky to nevypadá. A pokud to vypadá, že to napájení je nějaký čínské pes, co vede pak někam trubkou a možná strčen někde do zásuvky, tak když to uvidí revizák, tak bude "nadšen".
Nu, metalické rozvody Ethernet tam jsou, ne? Vypadá to, že cca 3 dráty jsou, je použit jeden, který jde skrz ten PoE napaječ, takže někde v bytě jinde je ještě možná Wifi APčko?
To řešení TV mě překvapuje, že to je overlay, to jsem u Cetinu neviděl. Co je v tom za skladbu kanálů a odkud se do těch GPON rozvodů injektuje, jestli-že je to mimo barák (to jest neinjektuje se to na poslendím spliteru v baráku) a v baráku není klasický rozvod STA, tak je investor ušetřil a Cetin si utíkání oveček dobře pojistil, protože odpadlíkovi odpadne asi i základní TV. :-)
Udivuje mě, že dneska je někdo ještě tak blbej, že je ochoten podepsat smlouvu v které se zavazujre, že se v domě neobjeví rozvody jiného operátora - tomu nedokáže majitel objektu zabránit. A pokud bude bránit a ISPák bude vytrvalý, tak je to to cca na 2 roky s vyvlastňovacím řízením s výsledkem, že určená část baráku připadne jinému ISP, aby  si mohl udělat rozvody svoje a majiteli nezbude, než to strpět a ještě zaplatí případné smluvní pokuty tomu, komu se zavázal, že jiný v baráku nebude. :-)
Jestli je to klasicky, že se barák rozprodal na jednotky a pak je z toho SVJ, tak toto řešení je výhodné jen pro investora domu (ušetřil) a Cetin (má dobře zaháčkovanou situaci), ne pak lidí, co v tom bydlí. Ale jinak souhlas, přesně takhle se to dělá. :-) Řešil jsem toto pár měsícl zpět v baráku u tchýně, kde jako ten druhý nechtěný přicházející ISP byl O2 s optikou, zabralo mu to cca rok,ale původní zaháčkovaný ISPík naštěstí je flegmouš a neřeší to (nebyl schopen za 2 roky začít ani posílat faktury polovině baráku, takže ta polovina ani o optice od O2 nechtěla slyšet, když mají internet zdarma).

200
Nějak to od tooh původního odbočilo? Ale míchat SOHO s nečím dalším je asi chaos. A třetí pohled: core prvky mají statickou konfiguraci IP a zároveň jsou zadané v DHCP. A tak od dob, kdy jsem už zařil pár slovutných zařízení, co provedla pobláznění s výmazem do defaultu a pokud mají v default DHCP, tak aspoň dostala občas OK adresu zpět (v horším případě nějakou default pevnou IP). :-)

201
Sítě / Re:konfigurace rstp a vlan
« kdy: 20. 12. 2020, 09:09:28 »
Switch to bude jeden ze dvou modelů CRS354-48...., víc jich Mikrotik nemá.
Ano, pro využité HW offloadu je třeba zachovat jeden bridge-lan, do něj mít všchny porty a SFP1+2 s tím předáním řešit správným nastavením VLAN nad tím jendím bridge-lan. Je opravdu škoda u toho swiche to dělat tak, aby něco šlo do CPU (zvláště ty 40 Gbps porty), takže si při nastavování hlásí, zda je stále hlášen aktivní flag H u portů switche, že je offloading aktivní. Pokud už to nejde bez dalšého bridge, tak při přidávání portů do něj rovnou nastavovat, ať hw offload nepoužívá, ať mám jistotu, že HW offload zůstane aktivní na tom hlavním bridge-lan.
Ten management bych řešil tak, že port ether49 jediný nedáš do žádného bridge, IP dostane přímo na sebe a je to (takže žádný bridge-management jen s jedním portem 49).
Pak to RSTP - opravdu je jen pro použití na těch dvou portec hk ISP,nepotřebuješ ho někde jinde, máš tma jedne swithc bez kruhování? PAk to jde nastavit OK přes ten bridge-lan RSTP nechat aktivní jen na těch SFP1/2 (na ostních portech bych si nechal aktivní aspoň loop protection).

202
Sítě / Re:konfigurace rstp a vlan
« kdy: 19. 12. 2020, 18:03:36 »
Já to pochopil, že má linku k ISP zdvojenu (SFP1 a 2) a jeden port je záloha, řídí to pomocí RSTP. Ono záleží, co je na druhé straně u ISP, aby si z toho mohlo udělat bond. Ty VLAN1 a 2 jsou nad oběma porty SFP1 i 2?
Dále, je to vidět, Mikrotik podporuje u toho switche maximálně jeden bridge s HW offloadingem. Jak máš udělané 2 brdoge, tak se HW offload uplatŇuje u toho btidge s názvem "rstp", ale bridge-lan jede celá v softwarovém switchování, takže jsi pty porty 1-48 degradoval na výkon 10 Mbps....

203
Sítě / Re:Mikrotik VLAN - Zmena MAC
« kdy: 18. 12. 2020, 09:03:20 »
Nu, někdy se to dělá a udělá se to jen tím popsaným způsobem, že nepoužívám přímo VLAN iface, ale VLAN dám jako port do bridge a na něm si nastavím admin MAC jak chci a pak provoz z routeru jde pod touto MAC.

204
Vývoj / Re:Python: komunikace mezi dvěma programy
« kdy: 12. 12. 2020, 22:03:47 »
Jj, chce si to pár věcí zkuit, zamyslet se a pak zvolit. Poprvé to bude stejně špatně. :-(

Ale pokud chceš inspiraci reálného: Mám také malou apku, co bere data pomocí OPC-UA (větší počet tisícovek tagů, aktualizace cca sekundová, napsáno v C s pomocí open62541), žere data z OPC-UA zdrojů, vyrábí z toho JSON v SenML formátu a dává to do Redisu jako streamy. Paralelně vedle třeba nějaká další apka v Ruby (to už řeší jen nižší tisíce tagů spíše s minutovou aktualizací), ta žere data přes SOAP z OCIsoft  PI krámu a také dává jako SenML do Redisu a pak je tam několik dalších obdobných, kde některé ještě interně používají mezi sebou NanoMsg nebo čisté TCP spojení, pro rychlejší data. Z Redisu si čte streamy pár apek a chroupá dál -  třeba je tam i Webdis pro lokální web info náhled Redis dat, další něco sesčítá a výsledky jdou pro vzdálenou vizualizaci přes MQTT protokol (a končí to někde přes MQTT->OPC bránu zase v nějakém InTouch Wonderware), hlavně se z těch Redis streamů něco počítá a strká výsledky do Kafky, kde to pak z Kafky několik dalších apek strká do několika různých DB. :-)

205
Vývoj / Re:Python: komunikace mezi dvěma programy
« kdy: 12. 12. 2020, 20:20:50 »
Uff, nějak se ti to z těch dvou programů v Pythonu komplikuje o další v Delphi? A poběží to vše na jednom kompu nebo několika?
Používá se kde co a pro různé věci, co je nejlepší bude dost záležet co vše a jak se má předávat, zpracovávat, ...
Unix socket nebo obecný síťový socket je rozumný základ. Ale možná zjistíš, že se bude hodit něco výše postaveného, co by řešilo některé věci, co budeš muset si u holého socketu řešit sám. Padla zmínka o 0MQ (ZeroMQ) - ano možnost, případně následnické projektyv podobě NanoMsg a NNG.
Možná můžeš skončit ještě výše o věcí kolem MQTT, Kafka, Redis, .... - vše jde použít a záleží co vše potřebuješ řešit. Často je to kombinace víc věcí, pokud je to rozsáhlejší záležitost. :-)

206
Vývoj / Re:Co je co při OPC ?
« kdy: 10. 12. 2020, 14:01:00 »
myvar.set_value(true)
Za předpokladů: a) to myvar je node typu scalar datavalue, b) je to datový typ boolean (nebo je povoleno změnit datový typ na boolean), c) máte právo zápisu do ní (třeba to vyžaduje pro zápis prvně autorizaci při připojení).

207
Vývoj / Re:Co je co při OPC ?
« kdy: 10. 12. 2020, 13:39:23 »
Asi by mělo být v nadpisu OPC-UA, protože OPC je něco jiného. :-)
V tom myvar by měl skončit objekt daného koncového uzlu na uvedené browse cestě, pokud existuje (v tom screen shootu nic se jménem "Scan_String" pod name space indexem 4 není vidět, ale když ti to hlásí to ns=4,s=Scan_String, tak ho třeba našel).
Pokud existuje někde níže, tak to chce ještě myvar.get_value() abych dostal datovou hodnotu v Python notaci, pokud chápu správně (nepoužívám OPC-UA z Pythonu, tak jen odhaduji dle toho demo kódu).
To i=84 a i=85 je jedinečný identifikátor jednotlivých uzlů (plně to je ns=0,i=84 a ns=0,i=85, což odpovídá tomu popisnému "Root" a "Object"). 

208
Windows a jiné systémy / Re:RIM OS 10
« kdy: 29. 11. 2020, 22:27:00 »
K 31.12.2019 OS 10 asi definitivně zařízli. Poslední telefon na tom OS uvedli na jaře 2015 (BB Leap) a další už jsou na Androidu. Škoda, také mi OS10 vyhovuje a řeším kam se hnout z dodělávajícího BB Classic.

209
Vlastní CA a vydané certifikáty na dlouhou dobu, je stále ještě asi cesta, ale z pohledu někoho, kdo musí takové vykopávky udržovat (a to 10 let starý systém je ještě mládě), tak narazíte spíše na ty zmíněné protokoly. Když vezmu současnou techniku a jak se tváří na servery, co umí jen SSL nebo max TLS1.0...
Proto půjde o to, zda mohu už projektově brát, že ty embedded servery jsou aktualizovatelné, třeba max každé 2 roky se k nim dostane servis, který by třeba ten server upradoval. Zda jde opravdu o ostrovní izolované systémy (kam přijde servis až po těch 10 letech) nebo jsou v izolované síti s centrálním dohledem.

210
Tak jde o to, zda ti připojující klienti bude běžný spotřebitel nebo specializované servisní zařízení. Pokud se mám připojit s něčím, co si za 10 let koupím v prvním obchodě, tak se dá předpokládat, že doba platnosti certifikátu bude to poslední, to možná už nebude klientské zařízení akceptovat ani TLSv1.3 nebo http/2.0 protokol. :-(
Pokud má jít o specializovaný servisní terminál, který bude existovat v omezeném množství kusů a budu i jeho dodavatelem, tak pak se s tím už nějak pracovat dá (když se rozhlídnu a vidím ty tuny systémů na bázi Windows NT4.0, co stále kolem fungují v server i workstation edici).

Stran: 1 ... 12 13 [14] 15 16 ... 22