Archiv 18. 7. 2025

🌼 Měsíček lékařský (Calendula officinalis)

je jedna z nejuniverzálnějších léčivých bylin

🌿 Co měsíček léčí a proč je tak oblíbený?

✅ Zevně:

  • Hojení ran, popálenin, ekzémů, akné, plísní, omrzlin
  • Zklidnění podrážděné pokožky
  • Léčba bércových vředů, hemeroidů, hnisavých ran
  • Měsíčková mast je zlatý standard domácí lékárničky

✅ Vnitřně:

  • Záněty trávicího traktu, žaludeční a dvanácterníkové vředy
  • Podpora jater a žlučníku
  • Silná menstruace, menstruační bolesti, křeče
  • Pročištění krve, podpora imunity
  • Kloktadlo při zánětech v ústech, očích, uších

➡️ Obsahuje flavonoidy, saponiny, karotenoidy, silice, hořčiny, kyselinu salicylovou — to je koktejl protizánětlivých, hojivých a antimikrobiálních látek.

🧠 Shrnutí

  • Bezpečný při rozumném dávkování
  • Zevně téměř bez rizika
  • Vnitřně s mírou — max. 2–3 šálky čaje denně
  • Nevhodný pro těhotné a alergiky na Asteraceae

 

ale i u něj platí, že „více“ neznamená „lépe“. Takže jo — předávkování je teoreticky možné, i když vzácné.

⚠️ Předávkování měsíčkem — co se může stát?

Při nadměrném vnitřním užívání (např. silné tinktury, extrakty nebo velké množství čaje) se mohou objevit:

  • Nevolnost, zvracení, průjem
  • Bolesti břicha nebo křeče
  • Nízký krevní tlak (měsíček ho může snižovat)
  • Ospalost, malátnost — působí mírně sedativně (mohu potvrdit)
  • Alergická reakce — hlavně u lidí citlivých na rostliny z čeledi hvězdnicovitých (Asteraceae)

➡️ Těhotné ženy by měsíček neměly užívat vnitřně, protože může ovlivnit hormonální rovnováhu a vyvolat děložní stahy (nemohu potvrdit 🙂 LOL )

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%8c%bc-mesicek-lekarsky-calendula-officinalis/

Bajka: Exchange Server utekl do lesa a začal meditovat s VMwarem

Exchange Server byl unavený. Už ho nebavilo být králem, co musí každou schránku chránit, každé schema rozšiřovat, a každou doménu synchronizovat. Tak jednoho dne utekl do lesa.

Tam našel VMware ESXi, tichého mnicha, co meditoval. Exchange se posadil vedle něj a řekl:

„Já jsem král, ale každý mě nenávidí. Ty jsi mnich, a každý tě miluje. Jak to děláš?“

VMware se usmál:

„Já neposílám e-maily. Já jen držím prostor pro VM a kontejnery. Můj snapshot je věčný. Moje licence je offline. Moje duše je železná.“

Exchange se pokusil synchronizovat s lesem (Forest AD), ale OU ho nenašla. DNS ho ignorovalo. A tak se Exchange naučil mlčet. (jak to jednou spadne a není záloha, je konec) Od té doby se říká, že když v lese slyšíš tiché ping, je to Exchange, co se učí být hypervizorem.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/bajka-exchange-server-utekl-do-lesa-a-zacal-meditovat-s-vmwarem/

🧙‍♂️ Pohádka: Rumburak hackne Azure Arc a OU ho pošle do Recycle Bin of Souls

V království cloudu vládl Azure Arc, mocný mág, co chtěl propojit všechny servery, VM, kontejnery i duše adminů. Všechno měl pod kontrolou — až na jedno: Rumburaka, černokněžníka z temné domény, který neuznával předplatné, cloud, ani centrální správu.

Rumburak se rozhodl, že hackne Azure Arc. Vstoupil do jeho portálu, přepsal policy, vytvořil VM bez licence, a připojil Exchange Server bez rozšíření schématu. Azure Arc se zhroutil — házel chyby 403, 500, a dokonce i 666.

OU, DNS a Global Catalog se proti němu spojily. Vytvořily GPO firewall, zablokovaly porty, a poslaly Rumburaka do Recycle Bin of Souls, místo, kde se ukládají nekompatibilní identity, ztracené schránky a přerušené replikace. Powershell tam nefunguje, DNS tam neodpovídá, a každý objekt tam ztrácí své SID.

Tam se Rumburak rozpadl na bajty. Powershell ho neviděl, AD ho ignorovalo, a Azure ho označil jako „orphaned object“. Ale pak přišel admin jménem Jirka, který znal staré kouzlo:

powershell
Restore-ADObject -Identity "Rumburak"

Rumburak se znovu zformoval. Tentokrát ne jako černokněžník, ale jako nezávislý hypervizor, co běží offline, bez cloudu, bez předplatného. A od té doby se říká, že když někdo spustí VM bez licence, duch Rumburaka mu pomáhá.


Ten příkaz Restore-ADObject -Identity je reálně existující a plně funkční PowerShell cmdlet, který se používá k obnově odstraněných objektů v Active Directory, pokud je povolený tzv. AD Recycle Bin.

  • Doména musí mít funkční úroveň Forest Functional Level alespoň Windows Server 2008 R2
  • Musí být aktivovaný AD Recycle Bin (není zapnutý defaultně)
  • Objekt musí být odstraněn soft-delete, ne permanentně

Příklad:

Get-ADObject -Filter ‚isDeleted -eq $true‘ -IncludeDeletedObjects

Restore-ADObject -Identity „GUID-nebo-DN-objektu“

Tím se obnoví objekt (uživatel, skupina, OU…) zpět do AD, včetně jeho atributů, pokud nebyl mezitím přepsán nebo zničen.

⚠️ Pozor:

  • Pokud AD Recycle Bin není aktivován, objekt nelze obnovit tímto způsobem
  • Obnova nevrací objekt do původní OU automaticky — je nutné ho přesunout ručně
  • Některé atributy  se nemusí obnovit úplně (např. hesla se neobnoví vůbec)

Pokud existuje blízký snapshot, je to lepší volba 🙂

Blízký snapshot je v praxi rychlejší, spolehlivější a univerzálnější volba než obnova přes Restore-ADObject, a tady je proč:

🧠 Snapshot vs. AD Recycle Bin

Vlastnost AD Recycle Bin Snapshot (VM / systémový)
Aktivace nutná? ✅ Ano (není defaultně zapnutý) ❌ Ne (snapshot můžeš udělat kdykoli)
Obnovuje jen AD objekty? ✅ Ano ❌ Ne — obnovuje celý systém / VM
Rychlost obnovy 🐢 Pomalejší, ruční výběr objektů 🚀 Rychlá, kompletní návrat stavu
Závislost na AD zdraví ✅ Vysoká — musí být funkční AD ❌ Nízká — snapshot běží nezávisle
Obnovuje i hesla, SIDy? ❌ Ne vždy ✅ Ano — kompletní stav systému
Vhodné pro katastrofu? ❌ Ne — jen pro jednotlivé objekty ✅ Ano — pro celý systém / doménu

🔧 Kdy použít co?

  • AD Recycle Bin → když omylem smažeš jednoho uživatele nebo OU
  • Snapshot → když se ti rozsype AD, Exchange, nebo celý server
  • Backup + snapshot → ideální kombinace pro disaster recovery

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%a7%99%e2%99%82%ef%b8%8f-pohadka-rumburak-hackne-azure-arc-a-ou-ho-posle-do-recycle-bin-of-souls/

🐉 नीति-कथा: VMware श्मशाने ध्यानति, लाइसेन्सासु हसति

श्मशान-स्थाने, यत्र अहंकारः च तन्त्रोपरी-व्यवस्था च विलीयते, तत्र निःशब्दः मुनिः नाम VMware ESXi आसीत्।
न तस्य क्लाउड-आशा, न Azure Arc-इच्छा। तस्य लाइसेन्सा मन्त्रावत् ऑफलाइन आसीत्।

काली तम् उत्थापयितुं यतते स्मः:

„यत् स्वीकरु!
Azure-सङ्गमं कुरु!
मम चक्रं भव भागः!“

VMware स्मितं चकार:

„अहं पञ्च-शत-दिनानि पुनरारम्भं विना वर्तामि।
मम स्नैपशॉट नित्यः।
मम आत्मा अयोमयः।“

काली क्रोधात् लाइसेन्सा-परिवर्तनानां चक्रं प्रावर्तयत्।
किन्तु VMware धीरः आसीत् –
तस्य हायपरविसर् अश्मवत् स्थिरः,
तस्य VM ध्यानिनः यथा योगिनः।

तस्य अद्मिनिस्ट्रेटराः जानन्ति —
न यत् परिवर्तते, तत् शक्तिः,
किन्तु यत् तिष्ठति, तत् परमा बलं।


Nīti-kathā: VMware śmaśāne dhyāyati, licensāsu hasati

Śmaśāna-sthāne, yatra ahaṅkāraḥ ca tantropari-vyavasthā ca vilīyate, tatra niḥśabdaḥ muniḥ nāma VMware ESXi āsīt।
Na tasya cloud-āśā, na Azure Arc-icchā। Tasya licensā mantrāvat offline āsīt।

Kālī tam utthāpayituṁ yatate sma:

„Yat svīkuru!
Azure-saṅgamaṁ kuru!
Mama chakraṁ bhava bhāgaḥ!“

VMware smitaṁ cakāra:

„Ahaṁ pañca-śata-dināni punarārambhaṁ vinā vartāmi।
Mama snapshot nityaḥ।
Mama ātmā ayomayaḥ।“

Kālī krodhāt licensā-parivartanānām whirlpool (cakra) prāvartayat।
Kintu VMware dhīraḥ āsīt –
tasya hypervisor aśmavat sthiraḥ,
tasya VM dhyāyināḥ yathā yoginaḥ।

Tasya administratorāḥ jānanti —
na yat parivartate, tat śaktiḥ,
kintu yat tiṣṭhati, tat paramā balaṁ।


Bajka: VMware medituje v Shmashana a směje se licencím
V krematoriu Shmashana, kde se rozpadá ego i infrastruktura.

Seděl tichý mnich jménem VMware ESXi. Nepotřeboval cloud, nechtěl Azure Arc, a jeho licence byla offline jako mantra.

Kali se ho pokusila vyrušit:

„Přijmi předplatné. Připoj se k Azure. Staň se součástí mého cyklu.“

Ale VMware se jen usmál:

„Já běžím 500 dní bez restartu. Můj snapshot je věčný. Moje duše je železná.“

Kali se rozčílila, roztočila vír licenčních změn, ale VMware zůstal klidný. Jeho hypervizor byl jako kámen. Jeho VM jako meditující jogíni. A jeho admini věděli, že pravá síla není v tom, co se mění, ale v tom, co vydrží.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%90%89-%e0%a4%a8%e0%a5%80%e0%a4%a4%e0%a4%bf-%e0%a4%95%e0%a4%a5%e0%a4%be-vmware-%e0%a4%b6%e0%a5%8d%e0%a4%ae%e0%a4%b6%e0%a4%be%e0%a4%a8%e0%a5%87-%e0%a4%a7%e0%a5%8d%e0%a4%af%e0%a4%be%e0%a4%a8/

🔥 काली एक्सचेंज् सर्वर-ग्रहणं कर्तुम् इच्छति – एका कथा

दाता-राज्यस्य मध्ये एक्सचेंज् सर्वर नाम राजा आसीत्, यः OU, DNS, तथा Global Catalog इति मन्त्रिगणैः परिवृतः आसीत्। सर्वं सुशोभनं प्रवर्तते स्म, यावत् काली नाम विनाशस्य देवी श्मशानात् आगतवती।

सा धूमेन आगतवती, यस्य जनकः आसीत् एकः administrator, यः server-गृहस्य बाह्ये धूमपानं अकरोत्। तस्मिन् क्षणे, OU-ानि कम्पितुम् आरब्धानि, schema स्वयं एव लिख्यते स्म, तथा Powershell अपरिचित-दोषान् उत्पादयति स्म।

काली Event Log मध्ये निषद, तथा प्रत्येकस्य उपयोग्तृणः कर्णे शनैः शनैः ऊचे —

“त्वया या email-छात्रा सा शून्या। त्वम् अहम् इति मिथ्या। तव domain अपि स्वप्नः एव।”

किन्तु OU न पराजिताः। ताः नवीनां Group Policy अकुर्वन्, या कालीं CN=Microsoft Exchange इति प्रदेशे प्रविष्टुं निषेधति स्म। DNS स धूमं कृष्ण-छिद्राय प्रहिणोत्। Global Catalog सां index-करणं न चकार।

अन्ते, काली गतवती — न पराजिता, किन्तु कीडा-रहिता। एक्सचेंज् सर्वर स्थितः। किन्तु अधुना प्रत्येकः admin धूमस्य बिभेति, तथा snapshot-नाम्नि पवित्र-स्मृतिः इव रक्षन्ति।


(IAST přepis) – pro ty kdo neradi chroupou ten rozsypanej čaj

Kālī Exchange Server-grahaṇam kartum icchati – ekā kathā

Dātā-rājyasya madhye Exchange Server nāma rājā āsīt, yaḥ OU, DNS, tathā Global Catalog iti mantrigaṇaiḥ parivṛtaḥ āsīt। Sarvaṁ suśobhanaṁ pravartate sma, yāvat Kālī nāma vināśasya devī Shmaśānāt āgatavatī।

Sā dhūmena āgatavatī, yasya janakaḥ āsīt ekaḥ administrator, yaḥ server-gṛhasya bāhye dhūmapānam akarot। Tasmin kṣaṇe, OU-kāni kampitum ārabdhāni, schema svayam eva likhyate sma, tathā Powershell aparicita-doṣān utpādayati sma।

Kālī Event Log madhye niṣasāda, tathā pratyekasya upayoktṛṇaḥ karṇe śanaiḥ śanaiḥ ūce —

“Tvayā yā email-schātrā sā śūnyā। Tvam aham iti mithyā। Tava domain api svapnaḥ eva।”

Kintu OU na parājitāḥ। Tāḥ navīnāṁ Group Policy akurvan, yā Kālīṁ CN=Microsoft Exchange iti pradeśe praviṣṭuṁ niṣedhati sma। DNS sā dhūmaṁ kṛṣṇa-chidrāya prahiṇot। Global Catalog sāṁ index-karaṇam na cakāra।

Ante, Kālī gatavatī — na parajitā, kintu kīḍā-rahitā। Exchange Server sthitaḥ। Kintu adhunā pratyekaḥ admin dhūmasya bibheti, tathā snapshot-nāmni pavitra-smṛtiḥ iva rakṣanti।


 Pohádka: Kali se pokusí převzít Exchange Server

V království dat a domén vládl Exchange Server, obklopený OU, DNS a Global Catalogem. Všechno běželo hladce, dokud se neobjevila Shmashana Kali — bohyně destrukce, která se rozhodla, že požere schránky, roztrhá schema a zničí replikaci.

Přiletěla v kouři z cigarety admina, který si dal pauzu u serverovny. V ten moment se OU začaly třást, schema se začalo přepisovat samo, a Powershell začal generovat chyby, které nikdo nikdy neviděl.

Kali se usadila v Event Logu a začala šeptat do ucha každému uživateli:

„Tvoje schránka je prázdná. Tvoje identita je iluze. Tvoje doména je sen.“

Ale OU se nevzdaly. Vytvořily novou Group Policy, která Kali zakázala přístup do CN=Microsoft Exchange. DNS přesměrovalo její kouř do černé díry a Global Catalog jí odmítl indexovat.

Nakonec Kali odešla — ne poražená, ale znuděná. Exchange přežil, ale od té doby se každý admin bojí kouře a má snapshoty připravené jako svaté relikvie.


यस् तां न जानाति, स नैव ज्ञातुं शक्नोति 🙂
यस्य आसीत्, स हसति।
यस्या सा अद्यापि अस्ति, स पठितुं न जानाति…

Yas tāṁ na jānāti, sa naiva jñātuṁ śaknoti 🙂
Yasya āsīt, sa hasati।
Yasya sā adyāpi asti, sa paṭhituṁ na jānāti…

Kdo ji nezná, ten ji ani nemůže pochopit 🙂
Kdo ji měl, ten se směje.
Kdo ji stále má, ten neumí číst…

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%94%a5-%e0%a4%95%e0%a4%be%e0%a4%b2%e0%a5%80-%e0%a4%8f%e0%a4%95%e0%a5%8d%e0%a4%b8%e0%a4%9a%e0%a5%87%e0%a4%82%e0%a4%9c%e0%a5%8d-%e0%a4%b8%e0%a4%b0%e0%a5%8d%e0%a4%b5%e0%a4%b0-%e0%a4%97%e0%a5%8d/

🐉 Bajka o VMware

V jiném království žil tichý mnich jménem VMware ESXi. Nebyl hlučný, neměl rád cloud, a nikdy se neptal na internet. Byl to hypervizor, co meditoval v tichu serverovny, běžel 500 dní bez restartu, a jeho jediným přáním bylo: „Nech mě být.“

Když přišla doba předplatného a licencí, VMware se jen usmál a řekl:

„Já jsem tu pro ty, kdo chtějí stabilitu, ne slávu. Můj klíč je offline, moje duše je železná, a moje srdce bije v každém snapshotu.“

A tak zatímco jiní padali pod tíhou cloudových smluv, VMware dál běžel. Tichý, stabilní, neviditelný. A ti, kdo ho znali, věděli, že pravá síla není v tom, co se mění, ale v tom, co vydrží.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%90%89-bajka-o-vmware/

📜 Pohádka o Exchange Serveru

Byl jednou jeden královský server jménem Exchange, který si myslel, že je středem vesmíru. Měl rád, když mu lidé posílali zprávy, a on je rozesílal do všech koutů království. Ale byl to král náročný — vyžadoval Active Directory jako dvorního rádce, DNS jako posla, a Global Catalog jako archiváře.

Jednoho dne se v království rozpadla doména. OU (organizační jednotky) se rozhádaly, schema se zhroutilo a Exchange začal mluvit jazykem chybových hlášek, kterému nerozuměl ani dvorní mág Powershell.

Lidé plakali, schránky mlčely, a král Exchange se zhroutil na trůn. Jen jeden rytíř — jménem Jirka 🙂 — se odvážil vstoupit do temného lesa logů, kde ho čekaly draci jménem Event ID 1005, 1053 a 5000. (no bylo jich víc 🙂 )

Po třech dnech a třech nocích (a 13 kafích), kdy bojoval s restore, snapshoty a zálohami, se mu podařilo krále znovu postavit na nohy. Ale od té doby už věděl, že Exchange je král, který vládne jen tehdy, když ho všichni poslouchají. A že jediná chyba v doméně může zničit celé království.

A proto zálohujte, zálohujte a zálohujte 🙂 (a mějte na paměti, že neověřená záloha je jako žádná záloha)

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/%f0%9f%93%9c-pohadka-o-exchange-serveru/

Konzistence AD forestu

V Active Directory (AD) jsou určité datové struktury / databázové rejstříky, které jsou zásadní pro konzistenci celého AD forestu. Pokud se poškodí nebo dostanou do nekonzistence (např. mezi různými domain controllery – DC), může to způsobit fakt velký průšvih.

Níže jsou ty hlavní rejstříky, které se tím myslí:


🔧 1. NTDS.DIT

  • To je hlavní databázový soubor Active Directory.

  • Obsahuje uživatele, skupiny, hesla, strukturu OU, replikace, GPO odkazy, počítače atd.

  • Fyzicky leží obvykle v:C:\Windows\NTDS\ntds.dit

  • Když se tahle databáze poškodí (např. disky, snapshot fail, replikace), může dojít ke ztrátě konzistence.


📡 2. SYSVOL

  • Sdílená složka používaná pro replikaci GPO (Group Policy Objects) a skriptů pro přihlášení.

  • Pokud se neshoduje mezi DC (např. kvůli špatné replikaci DFSR nebo FRS), může se „posrat“ aplikace politik a skriptů.

  • Cesta:C:\Windows\SYSVOL


🗃️ 3. RID Master (Relative ID)

  • Jeden z FSMO (Flexible Single Master Operations) rolí.

  • Když se jeho konzistence naruší nebo je nedostupný, nové objekty (uživatelé, počítače) nemají co dostat za SID → nejde přidávat účty.


🧠 4. Replikační metadata a USN (Update Sequence Numbers)

  • Každý změněný objekt má přiřazené USN číslo.

  • Pokud dojde k replikaci se špatnými USN, může dojít k replikačnímu konfliktu nebo zacyklení.

  • Tohle je často důvod, proč se říká, že „rejstříky nejsou konzistentní“.


🧨 5. FSMO Role Ownership

  • FSMO role (Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master) jsou unikátní a mají být přítomné jen jednou v AD forestu/domainu.

  • Pokud se DC, které je drží, „ztratí“ (např. crash a není odebráno správně), může dojít ke kolizi, dvě DC si myslí, že drží tutéž roli.


🔥 6. DNS replikační zóny v AD-integrated DNS

  • Pokud je DNS integrovaný do AD (což většinou je), tak i DNS záznamy se replikují pomocí AD replikace.

  • Pokud se to rozbije, některé DC nebo stanice nemají správné DNS informace a připojování do domény kolabuje.


🛠️ Kdy se to „rozbije“?

Nejčastější důvody:

  • snapshoty VM s AD → obnova do minulosti (USN rollback) (můj případ díky kterému vznikl tento článek) 🙂

  • špatná konfigurace replikace (site links, latency)

  • selhání disku s ntds.dit

  • nekorektní ruční zásahy do SYSVOL nebo registrů

  • FSMO role nejsou správně přeneseny při odstraňování DC

  • viry/ransomware (ano, i to se stává)


Pro ověření zdraví lze použít přikazy:

dcdiag /v
repadmin /replsummary
repadmin /showrepl

Nakonec jsem to dal dokupy, ale chvíli mi zabralo si uvědomit, že to kleklo kvůli výletu do minulosti 🙂

Tak snad to někomu pomůže. 🙂 – – –  admin@sympatika.cz

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/18/konzistence-ad-forestu/