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 - Ondrej Nemecek

Stran: [1] 2 3 ... 73
1
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 17:02:36 »
jQuery není framework, a hlavně už není rok 2010, aby se jQuery používalo (na cokoli). Záleží na tom, co na frontendu chcete řešit. Jestli bude lepší použít nějaký framework/prostředí jako Vue, Svelte nebo React, nebo jestli bude lepší použít jen nějaké knihovny.

Zajímavé, můžeš to rozvést Filipe?
Shopů jsem udělal dost, ale už je to 10 let.
(Vue, Svelte nebo React) jsou pro mě neznámé pojmy, o Reactu jsem mnohokrát slyšel, ale neviděl, je to hodně skloňované jméno. Co má dobrou křivku učení?
A JQuery se už fak moc nepoužívá? :o

JQuery se používá a je potřeba ho +- znát, ale své nejlepší roky má už za sebou. V čistém js se dá dnes napsat to samé a lépe. Pokud javascript tak bych doporučil zkusit si čistý js ve verzi es 6 a pak se podívat na vue. Řekl bych že zde bude poměrně dobrá učící křivka. Nejlepší je mít někoho k ruce, kdo pomůže prokousat se začátkem.

2
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 16:54:00 »
java na backend je strasny moloch. Kod sice vyzera super jednoducho, ale mas tam milion roznych kniznic, o ktorych netusis ako vlastne funguju.
Ja som niekolko rokov robil servisy v c#, bezia niekolko rokov bez vypadku a zaberaju minimum prostriedkov. Teraz skusam rok javu (springboot+docker) a katastrofa. Strasne to zabera prostriedkov, ten kod je este ako-tak ok, ale 30 importov, aby som urobil rest service s pripojenim na mssql a chodilo to nejak rozumne.
"Programatori" si to pochvaluju, lebo nemusia riesit nic, ale za aku cenu. Ja osobne mam radsej veci pod kontrolou, aj ked to znamena viac pisania.

Nikdo vás nenutí používat velké frameworky. V javě není problém psát jednoduše, použijte třeba javalite a jdbi a máte službu, která startuje za 2 sekundy a stačí jí desítky MB RAM. Java má jiné problémy - nedokonalá generika, nedokonalý optional, statický dispatch. Ale některé věci z toho právě řeší jiné jazyky nad jvm při zachování dobré interoperability. Takže jvm jako runtime je pro mnoho použití dost dobrá volba. - Můj názor.

3
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 16:46:36 »
Krom toho nad JVM je více zajímavých jazyků jako např. scala, kotlin, haskell, clojure.
Haskell?

aj, sorry, haskell samozřejmě není nad jvm, zkracoval jsem větu až jsem to zkrátil moc.

Škoda :) Už jsem si říkal, že je nějaká implementace Haskellu pod JVM.

Tak několik. Jaká je použitelnost je věc jiná, ale pod jvm je opravdu hodně jazyků.

4
USBčkové wifiny dělával Atheros, ale konkrétně u řady ar6k tuším býval nějaký problém s provozem AP. Nevím jak u modernějšího AR9271. Ani nevím, kde takový dongle shánět - leda snad u Mousera. Netušíte někdo, co za čipset má takový "TP-LINK Archer T2U Plus" ?

Je to asi rtl8812au.  Přijde mi divné, že nikde není databáze chipsetů, driverů a podporovaných funkcí. Nebo o ní jen nevím?

5
Server / Re:Docker a hosting bez námahy
« kdy: 13. 02. 2021, 22:46:53 »
Spravovat kontejnery není problém. Co se zabezpečení týče, když používám třeba základ Alpine Linux + dobře nastavený NGINX, co se dá vlastně zabezpečit jinak a lépe?
Jak je zde výše napsáno, nechci řešit zabezpečení celého OS, nechci ani moc řešit DDoS útoky aj. To už bych chtěl mít zajištěno od poskytovatele této služby. Chci si jen spravovat své kontejnery...

Zabezpečit potřebujete všechno - od dveří do serverovny, přes infrastrukturu, operační systém (...) až po aplikaci. A bavíme se o tom, o co se budete starat vy a o co se bude už starat poskytovatel (a za kolik). Což zase záleží na tom, v jakých image aplikace poběží (zda si je děláte sám nebo převezmete nějaké poskytovatelem garantované). V ideálním případě vám kontejnery poskytnou cca to samé co managed servery ale s větší flexibilitou běhového prostředí. Takže je ta debata mlávení slámy, protože není dost konkrétní...

Co mohu říct je jen to, že bych nedoporučoval OVH - mám s nimi dlouhodobě špatné zkušenosti a komunikace s ČR se stále zhoršuje (nedokážou si ani spárovat platby).

6
Server / Re:Docker a hosting bez námahy
« kdy: 13. 02. 2021, 22:26:08 »
(...) Spousta hotových platforem navíc znamená uzamčení k té platformě – nemůžete snadno přejít jinam.

To bohužel ano. A žádná standardizace pokud vím ani nehrozí.

7
Server / Re:Docker a hosting bez námahy
« kdy: 13. 02. 2021, 17:43:46 »
Předpoklad, že kontejner něco z výše zmíněného vyřeší, je podle mě zcela chybná. Kontejner řeší snadné spuštění projektu v předem specifikovaném runtime. Je sice oddělený od hostujícího os, ale svoji vlastní bezpečnost a snadnou správu neřeší.
V kontejneru ale máte typicky jen jednu aplikaci a pár knihoven, které ta aplikace potřebuje. To je na správu mnohem jednodušší, než celý OS.

Tak jasně, ale jak bude ten kontejner tučný záleží na okolnostech - a stejně jej bude muset tvůrce aktualizovat. Takže žádná velká výhra to není - bude platit a ještě se starat. To už je lepší použít tu hotovou platformu, kterou pak opravdu jen užívá.

8
Server / Re:Docker a hosting bez námahy
« kdy: 13. 02. 2021, 16:27:56 »
Měl bych takový dotaz stran provozování Docker kontejnerů. Dá se v ČR najít hosting, který by mi umožnil v podstatě neřešit server a jeho OS, bezpečnostní nastavení aj., ale zabývat se pouze nasazováním jednotlivých kontejnerizovaných projektů?

Předpoklad, že kontejner něco z výše zmíněného vyřeší, je podle mě zcela chybná. Kontejner řeší snadné spuštění projektu v předem specifikovaném runtime. Je sice oddělený od hostujícího os, ale svoji vlastní bezpečnost a snadnou správu neřeší.

Podle popisu spíš hledáte SaaS nebo PaaS. Ale vždy je to něco za něco, i tady můžete z řešení těžit až po jeho osvojení nebo po zaplacení někoho, kdo to řeší za Vás.

9
Takže realtek_rtwifi umí namespaces, ale neumí AP mód, což vylučuje použití dvou stejných wifi karet (jedna jako AP a druhá v namespace jako klient). Je možná kombinace interní wifi RPI v namespace a externí USB wifi pro běžný provoz.

Podpora namespaces v systemd vypadá docela dobře, jedna unit mi vyrobí namespace a druhá tam připojí wifinu a veth rozhraní. Na těchto unitech závisí pak ten IOT komunikační software, který běží ve dvou procesech z nichž jeden je v namespace a povídají si přes rmi. Systemd spustí proces v namespace sám díky direktivě JoinsNamespaceOf a PrivateNetwork.

Děkuji hlavně Ondřejovi Celetkovi a Michalovi Kubečkovi za nasměrování na namespaces. Pro úplně ideální řešení bych potřeboval ještě usb wifi, které umí AP mód (pomocí wpa_supplicant) i namespaces. Pokud by měl někdo tip kde hledat, uvítám to.

10

Nevím zda to je vlastnost hardware nebo kernel modulu, zkoumám tyhle ovladače:

https://github.com/kimocoder/realtek_rtwifi
https://github.com/aircrack-ng/rtl8188eus/issues/104

Takže aby to fungovalo musí network namespaces podporovat explicitně příslušná wifina:

Kód: [Vybrat]
# iw phy phy1 info | grep set_wiphy_netns
* set_wiphy_netns

Což třeba rozšířené usb wifiny s rtl8188 neumí a nedaří se je přesunout do namespace :(

Kód: [Vybrat]
# iw phy phy0 set netns name iotgw-configuration
command failed: Operation not supported (-95)

Což omezuje použití. Ani nevím, jak dohledat, které usb wifiny to umí?

Pokud to wifina umí  - jako třeba ta integrovaná v Raspberry PI - tak to funguje :)

V praxi budu muset konfigurovat IOT zařízení pomocí integrované wifiny (z namespacu) a pro běžný provoz používat externí usb wifinu.

To mne mimochodem nutí také vyřešit predikovatelné (reprodukovatelné) pojmenování síťových rozhraní protože wlan0 a wlan1 se inicializují náhodně takže nepoznám která je která.

11
Takže aby to fungovalo musí network namespaces podporovat explicitně příslušná wifina:

Kód: [Vybrat]
# iw phy phy1 info | grep set_wiphy_netns
* set_wiphy_netns

Což třeba rozšířené usb wifiny s rtl8188 neumí a nedaří se je přesunout do namespace :(

Kód: [Vybrat]
# iw phy phy0 set netns name iotgw-configuration
command failed: Operation not supported (-95)

Což to omezuje použití. Ani nevím, jak dohledat, které usb wifiny to umí?

Pokud to wifina umí  - jako třeba ta integrovaná v Raspberry PI - tak to funguje :)

V praxi budu muset konfigurovat IOT zařízení pomocí integrované wifiny (z namespacu) a pro běžný provoz používat externí usb wifinu.

To mne mimochodem nutí také vyřešit predikovatelné (reprodukovatelné) pojmenování síťových rozhraní protože wlan0 a wlan1 se inicializují náhodně takže nepoznám která je která.

12
Koukám, že se tu dobře rozjela debata. Díky za všechny příspěvky a jdu si s tím pohrát. Je fakt, že jelikož budu v namespaces spouštět vícero démonů, tak to už bude možná snadnější to rovnou strčit celé do kontejneru.

13
.. man ip-rule ..
taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?

Tak pochopil jsem to tak, že jedna routa bude
Kód: [Vybrat]
192.168.0.0/24 na eth0 a druhá
Kód: [Vybrat]
192.168.0.0/24 na wlan1 a prostě se dle pravidla použije jedna nebo druhá bez ohledu na metriky apod. Ale asi to není z hlediska tcp/ip úplně dobrá situace a může se to klidně někde vytelit - nevím co by se např. stalo, pokud by na obou rozhraní byly úplně totožné IP adresy  >:(

Ještě mě napadlo mě jak by si s tím poradil routovací démon (RIP)? Ale to se pro účel rychlého nastavení v duplicitní siti asi nehodí, minimálně by tam byla prodleva než si RIP démon osahá topologii. A byla by to asi celkově prasárna...

14
Tohle je přímo ukázkový příklad pro network namespaces. Jednoduše příslušnou síťovou kartu přestěhuješ do samostatného namespace a v něm spustíš třeba shell, v něm třeba DHCP klienta, či cokoli jiného. Uvnitř daného namespace bude existovat jen tahle jedna síťová karta a prázdná směrovací tabulka. Všechno ostatní ale bude sdílené s hostitelským systémem, takže je snadné předávat si data třeba přes filesystém.

...

No vida, člověk se pořád učí, tohle vidím poprvé a nejspíš je to hotové řešení přesně mého problému  :D Ono totiž přepínat směrovací tabulky pomocí ip rule by vyžadovalo spravovat ta pravidla, kdežto namespace vypadá že bude stačit nastavit jednou pro vždy a je to přesně k tomuto účelu určené!

Teď se jen podívat jak je to integrované do systému v Raspberry OS. Používám na všechna síťová rozhraní jednu instanci dhcpcd a jednu instanci wpa_supplicant. Dále tam mám pdnsd a udhcpd, ale to jen na wlan0. Podle řečeného to vypadá, že budu muset spustit od dhcpcd i wpa_supplicant dvě instance, v jednom namespace bude eth0 + wlan0 a v druhém wlan1.

Ty namespace se budou muset vytvořit při startu. V každém namespace poběží jedna instance komunikačního software, všechno bude nakonec komunikovat přes mqtt takže by tak mohly komunikovat i obě instance komunikačního software (za předpokladu že najdu vhodnou implementaci podporující unix sockety, nebo přes unix sockety rmi).


15
Na linuxu se dají používat pravidla (ip rule) pro výběr routovací tabulky. Pokud dokážete sestavit pravidla, která budou schopna rozlišit komunikaci pro to jedno rozhraní, můžete použít to. Nenapsal jste, čím bude ta komunikace na tom jednom rozhraní specifická – zda třeba dokážete určit zdrojovou IP adresu, proces apod.

Bingo, to by mohlo být ono.

Pravidlo je možná takto: Vše co jde ze systému na cílovou adresu 192.168.0.0/16 a má cílový tcp port 9999 nebo je to icmp ping do tohoto rozsahu (+ možná ještě udp broadcast na 192.168.0.0/16), tak má jít přes wlan1, jinak dle výchozích rout případně na bránu.  K tomu bych tedy asi navíc potřeboval, aby dhcp klient nenastavoval výchozí bránu pro wlan1.  Při použití ip rule si musím pakety značkovat ve firewallu a tu značku pak použít v ip rule pravidlech nebo pravidla na port, proces atd. umí ip rule přímo?

Je ovšem otázka, zda se ta pravidla do budoucna nezkomplikují (a ony se určitě zkomplikují, jak se bude přidávat podpora pro další IOT zařízení). Pak by bylo možná lepší volit nějaký obecnější filtr. Pokud by se na danou komunikaci vyhradil například separátní proces, mohlo by se vše z toho procesu směřovat na wlan1 - což by se pak asi podobalo té mnou zmíněné virtualizaci, tj. proces by na tcp/ip úrovni komunikoval pouze a jen prostřednictvím wlan1. S procesem by se muselo nějak komunikovat, nejlépe mechanismem nezávislým na tcp/ip, takže třeba RMI over Unix Sockets - junixsocket (ty procesy jsou java)?

PS: V praxi jde o úkol zapojit IOT zařízení do zásuvky, připojit se na něj wlan1 wifinou (IOT funguje při prvním zapnutí jako AP) a nakonfigurovat ho pro připojení na wlan0 našeho systému, které je v AP režimu a kde běží dhcp server. Tím pádem se zařízení přepne do wifi client režimu a přeadresuje dle našeho dhcp. Dhcp je pod kontrolou a tím pádem bude pod kontrolou i zařízení a půjde ze systému přes tcp/ip dále ovládat. Těch zařízení tam bude samosebou více a tímto mechanismem si je postupně „přivlastním“.

Stran: [1] 2 3 ... 73