Příspěvky

1

Hardware / Re:Výměna čipsetu na základní desce

« kdy: 16. 07. 2025, 09:41:43 »

Nejcastejsi pricina techto selhani neni kulicka, ale utrzeny intermetalicky kontakt (rozhrani med - nikl - zlato - Snx). To se na tech 200C neroztece a proto problem pretrvava. Kdyz se chip sunda, projevi se to padem, na ktery se nic nechde chytit, i kdyz utrzeny neni - staci ho ocistit a pak to jde.

Ale ze by se to tho nehdo chtel dobrovolne poustet

2

Odkladiště / Důsledky CRA pro OSS

« kdy: 04. 07. 2025, 02:00:02 »

Prave jsem si precetl a procsel pozadavky CRA.

Secure Boot, ochrana proti modifikaci

Prakticky to znamena nemoznost preinstalovat i jen klasicke PC koupene s OS na vlastni?
Rozumi tomu nekdo jak to je?

3

Sítě / Re:Routing provozu z více WAN

« kdy: 17. 06. 2025, 01:11:04 »

Nemůžete pro ten provoz, který má být směrován z veřejné IPv4 adresy do VPN, vyhradit v té VPN samostatnou IPv4 adresu?

Ne, to možné není.

4

Hardware / Re:USB-C zdroj pro tři notebooky zároveň

« kdy: 16. 06. 2025, 23:48:17 »

Docela dobre jsou analyzy na www.chargerlab.com

5

Sítě / Re:Routing provozu z více WAN

« kdy: 16. 06. 2025, 17:17:58 »

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále? Co to je zač a jaký typ VPN je použito? Ono občas nejde kombinovat některé věci v jednom, často je problém NAT a čistý IPsec tunel, pokud to je na jednom stroji, protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Čím realizuješ tu stranu VPN klienta? Routuješ správně na straně těch vzdálených sítí do tunelu tu IP,  kterou použiješ v tom SRCNAT na centrále? Samozřejmě by bylo hezčí řešení, pokud ten VPN klient na pobočkách je zároveň i wan brána do inetu, tak na něm pomocí značkování spojení si vést, co vracet do tunelu a co pustit přímo ven.

Takže spojení z Itnernetu jde na centrální server, zde provedeš DSTNAT pro poslání směrem k internímu serveru za VPN? A na stejném místě jsi zkusil i SRCNAT pro to, aby ti to šlo zpět správně? Ten VPN server je identický stroj s tím, co dělá to DST/SRCNAT v centrále?
Ano.

Čím realizuješ tu stranu VPN klienta?
Mikrotik na obou stranách.

Routuješ správně na straně těch vzdálených sítí do tunelu tu IP
Ano, zda s, že vše funguje správně

protože si vzájemně lezou v pořadí zpracování blbě do zelí.
Ajno, myslím, že to bude nějaký problém tohoto typu. Ale nevím, jak to debugovat. Torch v MK se mi zdá nefunguje korektně, když to nejde pres fyzická rozhraní.

6

Sítě / Re:Routing provozu z více WAN

« kdy: 16. 06. 2025, 14:03:29 »

Ten source NAT dělejte na tom centrálním serveru s veřejnými IP adresami – na jeho interní adresu, ať se odpověď vrátí interní sítí.

Ano, to byla moje původní myšlenka.

7

Sítě / Re:Routing provozu z více WAN

« kdy: 16. 06. 2025, 11:01:40 »

Zdravím,

mám rozsáhlejší routovanou síť, která má obecně více WAN.
Mám určitý problém s tím, jak zajistit, aby, pri pristupu z venku, šla odpověd pres stejnou WAN i ven, protoze se stane to, že pokud je to někde dále v síti a je nějaká WAN blíž, jde to default routou ven zde.
Zkouše jsem source-NAT vzdy na GW, ale nejak nejsem schopen to správně poskládat...

Nešlo by přiložit náčrtek sítě a případně dodat víc informací typu jestli máš vlastní veřejné, jestli se na GW provádí port forward, jak se řešený a tak podobně?
Čím víc informací dáš, tím líp.

Mám jeden centrální centrální s veřejnými IP, a pak větší množství sítí, které se k tomu připojují VPN tunelem. Jednoduše se dá říct, že potřebuju zpřístupnit některé služby z těch koncových sítí na tom veřejném serveru.

8

Sítě / Routing provozu z více WAN

« kdy: 14. 06. 2025, 16:22:20 »

Zdravím,

mám rozsáhlejší routovanou síť, která má obecně více WAN.
Mám určitý problém s tím, jak zajistit, aby, pri pristupu z venku, šla odpověd pres stejnou WAN i ven, protoze se stane to, že pokud je to někde dále v síti a je nějaká WAN blíž, jde to default routou ven zde.
Zkouše jsem source-NAT vzdy na GW, ale nejak nejsem schopen to správně poskládat...

9

Software / Re:Algoritmus pro doporučování zboží v e-shopu

« kdy: 11. 06. 2025, 15:14:45 »

Elektronicke suciatky pre domacich kutilov.

Jednoznacne dle nakupu ostatnich. Kupujes male konekotr -> typicky chces i female. Delaji to tak i velci kluci typu Mouseru, a je to uzitecne, vyuzivam to.

10

Hardware / Re:Rack jako centrum internetu pro domácnost

« kdy: 09. 06. 2025, 17:01:26 »

Rozhodne, rack je dobry napad.

Ale tento konkretni je podle me dost nestastny. Male 19" mi nikdy neprisli prakticke - jsou melke, a jedine, co se do toho vejde jsou switch/routery Rack PC me.
Bud bych volil velky, nebal bych se koupit i pouzity, stoji to par korun s tim, ze se do toho vejde vse.
A nebo klidne i vice malych 10" jako treba https://rackove-skrine.heureka.cz/triton-10u-rka-10-as4-cax-x1/#prehled/
Tenja obvykle davam na "domacnost", protoze odmitam komukoliv cokoliv delat, kdyz to neni pristroubovane - routery switche, patch panely nejsou problem, drzaky na male PC take ne (nebo jen policka a trema Lenovo m910q), drzaky treaba na nekolik RPI take jsou, nensi hotove NASy (Synology, QNAP co 10 disku) take ne, zaroven cena je ok.

https://allegro.cz/nabidka/patch-panel-rack-10-1u-12-portu-kategorie-6-utp-netrack-cerny-17347503676?utm_feed=712e6653-4749-4512-b084-b6e297fc9e0b&utm_source=google&utm_medium=cpc&utm_campaign=CZ%3EElectro%3EP%26S%3EPMAX&ev_campaign_id=20761721173&gad_source=1&gad_campaignid=20751599517&gbraid=0AAAAApZ4Y9QgQPmOnDatgj2gXh7Eb6-FS&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66UI2RTgHuPW2myNmOZUOcEC7ldTKBQq3JwmLbQRMfQhEl5idzlyj_AaArnxEALw_wcB
https://www.alza.cz/mikrotik-k-79-d12520377.htm?kampan=adwspn_sitove-prvky-a-nas_pla_all_top-produkty_rh-top-produkty_c_9062885___Mikro24025_745242948382_~176179024205~&gad_source=1&gad_campaignid=22432392883&gbraid=0AAAAAD2xsm7CNSb1KpnN2IzvbG-y4L063&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66X-0qc5InYJhQN8FF0zYE4cpiB0-CE9B8wODlLaY2zdAYATlJLdcUEaAh9pEALw_wcB

https://www.alza.cz/roline-10-police-1u-150-mm-cerna-d12631252.htm?kampan=adwspn_sitove-prvky-a-nas_pla_all_obecna_strukturovana-kabelaz_c_9062885___ROLpol004_602764218200_~134392693901~&gad_source=1&gad_campaignid=17449119791&gbraid=0AAAAAD2xsm5WBql0ZGCvNExnzjbmRM0FL&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66X1oFVKFO4Q8LduUYE54N6p8zQZ73fhIlGEo8hs9nITg2Z2Eghim-QaAp8iEALw_wcB

Stejny format - https://www.jeffgeerling.com/blog/2025/project-mini-rack-compact-and-portable-homelabs

Navic to jeste resim tak, ze k vseho vyhazu ty male cinske zdroje do zasuvky a nahladim to jednom prumyslovym do policky .

11

Hardware / Re:Rack jako centrum internetu pro domácnost

« kdy: 09. 06. 2025, 16:50:09 »

Rozhodne, rack je dobry napad.

Ale tento konkretni je podle me dost nestastny. Male 19" mi nikdy neprisli prakticke - jsou melke, a jedine, co se do toho vejde jsou switch/routery Rack PC me.
Bud bych volil velky, nebal bych se koupit i pouzity, stoji to par korun s tim, ze se do toho vejde vse.
A nebo klidne i vice malych 10" jako treba https://rackove-skrine.heureka.cz/triton-10u-rka-10-as4-cax-x1/#prehled/
Tenja obvykle davam na "domacnost", protoze odmitam komukoliv cokoliv delat, kdyz to neni pristroubovane - routery switche, patch panely nejsou problem, drzaky na male PC take ne (nebo jen policka a trema Lenovo m910q), drzaky treaba na nekolik RPI take jsou, nensi hotove NASy (Synology, QNAP co 10 disku) take ne, zaroven cena je ok.

https://allegro.cz/nabidka/patch-panel-rack-10-1u-12-portu-kategorie-6-utp-netrack-cerny-17347503676?utm_feed=712e6653-4749-4512-b084-b6e297fc9e0b&utm_source=google&utm_medium=cpc&utm_campaign=CZ%3EElectro%3EP%26S%3EPMAX&ev_campaign_id=20761721173&gad_source=1&gad_campaignid=20751599517&gbraid=0AAAAApZ4Y9QgQPmOnDatgj2gXh7Eb6-FS&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66UI2RTgHuPW2myNmOZUOcEC7ldTKBQq3JwmLbQRMfQhEl5idzlyj_AaArnxEALw_wcB
https://www.alza.cz/mikrotik-k-79-d12520377.htm?kampan=adwspn_sitove-prvky-a-nas_pla_all_top-produkty_rh-top-produkty_c_9062885___Mikro24025_745242948382_~176179024205~&gad_source=1&gad_campaignid=22432392883&gbraid=0AAAAAD2xsm7CNSb1KpnN2IzvbG-y4L063&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66X-0qc5InYJhQN8FF0zYE4cpiB0-CE9B8wODlLaY2zdAYATlJLdcUEaAh9pEALw_wcB

https://www.alza.cz/roline-10-police-1u-150-mm-cerna-d12631252.htm?kampan=adwspn_sitove-prvky-a-nas_pla_all_obecna_strukturovana-kabelaz_c_9062885___ROLpol004_602764218200_~134392693901~&gad_source=1&gad_campaignid=17449119791&gbraid=0AAAAAD2xsm5WBql0ZGCvNExnzjbmRM0FL&gclid=Cj0KCQjwjJrCBhCXARIsAI5x66X1oFVKFO4Q8LduUYE54N6p8zQZ73fhIlGEo8hs9nITg2Z2Eghim-QaAp8iEALw_wcB

Stejny format - https://www.jeffgeerling.com/blog/2025/project-mini-rack-compact-and-portable-homelabs

12

Server / Re:Geograficky redundantní NAS

« kdy: 14. 05. 2025, 12:49:28 »

Ja to nechci, to chce vedeni :-) Ja si uvedomuji, ze pokud to neni garazove reseni (ten stary nfs jsem slepil ja) slepene sysadminem/netadminem, tak to nikdy nebude levne. Synchronni to byt spis nemusi, vse, co jsme tu zatim zakoupili/postavili jsou urcite asynchroni reseni.

Tak se zamysli nad tim, ze nechat se do toho natlacit znamena pro tebe osobne nejspis slapnout do poradne velkeho hovna.
Ale myslim, ze to sam tusis...

13

Server / Re:Geograficky redundantní NAS

« kdy: 14. 05. 2025, 10:12:42 »

Tak AWS apod. rovnou skrtam, kdyz jsem koukal na ceniky EFS, tak by to urcite nevychazelo. Tam by melo akorat smysl nacpat web aplikaci primo do tech web VM/kontejneru a teprve zbytek souborovych dat na EFS, ale i tak by to bylo ve stovkach GB - realny provoz na nfs siti se spatne kalkuluje.

Cephfs jsem moc nezkousel, ale uz zpusob pripojovani klienta (auth) do ceph clusteru me od toho trochu odrazuje. Navic multisite (znam jen z proxmoxu) je spis jednostranna replika. Nemluve o tom, ze pro potrebny vykon bych potreboval nejakou hromadu ceph nodu na obou stranach. To se nevyrovna max 2U per lokalita profi reseni.

Jinak cekal jsem spis informace, ze nekdo pouziva takove reseni (synology HA, truenas, konejnery) popr. odkazy na ruzne MSP ci firmy to zajistujici. Nejak se mi nechce verit, ze jsme v CR jedini, kdo to resi a neni to banka nebo korporat.

Zatim me napadlo prinejhorsim postavit lokalni nfs cluster v kazde lokalite, z gitu by se posilaly zdrojaky na oba, a mezi clustery nasadit nejaky replikacni mechanismus pro zbytek souborovych "dat" - dokumenty, obrazky, apod. Mozna porad lepsi, kdyz sluzba "bezi", ale nema "data", nez nebezi nic. Ale krome drbd neznam nic, co by bezelo v realtime (async,sync) a ne opakovanym cronem apod.

Já to z popisu chápu tak, že chceš něco, co má mít už dost enterprise charakteristiky...
Z toho ten Ceph vychází jako levná a dobrá alternativa. Na věci typu Synology bych zapomněl rovnou, truenas bych považoval take jen za dost tupý storage...
Kolega ti tady nabízel konzultaci, takových lidí je málo, kteří jsou schopní s tím fundovaně poradit. A také záleží na budgetu, podkud není, tak se na to raději vykašli.

14

Vývoj / Re:Budoucnost Rust v embedded světě

« kdy: 14. 05. 2025, 10:05:18 »

Já pravě vidím pravý opak - čás vývojáře je nic pokud je schopný optimalizovat.

Pokud píšeš aplikaci pro desktop, tak čas vývojáře je velký náklad, pokud pro servery, kde jich budeš potřebovat tisíce, tak jakákoliv optimalizace může ušetřit miliony (v USD). Čas vývojáře byl drahý než přišel cloud.

Tohle, a možná ještě nějaký hlubší lowpower jsou jediné aplikace, kde jsem se setkal s tím, že to někdo ocení...
Jo, AVX-2  v asm, to byla zábava Ale smysl to mělo zatím přesně jednou.

15

Vývoj / Re:Budoucnost Rust v embedded světě

« kdy: 14. 05. 2025, 09:58:28 »

Dokonale spolehlivý software je potřeba pro místa, kde se nedá dělat servis nebo musíte garantovat dekádu provozu bez problémů a certifikace. Letectví, vesmír, lékařství... o trošku méně automotive, možná těžaři a nebezpečné průmyslové provozy.

Ale pořád to nemusí být optimalizovaný software, naopak, může být výhodnější napsat jednodušší software (super loop s minimem podmínek) a "matematicky" dokázat jeho spolehlivost než ladit každou ztracenou mikrosekundu nebo pár byte paměti (za spolehlivost se platí a dražší čip se už v té ceně ztratí).

Tato oblast mě zajímá a reaguji na informaci o matematickém dokázání spolehlivosti. Mám velmi rád programovací jazyk Ada, kde se právě pro toto prokázání používá nástroj Spark. Dle dokumentace od Adacore jej však nelze využít pro C/C++/Rust, cituji: "Kódu psanému v C/C++ nebo Rustu se SPARK použít nedá –⁠ nejvýš můžete ze SPARKu volat funkce napsané v C a těm pak důvěřovat nebo je testovat klasickými postupy, ale matematický důkaz vlastností pro ně SPARK nevede.". Umělá chytrost mi nabízí možnosti Frama-C + ACSL/WP, CBMC pro C++ nebo Prusti pro Rust, využíváte některou z nich?

Já používám formální analýzu výjímečně a vlastně pouze v FPGA designech, v místech, kde se řeší střet více hodinových domén.... většinou nad VHDL, což je de fakto ADA.