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 - czechsys

Stran: [1] 2 3 ... 39
1
Server / Re:Kubernetes a správa uživatelů
« kdy: 13. 02. 2026, 13:37:01 »
Tak jsem to cele (k3s + rancher + k3s) smazal a zkusil znova, tentokrat bez definovani dualstacku (service/cluster cidr). "Bezi" to ted na default ipv4 subnetech a chytlo se to cele napoprve. Tak zkusim ipv6 only...

2
Server / Re:Kubernetes a správa uživatelů
« kdy: 13. 02. 2026, 11:32:49 »
Chceme to na prvotni odzkouseni. Takze psani nejakych RBAC yaml apod, kdy clovek netusi co a jak, je nesmysl. Proto klikatko do zacatku.

Rancher ted zkousim, ale nejak se mi proti externimu k3s nechce chytnout. A clovek nevi proc...Chyba tady, chyba tamhle, jestli to mezi sebou komunikuje pres LUA, GUA, cert aby z logu pochopil.

Nemam zatim rad kubernetes :D

3
Server / Re:Některé repozitáře APT nefungují kvůli SHA1
« kdy: 11. 02. 2026, 11:33:05 »
Tak gpgv variantu asi taky skrtnu, to bych musel vsude nainstalovat gpgv...

4
Server / Re:Některé repozitáře APT nefungují kvůli SHA1
« kdy: 10. 02. 2026, 12:15:52 »
Do souboru /etc/crypto-policies/back-ends/sequoia.config vložit (vytvořit nejspíš nebude existovat):

Kód: [Vybrat]
[hash_algorithms]
sha1.second_preimage_resistance = 2027-02-01    # Extend the expiry for legacy repositories

tím se to posune o další rok (nebo kam až je libo).

Další možnost jak to udělat je vrátit se ke gpgv místo sqv, pak je do souboru /etc/apt/apt.conf.d/25keypolicy potřeba vepsat:

Kód: [Vybrat]
APT::Key::GPGVCommand "1";

Posouvat neni reseni, to se asi shodnem. Tomu jsem se snazil vyhnout.
Ta varianta s gpgv mi zni lepe, to se i lepe konfiguruje mimo default. Nejaky zdroj k tomu? Tehdy jsem videl jen reseni s posunem sqv.

5
Server / Re:Některé repozitáře APT nefungují kvůli SHA1
« kdy: 10. 02. 2026, 12:14:27 »
Ahoj,

zapomel jsem si to u par veci ohlidat, ale to by nebyl takovy problem. Problem je v tom, ze nektere repozitare proste nefunguji.

1] zabbix - mame nyni 6.4 kvuli serveru (ceka se na 8.x) kvuli slozitosti predelani sablon. 6.4 je nepodporovana, ale zatim to stacilo. Jenze ted si apt stezuje kvuli SHA1. Napadlo me pouzit zabbix-agent 2 7.0, tam ten klic funguje, ale v oficialni dokumentaci pisou, ze pro server 6.4 je podporovovany agent max verze 6.4. Ma nekdo zkusenosti s behem novejsich agentu?

2] downloads.linux.hpe.com/SDR/repo/mcp - ani GPG-KEY-mcp, ani hpPublicKey2048_key1.pub mi momentalne nefunguje. Je to nejaka chyba u mne, nebo je potreba jiny klic? Chyba je "signing key is not bound ... no binding signature at time 2023-09-05 ..."

Nechci videt, kolik dalsich repozitaru nefunguje a blizi se planovana aktualizace :D

Skoro bych rekl ze kdyz das novejsi agenty nez server tak to nevadi a bude to fungovat. Jen tam nebudou fungovat ty novejsi funkcionality... zkusil bych nejakej testovaci pushnout nahoru...

No tak jsem to zkusil. Dopadlo to zvlastne. Na skoro vsech serverech, kde je ted 7.0, to funguje. Ale na rabbit serverech nefungovala ani 7.0, ani 6.0 zabbix-agent2. No budu to muset jeste nejak odzkouset, ale musel jsem tam docasne lokalne nainstalovat 6.4.

6
Server / Některé repozitáře APT nefungují kvůli SHA1
« kdy: 02. 02. 2026, 10:35:29 »
Ahoj,

zapomel jsem si to u par veci ohlidat, ale to by nebyl takovy problem. Problem je v tom, ze nektere repozitare proste nefunguji.

1] zabbix - mame nyni 6.4 kvuli serveru (ceka se na 8.x) kvuli slozitosti predelani sablon. 6.4 je nepodporovana, ale zatim to stacilo. Jenze ted si apt stezuje kvuli SHA1. Napadlo me pouzit zabbix-agent 2 7.0, tam ten klic funguje, ale v oficialni dokumentaci pisou, ze pro server 6.4 je podporovovany agent max verze 6.4. Ma nekdo zkusenosti s behem novejsich agentu?

2] downloads.linux.hpe.com/SDR/repo/mcp - ani GPG-KEY-mcp, ani hpPublicKey2048_key1.pub mi momentalne nefunguje. Je to nejaka chyba u mne, nebo je potreba jiny klic? Chyba je "signing key is not bound ... no binding signature at time 2023-09-05 ..."

Nechci videt, kolik dalsich repozitaru nefunguje a blizi se planovana aktualizace :D

7
Server / Re:Kubernetes a správa uživatelů
« kdy: 28. 01. 2026, 09:07:22 »
Na redditu jsem zahledl info o Project Capsule - vytvari abstrakci tenant, ktery sdruzuji namespaces, network/security politiky, rbac atd.

8
Server / Re:Kubernetes a správa uživatelů
« kdy: 28. 01. 2026, 08:56:55 »
Co co myslíte těmi uživateli? K čemu chcete vlastně ten kubernet používat? Kubernet je systém pro běh služeb v kontejnerech, o jaké uživatele vám jde? Uživatele pro správu toho kubernetu nebo aplikační uživatele těch služeb??

Uzivatele, kteri budou mit moznost pristupu ke kubernetu, s omezenymi pravy - napr. aby skupina uzivatelu mela pristup jen do sveho namespace a nemohla tak pracovat s namespacem jine skupiny.

9
Server / Kubernetes a správa uživatelů
« kdy: 27. 01. 2026, 10:36:57 »
Cau,

vyvojari si chteji zkusit nejaky kubernetes, tak jsem zatim rozbehl zakladni k3s. Nejdrive jsem zkusil pouzit rootless k3s, ale testovaci kontejnery nespolupracovaly s gpu. Tak jsem se vratil k rootful. No a narazil jsem na to, ze tam vlastne neni zadna sprava uzivatelu. V tuhle chvili by mi na testovani stacilo aspon, kdyby se to dalo omezit na neprivilegovane kontejnery a omezit uzivatele do jejich namespace.

Postup pro funkcni pridani uzivatelu jsem musel nakonec musel hledat po githubech (wtf), defacto via uzivatelske certifikaty. Rancher UI jsem do toho jeste nezkousel nainstalovat. Nez budu zatracet cas ruznymi hokus pokusy, ma nekdo tip na nejakou administracni free variantu, ktera by se dala zkusit, resp. pripadne klidne i pripadne cele reseni (kube + administrace)?

Diky.

10
Distribuce / Re:Časté aktualizace jádra a restarty systému
« kdy: 16. 01. 2026, 10:59:04 »
Mel, bych jeden spis obecny dotaz a doufam ze z toho nebude dalsi hadka  ;D.
Za posledni rok mozna uz dele se frekvence aktualizaci kernelu zvysila na cca jedenkrat tydne. Delate poctive aktualizace kernelu a restarty OS, nebo jako ja pravidelne aktualizujete, ale restarty jsou jen vyjimecne?

Podle monitoringu bude prumerny uptime serveru hodne pres sto dni. Nemuzu a ani nejsem ochotny kazdy tyden restartovat vice jak stovku serveru. Na nekterych probihaji nekolik dnu a nekdy i tydnu dlouhe vypocty a par aplikaci ma zavislost na trech i vice serverech, takze automaticke restarty by byly dost problematicke.

A co resis? Aktualizace a jejich cetnost jsou soucasti firemni IT politiky a to je vec, kterou se mas ridit. Pokud takovy plan nemas, tak se obrat na vedeni, jak mas postupovat.

11
Ahoj,

dlouhodobe pouzivame zabbix a oproti predchazejicimu centreonu postradam jednoduche ci rozumne rozdeleni, komu se posilaji notifikace. Momentalne pouzivana varianta pres acl na host/hostgroup neni dostatecna. Napr. admin skupinam chodi vsechno, non-admin skupinam chodi jen neco, ale z celeho hosta. Proste zakladni princip. Chodi toho ale tolik, ze i z hlediska oddeleni aplikacnich/systemovych notifikaci to neni ono. Rekneme, ze mam

fqdn (host)
a] web scenar 1
b] web scenar 2
c] vlastni monitoring specificke sluzby/parametru

Jak oddelit, aby c] nechodilo admin skupinam?
- prozatim jsem pridal tag, ktery v nastaveni akce pro notifikace danou sluzbu neposila napr. na admin skupinu. To ale neni asi reseni pro vice skupin.

Jaky princip se nejlepe u Vas uplatnil? Nastavit tag (nap. devel, customer, appX) na danou  sablonu a napsat spoustu akci pro notifikace vcetne kombinace tagu? Nebo milion uzivatelskych skupin? Proste pro mne zabbix postrada viditelne a jednoduche deleni az na uroven "sluzby".

Diky.

12
Server / Re:DMARC/SFP a hlavička Return-Path
« kdy: 03. 11. 2025, 11:58:53 »
Testoval jsem to s jednim sikovnym dmarc analyzatorem  a muzu potvrdit, ze pokud v hlavicce Return-Path bude jina domena nez v hlavicce From, tak spf sice autorizuje ip adresu, ale dmarc alignment neni validni.
Celkovy vysledek pak je: spf fail, dkim pass, dmarc pass (spf a dkim relax mode).

13
Server / Re:DMARC/SFP a hlavička Return-Path
« kdy: 03. 11. 2025, 09:17:37 »
Pěkně to má popsáno Seznam.cz - https://o-seznam.cz/napoveda/email/profi/zaznamy-pro-autentifikaci-posty/dmarc/

Ten clanek neresi samostatnou hlavicku Return-Path.

14
Server / DMARC/SFP a hlavička Return-Path
« kdy: 30. 10. 2025, 15:51:12 »
Zakaznikum zrejme budeme zpracovavat bounce emaily, ale potrebuji si overit, ze to chapu spravne, standardne se generuje Return-Path z MailFrom:

0] RFC 5322.From: zakaznik@example.org
1] RFC 5321.MailFrom: zakaznik@example.org
2] vlozime extra hlavicku Return-Path: bounce@some-example.org

SPF zaznamy jsou pro domeny v 0]1] a 2] nastaveny korektne.

Co jsem cetl blogy z ruznych ESP, jsem to pochopil tak, ze aby bylo "SPF aligment to pass DMARC", musi domena v 2] byt shodna v 0]. Nebo se pletu a ma to byt pri pridane 2] zarovnane v 0] a 1]?

Diky.

15
Jo, nasel jsem to v postgresql-common ve verzi pro debian 13, v debian tahle zmena neni.

Stran: [1] 2 3 ... 39