Příspěvky

271

Windows a jiné systémy / Re:"Veřejný klíč" der (windows) počáteční bajty

« kdy: 19. 04. 2022, 15:44:53 »

ASN.1, RFC 5280, https://datatracker.ietf.org/doc/html/rfc5280#section-4.1

prožeň certifikát přes "openssl asn1parse -in cert.der -inform DER -i" a ukáže ti to jednotlivé hodnoty, ta tvoje sekvence 30 81 89 bude rozepsána hned na začátku.

272

Server / Re:Jak resite to, ze vice a vice sluzeb loguje do journald, pricemz rsyslog zustal?

« kdy: 19. 04. 2022, 15:12:07 »

v tom případě ukaž jak máš konfigurace jednotlivých částí.

Vlastně nevím, co chceš dělat. Pokud máš journald ve výchozím stavu v CentoOS, tak ti to loguje pouze do ramdisku, přesměrovává vše do syslogu a ten to rozděluje do jednotlivých souborů v /var/log.

Pokud chceš nějakou aplikaci filtrovat z journald, nastavíš jí StandardOutput=null, StandardError=null a tím vypneš systémové logování do journald, syslogu a tím do /var/log.

Pokud chceš nějakou aplikaci odstranit pouze z /var/log/messages a ponechat journald, nastavíš přes tag pravidlo do rsyslogu, aby zahodil logy pro tuhle aplikaci:

Kód: [Vybrat]

# /etc/rsyslog.d/pgbouncer.conf
# $programname je podle názvu aplikace v systemd službě
if $programname == 'pgbouncer' then stop

Zbytek je poté na logování v samotné aplikaci, neznám balíček pgbouncer a nevím jak to má nastavené, to musíš ověřit z dokumentace.

273

Server / Re:Jak resite to, ze vice a vice sluzeb loguje do journald, pricemz rsyslog zustal?

« kdy: 19. 04. 2022, 12:04:10 »

tak obecně na serverech mám v /etc/systemd/journald.conf:

Kód: [Vybrat]

ForwardToSyslog=no
Storage=persistent

Tím mi nekončí věci z journald v /var/log/*, mají vlastní log na disku a retenci, poté je z toho vyčítám do monitoringu. Je to hlavně kvůli tomu, že je jednodušší konfigurace pro jednotlivé služby.

Duplicitní zápis do /var/log/syslog a /var/log/messages je divný, to první je výchozí nastavení pro debian based distribuce, to druhé pro RHEL. Tady to ukazuje na nějakou špatnou konfiguraci někde u pgbounceru nebo syslogu.

Samozřejmě vždy je nutné revidovat nové či výchozí nastavení u instalovaných balíčků a je s tím bohužel vždy dost práce.

274

Windows a jiné systémy / Re:Kombinace přepnutí monitoru a spuštění NA monitoru-> jiné velikost části GUI

« kdy: 19. 04. 2022, 09:05:53 »

pravděpodobně za to může sám Total Commander, ten jeho pascal je koule na noze již hodně dlouho.

275

Vývoj / Re:Nasazení PyWebIO na produkčním webu

« kdy: 19. 04. 2022, 08:41:23 »

- aplikace není odolná proti DoS a řada volání jí umí přetížit

Myslíš konkrétní věci z PyWebIO, které vedou k přetížení nebo obecně, že to prostě jde zaDoSovat (to jde ale cokoli). Pokud se to nasadí za nginx, tak IMHO to je vcelku ok že?

Myslím konkrétně např. to jejich parsování commandů z prohlížeče, hooodně zanořený json udělá pěkné tornádo (i v tornadu jako backend).

Předřadit nginx je tak trochu na nic, když tornado nebo aiohttp jedou přes websocket, tj. terminují si SSL spojení sami a tady je další slabina v podobě dost nebezpečné implementace SSL.

Ok, použiji flask/django a pojedu jen před http polling a tady přesně se zvednou odezvy aplikace, zvýší spotřeba paměti a problém se špatně ošetřovanými command objekty zůstává.

Před pár lety dostal jeden z našich operátorů políček v podobě průniku přes pywebio i v interní síti. Skončilo to nasazením Apache knoxu na sanitizaci vstupu a výběrkem nového CRM, který dodavatě postavil na mongu, takže to probíhá doteď…

276

Vývoj / Re:Nasazení PyWebIO na produkčním webu

« kdy: 16. 04. 2022, 11:55:05 »

- každé otevřené okno bere několik MB paměti - ta oboustranná komunikace mezi pywebio a klientem není dobře řešena
- aplikace není odolná proti DoS a řada volání jí umí přetížit

Nejvíc pravděpodobný je ale důvod, že vývojáři nechtějí řešit podporu, dávají nástroj vývojářům a ti ať si sami určití, jestli  to je na produkci nebo ne. Podobně to je u všech dalších obdobných nástrojů.

277

Windows a jiné systémy / Re:Web IIS na Windows a SSO (ověření Windows)

« kdy: 14. 04. 2022, 09:06:29 »

Pokud chceš použít NTLM transparent authentication, stejně potřebuješ server v doméně nebo proti komu se chceš přes NTLM přihlašovat? Proti lokálním uživatelům na serveru? Případně zase potřebuješ prostředníka, který ti identitu uživatelů vzdáleně ověří.

Pořád tady je stejná písnička, pokud Windows server není v doméně, IIS se neumí dotázat na identitu uživatele, je možné použít variantu se SPNEGO wrapperem (NTLM + kerberos v5), tam se pak předá podepsaný tiket přes IIS do TGS od klienta, takže přihlášení funguje transparentně pro doménové uživatele přes IIS, který není v doméně, je to tvůj use case?

Můžeš lépe popsat tvůj use case? O co se snažíš? Proč chceš jít takhle proti zdi?

Tuhle variantu třeba máme někde s Citrixem, který funguje jako IDM, IIS je o něm opřený a autorizuje přes NTLM, protože legacy aplikace.

278

Windows a jiné systémy / Re:Web IIS na Windows a SSO (ověření Windows)

« kdy: 13. 04. 2022, 14:36:12 »

Nový server má stejné přístupy, může používat stejného uživatele, má mít zapnuté SSO, ale nechci, aby byl v doméně

to je ale implementaci IIS SSO a způsobem jak funguje kerberos, spn je nepřenosné, váže se vždy na daný hostnamea a nemůžeš ho přenést na druhý, musíš i ten druhý hostname přidat do domény. ISS prostě jinou implementaci pro SSO nemá a musíš to vzít přes nějakého externího providera.

Ten tvůj linux používá nejspíš LDAP na získání informací o uživatelích (např. přes nsssd), to je ta jiná implementace.

279

Windows a jiné systémy / Re:Web IIS na Windows a SSO (ověření Windows)

« kdy: 13. 04. 2022, 12:53:22 »

abys dostal spn v kerberosu, musíš ten server dát do domény. Nebo si můžeš provozovat svůj KDC, buď jako forest nebo crossrealm. Proč ti tak vadí ho dát do domény?

A můžeš ty zdroje odkázat, ať víme o čem se bavíme? A jak se dostaneš k radič/AD? Anonymní přístup a ověřování hesel přes anonymní přístup je věc, která je už nějakou dobu zapovězena. Potřebuješ tedy nějakého bind usera, přes kterého pojedeš, v AD se tohle vše děje pře LDAP protokol, o tom jsem hned psal na začátku příspěvku.

Tady máš problém, že co vím, ISS SSO neumí LDAP, umí pouze kerberos/negotiate nebo NTLM a to znamená členství v doméně. Konkrétně se bavím o téhle službě https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/.

280

Windows a jiné systémy / Re:Web IIS na Windows a SSO (ověření Windows)

« kdy: 13. 04. 2022, 11:05:25 »

princip je v nastavení providerů, musíš si přidat vlastního a ten bude opřený třeba LDAPem o AD nebo bude mít s ním fedaraci, nikoliv abys měl přímou integraci ISS do AD přes negotiate/NTLM. U klientů používáme často třeba Cyberark (placený) nebo open source Apache Knox. Můžeš využít i nějakou službu typu Azure Active Directory a spojit je pře federaci (ADFS), což je cesta kterou MS teď tlačí.

281

Server / Re:Kontejnerizace a různé pohledy

« kdy: 07. 04. 2022, 14:18:19 »

Když už na to příjde řeč, tak pro tvoje účely možná může být dostatečný systemd-nspawn, spustíš takhle container pod uživatelem a oprávnění a vše ostatní můžeš řešit jak jsi zvyklý.

Taky jsem o tom uz stihl premyslet, ale netusil jsem, ze to umi i docker kontejnery...tak to muzu zvazit.

on je neumí přímo, musíš container/image rozbalit. Používám pretask na rozbalení, mountnutí a případně mountnutí writable volume a z něho spustím nspawn, ten se na danou složku chrootne. Při ukončení se to zase odmountuje.

282

Server / Re:Kontejnerizace a různé pohledy

« kdy: 07. 04. 2022, 13:12:20 »

Když už na to příjde řeč, tak pro tvoje účely možná může být dostatečný systemd-nspawn, spustíš takhle container pod uživatelem a oprávnění a vše ostatní můžeš řešit jak jsi zvyklý.

283

Hardware / Re:HDD WD RED Pro 16TB a vibrácie

« kdy: 07. 04. 2022, 11:06:07 »

Jsem sem napsal pouze svůj názor.  Já bych ten disk šel vrátit. Mě takový věci dost vaděj.
Pokud tobě nevadí, že ti od disku drnčí kejs anebo se ti od disku klepe NAS, tak to je tvoje věc.

Mně to samozřejmě vadí, proto to dělám jak píše GPU. Smontoval jsem si doma rack, má 60 kg sám o sobě, je přišroubovaný do zdi. 18TB disků mám celou řadu a nic nedrnčí. V datacentru zase máme limity kolik disků může být v jednom racku, pro ty velké storage mašiny se musí používat speciální racky, jinak tam prostě ty tisíce disků nedáme.

Dá se vybrat i jiný výrobce, Exos nebo x300 dělají daleko menší kravál než tyhle WD. 9 ploten a 7tis otáček dělá prostě svoje, stačí sebemenší nerovnost nebo natočení disku a vibrace jsou na světě. Jednu dobu byly hodně populární WD 3TB s 2 plotnami, to byl příjemný disk.

284

Server / Re:Kontejnerizace a různé pohledy

« kdy: 07. 04. 2022, 10:55:20 »

třeba Nomad lze provozovat v jednom člověku, nebo i k3s (osobní zkušenost).

Když to vezmeš fakticky, můžeš v systemd si udělat službičku, která ti nahodí net interface pro redis a dát jí jako závislost redisu v podmanu, podobně to dělá docker. Tím nepotřebuješ zvýšená práva. Využij toho, že ti systemd běží pod vysokými právy a umí dělat ledacos.

Když chceš zachovat porty, tak si spouštějí jednotlivé instance redisu na extra IP, tím můžeš zachovat porty. Přestaň o portech přemýšlet jako o něčem statickém a něčem přímo dosažitelném. Port má být statický jen když to je nějaký veřejný kontrakt, api, pokud máš interní služby nebo redis jako sidecar, nic tě nenutí mít porty náhodné, pak je jen předáš do konfigurace. Stejně tak to používáme s uživateli, pevného uživatele mají jen jednotky služeb, všechny redisy např. běží pod dynamickým uživatelem bez práv a obehnané selinuxem.

Po velkém boom kontajnerů se dnes zase vracíme zpátky a čím dál častěji experimentujeme s infrastrukturou, kdy generujeme celá jednoúčelný VM s konkrétní aplikací. Vývojář/admin to připraví v dockeru, vezmeme definici a z ní uděláme celým VM vč. kernelu a ten se spouští. Výhoda je daleko menší režije (docker prostě dělá nějakých 10 - 20 %, což u velkých služeb je pořádný balík peněz), lepší monitoring provozu, daleko nižší nároky na znalosti, protože odpadá milion komplexní nástrojů jako k8s. To jen takový povzdech a nápad kam se dál ubírat.

285

Server / Re:Kontejnerizace a různé pohledy

« kdy: 06. 04. 2022, 14:38:34 »

to je dlouhé téma.

Vykašli se na podman, to není na běh služeb ideální, však už jsi na hlavní úskalí narazil. k8s pořád nemusí být mimo hru, stejně jako k3s, stejně tak dobře funguje openshift, rancher, nomad aj.

Deamonless režim ala podman má velká omezení, protože při inicializaci kontejneru nemůžeš skoro nikam šáhnout, i obyčejný docker s centrální službou toho udělá víc, umí ti to vysokými právy připravit síť a kontajner pak můžeš mít spuštění v uživatelem.

Provázání na systemd nefunguje dobře v dockeru a ani podmanu, konflikt různých cgroup namespaců je poměrně zásadní, ztratíš buď monitoring, zabezpečení nebo stabilitu.

S návrhem sítě ti moc neporadím, neposkytl jsi příliš moc informací. Varianta (2) mi ale nedává moc smysl, raději bych viděl oddělení tenanta do vlastního subnetu, z pohledu monitoringu a bezpečnosti se lépe řeší DMZ pro jednotlivé zákazníky než pak vertikálně řezat služby.

Nechce ti firma raději zaplatit školení? Za den/dva se toho dá projít strašně moc.