Příspěvky

PS: k čemu je proboha dobrý blok /48? To už je pomalu pro ISP a ne domácí/firemní přípojku.

Pro ISP je to dokonce málo, řekl bych. Jeden klasický panelák, 11 vchodů, každý 23 bytů, když každý byt dostane /56, tak to je pryč.

Zatím tu chybí odkaz na tohle video: https://www.youtube.com/watch?v=z5HH0cViGaI.
Ve zkratce:

• chlápek je hodně praktik, a využívá už 10let pískovou baterii (132 tun písku), do které ukládá přebytky, tepla, energie, z termických a fotovoltaických panelů
• má již skoro energeticky soběstačný dům, ale podcenil kapacitu, kterou by nakonec potřeboval
• je hodně znát, že ho moc netrápí, kolik to stojí, ale dělá spíš vývoj, aby pak věděl
• jde o sezónní akumulaci, takže co si uloží v létě, využije v zimě, ale nestačí to

Mně to dává smysl, když nemůžeme uložit elektřinu dlouhodobě, tak ukládat teplo, které vydrží na zimu, kdy je ho nedostatek, a je velkou částí rozpočtu.

Do zařízení je potřeba doinstalovat kořenový certifikát. Tady konkrétně "ISRG Root X1". Ten začal LE používat, ale to zařízení ho nezná.

To je blokované na straně banky. Pokud Oracle např. nemá implementované 3DS pro registrace, a zároveň to banka požaduje, tak ta transakce nemůže projít. I když je to jenom 1Kč. Zároveň to na začátku nemuselo projít z nějakého formálního důvodu, ale po neúspěšných pokusech je to již na BAN a teď už to je podezřelá transakce tuplovaně.

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?

IIS se sice sám na identitu uživatele bez AD dotázat neumí, ale stačí přeposlat autorizační hlavičky pro NTLM z klienta na server který to dokáže, a pak mu vrátit odpověď, která pak už u klienta zobrazí žádoucí přihlašovací dialog. Zbytek pak řešit dotazem na LDAP (skupiny, oprávnění atd.) jak je v jednom návrhu výše.
Jestli session pak řešit podepsaným tokenem, nebo záznamem v databázi je už detail.

otisk patří do povinných náležitostí OP. Par 19 mluví pouze o tom, že by musel být fyzicky nemožné otisk vzít.

A taková situace může nastat kdy?

Je to jednoduché, žadatel o OP povinnost poskytnout otisky prstů nemá.

Jakto?!

Zákon č. 269/2021 Sb., § 5 viz https://www.zakonyprolidi.cz/cs/2021-269/zneni-20210802#cast2

(1) V občanském průkazu se uvedou

a) údaje o držiteli občanského průkazu, kterými jsou

...

10. biometrické údaje; biometrickými údaji se rozumí zobrazení obličeje a otisky prstů rukou pořízené podle nařízení Evropského parlamentu a Rady (EU) 2019/1157,

Tohle ustanovení ale tu povinnost žadateli přece nikde neukládá. Naopak, zákon výslovně s takovým případem počítá v §19. Ani žádné sankce se tam neuvádí.

Je to jednoduché, žadatel o OP povinnost poskytnout otisky prstů nemá.

Kdyby sám docker uměl aktualizovat nějaké externí DNS přes nsupdate, a třeba zařídit i ty SRV záznamy ke každé službě, jo, to by byla jiná.

A nemohl by to řešit zvláštní proces, který bude ty kontejnery spouštět a doplňovat odpovídající záznamy do DNS?

Tohle by nějaký takový proces pochopitelně řešit mohl. A dokonce by to nebyla ani taková magie. Docker API je přístupné jak přes unix socket, tak i přes HTTP. O ničem stávajícím ale právě nevím, všechno co jsem našel vždycky umí jenom půlku toho, co by bylo potřeba, bez rovnáku.
Např. výše zmíněný external-dns umí pouze k8s API, ne Docker, a u podporovaných DNS providerů je krásně vidět, jak si to každý provider dělá po svém a má vlastní API, jako by k tomu neexistovalo RFC (2136), to umí, ale bez SRV. Kód k tomu má konkrétně cca 400 řádků v Go.

Kdyby sám docker uměl aktualizovat nějaké externí DNS přes nsupdate, a třeba zařídit i ty SRV záznamy ke každé službě, jo, to by byla jiná.

Pane Johnny, co zas vymýšlíte? Vlastní dockerová síť umožňuje spustit kontejner pomocí parametru --ip nebo --ip6 s pevnou adresou, což můžete mít v jednom konfiguráku, když používáte Compose. Žádné čarování s MAC, instalace čehosi do kontejnerů a já nevím, co ještě, netřeba.
Přímé spojení mezi kontejnery jsem taky kdesi viděl (jakýmsi parametrem), ale nechce se mi to hledat, není to potřeba, když jsou adresy jednotlivých služeb stejně v DNS.

Ale to ano, pokud dám každému kontejneru pevnou IP adresu, pak mi stačí /etc/hosts. Jenže to není situace, kterou budu mít na produkci.
Komunikace mezi kontejnery je možná pouze pro hostname, který tam vložím. Pokud se mají najít i podle externí domény, tak se jen tak neuvidí.

Věřím, že původnímu tazateli bude libovolné z nabízených řešení nejen stačit, ale i vyhovovat.
Ten problém je ale trochu širší. Co když budu mít přísnější požadavky? Které řešení zbyde? Za mě:

• nechci ani měnit konfiguraci stávajících běžících docker-kontejnerů, a to ani těch budoucích
• nechci do kontejnerů instalovat kvůli tomu žádný dodatečný software
• kontejner nemá vůbec znát který router/proxy na něj posílá požadavky/load balancing
• kontejner nemá znát ani doménu na které poběží (hostname je pro identifikaci ok)
• vše výše uvedené chci mít v samostatné konfiguraci na tom routeru/proxy/LB...
• kontejnerům se mění IP adresa, takže nepřipadá v úvahu ji někam do té konfigurace zapisovat
• jsem ochotný nastavit DNS, ale jen jednorázově, a tedy budou záznamy směrovat spíš na ten router, ne na jednotlivé kontejnery
• chci instalovat max. jednu službu, tedy NE agenty do kontejneru + proxy/router + bind/dnsmasq + dynDNS, ... to můžu mít rovnou celé k0-8s

Nejblíže tomuto stavu je podle mě ten traefik.
Pokud máte všude IPv6, tak existuje ještě možnost, že když každému kontejneru nastavujete fixní MAC adresu, tak dostává přidělenou stále stejnou IPv6 adresu (to jste věděli?), a s tím už se dá taky nějak pracovat, třeba skrz to DNS.
Pak ale chcete aby ty kontejnery mohly komunikovat i mezi sebou a zase hledáte rovnák...

Nějakou tu reversní proxy si může nainstalovat každý, ale to spoustu věcí neřeší.
I ten traefik to má nahnuté, naštěstí konfigurace, kterou nastavujete jako labely v dockeru při startu kontejneru, není povinná, a můžete ji mít v traefiku. Člověk by řekl, že si ty labely může jako metadata u běžícího kontejneru libovolně přidávat a měnit, což ale docker neumí (WTF?). Takže úplně všechno konfigurovat nelze.

A ideální řešení?

• služba se sama aktualizuje podle toho, co v dockeru běží - traefik
• uživatel dodá konfiguraci zvlášť - traefik (skoro)
• vše potřebné už běží, nic dalšího se neinstaluje - kubernetes

[tl;dr;]

Tady máte shrnutí všech důvodů, proč k tomu nepoužít JWT.
tl;dr; špatně navržený standard.
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid.

Lze použít klienta lftp, který to jednak při neúspěšném pokusu zkouší znovu, a umí parametr "--Remove-source-files", který po úspěšném nahrání soubor smaže.
Manuál zde: https://linux.die.net/man/1/lftp.
Pro upload je třeba parametr "--reverse".

Děkuji. Divím se že v tom Smalltalku někdo umí. Nevypadá to na zrovna rozšířený jazyk. Pracujete v něm, nebo jste se ho naučil jen tak?

Dostal jsem se k němu na akademické půdě, ještě předtím, než vzniklo Pharo. Ve Squeaku byl tou dobou docela chaos pro praktické využití, nyní je to už docela jiná káva. Pracuji v něm pro bussiness i pro zábavu. Především proto, že mi Smalltalk dává daleko větší smysl než "ten zbytek".