Příspěvky

1

Software / Re:SW pro archivaci (ne zálohování)

« kdy: 09. 09. 2023, 20:59:33 »

Co chcete jako slyset ? Lepsi reseni nez zpiratene tsm (spectrum) nebo networker plus worm na lto proste nevymyslite .

2

Hardware / Re:Hardware pro server domů

« kdy: 18. 08. 2023, 18:24:29 »

Take sem kdysi uvazoval o NUCu, ale nakonec sem sel do plnokrevne starsi hpe gen8 dl380 a jsem nadmiru spokojen. Clovek muze vystrelit treba 20-30 stroju a ani se nazedejcha, na hrani si z ruznejma kubernetema, integracema apod naprosto idealni.

3

Server / Re:Volby pro SSH, aby vydržel dlouhodobě NAT

« kdy: 20. 02. 2023, 00:17:28 »

3: TCPKeepAlive jsem pochopil že není to co chci.

No taky pomáhá udržet spojení aktivní, ale není to šifrovaný, takže je to riziko. Lepší je nastavit na serveru ClientAliveInterval a ClientAliveCountMax. Což dělá to stejné, ale z pohledu serveru. Teda server pošle klientovi alive zprávu. Když jich nedostane CountMax zpět, tak řekne, že klient se odpojil a zruší spojení.

Tcp keepalive je defacto prazdnej ack packet, tam nema bejt co sifrovany. Navic je resen os vrstvou a nikoliv aplikaci, ssh jen pozada aby socket byl otevren s so_keepalive option. OS pak zajisti periodicke posilani ack paketu, jak casto a v jakejch intevalech zalezi na sysctl options (sem ted linej je hledat).

4

Server / Re:K8s, PostgreSQL a replikace na tři nody

« kdy: 20. 01. 2023, 17:57:35 »

Nebude imho fungovat ani jedno z navrhovanych reseni. Chcete multimaster, ale ten v ramci rdbms neni jednoduche udelat. I Oracle RAC funguje nad jednemi daty, pokud chcete mit data jeste v replice musite mit dataguard. Zkratka navystacite si paralelnim fs, pokud zvolite active-pasive reseni neni to zase vhodne pro masazeni do k8s. Jedine reseni ktere
me napada je mit 2 instance jako statefulset, kterym bude predrazena nejaka haproxy, na kterou pujdou prichozi db konexe a bude ta v pripade  failovery/switchoveru prehodi provoz na druhy node. Nicmene i tak nevim jak byste resil treba switchover (otoceni replikace).

IMHO tohle presne ten pripad na co se k8s pouzivat nema , ale treba kolegove prijdou s nejakym reseni co neznam.

5

Studium a uplatnění / Re:Go backenďáci a Quasar frontenďáci u nás

« kdy: 10. 01. 2023, 13:21:50 »

Vim ze firmy jako Proton nebo Keebola shanely golang vyvojare a ze v nem maji napsanou nejakou cast sveho backendu. Sam v go pisu ruzne tools nebo restapi, ktere integruji to ci on s k8s, ale nepovazuji se za vyvojare, jsem spis sysadmin.

6

Studium a uplatnění / Re:RHCE - Red Hat Certified Engineer zkušenosti s využitím

« kdy: 30. 09. 2022, 14:36:57 »

Nicméně zkoušky od RH mám rád, jelikož mají nějakou hodnotu. Probíhají ve striktně kontrolovaném prostředí (2 kamery, přerušování zkoušky a kontrola místnosti na přítomnost dalších osob, zkušební volání na telefon, zda je opravdu vypnutý, ...)

Tady bych rad pripadne zajemce upozornil, aby si dobre rozmysleli, kde budou zkousku skladat. Bud je to mozne v ramci skoleni primo v ucebne, kde je na to klid (doufam ze tato moznost stale plati). A nebo v tzv. kiosku (nekterymi kolegy familierne prekrteno na suicide budka), kde jste sam a hlida Vas vzdalene indicky kolega. Tento zpusob skladani zkousky zdal se mi ponekud nestastnym.

Jednou za cas jste vytrzeni ze sveho soustredeni a musite projit svou mistnost s kamerou, zda se pod stolem neschovava kolega s tahakem, nesmite ani hybat rty (napriklad kdyz si pro sebe ctete otazky), nesmite sebou zadne jidlo a tusim ze je povolena sklenice vody.

Celkove je to dost frustrujici zkusenost a obcas byste nejradsi vzdaleneho indickeho kolegu umlatili rycem ci mu privodili nejakou jinou, velmi bolestivou formu smrti. Takze radim spis si zvolit termin v ucebne, kde je na to fakt klid (tech ale neni tolik).

7

Studium a uplatnění / Re:RHCE - Red Hat Certified Engineer zkušenosti s využitím

« kdy: 28. 09. 2022, 22:20:00 »

Nechceš si RHCE udělat, bylo by to dost narychlo, ale platím .

Moc dekuju za nabidku ale musim odmitnout. A ponizene priznavam, ze v mem soucasnem pracovnim i dusevnim rozpolozeni by to z Tve strany byly nejspis vyhozene penize

8

Studium a uplatnění / Re:RHCE - Red Hat Certified Engineer zkušenosti s využitím

« kdy: 28. 09. 2022, 16:26:37 »

Koukám, že je RHCE docela prestižní záležitost - zatím jsem nepotkal nikoho kdo tu certifikaci má platnou. Je háček v tom, že je to drahé, nebo v tom, že je to těžké?

Problem dnesni RHCE imho neni ani to, ze by byla tezka nebo draha, ale to ze je orientovana prevazne na jednu jedinou technologii (hlavne ansible), coz rozhodne v soucasne turbulentni dobe neni znalost, ktera ma nejakou trvalou hodnotu. Pokud to srovnam s objectives RHCE7, kde se clovek potka se selinuxem (ktery vyuzije napr konteknerech), kerberosem (integrace s AD), ldap (taktez) tak ta cerifikace pro mne neni zajimava. Navic pokud uz vlastnim (byt expirovanou) nejakou rhce tak z hlediska hledani zamestnani to taky nema uplne smysl. A posledni vec bylo jiz nekolikrat zminivane zariznuti centos8, protoze kdo mel rhce umel i centos.

Zkratka atraktivita teto certifikace at uz z hlediska hledani zamestnani ci pouhe radosti se z uceni znacne upadla. Mam dat opravdu minimalne 10k za to, ze budu master na ansible ?

Ja chci vedet jak ten system funguje, jak se chova a jak ho konfigurovat na te nejnizsi urovni, protoze me to jednak zajima a jednak to uziju i jinde. Ansible nebo jinej tool, kterej firma bude pouzivat se naucim za pochodu.

9

Server / Re:HTTP reverse proxy s dynamickou URL

« kdy: 27. 09. 2022, 17:19:12 »

Vaše spása se jmenuje buď openresty (nginx+lua) a nebo nginx javascript module

 

https://www.nginx.com/blog/harnessing-power-convenience-of-javascript-for-each-request-with-nginx-javascript-module

https://openresty.org

Mame to v produkci na ne uplne trivialnich casech a plna spokojenost.

10

Studium a uplatnění / Re:RHCE - Red Hat Certified Engineer zkušenosti s využitím

« kdy: 23. 09. 2022, 09:35:28 »

RHCE 6x sem dal cele v pohode a bez skoleni, na 7x sem mel uz zaplacenej jakejsi fasttrack od zamestnavatele,za
coz sem byl tenkrat vcelku rad, protoze se tam resily ty osklive veci kolem systemd, network managera a podobnejch tehdy jeste propriaeternich sracek . Na 8x uz sem nesel neb to nepotrebuju, musel bych se poradne ucit ansible kterej nesnasim a nechci na tom uz palit ani cas ani penize

Jinak RHCSA se dala udelat za pul hodiny pokud mas s linuxem nejake zkusenosti.

11

Server / Re:SQL dotaz: defragmentace tabulky

« kdy: 07. 08. 2022, 22:11:06 »

Mozna by bylo dobry si nejdriv rict co chapete pod pojmem fragmentace tabulky a jak to tento pojem chapou ostatni. A bylo by fajn vedet co za db engine to je.

Napriklad na oracle (ehh mam informace do 12c, uz db dlouho nedelam) fragmentace vznikala defakto na urovni tablespace, kdy bloky objektu (v tomto pripade tabulky) byly rozstrkany vsude mozne vlivem pridavani a mazani zaznamu. Tbs zde totiz byla popsana bitmapou neco jako byla treba FAT. Pokud jste chtel udelat "defragmentaci", znamenalo to analyzu objektu v prislusne tablespace, jejich move jinam a zase zpet, pripadne rebuild u indexu. Nicmene k tomu, aby clovek mohl bez ztraty kyticky takovou operaci provest, musel vedet jake objekty jsou jak na sobe zavisle, kam je presunout a kdyz tim presunem neco rozbil (indexy, procky, package..) vedet co rebuildnout. Nekdo delal import/export ale to mi prislo uz trochu hardcore

12

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 01. 07. 2022, 21:21:04 »

….a samozrejme jsem zapomnel na ruzna objektova udelatka typu ceph, s3 apod.

13

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 01. 07. 2022, 21:19:35 »

Uprimne moc netusim o jakem enterprise svete kolegove mluvi . Imho vnimam nekolik smeru a iscsi v nem moc nefiguruje.

1) Pokud chci slusnou blokovou storage a mam prachy pak je tu stary dobry fc
2) Pokud z nejakeho duvodu fc nemam rad (treba kvuli dedikovane inrastrukture) pak je to vetsinou reseny necim ala NetApp na dedikovane infrastrukture => tedy nfs like, ktere uz samo o sobe zajistuje paralelni pristup  (kolikrat nahrada vmfs) plus mrte cool ficur navic jako replikace, failover apod.
3) Diky rozmachu technologii podporujici sharding apod je tu takova skromna renesance DAS.

iscsi je porad jen publikovani blokove storage - nic vic nic min.

14

Vývoj / Re:Google OpenID connect a mikrosluzby

« kdy: 23. 06. 2022, 23:01:09 »

Imho nevidim duvod proc neresit vyse zmineny problem prave pres sessions vydane na zaklade oidc tokenu (treba pres auth code flow). V praxi i v microservice architekture je to vcelku bezna metoda, ktera resi prave problem okamziteho odhlaseni. Pokud jde distribuci stavu a jeji dopad na skalovatelnost pak ji lze castecne resit session affinity. Proste zaridite, aby pozadavky od konkretniho klienta koncily vzdy na stejne instanci/podu a session budete na ostatni pody replikovat jen pro ucely ha. Jasne, nebudete moc skalovat az do vesmiru kvuli overheadu na distribuci, ale budete skalovat nejspis dostacne na to, aby to pokrylo Vas load.

Dalsi moznosti je presunout celej oidc stack na nejakou apigw/proxy pred microservice svet (k8s) na nejakej nadupanejsi hw pripadne se podivat zda to neumi treba cloudflare nebo jinej provider. Tim Vam odpadne nutnost resit do detailu tyto veci(authorizaci, refresh fazi, synchronizaci apod) na samotnych microservisach a nechat jejich logiku zamerenou na vas business problem se vsema vyhodama co microservice svet prinasi. Opet v praxi se tento scenar normalne pouziva.

Proti argumentu "pouzij jwt token authorizaci protoze microservices" muze stat argument bezpecaku "kdyz jwt tak oidc a kdyz uz oidc tak auth codeflow a zadny tokeny na fe/v browseru). Muzeme vest dlouhe filosoficke disputace jak moc stateless ma microservice svet byt, nicmene "opet v praxi" to zalezi na konkretnim pripadu a vysledku PoC.

Jinak zkuste se podivat jak funguje oidc codeflow, relaying party a vytvoreni session (v tomhle pripade auth cookie) zde:

https://www.nginx.com/blog/authenticating-users-existing-applications-openid-connect-nginx-plus/amp/

Navod je na nginx plus (placena verze nginxu), nicmene muzete pouzit jine reseni. Melo by Vam to dat ale predstavu jak to cele funguje a co od toho chtit.

15

Vývoj / Re:Google OpenID connect a mikrosluzby

« kdy: 21. 06. 2022, 16:21:41 »

Pokud potrebujete uzivatele odhlasit a zaroven chcete pouzit oidc/jwt authorizaci resi se to to scenarem v jednomz prvnich prispevku: Backend ziska tokeny a vygeneruje session s expiraci stejnou jako ma access token a ty posle fe(uzivateli). Pokud uzivatele potrebujete okamzite odhlasit, znevalidujete jeho session v aplikaci a tokeny v idp (tedy autentizace pres refresh selze) a vynutite jeji opetovne prihlaseni. Jak to udelat primo skrz google/fb apod netusim, ncimene treba konkretne keycloak ktery umi idp brokering pro zminene providery to umi: odhlasite session a tim padem se pres refresh uz neprihlasite. Zaroven tez muzete uzivatele uplne zablokovat. Pozor v tomto pripade musite take nejak zajistit samotnou refresh fazi s idp po te co expiruje access_token a to nejlip nejak transparentne (tedy beze zmeny user session). Vyhoda takove postupu je ze fe/uzivatel nema vybec sajnu o nejakych tokenech a tudiz vubec nevi jake interni prava ma. Nevyhodou je komplexita se kterou se ale da hrat. Session overovani Vsm muze delat treba nejaka proxy/apigw a na be budou chodit jen claimy z tokenu (ulozene interne nebo v nejake key/val) takze i kdyz vyvojari be nechtej zabrednout do bazin oidc, lze to nechat na nejakem lepsim ifrastrukturnim prvku co to umi