Příspěvky

571

Server / Re:Omezené rychlosti z DC do Cloud při přenosu pomocí SMB

« kdy: 06. 08. 2020, 20:14:59 »

mrkni na tcp frames a jejich velikost, jaký congestion se na síti používá? Jak vypadá rychlost v čase? Jak dlouho jsi vůbec nechal běžet iperf, nesaturují se routery při delším přenosu? Stíhá to druhá strana ukládat?

Zabal smb do ipsec, změř iperfem ipsec tunel samostatně a pak přes to spusť smb a uvidíš, jestli je na cestě nějaké QoS či nikoliv.

Těch proměnných tam může být opravdu spousta. Osobně bych začal postupně vylučovat jednou za druhou a zkoumat anomálie v měřeních.

572

Studium a uplatnění / Re:ČZU Informatika (Ing)

« kdy: 22. 07. 2020, 21:44:09 »

Obor informatika na ČZU (Provozně-ekonomická fakulta) je směs ekonomiky a informatiky. Náročnost je nízká (proti FEL, UK atd.), do praxe tě nenaučí (to není chyba tohoto oboru, ale obecně IT). Dálkové studium je paskvil, spousty víkendových nalejváren, jak tady zaznělo, občas to ale skočí na pátek odpoledne nebo konzultačky pouze přes týden. Dělat to distančně s prací není snadné a ani škola k tomu nešla nikdy naproti.

Osobně bych neočekával, že mi vysokoškolák z oboru informatika napíše jakýkoliv kód na pohovoru, to ta škola moc neučí a není to cíl, někteří to umí, někteří ne. Lidi v IT s vejškou mají ale daleko lepší obecné znalosti a předpoklady zvládnout různou agendu.

Pracuji kolem databází a obrovský se hodí, že lidé znají náročnosti řadící algoritmů, struktury indexů, optimalizaci bitových operací, multibajt instrukce na cpu atd. Tohle ti samoukové často vůbec netuší a pak je to člověk musí učit. Tohle zase není u většiny pozic potřeba, takže je těžké to generalizovat.

573

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 26. 06. 2020, 11:27:15 »

použití privátních IP adres pod veřejnými doménami vidím čím dál častěji pro interní systémy uvnitř firem. Dříve se používaly neobsazené generické domény (typu .dev, .internal či zkratky firem), ale se ale začaly rozšiřovat top level domény, tohle začalo být překážkou a mohlo dojít k nefunknčosti.

Další rána je poměrně striktní chování prohlížečů kolem TLS, není snadné si vystavit interní CA, aby ho prohlížeč bral vážně, takže se používají TLS certifikáty vystavené na veřejné domény (klidně wildcard, aby nedošlo k vyzrazení těch domén) a domény se směrují přes privátní rozsahy do intranetu.

Spousty prohlížečů, mobilních telefonů a dalších zařízení, které uživatel dneska používá a chce s nimi fungovat i v interních systémech neumí jednoduše a spolehlivě přetížit nameservery a volá si svoje.

Řešením by mohlo být si zřídit vlastní AS a používat veřejné rozsahy ip adres routovaných pouze interně, ale to neni pro spousty společností dostupné.

Je čím dále těžší mít pro malé společnosti interní systémy, které nejsou v internetu.

574

Vývoj / Re:Docker a systém v kontejnerech

« kdy: 16. 06. 2020, 23:30:19 »

pro docker image bez OS nemusí být binárka staticky kompilovaná, mohu to tam dát i s těmi závislostmi

575

Sítě / Re:IoT vs. bezpečnost

« kdy: 16. 06. 2020, 23:25:10 »

nebezpečí je přece také v připojení k/z internetu a nikoliv v odposlechu samotné komunikace (VPN), na to bys potřeboval mít VPN terminátor někde lokálně schované v lan a pak teprve routovat do internetu či do služeb.

K Mirkovi bych jen dodal, že u IoT je také nedostatek logů, audit nástrojů a sledování provozu, wireguard to nevyřeší, u běžných IoT hraček nemáš dostatek entropie a výkonu na dobré šifrování.

576

Desktop / Re:OOM killer, něco jiného než kill

« kdy: 16. 06. 2020, 10:37:24 »

Pro hlavní OS je totiž ta virtuálka jako jeden proces, nevidí do něj, OOM killer chrání ostatní procesy, aby nespadly.

Schovej si chrome také chrome do cgroupy, jiné virtuálky a omez mu také pameť. Můžeš nastavit jinou prioritu pro virtuálku či jí úplně vyloučit z oome killeru, pak ale náhodně zabije něco jiného. Osobně bych začal nastavením swapu a omezováním chromu.

577

Distribuce / Re:velky /var/log/sysglog

« kdy: 15. 06. 2020, 11:52:21 »

a to nemáš log rotate aktivní?

S tou chybovou hlášku ti nepordím, to neznám.

578

Server / Re:Omezení přístupu na SSH z některých IP

« kdy: 07. 06. 2020, 09:43:01 »

Nemám rád následování takovýhle rad aniž by k tomu byl řečený důvod a útok, kterému to zabrání. Vede to pak k domnění, že root s ssh klíčem je bezpečný, také není (nešifrovaný klíč v home složce je čitelný skoro i pro internetové stránky). Heslo na root je špatné kvůli brute force (či za pomocí slovníku) útoku na server, uhádnout konkrétní neznámý ssh klíč je dnes nemožné, uhádnout párznaké heslo je reálné. Notifikace, pravidelné sledování, nástroje jako fail2ban či pokročilejší mohou nevýhodu hesla smazat.

Je to až s podivem, ale třeba v některých bankách se setkávám pouze s přihlašováním na roota a pouze s doménovým heslem, protože věci jako cyberark, Microsoft AD a nulová podpora ssh klíče při SSO.

579

Windows a jiné systémy / Re:Víceuživatelský VPN server pro Windows

« kdy: 03. 06. 2020, 15:51:59 »

chápu, ty chceš vpn a ne přímo přihlášení do windows, to ti je putna. Sám používám tinc (http://tinc-vpn.org/, umí to L2, takže funguje streaming videa, voip atd.), ale to je těžké na nastavení, openvpn se nastavuje trochu jednodušeji, ale podporuje pouze L3 (point to point), mikrotik routery třeba umí ipsec (opět L2) či jiné věci. Pokud to chceš i z mobilu, openvpn může dostačovat, wireguard je stejně tak jednoduchý a už snad funguje i na mobilu.

Mrkni ale na ten softether, můžeš tam poměrně snadno naklikat i spojení pro mobil, aby fungovalo nativně.

580

Windows a jiné systémy / Re:Víceuživatelský VPN server pro Windows

« kdy: 03. 06. 2020, 15:07:47 »

Windows 10 nemá víceuživatelský režim, na to jsou Wndows Server, ale tam platíš licenci za každého uživatele, nebo tak to aspoň dříve bývalo

To je mi známo. Proto si to představuji tak, že si nainstaluji program, který bude fungovat jako VPN server, který nebude mít s uživatelskými účty ve Windows nic společného a bude možné se k němu připojit z více zařízení současně.
Ale je možné, že je tato moje představa mylná.

pokud nevadí, že ti uživatelé uvidí to stejné, tak teamviewer nebo tightvnc s nějakou vpn (ať už zmíněný softeher, openvpn, tinc či nějaký ipsec přes router).

Windows ale nepodporuje, aby ti uživatelé viděli rozdílnou plochu, v jednu dobu může být aktivní jen jeden "desktop".

581

Windows a jiné systémy / Re:Víceuživatelský VPN server pro Windows

« kdy: 03. 06. 2020, 14:23:53 »

Windows 10 nemá víceuživatelský režim, na to jsou Wndows Server, ale tam platíš licenci za každého uživatele, nebo tak to aspoň dříve bývalo

582

Server / Re:Omezení přístupu na SSH z některých IP

« kdy: 03. 06. 2020, 09:42:47 »

je možné naistalovat fail2ban, nastavit striktní blokování při prvním pokusu a svoje IP dát do whitelistu. Jak ale píšou ostatní, můžeš si snadno odříznout přístup od vps i pro sebe.

583

Vývoj / Re:Zkušenosti s cloudem a Kubernetes

« kdy: 02. 06. 2020, 17:44:57 »

ale řadu věci také značně zesložiťuje, vždyť implementace k8s trvá do produkce několik let (moje praxe z českého prostředí) a pořád nastávají i několikadenní výpadky (nedávna zkušenost z banky). To řešení není dostatečně připravené na širší nasazení, jakýkoliv debugging je obrovský až nemožný problém, post-mortem analýzy skoro nemožné, chybí dospělý resource management, saturovat 10Gbps+ linky je skoro nemožné (přitom dnes už fyzicky používáme i 100Gbps mezi servery) atd. atd.

Podle mě to má smysl až když jsou splněný následující body:
* mám víc dodavatelů software a potřebuji pro ně jednotné běhové prostředí, se kterým si poradí i průměrný vývojář
* provozujeme toho opravdu hodně, potřebujeme automatické horizontální škálování a load-balancing
* s tím související automatické logování na jedno místo (nám se logy neztrácí, ale můžeme mít zatím jen štěstí)
* máme schopný tým adminů, kteří se o to postarají (a na oplátku nemusí řešit zákoutí každé nasazované aplikace)
* aplikace jsou jasně definovaného formátu (komunikace přes http, bezstavové, ideálně bez potřeby zapisovat na disk persistentní data)

Jinak je to podle mě špatně vybraný nástroj. Autor vlákna operuje s nejmenšími VPS, které Amazon nabízí, to prostě nemůže fungovat. Naopak máme zkušenost, že pokud je hardware dimenzovaný dostatečně, je cluster stabilní.

S (ne)dospělostí administrace, logování a debuggingu souhlasím. U Openshiftu bych doplnil bych ještě značnou nestabilitu instalačních skriptů. Dost překotný vývoj, zpětná kompatibilita nic moc.

Pro menší provozy se určitě v konečném důsledku vyplatí si to pronajmout jako službu od RedHatu nebo Amazonu. Jakkoliv ty ceny možná vypadají "draze".

--------------

Ad efektivita: pokud je mým primárním cílem efektivita, nepoužiji Kubernetes. Ono technicky vzato i ty VPS jsou vlastně neefektivní oproti dedikovanému serveru, že?

--------------

Dohromady s tím pracuju docela rád, myslím, že až projekt dospěje a admini se ho naučí nastavit, bude to přínosem pro mnoho vývojářů. Ale je to jen pro určité případy užití, jako obvykle, there is no such thing as a silver bullet.

Jo, s tím co jsi napsal plně souhlasím, jen to bohužel vidím nasazované jen špatně, všichni předpokládají, že se vlastně administratory nebudou potřebovat a vše obstarají vývojáři... To je vlastně i případ tohoto vlákna. Kubernetes ale vyžaduje daleko více přípravy, odměnou za to je šance na flexibilnější provoz, pokud se z toho neudělá zoo.

VPS může mít overhead skoro neměřitelný, ale také značný, však víme.

Na kubernetes mi vlastně asi nejvíce vadí ta obrovská code base (2 mio řádků v současnosti), to je něco tak monstrózního, že to může rychle přerůst přes hlavu.

584

Vývoj / Re:Zkušenosti s cloudem a Kubernetes

« kdy: 02. 06. 2020, 14:40:22 »

áno, ale protože Kubernetes veľa vecí značne zjednodušuje. To že to jde aj bez neho neznamená že teraz by sme nemali K8s používať.

ale řadu věci také značně zesložiťuje, vždyť implementace k8s trvá do produkce několik let (moje praxe z českého prostředí) a pořád nastávají i několikadenní výpadky (nedávna zkušenost z banky). To řešení není dostatečně připravené na širší nasazení, jakýkoliv debugging je obrovský až nemožný problém, post-mortem analýzy skoro nemožné, chybí dospělý resource management, saturovat 10Gbps+ linky je skoro nemožné (přitom dnes už fyzicky používáme i 100Gbps mezi servery) atd. atd.

Nápady a algoritmy, které výrazně zjednoduššují práci "uživatelům" se mi v tom líbí, ale implementace je takové malé peklo. Nemám rád složité služby, unix není příliš uživatelský přívětivý a proto asi vznikají podobné technologie, které se zase vzhlídly v komplexnosti, to je ale na škodu.

Výměna serveru v clusteru je přece běžná věc, i na starém debian s kickstart scriptem a ipxe to šlo zautomatizovat bez jakéhokoliv zásahu a výpadku služeb, jen se to moc nedělalo. Kubernetes pro mě nepřináší nic co jsem dříve již nepoužíval, pouze to balí do balíčku jako jednu službu a teď mě živí, řeším jeho implementace do produkčního prostředí.

585

Vývoj / Re:Zkušenosti s cloudem a Kubernetes

« kdy: 02. 06. 2020, 13:49:30 »

potřeba dělat distribuované systémy tady je několik desetiletí, weby jako wikipedia běží i bez kubernetes a dalších cloudových vylepšení. Jen teď přichází asi nová generace IT lidí, pro které kubernetes je jediným řešením problémů...