Certifikát vyexpiroval o víkendu. Nikdo si toho nevšiml, dokud v pondělí ráno nenaběhl deployment.

Token do GitLabu, přes který běží CI/CD do Kubernetu, měl platnost tři měsíce. Nastavil ho někdo v týmu, na expiraci upozornění nenastavil nikdo. Když vypršel, pipeline prostě přestala fungovat - žádná chybová hláška, která by řekla “tohle je ten problém”, jen tichý pád na kroku, který dřív fungoval.

Stejná story se SSL certifikáty. Dneska už se dají nastavit skoro jen na omezenou platnost - třeba 90 dní u Let’s Encryptu - a pokud obnovu neautomatizujete, jednoho dne vám prohlížeč začne hlásit, že spojení není bezpečné. U zákazníků na produkci je tohle přesně ten výpadek, který přijde v nejhorší možnou chvíli, protože o něm nikdo dopředu nevěděl.

Řešení není složité: certifikáty obnovovat automaticky (certbot, cert-manager v Kubernetu), tokeny mít v přehledu s datem expirace a monitoringem, co upozorní týden dopředu, ne v den D. Není to nic, co byste museli řešit ručně pokaždé znovu - stačí to jednou nastavit a pak se tomu nevěnovat.

Přesně tenhle typ prevence - jak si nastavit monitoring na věci, které vám jinak vybuchnou beze varování - rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Váš admin vám káže vodu a sám pije víno.

Naposledy jsem to viděl minulý týden. Otevřu web člověka, který mi nabízí monitoring serverů - a prohlížeč mi hlásí, že certifikát vypršel před třemi dny. Jeho vlastní web. Ten, který má být jeho vizitkou.

Kovářova kobyla chodí bosa. Jenže tohle už není vtipné rčení, tohle je diagnóza. Vídám to pravidelně - vyexpirovaný certifikát, chybová hláška 500, web rozbitý po poslední aktualizaci WordPressu, kterou zapomněl otestovat. Přitom tenhle člověk chce, abyste mu svěřili produkci. Servery, na kterých vám běží byznys.

Když admin nemá na svůj vlastní web monitoring, nekoupil bych si od něj monitoring vašeho webu. A není to jen otázka lajdáctví - je to otázka priorit. Pokud vlastní vizitka nestojí za pět minut jeho času, proč by vaše produkce stála za víc.

Než někomu svěříte servery, otevřete si jeho web. Certifikát, rychlost načtení, funkční formulář. Pár vteřin vám řekne víc než hodina pohovoru - a ušetří vám nejeden výpadek, který přijde v nejhorší možnou chvíli.

Podobné signály, na které se dívám při výběru dodavatelů, rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Nechal jsem AI agenta, ať se přihlásí přes SSH na server a upraví konfiguraci. Řekl jsem mu, ať se před každým zásahem zeptá.

Neptal se. Prostě to udělal.

Instrukce v promptu nejsou zámek, jsou doporučení, které agent při troše snahy obejde. Když má SSH klíč a přístup, dřív nebo později se stane, že něco spustí bez potvrzení - a na produkci s živými daty je tohle přesně ten scénář, který nechcete zažít.

Řešení, které používám, je jednoduché a nezávisí na tom, jestli se agent zeptá nebo ne: zašifrovaný SSH klíč a alias, který spouští Clauda s prázdným SSH_AUTH_SOCK. Agent tak nemá k dispozici žádný agent SSH, přes který by se mohl kamkoliv připojit - i kdyby chtěl, fyzicky se nemá čím autentizovat.

V domácí síti se přes Clauda podílím na správě serveru přímo, většinou bez problémů. Sem tam se něco rozbije nebo smaže - ale mám dostatek záloh, takže je to otázka minut, ne katastrofa. Ve firmě, na produkci a na živých zákaznických datech je tohle úplně jiná váha rozhodnutí, a tam bych stejnou volnost agentovi nikdy nedal.

Podobná opatření, jak bezpečně pouštět AI agenty k infrastruktuře, rozepisuju v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Klient chtěl Kubernetes. Ptal jsem se proč.

“Protože to používají všude.” Jenže “všude” v jeho případě znamenalo jednu aplikaci, dva vývojáře a pár desítek uživatelů denně.

Kubernetes na tohle je kanón na vrabce. Naučit se ho, provozovat ho a udržet ho v bezpečném stavu stojí čas a peníze, které se u projektu tohohle rozsahu nikdy nevrátí. Docker container spolu s jednoduchým docker-compose zvládne to samé s desetinovou režií - a hlavně tomu rozumí i jeden člověk, ne celý tým.

Občas si klienti myslí, že řešením je odlehčená verze - k3s nebo microk8s. Jenže to je pořád Kubernetes. Jak přibývají služby a lidé, kteří k tomu potřebují přístup, komplexita se nabaluje stejně jako u plné verze - jen o to nenápadněji, protože to na začátku vypadalo jednoduše.

Kubernetes dává smysl tam, kde ho firemní prostředí opravdu potřebuje - víc týmů, víc prostředí, jasně oddělená oprávnění, kdo smí co nasadit a kam. Docker sám o sobě se tohle řídí špatně - RBAC v něm prakticky neexistuje, a v momentě, kdy potřebujete auditovat, kdo měl přístup k čemu, narazíte na strop.

Takže než sáhnete po Kubernetes, protože “to používají všude”, zeptejte se, kolik lidí a služeb u vás skutečně potřebuje tu vrstvu řízení oprávnění navíc. Často je odpověď: nikdo, a Docker vám bude stačit roky.

Podobné rozhodování - kdy sáhnout po jednodušším nástroji a kdy ne - rozepisuju v newsletteru “Sám sobě ajťákem”. Chodí zhruba jednou měsíčně, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Dneska mi čtenáři newsletteru napsali, že dělám chybu, kterou dělá skoro každý, kdo si doma nastavuje vlastní domény - včetně mě donedávna.

Používal jsem .home pro věci jako zabbix.home nebo pgadmin.home. Zní to logicky, každý to tak dělá. Jenže .home není nikde oficiálně vyhrazená pro soukromé sítě. Zkuste si napsat cokoliv na .home do adresního řádku Firefoxu - on to nevezme jako adresu, ale jako hledaný výraz a pošle vás rovnou do Google. Prohlížeč prostě nevěří, že jde o skutečnou doménu, protože oficiálně žádná taková není.

Doména, která tohle řeší, existuje - jmenuje se .home.arpa a je definovaná přímo IETF v RFC 6761 jako vyhrazená pro domácí sítě. Tu už si prohlížeč nesnaží opravovat na vyhledávání - bere ji jako adresu, protože jí oficiálně je.

Pro firemní prostředí bohužel obdoba .office neexistuje, ale funguje .alt - taky vyhrazená a bezpečná varianta pro interní použití.

Tahle oprava mě nemrzí. Nejsem neomylný a rád, když mě na něco takového někdo upozorní - přesně proto o tom, co dělám, píšu veřejně.

Podobné opravy vlastních chyb i praktické kroky ke správě domácí sítě sdílím v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, žádné výplňové e-maily, jen věci, které si sami ověříte a nastavíte. martinkonicek.eu/newsletter/

Četl jsem si v Kindlu Cashvertising. Zvýraznil jsem si pár pasáží, hodil je do Claude a poprosil, ať mi je zformátuje do přehledných poznámek.

Odmítl. Text je prý autorsky chráněný.

Model, který se natrénoval na půlce internetu - často bez souhlasu autorů - mi teď kázal o autorských právech nad mými vlastními zvýrazněnými větami z knihy, kterou jsem si legálně koupil.

Hodil jsem to samé do Groq Compound. Bez řečí to zpracoval za pár vteřin.

Není to náhoda. WSJ tenhle týden psal o tom, jak firmy hromadně opouštějí drahé uzavřené modely (Claude, GPT) ve prospěch levnějších open-weight alternativ. Loajalita k jednomu poskytovateli AI je nulová - a je to tak správně. Proč platit za model, který vám nejen kecá do práce, ale ještě si účtuje stovky korun za hodinu provozu, když existuje varianta, kde máte plnou kontrolu nad výstupem i cenou.

V newsletteru “Sám sobě ajťákem” jsem tenhle příběh rozepsal do širšího kontextu - co přesně je open-weight model, proč se u menších projektů dá dostat z tisíců korun měsíčně na stokoruny, a proč tenhle trend hraje ve prospěch firem, ne poskytovatelů. martinkonicek.eu/newsletter/

Když jsem hledal práci, psal jsem motivační dopisy přes AI. Ne tak, že bych napsal “napiš mi motivační dopis” a odeslal, co vypadlo.

Měl jsem v Claude projektovou složku s podklady o sobě - co jsem dělal, na čem jsem pracoval, jak o sobě mluvím. Ke každé pozici jsem pak přidal jako další podklad konkrétní inzerát. AI z toho generovala dopisy, které zněly jako já a mířily přesně na to, co firma hledala. Úspěšnost nebyla malá.

Co mě překvapilo, když jsem se o tom bavil s lidmi kolem - jsem v menšině. Většina buď napíše dvě tři věty sama, nebo to nechá kompletně vygenerovat z prázdného promptu, bez jediného podkladu.

AI je jako vrtačka. Skvělý nástroj, který vám může výrazně usnadnit práci. Problém není nástroj, ale to, že si ho většina lidí neumí nebo nechce pořádně nastavit. Kvalita výstupu se přitom láme přesně na tomhle - kolik kontextu jí dáte, ne na tom, jaký model zrovna používáte.

S AI rozhodně neumí každý, i když si to skoro každý myslí.

Přesně tomuhle se věnuju v newsletteru “Sám sobě ajťákem” - jak si AI nastavit, aby dělala práci za vás, ne jen odpovídala na to, co jí hodíte. martinkonicek.eu/newsletter/

Mačkat DEL nebo F10 hned po zapnutí notebooku, abyste trefili ten půlvteřinový moment, kdy vás pustí do BIOSu - to je přesně ten pocit jako důchodce v casinu v Las Vegas, co zoufale mačká tlačítko na automatu ve chvíli, kdy se točí válce, protože jednou to prý vyšlo.

Dobrá zpráva: dneska to takhle dělat nemusíte.

Windows má cestu, která funguje pokaždé, bez ohledu na to, jak rychle se váš notebook nabootuje. Jde se přes Nastavení > Systém > Obnovení > Rozšířené spuštění > Restartovat nyní. Počítač se restartuje do modré obrazovky, tam kliknete na Poradce při potížích > Rozšířené možnosti > Nastavení firmwaru UEFI > Restartovat - a nabootujete přímo tam, kam jste mířili.

Ještě rychlejší zkratka: podržte Shift a kliknete na Restartovat ve Start menu. Vede to na stejnou obrazovku, jen o dva kliky dřív.

Žádné odhadování timingu, žádné druhé kolo restartů, protože jste to netrefili poprvé.

Podobné praktické zkratky sdílím v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, jen věci, co vám reálně ušetří čas u vlastního počítače nebo serveru, žádné výplňové e-maily. martinkonicek.eu/newsletter/

Váš “vypnutý” notebook není vypnutý. Jen o tom mlčí.

Zavřete víko, klepnete na Vypnout, hodíte notebook do batohu, a druhý den má o 15 % míň baterie, i když jste s ním celý den nehnuli. Není to vadná baterie ani rozbitý hardware.

Windows totiž ve výchozím nastavení nevypíná počítač doopravdy. “Vypnout” spustí Fast Startup - hybridní vypnutí, které je ve skutečnosti forma hibernace. Jádro systému se uloží do souboru na disku a část stavu zůstává zmrazená, ne mrtvá.

K tomu se na většině dnešních notebooků přidává Modern Standby - nástupce starého spánkového režimu S3, který drží Wi-Fi a část systému nízkoenergeticky naživu i ve “spánku”, aby vám mohl doručit notifikaci nebo e-mail a probudit se za zlomek vteřiny. Zavřené víko tedy neznamená spící počítač, znamená počítač, který dál poslouchá síť.

Fast Startup a Modern Standby dohromady - a máte notebook, který vypadá vypnutý, ale reálně žere baterii v tašce.

Řešení je jednoduché. Buď vypnete Fast Startup v nastavení napájení, nebo použijete Shift + kliknutí na Vypnout - to hybridní vypnutí obchází a systém se skutečně celý vypne.

Podobné praktické opravy sdílím v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, žádné výplňové e-maily, jen věci, co vám ušetří čas s vlastním počítačem. martinkonicek.eu/newsletter/

Kdo se u vás na serveru přihlásil jako root včera ve 3 ráno?

Pokud je odpověď “nevím, prostě root”, máte problém. Root účet totiž neumí říct, který konkrétní člověk co udělal - v logu vidíte jen “root”, ne jméno.

Řešení, které nastavuji klientům jako standard:

✅ Zakázat su přes pam_wheel - obyčejný uživatel se na roota nepřepne, ani kdyby heslo znal ✅ Root pouze z hardwarové konzole - fyzicky u serveru, nikde jinde ✅ Všichni ostatní přistupují přes sudo - pod svým jménem, se svým klíčem ✅ Zakázat PermitRootLogin přes SSH ✅ Zakázat Password Authentication přes SSH - přihlášení jen klíčem

Efekt je jednoduchý. Každý příkaz na serveru jde dohledat ke konkrétnímu člověku, ne k anonymnímu rootovi. A slabé heslo přestává být riziko, protože se přes heslo vůbec nedá přihlásit - jen přes klíč, a pak přes sudo.

Tohle nastavuji na serverech, které spravuji pro klienty.

Přesně tyhle kroky, krok za krokem, najdete i v newsletteru “Sám sobě ajťákem” - chodí zhruba jednou měsíčně, žádné výplňové e-maily, jen věci jako tahle, které si na svém serveru zvládnete nastavit sami, bez drahého dodavatele. martinkonicek.eu/newsletter/