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 - Michal Šmucr

Stran: [1] 2 3 ... 34
1
Chování skriptů spouštěných z libovolného shellu se vám určitě nezmění. Pokud ho spustíte rovnou, o interpretru rozhoduje shebang (#!/bin/bash např.).
Co je tady spíš míněno je chování přímo v shellu, pokud používáte třeba nějaké ad hoc smyčky pro práci s více soubory atp.
Co si pamatuju, fish např. nemá tokeny do a done, naopak se musí blok uzavírat pomocí end, je tam jiná syntaxe pro vyhodnocování podmínek, s proměnnými kde jsou slova oddělená whitespacem to pracuje jako se seznamem atd.
Jestli tohle neděláte a máte skripty jen v souborech s shebangem, asi tohle nemusíte vůbec řešit.

2
Server / Re:Resolvery CZ.NIC nepřekládají weby Monety?
« kdy: 09. 12. 2025, 22:38:39 »
@vcunat

Díky za odpověd a nasměrování k RFC 8198. Překvapily mě ty rozdíly v odpovědích i mezi validujícími resolvery, tohle to pěkně vysvětluje.

3
Server / Re:Resolvery CZ.NIC nepřekládají weby Monety?
« kdy: 09. 12. 2025, 12:55:26 »
Chyba je na straně autoritativních serverů. Zdá se, že vracejí A záznam a rovnou k němu informaci v NSEC3, že takový záznam neexistuje. Tipoval bych na nějakou kreativitu na straně F5, který jim dělá autoritativní servery.

Teď jsem na to samé koukal na DNSViz

https://dnsviz.net/d/moneta.cz/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

Tam to tu chybu popisuje tak, že nesedí RR bitmapa s těmi záznamy.
Jen to vypadá, že DNS od NIC.CZ je na to citlivější, protože třeba Quad9 nebo Cloudflare to v pohodě vrací.. možná tohle ignorují.

U DNS4EU je to trochu zvláštní. U výchozí, protected: 86.54.11.1 se to chová stejně jako u NIC.CZ, ale ta uprotected 86.54.11.100 ten záznam vrací, přičemž by obě varianty měly používat DNSSEC.

Zajímavé, zatím jsem se podobnou věcí nesetkal.

4
Distribuce / Re:Ubuntu 25.04 na Ivy Bridge nejede?
« kdy: 04. 12. 2025, 02:52:40 »
Dobré zprávy. Tak hlavně se zdá, že hardware je v pořádku a rozběhl jsi tam nějakou distribuci. Věřím, že na nějaké základní používání s internetem by to mohlo být ještě v pohodě.

Jinak to manuální kopírování by se v budoucnu případně dalo ošetřit přes apt hook.. pokud se to bude aktualizovat.
V /etc/apt/triggers.d je trigger soubor (např. efi-grub-copy), kam napíšeš "interest grub-efi-amd64" (nebo jak se jmenuje ten balíček s grubem).
V /usr/share/apt/triggers.d pak handler se stejným názvem (normální shell skript s shebangem, co to tedy zkopíruje ten efi soubor v ESP oddílu)

S tím upgradem Ubuntu a jak to případně spravit bohužel moc neporadím.. Nepoužívám jej nijak pravidelně a často moje setkání, když s tím někde pracuju třeba na cizím notebooku nebo vynucené nějakýn uzavřený softwarem, vypadá jako náraz do zdi.. :) Ale třeba je to mnou..

5
Distribuce / Re:Ubuntu 25.04 na Ivy Bridge nejede?
« kdy: 04. 12. 2025, 01:16:56 »
Aha, už jsi na to přišel ;)

6
Distribuce / Re:Ubuntu 25.04 na Ivy Bridge nejede?
« kdy: 04. 12. 2025, 01:16:06 »
Ty HP notebooky z té doby měly něco nestandardního/domrveného v UEFI, že to nerespektovalo vytvořené boot entries v EFI vars, když se odkazovaly na interní disk. Zatímco u externího USB disku nebo CD, to sežralo výchozí /EFI/boot/bootx64.efi.

Neměl jsem sice v ruce tenhle Elitebook, ale u ProBooků to občas takhle blblo.
Narazil jsem dokonce jednou i na nějaký přiblblý whitelist na Windows bootloader (bootmgr.efi), kde to chtělo prostě v EFI oddílu zkopírovat soubor grub.efi, aby byla celá cesta: /EFI/Microsoft/Boot/bootmgr.efi Ale je to dávno, už si nepamatuju model.

Takže na tohle bych se podíval. Třeba ozkoušet boot menu a ruční volbu celého disku, takže by si měl vybrat (/EFI/boot/bootx64.efi) a pak to případně nastavit v BIOSu jako výchozí.
Nebo na test zkusit natáhnout grub z flešky a pak udělat chainload toho dalšího grubu, co je na disku, minimálně abys zjistil, jestli to aspoň jednou naběhne a instalace je v pořádku.

Nicméně proč to nechodilo s legacy BIOS bootováním (přes CSM), to je otázka. Výše zmíněné věci by na to neměly mít vliv.

7
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 02. 12. 2025, 22:56:08 »
Nedávno jsem zkoušel, jak na tom poběží klasická llama.cpp a nebyl problém svižně pracovat s modely do cca 50GiB. Přes vulkan a jen s otevřeným ovladačem. Jestli se používalo i NPU netuším.

Nejspíš ne. Co vím, tak upstream llama.cpp nemá žádný oficiální backend pro tahle NPU. S tím Strixem to bude používat buď Vulkan nebo HIP.
Ale AMD má nějaký svůj fork, kde to je dostupné.. ale použitelné omezeně.
viz https://github.com/ggml-org/llama.cpp/issues/14377
Co se týká hardwaru samotného, tak v mainline kernelu je pro to určitě modul.. drivers/accel/amdxdna

Jinak vůbec to neznám detailně a konkrétní HW se mi zatím nedostal do ruky. Ale nicméně jestli to chápu správně, tak hlavní benefit toho NPU je, že to má v porovnání s GPU daleko menší spotřebu, ale je to pomalejší a daleko míň univerzální.. Ta idea podle mě byla, že se to hodí primárně na nenáročný běh nějakých specifických menší modelů, co dělají třeba pre-procesing promptů, řeší třeba audio nebo obrazové vstupy přes CNN.. než se to finálně pošle do většího LLM. Buď v cloudu (jako třeba Copilot), nebo i lokálně, pokud bude běžet na GPU (byť jsem zatím žádný takový NPU+GPU hotový hybrid neviděl, ale extra jsem to nehledal).

8
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 02. 12. 2025, 16:36:05 »
Já rozlišuji mezi běžícími službami a dostupnými službami.Pokud totiž vypadne víc, než domácí jistič, nemusí být služby dostupné tak jako tak, ale nepřijdu o data vypnutím na tvrdo, případně se to nedostane do nějakého neočekávatelného stavu (domrvené aktualizace, atp).

Ono i řádné vypnutí, jen neplánovaně, je někdy problém, protože to zase musí někdo zapnout. S UPS je ten problém, že pokud se při delším výpadku vybije ale dojde včas k řádnému vypnutí, musíte před zapnutím systému počkat na nabití UPS do určité úrovně, aby byl systém chráněn v případně dalšího výpadku, to se pochopitelně týká i laptopového řešení. Tohle dokáže v konečném důsledku způsobit víc škody, než užitku.

Ona ta UPS bude mít určitě vyšší režii, než celá spotřeba toho stroje v idle. A laptopy se většinou nabíjí o dost rychleji, než olověné baterie v UPS.

Pak je otázkou, jesti to chtít z baterie táhnout co nejdéle, ale vykrýt jdeen jeden dlouhý výpadek a pak čekat na dostatečné nabití, nebo to začít vypínat už třeba po minutě bez napájení ze sítě s tím, že jakmile sít naběhne, mohu to hned začít zase spouštět, protože když dojde k dalšímu výpadku, mohu to zase bezpečně vypnout.

Ano, souhlas pokud se má opravdu zajistit dostupnost (dobře jste to upřesnil), je potřeba promyslet víc scénářů.
Já to jen nikdy neřešil takhle napůl (jedno zařízení se svou baterkou). Buď to bylo víceméně jedno resp. se počítalo s tím, že to může někdy nastat (s tím, že kritické poškození, když by se to specificky trefilo do "správného" momentu je málo pravděpodbné), nebo tam prostě byly UPSky. A to i co se týká těch malých DIY systémů (typicky - server/NAS, router/modem, switch, možná nějaká další řídící jednotka).. a zas, o.k. něco to žere, nemám teď úplně přehled napříč modely, ale když jsem si onehdá měřil nějaou malou line-interactive APC, tak to mělo asi 10W řežii (rozdíl výkonu před/za s konkrétní zátěží).
Ale jak jsem psal předtím beru, že notebook s baterkou většinou překlene ty vypnutí natvrdo.
Jediné, co by mě nenaplňovalo úplně klidem při provozu 24/7/365, je pak to, že jsem když jsem kolikrát viděl (i známí, příbuzní nosí různé notebooky na ugprade, opravu) jak se tam někdy baterka dokáže vyhřát od ostatních komponent, nafouknout tak, že to při rozebírání člověku pomalu nevyletí do.. jak je to vypružné, pak to z toho rvát. Zrovna nedávnou jsem v nějakém ACERu interní baterku radši vyndal a odpojil, než se případně sežene jiná.
To se mi zatím u UPSek nestalo, jasně odejde baterka, začne to pípat, přepne se to do bypassu.. pak výměna, ale nikdy jsem to z toho zatím nemusel takhle dolovat.. :)
Ale třeba ten Elitebook, co máte, je v tomhle ohledu úplně v pohodě.



9
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 02. 12. 2025, 16:07:22 »
Tak ono nekdy staci aby se to nevyplo tvrde ale rizene a nemusel tam veci startovat a resit problemy. Tvrdy pad u stroje neni hezky a u virtualizacniho stroje o to vice boli, ze VM disky se muzou cachovat a guest o tom vedet nemusi.

To určitě, taky to většinou beru jako plus, že se to regulérně vypne.

Ještě stran těch hypervizorů, cachování atp. Pokud je to všechno dobře nastavené a odladěné, tak by ty flushe a bariéry zevnitř virtuálu měly korektně probublat přes všechny vrstvy až do fyz. zařízení. Pak je to i v tom krajním případě (vypnutí natvrdo) víceméně podobné jako pokud to běží přímo na serveru. Byť samozřejmě konkrétní praktický dopad záleží také na aplikaci/službě.
Nicméně ne vždycky se to probublání povede (patch je mimochodem od pána z Proxmoxu)
https://github.com/openzfs/zfs/pull/17131

Do jisté míry se tomu dá předcházet trochu paranoidním nastavením u důležitých virtuálů/služeb, když to dovolí situace a požadavky na výkon. Tzn. vynutit synchronní zápisy.. (sync=always u ZFS zvol/datasetu nebo cache=writethrough příp. directsync u standardního qcow2 backendu). Obdobně jsem to řešíval i fyz. serverů, kdy jsem měl vyhrazené oddíly na datové adresáře konkrétních služeb, logy a u některých mountpointů pak natvrdo sync.
Ale bavíme se o poměrně specifických situacích, kdy to bylo často v nějakých pratkicky nekontrolovatelných podmínkách nebo třeba mobilní systém jezil v autě a celé se to napájelo agregátem, který klidně třikrát za dopoledne zhebnul :)
Nebo někde, kde to nevadilo a chtěl jsem si být jistý.

Citace
Jinak s takovym polovicatym zalohovanim (bez UPS) je dobre si overit, zda se stroj opravdu vypne. No nekdy je lepsi si overit celkovy normalni vypinaci protokol... protoze jakmile mate vice stroju a mezi nema napr. NFS s hard option, tak pri vypnuti nfs serveru se uplne zaseknou klienti a nejde je vubec vypnout. A myslim ze tomu nepomohlo ani umount -l, takze se zalohovat musi vsechny nody a konektivita a ono se to musi domluvit a odmountovat pred tim nez se to zacne vypinat. Tohle me dost prekvapilo a vypeklo.

Dobrá poznámka. A souhlas zombie jsou peklo. A taky jsem si dávno v něčem podobném vymáchal ústa.. :)
Správná sekvence vypínání. Nakonec jsem místo přímé komunikace z NUT (démon pro UPSky) do serverů a stanic musel udělat na jednom serveru orchestraci vypínání podle správného pořadí, kdy to přes ssh a WMI v určité sekvenci posílalo příkazy do ostatních strojů.

10
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 02. 12. 2025, 12:02:29 »
Provozuji dva domací mini pc jako servery - webhosting, gamehosting, všechny možné služby co si chci otestovat/vyzkoušet. A moje zkušenost a směr byla : pokud si to na sebe nevydělává, každý watt navíc není dobrý.

Spotřeba se dá hodně ladit, ale je to alchymie..

Já to beru, pokud to si tenhle atribut člověk dá jako zásadní kritérium.
Osobně u tom přemýšlím tak, že je to samozřejmě fajn udržet rozumnou spotřebu, ale nemám z toho zas úplnou obsesi, která přebije všechno ostatní.
Taky mám někde podobný, malý Alder Lake, je to bezva, žere to málo. Ideální pro nějaké malé NASy, pár služeb, router atp.
Ale samozřejmě, že podobné úsporné nebo primárně notebookové procesory jsou kompromisem (výkon, rozšířitelnost).
Takže při rozhodování by u mě záleželo, jaké ambice tam mám s aplikacemi/službami a co potřebuju nebo na tom chci zkoušet.
Třeba jakmile se to překlopí do toho, že na tom budu pravidelně něco sestavovat (CI/CD), nebo tam třeba budu mít virtuály, kde budou databáze s něajkými reálnými (většími) datasety vůči kterým budu testovat aplikace atp., tak přestože to na třeba úsporném CPU rozjedu, začne mě otravovat, že to trvá 2-3x dlouho.
Další moment je pak zmíněná rozšířitelnost.. pokud mám nějaké jasně ohraničené úlohy a vím, že to nebudu potřebovat, fajn. Na druhou stranu pokud tam budu někdy chtít třeba přidat další periferie i třeba na blbnutí (ozkoušet si pass-thru do virtuálu, dělat něco s GPU), rozšířit úložiště o další SSD atp. Tak pár normální PCIe slotu a linek je prostě fajn mít.
V tomhle světle mi pak přijde, že třeba 1500 navíc za roční provoz podobného stroje v porovnání s nějakým úsporným miniPC/NASem se absolutně ztratí, pokud to využiju.

O proti miniPC to mý výhodu, že je v tom i baterka, na kterou to nějakou hodinu klidně jede.

Jako jo, překlenu tím tvrdý shutdown stroje, to je ve většině případů plus. Ale pokud chci, aby ty služby běžely i s výpadkem napájení, tak stejně musím jistit i síťové prvky, ne? Takže vlastně malá UPS je stejně nutnost.

Minulý týden jsem upgradoval můj homelab na AMD Ryzen max+ 395 (Strix Halo) 128GB RAM, 2x SSD, total 5GB, network 5Gb+2.5Gb, který beží 24/7..

To je přesně to, o čem bych taky uvažoval, kdybych chtěl řešit běhl lokálních modelů. Jestli se můžu zeptat, co jste nakonec vybral za variantu? (board nebo miniPC.. příp. třeba BeeLink, HP)..
Jestli je to miniPC, tak jak je to třeba s hlučností a teplotou v zátěži? Ty TDP už pak můžou být vcelku vysoké, aby to potřebovalo rozumné chlazení, ne?

11
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 01. 12. 2025, 23:57:40 »
Pokud by se melo jednat o typicky multi-VM host - tak zas klidne muze zapinovat router a NAS na E-cores, zatimco P-cores necha pro nejake narocnejsi systemy (napr Win s passthrough GPU, na hrani).

Neni potreba spolehat na automatiku, kdyz to lze krasne a vedome uridit.

Jo to samozřejmě můžeš (a v Proxmoxu je to affinity dokonce hezky editovatelné z GUI/API) a může to dávat smysl i v některých jiných situacích než u hybridních CPU.
Ale chceš to řešit, když si můžeš za plus-mínus stejné peníze vybrat CPU s rovnocennými jádry a nechat si to schedulovat dynamicky podle vytížení? Pokud už daný hardware mám, tak jasně, zařídím se podle toho.. ale pokud si můžu vybrat, tak za mě fakt ne.

12
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 01. 12. 2025, 21:59:55 »
Pokud se jedná o desktop CPU tak určitě AMD - AMD má AVX-512.
I když jsem se dost namáhal, nezjistil jsem, k čemu by mi to AVX-512 natolik, abych jenom kvůli němu kupoval CPU mělo být. Zrovna to je klasická feature, kterou když (kromě specifických úloh) máte k dispozici, dobrý a pokud nemáte, je to víceméně jedno. Ono to AVX2 o tolik horší zase není. Kde se tahle obsese bere fakt nechápu. I když že se teda tady ptám...

Já bych to taky nebral jako hlavní kritérium (ve smyslu teď si běžím vyměnit CPU protože nemám AVX-512), ale prostě jako další plusový bod (i do budoucna, je to součástí x86-64 v4 a tohlo obvykle nekupuju na 2r).

A pokud bych třeba vybíral mezi novými desktop procesory na dané použití, tak bych se díval třeba na Ultra 5 a proti tomu Ryzen 7 9700x.. a dal bych si to vedle sebe, tak to AMD má např.
- všechna stejná jádra (pořád mi pro provoz hypervizoru přijde lepší varianta)
- menší spotřebu v zátěži (v idle to bude víceméně stejné u CPU s jedním čipletem)
- AVX-512
Cenově bych to s těmi zmíněnými požadavky seskládal nové do 40 tis. bez daně (z čehož bohužel bude aktuálně přes 20 za 128GB RAMky).

Těm požadavkům (hlavně energetickým) by mohl vyhovět i nějaký notebook.

Jako asi by se něco našlo, zas ty rozumnější notebooky, co by třeba podporovaly víc paměti a měly nějaký slušný výkon (rozuměj srovnatelný s běžným středním desktop CPU), pak budou z nějakých vyšších řad a nebude to levné ani starší.. člověk pak pro stacionární použití často platí zbytečně za displej, třeba i workstation graf. kartu uvnitř atp.
A energeticky.. jsem to pochopil tak, že principiálně nechce mít prostě velký, hlučný server class hardware s relativně vyšší idle spotřebou..
Pak jestli to bude "normální" desktop nebo notebook mi osobně nepřijde až tak zajímavé.. jestli ve výsledku zaplatí na provozu třeba o tisíc víc nebo míň za celý rok, to asi pro pracovní využití nebude hrát takovou roli.. příp. offsetuje to pak případnou vyšší pořizovací cenu? Je větší výhoda, že je jedna z variant mobilní a druhá třeba mnohem líp modifikovatelná/opravitelná, míň tepelně namáhaná?

13
Hardware / Re:Hardware s nízkou spotřebou pro domácí lab
« kdy: 30. 11. 2025, 01:19:55 »
Ty přesné konfigurace se průběžně mění podle generací, ale pro použití bych se teď nejspíš rozhodoval mezi dvěma variantami.

1) standardní PC, nějakou mATX desku, desktopový Ryzen, normální paměti (po nějakém předvýběru bych si projel QVL pro RAM pro konkrétní desky, ale 128 GB by mělo jít v pohodě). V tomhle případě bych to bral tak, že to není  kritická sestava, stroj na testování a vývoj, pokud to chvíli nepojede, nic se neděje. Bude to relativně levné, snadno se to recykluje na jiné použití nebo prodá.

2) mATX server desku s BMC (dělá třeba ASROCK Rack), ECC paměti, entry level server CPU (EPYC 400x, Intel E-24xx.. může rozhodovat víc faktorů, asi bych bral AMD, už jen kvůli AVX-512). V těch mATX jsou nejrůznější konfigurace, někde jsou třeba OcuLink připojení na další U.2/U.3 SSD přes rozešitinu, jiné mají zas třeba integrované 25GbE SFP porty atd.

Ta vhodná miniPC jsou víceméně záležitostí posledních pár let, teď je boom s AMD SoC (AI Max), co podporují až 128GB sdílené paměti. Chápu to jako způsob, jak třeba provozovat nějaké lokální modely, proto je po tom taková sháňka. Na druhou stranu, s tolika GB pevné, naletované paměti to nebude levné (tipoval bych tak 60+) a je to furt víceméně nerozšířitelné, s relativně omezenou možností servisování.
A zatímco třeba ty Mac Studia s podobnou koncepcí jsou už nějaký rok na trhu, takže se víceméně ví, jak se to chová v zátěži, že je to relativně slušně udělané i co se týká thermal designu. U tohohle bych prostě počítal s tím, že každá kulka nutně netrefí.
Takže za mě, pokud bych to nechtěl nutně na ty lokální modely, nešel bych do toho. V sestavě si vyměním víceméně jakýkoliv komponent, větráky, přidám třeba kartu na další SSD atp.
Stran velikosti to, krom nějakých specifických situací, podle mě nemá smysl hnát do extrému i kvůli zmíněné flexibilitě.. mini tower s mATX deskou při nejhorším prostě kopnu pod stůl, nebo na něj postavím fíkus :)

Věřím, že to někdo bude vidět úplně jinak :)

14
To byla výborná taškařice. Aktualizace microsoftího podpisu v EFI způsobila, že žádnej post-Vista OS microsoftu nestartoval. Pár virtuálů jsem u zákazníka musel oživovat přes recovery, protože odmítali vypnutí SecureBootu, a u asi 4 ani to nezabralo a při zákazu vypnutí SB to bylo na reinstalaci .
BTW se jim to pak povedlo ještě jednou, ale to už nebyl takovej průser, protože to 1) velmi rychle rollbackli a vydali opravenou záplatu, 2) spousta provozovatelů se už poprvý poučila a SB měla vypnutej.

Tak to muselo být ještě něco dalšího, protože to co jsem registroval já (ESXi 7.0u3) se fakt týkalo jen Windows Server 2022.. pak MS vydal ještě později nějaké své patche, protože ti lidi, co měli starší ESXi už od Broadcomu nedostali žádnou opravu.

15
Off-topic. Proč bys vypínal SB?...
Kolik widli adminujes? je to tak 2 roky +- ... kdy po aktualizacich pestaly bootovat vsechny widli virtualy na vmware (se zapnutym SB) a soudruzi se pak 3 mesice dohadovali, kdo za to muze.

Aktualne pak v tom ma MS takovej bordel, ze co tyden zverejnuje jinou informaci na tema expirace certifikatu. Takze mas dost velkou sanci ze nekdy po vanocich ti ten stroj jednoduse nenabootuje.

U mě ani nejde o celkové množství stanic/serverů, spíš o variaci různých konfigurací. Řekněme že od toho roku 2012, kdy MS přišel se SB ve Win 8 a Server 2012, mi za cca 3-4 generace počítačů mohlo projít rukama řekněme vyšší desítky kombinací různých HW konfigurací a verzí Windows (od práce, přes individuální servery a stanice v systémech jinde, video střižny až po nějaké rodinné notebooky).
Možná jsem měl kliku, ale opravdu jsem nikdy nemusel vypínat SB kvůli nějaké aktualizaci Windows nebo chybě, téměř ve všech případech to zůstávalo zapnuté (výchozí stav).
Pokud už jsem to vypínal, tak kvůli nějakému specifickému setupu (mutliboot s Linuxem bez podepsaného SHIMu, Hackintosh) nebo dalšímu hardwaru, který měl např. starý nepodepsaný UEFI firmware (starší FC, 10GbE karty - většinou vyřešil vendor updatem) příp. tam třeba v té přechodové době byly nějaké špatně podepsané ovladače třetích stran (jenom přebalený driver do W7/WS2008, což opět vyřešil vendor).

Ten problém s VMWare a Server 2022 jsem zaregistroval před 2r., ale naštěstí se mě to vyhnulo. Pár virtuálů ve správě mám, ale ty měly Server 2016 a 2019. I když možná toho víc řešil kolega, co primárně spravuje stovky virtuálů s Windows, kdežto já spíš řeším ty Linuxové. Ale i tak, kdyby to nastalo, tak pravděpodbně udělám jen revert snapshotu před updatem. Mám vcelku striktně rozdělené disky ve virtuálech pro systém, aplikační data a databáze (už jsem si párkrát s aktualizací v daném časovém okně nabil hubu :)).
Taky jsem registroval že byly někdy vloni potíže s aktualizací DBX (blacklisty v UEFI) z updatu Windows, kdy to nedoběhlo, a pak to vyžadovalo zadání BL recovery kódu, ale opět - u strojů, které spravuju, to prošlo vše v pohodě.

Citace
Vazne nevim, proc bych mel resit problem, kterej neexistuje. Pokud se nekdo dostane k libovolnymu stroji fyzicky, nabootuje si na nem co chce. A pokud se dostane do beziciho systemu, mas mnohem vetsi problem nez nejakej bootloader.

Tak protože u mě prostě vzhledem k tomu, jak relativně málo bylo za ty roky problémů přímo souvisejících se SB, tak nenastala situace, abych prostě en-bloc vyřadil jednu bezpečnostní fíčuru nebo rovnou bez znalosti situace radil, aby první co udělali na stroji s Windows, je vypnutí SB.
Není to jen o tom, že si někdo s fyzickým přísutpem z flešky nabootuje, co chce. Jakmile zapneš SB, tak se kontrolují podpisy u všech UEFI firmwarů před startem systému, bootloader, a stejným klíčem musí být podepsané i drivery, co startují rovnou po bootu (start=0). Je pak výrazně složitější tam nasadit nějaký rootkit, případně driver, který pak následně vyřadí třeba nějaký další (EDRko, antivir, které typicky také startují po bootu..) atp.
Samozřejmě pro určité situace většinou ve firemním prostředí pak dává smysl zároveň zaheslovat BIOS a použít šifrování na disku.

Citace
A sifrovani ... lol ... jako vazne povazujes za relevantni sifrovani, ktery si uklada klice k MS? A navic zas skoncis se strojem, kterej nenastaruje (coz se stalo nejspis milionum useru) a dozaduje se aby ses (nekde jinde) prihlasil k tomu ms uctu ... a stahnul si zalozni klic? (uz vidim jak to dela bfu ...)

Hele, jo. Myslím, že je daleko menší pravděpodobnost, že se někdo dostane k recovery klíči u MS a zároveň k počítači, než že bude nějaký jouda, co třeba ukradl pani notebook z auta, číst její nešifrovaná data z disku.

Citace
Vis jak vypada BFU kterej se nechal dotlacit k tomu, ze bude pouzivat ms ucet? Prijdes k nemu, chces po nem email ... "jakej?" ... tak heslo "jaky?" ... "vzdyt to rikalo ze pin staci" ... takze je v riti a k tomu ms uctu se uz nikdy nedostane.

:D vím. Jako bys se mnou chodil na rodinné návštěvy.

Ale přece nebudu nastavovat nějaké výchozí technické řešení podle nejslabších uživatelů.
Když je to ve firmě, tak máš pod kontrolou účty a v případě BL i ty kódy pro obnovení, dají se uložit do AD.
U jednotlivců to chce opravdu dobře popsat, a přesně říct, co mají dělat.. (pokud to neudělají, není to dál můj problém).
U rodiny a kamarádů jsem mnohem trpělivější, komplet to s nimi projdu včetně těch záložních cest, mailů pro obnovu.
Netýká se to zdaleka jen počítačů s Windows. Snažím se jim vštěpovat, že jejich on-line účet (MS, Apple, Google, nebo třeba Seznam s mailem) je mnohem cennější a důležitější než kterékoliv fyzické zařízení, co mají.
Většinou to zabírá, píšeme/tiskneme hesla na papír, přidávám 2FA, když to dává smysl.. atp.

Stran: [1] 2 3 ... 34