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 - Filip Jirsák (forum)

Stran: [1] 2 3 ... 22
1
Windows a jiné systémy / Re:Skok systémového času Windows
« kdy: 09. 01. 2026, 12:05:26 »
VMware si udržuje pro každého hosta stav RTC jako ofset k času hostitele.
Při startu hosta vezme RTC z hostitele, přičte ofset. Při zápisu do RTC si uloží jen ten ofset.
Každý host může mít jiné časové pásmo i úplně jiný čas.
Do VM configu jde přidat relativní čas k hostiteli rtc.diffFromUTC nebo absolutní čas rtc.startTime.
Díky, nevěděl jsem, že už tam tato možnost je. (Teď se ukáže, že „už“ je 20 let…)

Škoda, že tu není možnost jenom dát komentáři palec nahoru, bez dalšího okecávání.

2
Windows a jiné systémy / Re:Skok systémového času Windows
« kdy: 09. 01. 2026, 09:34:42 »
Tohle váš problém nevyřeší, ale není od věci ve Windows nastavit systémový čas na UTC:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f
(nutný restart)

Pak tam nebudou žádné posuny o 3600.
V případě dual boot je to skoro nezbytné.
Tohle nastavení by mělo být shodné s tím, v jakém časovém pásmu poskytuje čas hypervizor. Pokud hypervisor poskytuje hostovi čas v UTC, mělo by to být nastavené, jak píšete. Pokud hypervizor poskytuje lokálí čas, měla by tam být výchozí hodnota.

Každopádně tohle ovlivňuje, jak se čas načte ze systémových hodin při startu systému. Pak naběhnou služby a ty to srovnají buď podle NTP, nebo podle hypervizora (pokud se používá ta služba z VMware Tools).

(Když běží systém nafyzickém železe, ovlivňuje výše uvedené samozřejmě i zpětný zápis, když operační systém zapíše svůj čas zpátky do hodin počítače. Ve virtualizovnaém prostředí to ale nemá žádný efekt – nevím o tom, že by nějaká virtualizační technologie udržovala systémové hodiny pro každého hosta zvlášť.)

3
Windows a jiné systémy / Re:Skok systémového času Windows
« kdy: 07. 01. 2026, 13:14:52 »
Teď už zbývá jenom zjistit proč to dělá.
Přepdokládám, že proto, že máte zapnutou synchronizaci času s hostitelem, jak psal Marvin. A ty časové skoky by pak byly způsobené tím, že má špatně nastavený čas hostitel – jak psal František Ryšánek, je potřeba zkontrolovat, zda hypervizor má správný čas, a zda má nějaký mechanismus, jak čas udržovat správný (např. z NTP).

Pokud to tak je, u vás by se problém vyřešil tím, že vypnete synchronizaci času s hostitelem a necháte Windows, ať se o čas starají na základě NTP (tj. to standardní nastavení, které vám ráno nastavuje zpět správný čas). Nicméně chtělo by to vyřešit správný čas i na tom hypervizoru, protože dneska mít někde špatný čas je celkem nebezpečné (jsou z toho různé podivné chyby) a v drtivé většině případů zbytečné (pokud nemáte počítač v bunkru pod zemí odpojený od sítě, vždycky se aspoň nějaký zdroj přesného času dá sehnat).

A až bude vyřešen problém se synchronizací času v hypervizoru, rozhodněte se, který ze způsobů synchronizace času chcete použít, a použijte jenom jeden. Buď vlastí synchornizaci v hostovaném systému (Windows) nejspíš přes NTP, nebo synchornizaci času s hypervizorem. Protože ještě horší, než mít špatný čas, je mít špatný čas pokaždé jinak, podle toho, který zdroj času zrovna vyhraje.

4
Windows a jiné systémy / Re:Skok systémového času Windows
« kdy: 06. 01. 2026, 16:31:32 »
vím že Windows není tady primární zaměření, ale mám zajímavý problém ve virtuálce s Windows 11 pod VMware. Od 29.12.2025 se každý den někdy kolem třetí v noci posune systémový čas o 2773 vteřin a ráno kolem 7 - 8 se vrátí zpět.
Je ten rozdíl plus mínus pár vteřin pořád stejný? 2773 vteřin je tak divné číslo, že jediné reálné vysvětlení, které mne napadá, je že se to synchronizuje ze dvou různých zdrojů, a jeden z nich jde špatně. Nabízí se ty hardwarové hodiny, tj. ve vašem případě čas ve VMware.

Ve vmwarovy virtualce ti za normalnich okolnosti (=by default) jakykoli pokus o nastaveni hodin failne, protoze cas si resi ten vmware, a system ma drzet hubu a pouzivat ho.
Nikoli, systém si zjistí čas z hradwarových hodin akorát při startu, a pak už si udržuje čas sám, nanejvýš občas synchronizuje hardwarové hodiny se svým časem, aby v hardwarových hodinách po restartu bylo aspoň něco trochu správného. Systém si totiž umí udržovat čas daleko přesněji, než jak to dělají hardwarové hodiny.

Rozhodně to tak dělá Linux, a nedovedu si přestavit, že by to Windows dělaly jinak.

5
Sítě / Re:SIM karta anonymně bez registrace
« kdy: 29. 12. 2025, 21:11:55 »
Před kým chcete být v soukromí? Pokud před provozovatelem těch webů, pak vám stačí libovolná SIM karty klidně na jméno – provozovatel webu se nemá jak dozvědět, na koho je SIM registrovaná u mobilního operátora.

6
Software / Re:Má vůbec smysl reportovat někam chyby?
« kdy: 29. 12. 2025, 18:16:28 »
Osobne bych si naivne predstavoval, ze pokud nejaky laik prijde s navrhem opravy, tak tento navrh muze poslat obycejnym emailem a ocekaval bych, ze se tohoto hlaseni nekdo ujme a lidsky ho vyhodnoti. Ok, treba za mesic. Myslim, ze spouste lidi nebude vubec vadit, ze jejich kod nekdo vezme, upravi v nem formalni veci ci ho jeste vylepsi a zaradi ho do projektu bez vyzvednuti zasluh puvodniho autora.
Někdo, někdo, někdo. Vy někoho za vývoj Thunderbirdu platíte? Protože pokud ne, pak ten „někdo“, od koho něco „očekáváte“, je buď dobrovolník, který to dělá ve svém volném čase, nebo někdo, koho platí někdo jiný. Proč by ten „někdo“ tohle měl pro vás dělat? A hlavně – jak to má dělat, když takových hlášení, jaká jste poslal vy, je řádově víc, než takový „někdo“ může zvládnout? Proč ten „někdo“, kdo to podle vás má dělat, nejste vy? Že to neumíte? Ten „někdo“ se to také musel naučit. Že na to nemáte čas? A „někdo“ na to čas má?

Chtit po nekom, kdo jednorazove prispeje svou troskou do mlyna, aby splnil ouredni pozadavky pro pravidelne prispevatele a odborniky na dany projekt, mi prijde jako hazeni klacku pod nohy a plytvani cizi praci.
Práce těch pravidelných přispěvatelů a odborníků na daný projekt se nepočítá? Protože vy byste chtěl, aby tihle lidé, kteří do toho projektu doopravdy přispívají a odvádějí na něm spoustu práce, všechno zahodili, přestali projekt udržovat a rozvíjet a místo toho se začali piplat s jednorázovými příspěvky, jako je ten váš. To byste chtěl, abyste místo nové funkcionality dostával nové verze, kde bude vyřešen problém nějakého JmJ z druhé konce světa, který trápí ještě dalších deset lidí a je to věc, na kterou jste v aplikaci v životě nenarazil? Nedává vám přeci jen větší smysl, že se postupuje od těch věcí, které mají dopad na největší množství uživatelů?

Ty požadavky pro přispění nejsou žádné úřední požadavky. Jsou to požadavky pro to, aby to těm, kteří na projektu skutečně odvádějí práci, co nejvíce tu práci ulehčilo. Protože ten projekt stojí na jeho vývojářích, ne na uživatelích.

Pokud vás ten váš problém opravdu trápí, nic vám nebrání si to pořádně nastudovat, jak do toho projektu přispívat, a udělat si to sám. Nebo za to někomu zaplatit.

Celkove mi prijde, ze open source rozhodne neni neco, co by melo zajem o hlaseni chyb a reseni problemu nekym mimo vyvolenou komunitu.
„Vyvolená komunita“ zavání trochu konspiračními teoriemi, nemyslíte? Ale ten začátek jste trefil docela dobře. Open-source opravdu nemá zájem o vaše hlášení chyb a řešení vašich problémů. Proč by měli mít autoři zájem o vaše problémy? Máte vy zájem o jejich problémy? Autoři open-source mají zájem, aby to fungovalo pro ně. Nebo pro ty, kteří je platí. Nebo pro ty, kteří přispívají jinak. Ale proč by se měli starat o někoho, kdo jen využívá program, který dali k dispozici zadarmo?

Ja si s dovolenim taky lehce postezuju.
Já to s dovolením uvedu do realistické perspektivy. Vy využíváte něco, co vám někdo dal k dispozici zadarmo. Myslet si, že vám tím vzniká nějaký nárok na to, aby někdo opravoval chyby, které vám vadí, je úplně mimo. Poku dk tomu chcete namítnout nějaké „ale“, je na to stále ta samá odpověď: Tím, že začnete používat něco, co vám někdo dal zadarmo, vám žádný nárok na nic nevzniká.

Nezlobte se, že to píšu tak tvrdě. Možná vám jen nedošlo, jak zle vyznívá to, co jste napsal. A právě proto na to reaguju. Já jsem ještě z generace, kde jsme open-source považovali za dar. Ne jen každý jednotlivý open-source program či knihovnu, ale celý koncept open-source – to, že existuje; to, že přežívá. Protože byl trnem v oku mnohým softwarovým firmám a vůbec to nebylo jisté, že nezanikne.

Je úžasné, že dnes lidé považují open-source za samozřejmost. Akorát je potřeba si občas připomenout, že když vám někdo něco dá zadarmo, je to dar. A darováním vám žádný nárok nevzniká. Ber nebo nech bejt. Nebo můžete přispět – tak, jak si přeje ten, kdo vás obdaroval. Pokud se vám to nelíbí, nemusíte ten dar přijmout, nemusíte ten software používat. Kdyby vás náhodou napadlo argumentovat tím, že bez uživatelů by program nebyl tak známý a oblíbený a používaný – uživatelů je jako much. Uživatel může být každý. Někteří uživatelé aspoň nějak přispějí – penězi, překladem, kódem (tak, aby s tím autoři neměli zbytečnou práci navíc). Uživatele, kteří si myslí, že tím, že program zdarma používají, jim vzniká nějaký nárok, fakt nikdo nepotřebuje.

7
Software / Re:Má vůbec smysl reportovat někam chyby?
« kdy: 26. 12. 2025, 18:41:54 »
Co se vám nezdá? Vždyť tam máte reakci i během vánočních svátků a máte tam napsáno, co s chybou dál dělat.

8
Dokážu si představit, že dneska prohlížeč PDF obsahuje efektivně Chrome (WebKit, interpretace JS…)
Běžné prohlížeče PDF, které PDF sami interpretují (typicky Adobe Acrobat Reader) neobsahují Chrome ani Webkit. Formát PDF neumožňuje v sobě zobrazit HTML, takže není důvod mít v PDF prohlížeči webový prohlížeč.

PDF může obsahovat JavaScript, ale tam platí to samé, co ve webovém prohlížeči – JavaScript běží v sandboxu a má přístup jen k API vystavenému prohlížečem, takže v něm musí být vážná chyba, aby mohl nějak zasáhnout do systému. A API webových prohlížečů je nesrovnatelně bohatší, než API PDF prohlížeče.

Pak samozřejmě může být nějaká chyba (typicky při práci s pamětí) jak v PDF prohlížeči, tak v knihovnách používaných pro zobrazení obrázků, textů… Ta chyba teoreticky může vést ke spuštění kódu. Taková chyba ovšem může být i v antiviru…

Proto jsem se ptal na ty zranitelnosti. Protože z hlediska možného výskytu viru na tom PDF formát není o moc hůř než třeba JPEG nebo PNG, a je na tom výrazně lépe, než třeba formáty Microsoft Office s makry.

9
Server / Re:Jak správně nastavit DNS DMARC RUA / RUF záznam
« kdy: 23. 12. 2025, 14:35:32 »
jen takový nápad - neschází ti u těch dat za TXT uvozovky??? Možná to chybí jenom tady ve fóru, ale středník je pak v zónovém souboru komentář...
Nikoli, DNS server vrací celý záznam, tak jak byl uveden v prvním komentáři.

10
Server / Re:Jak správně nastavit DNS DMARC RUA / RUF záznam
« kdy: 23. 12. 2025, 14:33:54 »
Děkuji za popis, a myslíte tedy, že ty rua/ruf záznamy mohu ignorovat?
Můžete je ignorovat, ale zejména při absenci tagu rua se pak nedozvíte, že je něco špatně. Jak jsem psal, je dobré začít s tím, že uvedete rua, politiku nastavíte na none, a budete sledovat reporty, zda není někde něco špatně. Že jste si třeba neuvědomil, že se ta e-mailová adresa používá ještě někde, kde se e-maily posílají přímo, ne přes hlavní poštovní server.

V SPF máte uvedeno, že e-maily z vaší domény smí odesílat akorát servery uvedené v MX záznamech pro uvedenou doménu. Tam je uveden jen jeden záznam box.<vaše-doména>. Ten má jeden A záznam a jeden AAAA záznam a obě dvě adresy mají nastaven reverzní záznam zpět na box.<vaše-doména>. Takže pokud se e-maily posílají skutečně z těch IP adres, mělo by to být v pořádku.

Ještě bych doporučil nastavit DKIM, pokud to nemáte. Bez toho se nedají vámi odeslané e-maily rozumně přeposílat.

Ještě bych se chtěl zeptat na Váš názor na:
Kód: [Vybrat]
This box's reverse DNS is currently [Not Set], but it should be box.littlehill.xyz. Your ISP or cloud provider will have instructions on setting up reverse DNS for this box.
Odkud tahle hláška pochází? Vztahuje se skutečně k IP adrese odesílajícího poštovního serveru?

Omlouvám se, jestli je to skutečně třeba, ale nechtěl jsem zveřejňovat (hlavně pro roboty) reálné ip a domény (přece jen jsem laik, tak se raději ptám nekonkrétně, kdyby tam byl opravdu nějaký kiks)...
Minimálně vaši IPv4 adresu už roboti stejně navštívily. IPv4 adres je málo, takže pro roboty není problém navštívit všechny. A o doméně už také vědí z Certificate Transparency listu, protože na ni máte vystaven důvěryhodný TLS certifikát (což je v správně).

Pokud se přesto bojíte uvádět doménu a IP adresu rozpoznatelnou pro roboty, je dobré je uvést alespoň tak, aby to mohl čtenář dekódovat. Stačí napsat třeba example tečka com, s tím se roboti obtěžovat nebudou. A když fakt chcete tu doménu před diskutujícími udržet v utajení, používejte ty domény example, ať je na první pohled jasné, že to není skutečná doména. Navíc takhle jste sice svou doménu ochránil, ale kdyby doména littlehill.xyz byla zaregistrovaná (TLD xyz existuje), vystavil byste ji tomu, před čím jste chtěl uchránit svou doménu.

11
Server / Re:Jak správně nastavit DNS DMARC RUA / RUF záznam
« kdy: 23. 12. 2025, 13:43:26 »
Nevypadá to, že by doména littlehill.xyz existovala. Pokud chcete poradit, je dobré uvést skutečnou doménu, abychom se na ty záznamy mohli podívat. Pokud mermomocí chcete doménu skrývat, používají se domény example.com, example.net, example.org a example.edu, aby nedocházelo k záměně se skutečnými doménami.

Tag rua slouží k zasílání přehledů/statistik o splnění/nesplnění pravidel stanovených DMARC záznamem. Používá se to pro zjištění, zda někde nemáte něco nastavené špatně, nebo zda se za vás někdo nezkouší vydávat.

Tag ruf je něco podobného, ale používá se to pro informování o jednom konkrétním chybném e-mailu.

Je dobré začít s něčím méně přísným, než je reject, sledovat tyto reporty a teprve když víte, že je vše v pořádku, politiku zpřísňovat.

S tím reverzním záznamem je to to samé – když neznáme konkrétní adresy, těžko k tomu něco napsat.

12
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 22. 12. 2025, 17:01:16 »
Vyzkoušejte, uvidíte.
Ne, vážně nemám v úmyslu rozbíjet někde nastavení SPF nebo DKIM. A tak nějak stále doufám, že ani vy nemáte zkušenost s tím, jak se doručují e-maily na GMail nebo Office365, když máte rozbité SPF a DKIM.

13
Nechci to tu úplně plevelit offtopicem, ale opravdu si Filipe tak naivní, že pokud by u těch PDF bruteforcem zjišťovali hesla, aby je datově vytěžili, že pak na sebe upozorní tím, že před uživatelem přílohu schovají, protože v ní našli vir?
Nejsme tak naivní, abych si myslel, že by GMail nebo Seznam u těch PDF bruteforcem zjišťovali hesla, aby je datově vytěžili. Nedává to žádný smysl – přínos prakticky žádný, náklady velké, riziko obrovské.

14
stejně jako si Gmail a Seznam buduje odesílatele, u kterých zkouší bruteforcem ta data narození nebo čísla za lomítkem. :)
Tak určitě.

A to varování, které GMail u zaheslované přílohy zobrazuje, to je jen naoko.

Citace
Varování o zašifrované příloze – Na tuto přílohu si dejte pozor. Zpráva obsahuje 1 zašifrovanou přílohu, u které není možné provést kontrolu proti škodlivému obsahu. Zprávu proto nestahujte, pokud odesílatele neznáte a nemáte jistotu, že jde o legitimní e-mail.

Jojo, přesně, protože produkty Adobe jsou historicky etalonem bezpečnosti a skvělých programátorských praktik a samotný PDF formát je taky bezpečnostní skvost.  :P Posíláme klíčenku a už mi témata nekomentuj, prosím.
Kdy měl naposledy Adobe Reader nějakou bezpečnostní chybu umožňující napadnout počítač? Byla v době vydání opravy zneužívána? O PDF formátu toho asi také moc nevíte. Jinak byste napsal, co je na něm nebezpečného.

Ptáte se na veřejném fóru. Nejsou to vaše témata – je to poradna, která slouží všem. Vy trváte na špatných řešeních a nepravdivých informacích. Ale všichni to tak nemají – mnozí si tu rádi přečtou pravdivé informace a dobrá řešení.

15
Server / Re:Pošta z Gmail.com má zpoždění několik hodin
« kdy: 21. 12. 2025, 20:47:33 »
ten greylisting je jednak o dost méně náročný i než ověřovat SPF a DKIM
O tom se dá s úspěchem pochybovat.

hlavně byste tušil, že je spousta adres, které si o nějakém DMARC/DKIM/SPF mohou nechat jenom zdát
To by mne zajímalo, jak doručují e-maily třeba na GMail nebo Microsoft365.

takže i když nasadíte tuto druhou nejméně náročnou variantu, úspěšnost i tak bude ve výsledku o dost nižší. Protože spamující MTA (aka často různé botnety) se prostě velmi nerady připojují podruhé.
Co přesně jste tímhle chtěl napsat? Že spamující MTA, které se nerady připojují podruhé, posílají e-maily se správným SPF nebo DKIM? Protože pokud žádný spamující MTA, který se nechce připojovat podruhé zároveň nemá validní SPF nebo DKIM, musí logicky těch, co neprojdou přes SPF nebo DKIM, být logicky stejně nebo více, než těch, co neprojdou přes greylist.

Stran: [1] 2 3 ... 22