Příspěvky

1

Server / Re:Traefik není z venčí přístupný

« kdy: 24. 08. 2026, 14:18:32 »

Tak nakonec pomohlo nahazet konfigurace ruznych sluzeb do AI, aby udelala krizovou kontrolu. Traefik "nakonec" by default je dostupny na hostPort (ale ss nic neukaze !!! grrr), poznalo se to podle toho, ze proti curl vracel http kod 404, nasledne se opravily porty, na kterych naslouchalo interne argocd, premapovala se externi haproxy, aby sla proti worker a ne proti master. Takze momentalne to bezi, ale ta komplexita a (ne)viditelnost, ta je silena.

2

Server / Re:Traefik není z venčí přístupný

« kdy: 24. 08. 2026, 08:48:32 »

Vzhledem k prejmenovani tematu doplnim: zkousim roli lablabs.rke2

Dival jsem se na ten odkaz, a uplne se mi do dvou ingressu na zacatek jeste moc nechce. Me se zda divne, ze by ta hodne znama role potrebovala neco takoveho, aby na ten cluster byl pristup, v dokumentaci o tom samozrejme neni ani slovo. Ja mam zatim zkusenost jen s tou k3s, ta pouzivala kube-vip a proste vse chodilo out-of-box.

Snad nekdo prida nejaky dalsi tip nebo zkusenejsi AI.

3

Server / Traefik není z venčí přístupný

« kdy: 21. 08. 2026, 15:29:44 »

Ahoj,

zkousim tuto roli a mam seskladany cely (v 1.35.7, dualstack) rke2 cluster s externi haproxy (api, registrace) a funguje to. Ale cely den se morim i s podporou AI, ze zvoleny (pri instalaci) ingress traefik (daemonset) neni dostupny externe:

Kód: [Vybrat]

# /var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml describe ds rke2-traefik -n kube-system
...
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
...
  Containers:
   rke2-traefik:
    Image:       rancher/hardened-traefik:v3.7.8-build20260717
    Ports:       9100/TCP (metrics), 8080/TCP (traefik), 8000/TCP (web), 8443/TCP (websecure)
    Host Ports:  0/TCP (metrics), 0/TCP (traefik), 80/TCP (web), 443/TCP (websecure)
    Args:
      --entryPoints.metrics.address=:9100/tcp
      --entryPoints.traefik.address=:8080/tcp
      --entryPoints.web.address=:8000/tcp
      --entryPoints.websecure.address=:8443/tcp
...

# /var/lib/rancher/rke2/bin/kubectl --kubeconfig /etc/rancher/rke2/rke2.yaml get svc rke2-traefik -n kube-system
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
rke2-traefik   ClusterIP   10.43.178.210   <none>        80/TCP,443/TCP   68m

V principu mne AI navedla na pouziti nodePort:

Kód: [Vybrat]

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-traefik
  namespace: kube-system
spec:
  valuesContent: |-
    service:
      type: NodePort
    ports:
      web:
        nodePort: 30080
      websecure:
        nodePort: 30443

resp. v obdobne variante na hostPort. Problem je, ze se mi to sice nakonfiguruje, ale traefik mi bud jako sluzba zmizi ze systemu, pripadne tam zustane, ale stale je ve formatu ClusterIP. Zatim se mi nechce jit pres kube-vip.

Nevi nekdo, co s tim, uz jsem (jako zacatecnik) v koncich. Chci na to prejit z k3s, ktery tu mam jako PoC.

Diky.

4

Server / Zabbix jako notifikační systém

« kdy: 13. 05. 2026, 14:11:32 »

Cau,

mam tu takovy specificky zadani monitoringu specificke aplikace a uvedomil jsem si, ze s jednou veci se na zacatku nepocitalo. Rekneme, ze v principu se jedna o jednorazovou (v intervalu opakovanou) notifikaci:

1] monitorovana polozka v intervalu treba 1x denne
2] pokud je trigger vyhodnocen jako true, posle notifikaci
3] automaticky reset triggeru na false - bez resetu by neposlal v dalsim intervalu (tady asi by to chtelo typ multiple?)

A bod 3] mi ted vrta hlavou. Zatim jedine reseni, co mne napada, je spustit 1] alespon 2x denne (napr. 1:00, 5:00) a dat do toho podminku, ze pokud je po 5:00, tak je OK stav a udelat extra akce, aby se neposilal stav obnovy.

Ma nekdo lepsi napad/znalosti? Z dokumentace se zda, ze s takovymhle monitorovanim stavu se nepocita.

Diky.

5

Software / Re:Expirace interního kořenového certifikátu

« kdy: 06. 05. 2026, 15:24:45 »

Nevim, co presne myslite tim "renewal nahrazenim", ale pokud se "Issuer", "Subject Key Identifier", "Authority Key Identifier" a hlavne klice CA (at ut Root ci Intermediate) nezmenily, muzete mit dva (i vice) soucasne platnych Root a Intermediate CA certifikatu, stale jde o stejnou CA a system si je pro dany certifikat najde, overi podpisy (a interval platnosti) a sestavi retezec az ke korenovemu CA v trusted store at uz jde o operacni system ci firefox apod. Takze zkontrolujte vyse uvedene a za predpokladu nezmenenych klicu plati a) i b) z vaseho dotazu soucasne.

A jeste pro jistotu: keyID z "Authority Key Identifier" (pokud existuje) Leaf certifikatu musi byt stejne jako "Subject Key Identifier" certifikatu CA vydavatele.

A vezmete prosim v uvahu, ze nejsem Buh a radeji si to jeste overte a otestujte Ale principialne to tak je.

Tak zkouseno, prodlouzeni (s nahrazenim za puvodni certifikat v XCA) Root, Intermediate, Leaf a dodrzeni:

Kód: [Vybrat]

A jeste pro jistotu: keyID z "Authority Key Identifier" (pokud existuje) Leaf certifikatu musi byt stejne jako "Subject Key Identifier" certifikatu CA vydavatele.

Toto bylo dodrzeno. Musel jsem jeste v XCA pri prodlouzeni nastavit, aby "serial" byl identicky, nebot byl soucasti keyID.

Pak otestovano:
Klient s Root V1 akceptoval vzdalenou sluzbu s Intermediate V2 + Leaf 2 jako validni.
Klient s Root V2 akceptoval vzdalenou sluzbu s Intermediate V1 + Leaf 1 jako validni.

Tedy v tomto pripade lze primo nahradit veskere vyskyty V1 za V2, aniz by bylo nutno nejdrive instalovat Root V2 na kazdem serveru v infrastrukture. Jen je skoda, ze nemuzu primo prejit na ecdsa, par serveru s omezenou podporou tu jeste je a uplne se mi nechce riskovat problemy.

6

Software / Re:Expirace interního kořenového certifikátu

« kdy: 05. 05. 2026, 09:02:27 »

ad "renewal nahrazenim"

Delam to v XCA. Pokud nepouziji nahrazeni, vytvori se certifikat V2 vedle V1 na stejne urovni stromu. Certifikacni struktura podepsana danym V1 tak zustane napojena na V1. Pokud pouziji nahrazeni, tak V1 je nahrazen novym V2 a struktura se propoji na dany V2.

7

Software / Expirace interního kořenového certifikátu

« kdy: 04. 05. 2026, 15:23:37 »

Cau,

mam interni CA kde bude expirovat root certifikat behem tohoto roku. Konfigurace je Root V1 -> Intermediate V1 -> Leaf V1 zivotnosti do Datum V1. Budu to poprve menit a jeste na stovkach systemu.

V ramci oddeleneho pokusu, ktery nema vliv na aktualni konfigurace, jsem udelal prodlouzeni "renewal" s tim, ze jsem na zkousku zvolil nahrazeni. Nahradil jsem tedy postupne od korene certifikaty:
Root V1 -> Root V2
Intermediate V1 -> Intermediate V2
Leaf V1 -> Leaf V2
(ostatni certifikaty v celem strome zustaly beze zmeny na V1)

Datum generovani je od Datum V2, kde Datum V2 < Datum V1 a zaroven do V2 je daleko za zivotnosti V1.

Nasadil jsem Intermediate V2 + Leaf V2 do jednoho testovaciho webu. Na klientovi jsem mel Root V1, certifikat byl akceptovan jako validni (Root V1 -> Intermediate V2 -> Leaf V2), coz jsem necekal. Chtel bych si overit, ze to spravne chapu - prodlouzeni(nahrazeni) Root + Intermediate + Leaf certifikatu v retezci zachovava duveryhodnost celeho celeho stromu vuci korenovemu certifikatu ? Tedy:

a] pokud klient ma Root V1, bude duverovat i systemum, ktere nasadi komplet V2?
b] pokud klient ma Root V2, bude duverovat i systemum, ktere jsou momentalne na V1?

Pokud by platily body a] a b] najednou, tak by to velmi usnadnilo prechod na V2.

Jo a kdyby to nekoho zajimalo, Safari neakceptoval Leaf V2 s zivotnosti 5Y, akceptoval jen s zivotnosti 2Y. Tedy, omezeni platnosti na interni certifikaty na 825D.

8

Server / Re:Dovecot sieve a odchozi emaily

« kdy: 20. 03. 2026, 14:41:12 »

No ma se poslat kopie na dalsi adresaty. Dal bych prednost, aby to bylo soucasti mailove schranky, nez schovane nekde v nesouvisejici postfix konfiguraci. A ano, vim, ze primo v postfixu to nakonfigurovat lze.

9

Server / Dovecot Sieve a odchozí e-maily

« kdy: 20. 03. 2026, 13:10:09 »

Zdravim,

ma nekdo realnou zkusenost? Zkusil jsem nastavit pres roundcube filtr na "Sender", nasledne na "all messages" (tedy bez filtrovani), ale odchozi testovaci email tim filtrem zrejme neprojde.

Na googlu je par pripadu, kde se pise, ze to pry podporuje (proton atd)., ale v dokumentaci sieve jsem nasel jen:

"Useful, when you want sieve to manage your incoming and outgoing email (you must ask your mail reader to Bcc your mail to your dovecot in this case)."

Posilani pres bcc, ktery nesmi uzivatel zapomenout, mi pripada jako kockopes (to uz muzu nastavit bcc v profilu).

Jde tedy pouzit sieve na odchozi emaily (posilane pres submission/smtpd)? Nebo pouze konfigurace primo v postfixu?

Diky

10

Server / Re:Kubernetes a správa uživatelů

« kdy: 16. 02. 2026, 11:11:04 »

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

Tak je to otrava.
ciste ipv4 - oba k3s a rancher s agenty funguji hned
ciste ipv6 - agent se nepripoji na rancher
dualstack ipv6/ipv4 - agent se nepripoji na rancher
dualstack ipv4/ipv6 - oba k3s a rancher s agenty funguji hned

Tak to ta jejich proklamovana funkcni podpora ipv6 only a ipv6,ipv4 je za mne podle postupu z dokumentace nefunkcni v pripade pouziti ULA pro cluster/service-networks. Na pouziti GUA uz nemam nervy.

11

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

12

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

13

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

14

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.

15

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

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.