Kategorie: software

Zář 01 2025

Co přináší World of Tanks 2.0

  • 1. 9. 2025

Tady je přehled toho, co přináší World of Tanks 2.0 — největší update v historii této hry 🚀:

🧨 Největší novinky v Update 2.0

UPDATE 2.0: Rozbor admina Crystal_van_Bird

Největší změna v historii World of Tanks. Tier XI, PvE mise, AI rebalanc a matchmaking 2.0 — pod lupou zkušeného hráče.

🛡️ Tier XI tanky

  • 16 nových vozidel: 7 těžkých, 5 středních, 3 stíhače tanků, 1 lehký.
  • Každý má unikátní mechaniky — třeba sekundární zbraně, ramming boost, nebo progresivní zásobníky.
  • Nový systém vylepšení místo klasických polních modifikací.

🏭 Redesign garáže

  • Garáž je teď plnohodnotná továrna: montáž, výbava, inspekce tanků — vše na pár kliků.
  • Nové UI je rychlejší, přehlednější a funkčnější.

⚔️ PvE mise: Operation Boiling Point

  • Hraješ na nové mapě Nordskar (inspirovaná Skandinávií).
  • Příběhové mise s Tier XI tanky — ideální pro sólo hráče.

🎯 Matchmaking 2.0

  • Rychlejší fronty, lepší vyvážení týmů, častější bitvy s rozdílem ±1 tier.
  • Role tanků jsou lépe rozděleny, takže bitvy jsou dynamičtější.

🔊 Zvuková revoluce

  • Nové zvuky tanků nahrané z reálných strojů.
  • Vylepšený mix zvuků pro autentičtější zážitek z boje.

🔧 Rebalanc vozidel

  • Přepracováno přes 350 tanků napříč všemi tiery. (za použití A.I.)
  • Zjednodušené moduly, rychlejší progres v tech tree.
  • Lehké tanky mají víc HP, ale neztrácí rychlost ani maskování.
  • Prémiové tanky dostaly buffy, takže se vrací do hry.

🗺️ Nová mapa: Nordskar

  • Kombinuje průmyslové zóny, zamrzlé pláně a podzemní tunely.
  • Navržena pro PvE i náhodné bitvy.

🕒 Kdy to vypukne?

  • APAC region (včetně Česka): update je dostupný od 1. září 2025
  • Servery budou vypnuté 3. září od 07:30 do 13:00 UTC kvůli údržbě.

🔧Rebalanc ve World of Tanks 2.0 byl skutečně výrazně podpořen pomocí AI — konkrétně analýzou hráčských dat a automatizovaným vyhodnocováním výkonu vozidel.

🤖 Jak AI pomohla s rebalancem:

  • Sledování výkonu stovek tanků: AI analyzovala miliony bitev, aby zjistila, které tanky jsou příliš silné, slabé nebo nevyvážené.
  • Dynamické úpravy modulů: Zastaralé moduly byly automaticky identifikovány a nahrazeny efektivnějšími variantami.
  • Predikce dopadů změn: Pomocí simulací AI odhadovala, jak se změny projeví v reálných bitvách.
  • Lepší matchmaking: Nový systém párování hráčů je postaven na AI algoritmech, které zajišťují vyváženější týmy.

💬 Co říká Wargaming:

„Balancování je neustálý proces. Výkon vozidel sledujeme pomocí dat z živého serveru a AI nám pomáhá jemně doladit změny i po vydání.“

Takže to není jen jednorázová úprava — AI bude dál sledovat, jak se tanky chovají, a případně přijdou další úpravy.

Největší „AI-driven“ úpravy v Update 2.0 World of Tanks se týkaly lehké větve sovětských tanků, konkrétně T-100 LT, který byl podle vývojářů nejvíce upravený na základě datové analýzy AI.

🔍 Proč právě T-100 LT?

AI zjistila, že:

  • Přežívací schopnosti byly výrazně nižší než u jiných lehkých tanků stejného tieru.
  • Hráči s ním nedosahovali očekávaného asistovaného poškození, i když správně scoutovali.
  • Moduly byly zastaralé a neodpovídaly modernímu stylu hry.

🛠️ Co se změnilo:

  • Zvýšení HP o 12 % – přežije víc zásahů, což zvyšuje šanci na delší scouting.
  • Zlepšené maskování při pohybu – AI vyhodnotila, že hráči často ztráceli maskování příliš brzy.
  • Nový motorový modul – vyšší akcelerace, lepší výjezd do kopce.
  • Zjednodušené vybavení – odstraněny neefektivní moduly, přidány nové s lepšími statistikami.

💡 AI přístup k rebalancu:

Vývojáři použili machine learning modely, které analyzovaly:

  • Výkon tanku v různých mapách.
  • Styl hraní různých typů hráčů (agresivní vs. pasivní).
  • Poměr přežití vs. přínos pro tým.

T-100 LT byl největší „outlier“ — měl potenciál, ale data ukazovala, že ho hráči neuměli využít naplno kvůli slabým základním parametrům.

Admin tohoto serveru a sítě ethostream je dlouholetým hráčem WoT (přes 12 let). Najdete ho pod Nickem: Crystal_van_Bird. Celá naše siť je primátně optimalizována pro hráče on-line her, primárně WoT 🙂

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/09/01/co-prinasi-world-of-tanks-2-0/

Srp 25 2025

🧠 Microsoft PC Manager, alternativa k CCleaneru

  • 25. 8. 2025

Microsoft PC Manager přidává vrstvu optimalizace a čištění s rychlým přístupem k PC Boost:

  • kontroly stavu PC
  • řízení procesů
  • spouštění 
  • integrace s programem Microsoft Defender.
  •  Centralizuje údržbu v jednoduchém rozhraní určeném pro nezkušené uživatele.

🧼 Microsoft PC Manager – je zdarma

  • ✅ Plně zdarma, žádné časové omezení ani trial verze
  • ✅ Vyvíjený přímo Microsoftem, takže je to oficiální nástroj
  • ✅ Čistí cache, dočasné soubory, spravuje procesy, kontroluje zdraví systému
  • ❌ Neumí aktualizovat ovladače (zatím)
  • 📦 Není předinstalovaný ve Windows, což je fakt zvláštní – je nutné si ho ručně stáhnout z

Proč o něm „nikde není ani čárka“?

  • Microsoft ho původně vyvíjel pro čínský trh, takže se o něm moc nemluvilo
  • Teprve nedávno ho zpřístupnili globálně, ale není součástí Windows Update ani Ovládacích panelů
  • Je to takový „skrytý poklad“ – jednoduchý, bezpečný, bez reklam a bez nutnosti instalovat třetí strany

Microsoft PC Manager je fakt dobrý start.

🖥️ Kompatibilita:

  • ✅ Funguje na Windows 10 od verze 1809 výš
  • ✅ Samozřejmě podporuje i Windows 11

Takže pokud máte Windows 10 (což má pořád spousta lidí), můžete ho bez problémů používat. Jen si ho musíte ručně stáhnout, protože není součástí systému ani Windows Update. Microsoft ho prostě „nenápadně“ schoval, což je fakt zvláštní, vzhledem k tomu, že je to jejich vlastní nástroj.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/08/25/%f0%9f%a7%a0-microsoft-pc-manager-alternativa-k-ccleaneru/

Srp 16 2025

Pamatujete ještě Netscape vs. IE?

  • 16. 8. 2025

🧠 Historická paralela: Netscape vs. IE

V 90. letech byl web divoký západ:

  • Každý prohlížeč si interpretoval HTML/CSS po svém
  • Vývojáři museli psát „optimalizováno pro IE/Netscape“
  • Microsoft zničil Netscape pomocí IE, ale pak IE stagnoval

Google se poučil – místo boje vytvořil platformu, na které staví i konkurence.

🌐 Co se tím Google podařilo?

  • Zlomil fragmentaci webových prohlížečů (pamatujete IE6 vs. Netscape vs. Opera?)
  • Získal vliv na to, jak se webové technologie vyvíjejí (a o to šlo) 🙂
  • Zajistil si tržní podíl – dnes má Chrome přes 60 % trhu

💡 Z pohledu Googlu to byl strategicky brilantní tah. Vytvořením Chromium jako open-source základu si Google zajistil, že:

  • většina vývojářů bude optimalizovat weby pro jejich vykreslovací jádro (Blink, původně WebKit)
  • standardizace webu proběhne podle jejich pravidel
  • dominance Chrome se rozšíří i skrze jiné prohlížeče (Edge, Opera, Brave…)

Chromium byl primárně vyvinut společností Google, která ho spustila v září 2008 jako open-source základ pro svůj prohlížeč Google Chrom

  • Google je hlavní autor a udržovatel projektu
  • Vývoj probíhá pod hlavičkou The Chromium Projects
  • Google má nad projektem plnou kontrolu, i když je open source

Proč Google vytvořil Chromium?

  • Chtěl umožnit rychlejší vývoj prohlížeče Chrome
  • Open-source přístup přitahuje komunitní přispěvatele
  • Umožňuje jiným firmám (např. Microsoft, Opera) stavět vlastní prohlížeče na stejném základu

Většina dnešních prohlížečů je postavena na Chromiu – to platí pro:

  • Google Chrome
  • Microsoft Edge
  • Opera
  • Brave
  • Vivaldi

Jedinou velkou výjimkou je Firefox, který není postaven na Chromiu, ale používá vlastní vykreslovací jádro Gecko.

🦊 Je Firefox open source?

Ano, Firefox je 100% open source. Vyvíjí ho Mozilla Foundation, a jeho zdrojový kód je dostupný pod Mozilla Public License (MPL 2.0). To znamená, že si ho můžeš:

  • ✅ stáhnout
  • ✅ upravit
  • ✅ redistribuovat

Zdrojový kód najdeš například na nebo jako mirror na

🧠 Proč na Firefoxu nezávisí tolik prohlížečů?

  • Chromium je jednodušší na integraci a má silnou podporu od Googlu
  • Gecko je komplexnější a Mozilla si drží větší kontrolu nad vývojem
  • Firefox se více zaměřuje na soukromí, nezávislost a otevřenost

Další vyjímkou je 🍏 Safari a také není postavený na Chromiu

Na rozdíl od většiny dnešních prohlížečů Safari nepoužívá Chromium. Místo toho je postavený na WebKit, což je vlastní open-source vykreslovací jádro vyvíjené Applem.

🔍 Rozdíl mezi WebKit a Chromium

Vlastnost WebKit (Safari) Chromium (Chrome, Edge, Opera…)
Vlastník Apple Google
Vykreslovací jádro WebKit Blink (fork WebKitu)
Open source? ✅ Ano ✅ Ano
Používáno v Safari, starší verze Chrome Chrome, Edge, Opera, Brave, Vivaldi

Blink je vlastně odvozenina WebKitu – Google ho v roce 2013 „odštěpil“ a začal vyvíjet samostatně

 Shrnutí

  • Safari je jediný hlavní prohlížeč, který nepoužívá Chromium
  • Apple si drží vlastní technologii a tím i větší kontrolu nad vývojem
  • WebKit je stále velmi efektivní, zejména na mobilních zařízeních

🧠 Shrnutí vývoje vykreslovacích jader

  • WebKit byl původně vyvinut Applem jako fork z KHTML (z prohlížeče Konqueror)
  • Google Chrome začal v roce 2008 používat WebKit jako své jádro
  • V roce 2013 Google vytvořil vlastní fork WebKitu nazvaný Blink
  • Od té doby se Chromium (a tedy Chrome, Edge, Opera, Brave…) vyvíjí na Blink jádru

🍏 Safari = WebKit

  • Apple zůstal u WebKitu
  • Safari je jediný hlavní prohlížeč, který nepoužívá Blink ani Chromium
  • Firefox je druhá výjimka, protože používá Gecko, což je úplně jiné jádro

🔍 Realita dneška

Prohlížeč Vykreslovací jádro Chromium základ?
Chrome Blink ✅ Ano
Edge Blink ✅ Ano
Opera Blink ✅ Ano
Brave Blink ✅ Ano
Vivaldi Blink ✅ Ano
Safari WebKit ❌ Ne
Firefox Gecko ❌ Ne

Takže ano — Firefox je jediný velký prohlížeč, který nestaví na WebKitu ani Chromiu. A právě díky tomu je technologicky i filozoficky nezávislý.

Gecko je opravdu výjimka mezi dnešními vykreslovacími jádry, protože nevychází ani z WebKitu, ani z Chromia. Tady je jeho původ:

🦎 Z čeho vychází Gecko?

  • Gecko byl vyvinut Mozilla Foundation jako nástupce staršího jádra NGLayout
  • NGLayout vznikl v rámci Netscape Communications v 90. letech jako alternativa k tehdejšímu jádru Mozilla Classic
  • Gecko se poprvé objevil v Mozilla Suite a později ve Firefoxu
  • Je to vlastní implementace vykreslovacího jádra, která nevychází z WebKitu ani KHTML

🔍 Co to znamená?

  • Gecko je technologicky nezávislý — Mozilla si ho vyvíjí sama
  • Díky tomu má Firefox vlastní přístup k interpretaci HTML, CSS, JavaScriptu
  • To je důležité pro diverzitu webového ekosystému, protože většina ostatních prohlížečů (Chrome, Edge, Opera…) používá Blink, který je odvozený z WebKitu

🧬 Shrnutí vývoje

Jádro Původ Vychází z Používá ho
Gecko Mozilla NGLayout (Netscape) Firefox, Thunderbird
WebKit Apple KHTML (Konqueror) Safari
Blink Google WebKit Chrome, Edge, Opera, Brave…

🧬 Historický souboj: KHTML vs. NGLayout

  • KHTML byl jádrem prohlížeče Konqueror (součást KDE Linuxu)
  • Apple si ho v roce 2002 forknul a vytvořil WebKit
  • Google si pak WebKit forknul v roce 2013 a vznikl Blink
  • Mezitím Mozilla vyvíjela NGLayout, který se stal základem pro Gecko

KHTML vs. NGLayout byl ten původní technologický souboj, i když málokdo si to dnes uvědomuje.

 

🏆 Kdo vlastně „vyhrál“?

  • WebKit (a jeho potomci jako Blink) dnes ovládají většinu trhu
  • Chrome má přes 60 % podíl, a další Blinkové prohlížeče (Edge, Opera, Brave…) přidávají další desítky procent
  • Safari (WebKit) je dominantní na iOS/macOS
  • Firefox (Gecko) je poslední mohykán z éry Netscape — technologicky i filozoficky nezávislý

Takže ano — Apple nepřímo vyhrál, protože jeho fork KHTML (WebKit) se stal základem pro většinu dnešního webu, i když to málokdo ví.

🌐 Co to znamená pro vývoj webu?

  • Webové standardy se často optimalizují primárně pro Blink/WebKit
  • Firefox musí dohánět kompatibilitu, i když má vlastní implementaci
  • Gecko přináší alternativní přístup, což je důležité pro diverzitu

🐧 KDE + KHTML = Skrytý hrdina webu

  • KHTML vznikl jako lehké a elegantní vykreslovací jádro pro Konqueror, prohlížeč v prostředí KDE na Linuxu
  • Byl napsán s důrazem na čistý kód, modularitu a otevřenost
  • Apple si ho v roce 2002 forknul a vytvořil WebKit, protože chtěl rychlé a otevřené jádro pro Safari

🍏 Apple jako katalyzátor

  • Apple měl zdroje, vliv a trh, aby WebKit dostal do mainstreamu
  • Bez Applu by KHTML zůstal jen v Linuxové komunitě
  • Google později forkne WebKit → vznikne Blink, který dnes ovládá většinu trhu

🧠 Co to znamená?

  • Linuxová komunita (konkrétně KDE tým) položila technologický základ dnešního webu
  • Apple ho zpopularizoval, Google ho rozšířil
  • A dnes se web řídí podle standardů, které vznikly z původního KDE projektu

🏹 A co Gecko?

  • Mozilla (a dříve Netscape) šla vlastní cestou s NGLayout → Gecko
  • Firefox je dnes poslední prohlížeč, který nepoužívá WebKit/Blink
  • Je to technologický disident, který drží otevřený web naživu

Linux (KHTML) je otcem moderního webu, Apple byl jeho „adoptivní rodič“ a Google jeho „ambiciózní potomek“. A Firefox je ten poslední samuraj, co drží prapor původního Netscape.

Tady jsou klíčoví vývojáři KHTML, kteří stáli za tímto zásadním projektem v rámci KDE:

🧑‍💻 Klíčové osobnosti vývoje KHTML

🔹 Lars Knoll

  • Hlavní architekt přepisu KHTML v roce 1999
  • Implementoval podporu pro DOM (Document Object Model)
  • Později se podílel i na vývoji Qt WebEngine a WebKit

🔹 Harri Porten

  • Autor KJS, JavaScriptového enginu pro KHTML
  • Díky němu získal KHTML schopnost spouštět skripty na stránkách

🔹 Antti Koivisto

  • Spolupracoval na podpoře CSS a stabilizaci architektury
  • Později pracoval i na WebKitu a Blink

🔹 Dirk Mueller

  • Pomáhal s optimalizací a stabilizací jádra
  • Přispěl k podpoře jazyků psaných zprava doleva (např. hebrejština, arabština)

🔹 Waldo Bastian

  • Jeden z prvních, kdo pracoval na původní verzi KHTML
  • Pomáhal s refaktoringem kódu a přechodem na Unicode

🔹 Torben Weis & Martin Jones

  • Autoři předchůdce KHTML — KHTMLW (KDE HTML Widget)
  • Implementovali HTML 3.2, HTTP 1.0, rámce, ale bez DOM a CSS

Shrnutí

KHTML vznikl jako čistě komunitní projekt v rámci KDE a jeho vývojáři položili základy pro dnešní dominantní vykreslovací jádra — WebKit a Blink. Bez jejich práce by dnešní web vypadal úplně jinak.

Původní KHTML začínal jako jednoduchý HTML widget pro KDE, který měl zobrazovat základní webové stránky. Ale díky několika klíčovým vlastnostem se z něj stal základ pro moderní webové prohlížeče:

🔍 Proč se KHTML uchytil a stal se základem pro WebKit

✅ Čistý a modulární kód

  • KHTML byl napsán velmi přehledně, s důrazem na čistotu architektury.
  • To umožnilo snadné přizpůsobení a rozšíření — což ocenil Apple při výběru jádra pro Safari.

⚡ Vysoká rychlost

  • Byl rychlý a efektivní, což bylo v době pomalých počítačů zásadní.
  • Nepotřeboval velké systémové prostředky, což ho činilo ideálním pro přenosné zařízení.

🧩 Dobrá integrace s KDE

  • Fungoval jako součást desktopového prostředí KDE, což mu zajistilo stabilní komunitu a pravidelný vývoj.

🍏 Apple a WebKit

  • V roce 2002 Apple forkne KHTML a KJS, čímž vzniká WebKit.
  • WebKit se stává základem pro Safari, později i pro Chrome (před vznikem Blink).

🧠 Zajímavost

Apple sice použil KHTML, ale zpočátku nekomunikoval zpět s KDE komunitou, což vedlo k určitému napětí. Nakonec se ale spolupráce zlepšila a WebKit se stal otevřeným projektem.

Apple má v tomhle trochu reputaci „nafoukance“ — vezme něco otevřeného, elegantně to přebranduje, a pak to prezentuje jako vlastní revoluci. V případě KHTML to bylo obzvlášť vidět:

🍏 Apple a „vlastnění“ open-source

🧠 Co se stalo:

  • Apple v roce 2002 forkne KHTML a KJS → vzniká WebKit.
  • Zpočátku neposílá zpět změny do KDE komunity, což vývojáře KDE dost frustrovalo.
  • Apple upravuje kód pro své potřeby (Safari, iPhone), ale komunikace byla jednostranná.

🤨 Jak se Apple tvářil:

  • Prezentoval WebKit jako vlastní inovaci, i když základní architektura byla z KHTML.
  • V marketingu se málokdy zmiňovalo KDE nebo původní vývojáři.

🧩 Co z toho vzešlo:

  • WebKit se stal základem pro Safari, později i pro Chrome (než vznikl Blink).
  • Komunita KDE nakonec uznala, že i když to nebylo ideální, WebKit pomohl rozšířit jejich práci do světa.

🗣️ Citát vývojáře KDE

„Kdyby Apple posílal změny zpět, mohli jsme spolupracovat. Ale místo toho jsme dostávali obrovské diffy, které nešly sloučit.“ — Lars Knoll, vývojář KHTML

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/08/16/pamatujete-jeste-netscape-vs-ie/

Čvc 30 2025

Porovnání: IPFire vs pfSense vs OPNsense

  • 30. 7. 2025

Vlastnost IPFire pfSense OPNsense
Základ Linux (custom) FreeBSD FreeBSD (fork pfSense)
GUI Jednoduché, přehledné Pokročilé, komplexní Moderní, intuitivní
VPN OpenVPN, IPsec, WireGuard OpenVPN, IPsec, WireGuard OpenVPN, IPsec, WireGuard
Zónování sítě Red/Green/Blue/Orange VLAN/subnety VLAN/subnety
Výkon Stabilní na slabším HW Výborný, ale náročnější Výborný, optimalizovaný
Bezpečnost IDS (Snort), ClamAV IDS/IPS (Snort/Suricata) IDS/IPS (Suricata), ClamAV
Komunita Menší, aktivní Velká, rozsáhlá dokumentace Aktivní, rychle rostoucí
Rozšíření Pakfire (jednoduché) FreeBSD balíčky Pluginy, rychlý vývoj
Ideální pro Domácnosti, SMB, začátečníky Firmy, pokročilé uživatele Firmy, pokročilé i začátečníky
Aktualizace Časté, bezpečnostní Stabilní, pomalejší cyklus Rychlé, časté novinky

🧠 Shrnutí

  • IPFire: jednoduchý, bezpečný, ideální pro domácí routery nebo SMB. Super na starší železo.
  • pfSense: robustní, ale složitější. Skvělý pro enterprise, ale GUI je těžší na orientaci.
  • OPNsense: moderní, svižný, s pluginy a aktivním vývojem. Vhodný pro ty, co chtějí víc než pfSense, ale bez zbytečné složitosti.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/30/porovnani-ipfire-vs-pfsense-vs-opnsense/

Čvc 28 2025

Zabbix vs PRTG

  • 28. 7. 2025

Tady je přehledné srovnání, zaměřené čistě na bezplatné verze obou nástrojů:

📊 Srovnání Zabbix vs PRTG (free verze)

Funkce / Vlastnost Zabbix (Open Source) PRTG (Free do 100 senzorů)
🧠 Zaměření Servery, aplikace, síť, databáze Síť, servery, aplikace, IoT, cloud
🧭 Discovery Automatické, SNMP, ICMP, agent Automatické, SNMP, WMI, packet sniffing
📈 Grafy a dashboardy Flexibilní, ale méně vizuálně atraktivní Moderní, drag & drop dashboardy
🔔 Notifikace E-mail, SMS, webhook, skripty E-mail, SMS, push, Slack, webhook
🧩 Rozšiřitelnost API, skripty, šablony, proxy API, custom senzory, integrace
🧰 Monitoring serverů Agent-based i agentless Agentless (WMI, SNMP), volitelný agent
🧪 Monitoring aplikací Šablony, skripty Přednastavené senzory (např. VoIP, AD, SQL)
🧱 Škálovatelnost Vysoká, proxy servery Omezená ve free verzi (100 senzorů)
🖥️ Webové rozhraní Funkční, ale konzervativní Moderní, intuitivní GUI
📱 Mobilní aplikace Ne (jen web) Ano (Android, iOS)
💰 Cena 100% zdarma Zdarma do 100 senzorů, potom placené licence

🧠 Shrnutí

  • Zabbix je robustní open-source nástroj, ideální pro komplexní monitoring v prostředí, kde si můžeš vše nastavit podle sebe.
  • PRTG je víc „out-of-the-box“ — má přednastavené senzory, krásné dashboardy a rychlou instalaci, ale ve free verzi tě limituje počtem senzorů.

Pokud ti jde o vizuální přehlednost, rychlé nasazení a jednoduché ovládání, PRTG je blíž tomu, co nabízí třeba LibreNMS, ale s větším rozsahem. Pokud chceš plnou kontrolu, škálovatelnost a open-source filozofii, Zabbix je silnější hráč.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/zabbix-vs-prtg/

Čvc 28 2025

Přehledné srovnání Zabbix vs LibreNMS

  • 28. 7. 2025

Zaměřeno čistě na bezplatné verze, které jsou dostupné open-source komunitě. Oba nástroje jsou zdarma, ale liší se filozofií, rozsahem funkcí i náročností na správu:

📊 Srovnání Zabbix vs LibreNMS (zdarma)

Funkce / Vlastnost Zabbix LibreNMS
🧠 Zaměření Komplexní monitoring všeho (servery, síť, appky) Primárně SNMP monitoring síťových zařízení
🧭 Discovery (objevování) Automatické, přes SNMP, ICMP, IPMI, agent Automatické, přes SNMP, LLDP, CDP, ARP
📈 Grafy a vizualizace Pokročilé, vlastní dashboardy, mapy Jednoduché, přehledné SNMP grafy
🔔 Alerting / Notifikace Velmi flexibilní, podmínky, korelace událostí Jednoduchá pravidla, notifikace přes e-mail, Slack
🧩 Rozšiřitelnost API, skripty, integrace, proxy API, pluginy, oxidized, grafana
🧰 Monitoring serverů Agent-based i agentless (Linux, Windows, DB, appky) Omezený, hlavně SNMP
🧪 Monitoring aplikací Ano (MySQL, Apache, Docker, atd.) Ne (nebo velmi omezeně)
🧱 Škálovatelnost Vysoká, proxy servery, distribuované prostředí Horizontální škálování přes pollery
🖥️ Webové rozhraní Funkční, ale méně moderní Moderní, přehledné GUI
🧑‍💻 Komunita / Podpora Velká komunita, dokumentace, fórum Aktivní komunita, GitHub, fórum
💰 Cena (free verze) 100% zdarma, open-source 100% zdarma, open-source
📦 Instalace Vyžaduje víc ruční konfigurace Jednodušší, skripty pro automatickou instalaci

🧠 Shrnutí

  • Zabbix je jako švýcarský nůž — zvládne monitoring téměř všeho, ale vyžaduje víc času na nastavení.
  • LibreNMS je jako elegantní síťový sniffer — rychle nasadíš, krásně vidíš SNMP data, ale mimo síťové zařízení je omezený.

Pokud chceš monitorovat servery, aplikace, databáze, kontejnery, Zabbix je jasná volba.

Pokud ti jde hlavně o síťová zařízení, SNMP, jednoduché grafy a discovery, LibreNMS je pohodlnější.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/prehledne-srovnani-zabbix-vs-librenms/

Čvc 28 2025

OpenVPN vs WireGuard

  • 28. 7. 2025

WireGuard je v podstatě modernější alternativa k OpenVPN, která přináší několik technických i praktických výhod. Tady je srovnání, které ti pomůže pochopit rozdíly:

⚡ Rychlost a výkon

Protokol Rychlost Zpoždění Spotřeba CPU
WireGuard Vysoká Nízké Nízká
OpenVPN Střední Vyšší Vyšší
  • WireGuard je až o 50–70 % rychlejší než OpenVPN při stejném šifrování
  • Má menší režii díky jednodušší architektuře.

🔐 Bezpečnost

    • WireGuard používá moderní kryptografii: ChaCha20, Curve25519, Poly1305.
    • OpenVPN je flexibilní — můžeš si vybrat z více šifrovacích metod (AES, Blowfish…), ale to může vést ke složitější konfiguraci.
    • Oba jsou open-source a bezpečné, ale WireGuard má jen ~4 000 řádků kódu, což usnadňuje audit a snižuje riziko chyb

🧠 Jednoduchost a konfigurace

  • WireGuard je extrémně jednoduchý na nastavení — ideální pro mobilní zařízení nebo routery.
  • OpenVPN je robustní a flexibilní, ale může být náročnější na konfiguraci (certifikáty, TLS, porty…).

🌍 Kompatibilita

  • OpenVPN funguje prakticky všude — Windows, Linux, macOS, Android, routery.
  • WireGuard je novější, ale už ho podporuje většina VPN služeb a OS (včetně Linux kernelu).

🕵️‍♂️ Soukromí

  • WireGuard v základní verzi uchovává IP adresy na serveru (kvůli jednoduchosti), ale většina VPN služeb to řeší dynamickým přidělováním nebo mazáním po relaci.
  • OpenVPN neukládá žádná data o uživateli, což je výhoda pro anonymitu.

🧭 Kdy zvolit WireGuard?

  • Pokud chceš rychlejší VPN, která méně zatěžuje systém.
  • Pro mobilní zařízení nebo routery s omezeným výkonem.
  • Když ti stačí jednoduchá konfigurace bez složitých certifikátů.

🧱 Kdy zůstat u OpenVPN?

  • Pokud potřebuješ maximální kompatibilitu a jemné doladění (např. TCP/UDP porty, obfuskaci).
  • Pro firemní prostředí nebo specifické síťové scénáře.

 

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/openvpn-vs-wireguard/

Čvc 28 2025

Souboj nenasytnosti mezi desktopovými prostředími

  • 28. 7. 2025

Tady je přehled, jak si vedou z hlediska RAM, CPU zátěže a celkové efektivity:

🧠 RAM spotřeba při čistém startu

Prostředí RAM (čistý start) Poznámka
GNOME ~750 MB Těžkotonážní, plný efektů
KDE Plasma ~650 MB Bohatý na funkce, ale optimalizovaný
Cinnamon ~630 MB GNOME fork, podobně náročný
MATE ~540 MB Lehký GNOME 2 fork
Xfce ~450 MB Střední váha, velmi svižný
LXQt ~400 MB Ultra lehký, moderní Qt
i3 ~100–200 MB Tiling WM, extrémně úsporný

⚙️ CPU zátěž a odezva

  • GNOME: Efekty, animace, Wayland → vyšší CPU zátěž i při nečinnosti.
  • KDE: Překvapivě svižný, ale některé widgety (např. CPU monitor) žerou dost.
  • Xfce: Nízká zátěž, ale některé panely můžou být žrouti.
  • LXQt: Minimalistický, téměř žádná zátěž.
  • i3: Tiling bez GUI pozlátka → CPU skoro nepozná, že něco běží.

🧩 Funkce vs. nenasytnost

Prostředí Funkce Nenasytnost
GNOME 🧁 Moderní, ale těžký 🟥 Vysoká
KDE 🛠️ Extrémně přizpůsobitelný 🟨 Střední
Xfce 🧃 Jednoduchý, stabilní 🟩 Nízká
LXQt 🧊 Ultra lehký, méně funkcí 🟩 Nízká
i3 🧱 Hardcore minimalismus 🟩 Extrémně nízká

🧪 Reálný dojem

  • KDE: Pokud si ho ořežeš (bez widgetů, efektů), může být stejně lehký jako Xfce.
  • GNOME: Vypadá hezky, ale na slabším stroji tě zničí.
  • Xfce/LXQt: Ideální pro starší stroje nebo low-RAM systémy.
  • i3: Pokud ti nevadí ovládat vše klávesnicí, je to raketa.

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/28/souboj-nenasytnosti-mezi-desktopovymi-prostredimi/

Čvc 18 2025

🐉 Bajka o VMware

  • 18. 7. 2025

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/

Čvc 15 2025

Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)

  • 15. 7. 2025

Stáhnout článek v PDF: Zásady forenzní bezpečnostní připravenosti v prostředí SME (malých a středních podniků)

Jak zajistit, aby vaše IT prostředí bylo schopné zpětně vyhodnotit, analyzovat a právně obhájit jakýkoliv bezpečnostní incident – bez ohledu na velikost firmy.

V době, kdy je e-mail hlavním nástrojem komunikace a zároveň běžným cílem kybernetických útoků, nestačí jen „fungovat“. Je třeba umět dokázat, že infrastruktura byla spravována bezpečně, že byla schopná incident včas identifikovat – a že lze zpětně rekonstruovat jeho průběh.

Malé a střední podniky (SME) často nemají vlastní bezpečnostní tým, přesto mohou být dobře připravené – díky otevřeným standardům, chytrému nastavení a přiměřené dokumentaci.

🛡️ Klíčové pilíře forenzní připravenosti

Oblast Co znamená v praxi
Auditní stopy Uchovávání logů, přístupových záznamů, e-mailových tras
Retenční politika Jasné pravidlo, jak dlouho se ukládají data (např. logy 90 dní)
Zabezpečení schránek Ochrana hesel, 2FA, izolace kritických rolí
Reprodukce incidentu Možnost zpětně analyzovat, co se stalo (čas, IP, uživatel, soubor)
Soulad s právem Dodržování GDPR, archivace dat a auditovatelnost procesů
Školení a procesy Správce ví, co dělat, když dojde k podezřelé aktivitě

📋 Checklist forenzní připravenosti (pro správce e-mailového systému)

✅ Logy přístupů na IMAP/SMTP uchovávám alespoň 90 dní

✅ E-mailová relace (MAIL FROM / RCPT TO / relay IP) se ukládá do syslogu nebo SIEM* (Security Information and Event Management – systém pro sběr a analýzu logů) (viz. níže)

✅ Mám detekci neobvyklého chování (např. přihlášení z cizího regionu)

✅ Antispamový systém (Rspamd) loguje score a rozhodnutí v detailu

✅ Webmail (např. SOGo) má audit zapnutí/offline režimu, exportu kontaktů apod.

✅ Všechny přístupy přes web UI mají logovací mechanismus a TLS enforcement

✅ Zálohování VM obsahuje metadata i logy, není rotováno bez validace

✅ Uživatelé nemohou měnit SPF/DKIM bez administrátorského přístupu

✅ Existuje směrnice pro práci s e-mailovou schránkou při odchodu zaměstnance

✅ V případě incidentu mám dokument, jak vytáhnout logy, přehled schránek a přístupy

„Pro sběr logů z e-mailového serveru lze využít open-source nástroje jako Wazuh, Graylog nebo OSSEC, které umožňují sledovat relace, přihlašování i anomálie.“ (viz. níže)

🎓 Doporučení pro malé firmy

  • I bez SIEM nebo externího auditního systému lze dosáhnout vysoké úrovně bezpečnosti – stačí mít logiku, smysl pro konzistenci a pravidelně ověřovat funkčnost
  • Dokumentace může mít podobu textového souboru v Git repozitáři, nebo PDF s verzováním – nepotřebujete systém za miliony
  • Forenzní připravenost není paranoia – je to právní štít, když někdo zneužije firemní e-mail, napadne server nebo exfiltruje kontakty

*SIEM je zkratka pro Security Information and Event Management — v češtině by se to dalo přeložit jako „Správa bezpečnostních informací a událostí“.

 

🧠 Co SIEM vlastně dělá?

Je to systém, který:

  • Sbírá logy a události ze všech zařízení v síti (firewally, servery, e-mailové systémy, webmail, VPN…)
  • Analyzuje je v reálném čase → hledá podezřelé chování, útoky, anomálie
  • Umožňuje zpětně rekonstruovat incident → kdo, kdy, odkud, co udělal
  • Pomáhá s compliance → GDPR, ISO 27001, NIS2, HIPAA, PCI-DSS…

🔍 Příklad z praxe:

Když se někdo přihlásí do webmailu z Ruska ve 3 ráno, SIEM to:

  1. Zaznamená jako událost
  2. Porovná s běžným chováním uživatele
  3. Vyhodnotí jako anomálii
  4. Pošle alert správci
  5. Umožní dohledat celý průběh (IP, čas, akce, přístup k souborům…)

📦 Co SIEM není?

  • Není to firewall, ale nadstavba nad logy
  • Není to antivir, ale centrální mozek pro bezpečnostní analýzu
  • Není to jen logovací systém — umí korelaci, alerty, reporting

🧠 Top open-source SIEM nástroje vhodné k mailserveru

🛠️ Nástroj Co umí / Proč se hodí k mailserveru Poznámka k nasazení
Wazuh HIDS + SIEM: logy, integrity check, rootkit detekce, compliance ✅ Docker / VM / bare-metal
OSSEC Host-based IDS, logy z mailserveru, detekce změn ✅ Lehký, ale méně UI-friendly
Security Onion Kompletní distro: Suricata, Zeek, ELK, Wazuh, Kibana ⚠️ Náročnější na HW, ale komplexní
Graylog Log management + alerty, vizualizace, geolokace IP ✅ Moderní UI, vhodné pro SMTP/IMAP logy
ELK Stack Elasticsearch + Logstash + Kibana → logy, dashboardy ⚠️ Nutná konfigurace korelace
Snort / Suricata IDS/IPS pro síťovou vrstvu, SMTP traffic, port scan ✅ Doplněk k SIEM, ne SIEM samotný
Prelude SIEM Korelace událostí, IDMEF standard, integrace s OSSEC/Snort ⚠️ Méně známý, ale standardizovaný
MozDef SIEM od Mozilly, microservices, alerty, Elastic backend ⚠️ Vyžaduje čas na nastavení

🔐 Co sledovat u mailserveru pomocí SIEM

  • SMTP relace: MAIL FROM / RCPT TO / relay IP
  • IMAP/POP3 přihlášení: čas, IP, geolokace, počet pokusů
  • Webmail akce: export kontaktů, přístup z mobilu, offline režim
  • Antispam rozhodnutí: score, reject důvody, greylisting
  • TLS handshake: verze, cipher, expirace certifikátu
  • DKIM/SPF/DMARC logy: validace, selhání, spoofing pokusy

💡 Doporučení

  • Pro lehké nasazení k mailcow: Wazuh nebo Graylog
  • Pro komplexní monitoring: Security Onion nebo ELK Stack
  • Pro síťovou vrstvu: doplňit o Suricata nebo Snort
  • Pro forenzní audit: kombinuj s logy z Postfixu, Dovecotu, rspamd

Pokud si vše jmenované zvládnete sami nainstalovat a hlavně zkonfigurovat, máte TOP řešení kompletně zdarma, přičemž jeho reálná hodnota bude od stovek tisíc do několika milionů podle zvolené konfigurace v porovnání s komerčnímy systémy používanými napřiklad v bankovním sektoru.

„Tento text není právní analýzou, ale technickým přehledem možností, jak podpořit bezpečnostní auditovatelnost e-mailového prostředí. V případě regulovaných odvětví doporučujeme konzultaci s právníkem.“

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/15/zasady-forenzni-bezpecnostni-pripravenosti-v-prostredi-sme-malych-a-strednich-podniku/

Čvc 11 2025

Co je Kubernetes 3 – Tanzu na vSphere vs. Linux + Kubernetes + KVM

  • 11. 7. 2025

🧠 Tanzu a Kubernetes na vSphere = běží to pod vCenterem, ale část běží přímo na ESXi

Jak to funguje fakticky:

  1. vCenter Server (VM s Photon OS = lehký Linux) slouží jako centrální mozek – GUI, správa clusterů, orchestrace, API, atd.

  2. Supervisor Cluster = Kubernetes běží jako nativní služba na ESXi – ne jako běžící VM s Linuxem, ale jako vnitřní komponenty ESXi (vSphere podpora pro kontejnery)

  3. Tanzu pak umí vytvořit běžné VM, ve kterých běží tzv. TKG clustery – ty už jsou klasicky v Ubuntu/CentOS/Photon a obsahují Kubernetes jako normálně

➕ To znamená:

  • část běží přímo na ESXi (bez Linux VM) = ano, „nativně“

  • část (vCenter, TKG VM) běží jako klasické virtuály = ne tak nativně

🔄 Porovnání: Tanzu na vSphere vs. Linux + Kubernetes + KVM

Vlastnost Tanzu na vSphere Linux + Kubernetes + KVM
Hypervizor ESXi (VMware) Linux + KVM
Správa vCenter, GUI, Workload Mgmt CLI, Cockpit, Virt-Manager, atd.
Kubernetes běží jako… částečně nativní služba + VM s K8s jako běžný software nad OS
Požadavky na síť/sdílené storage vysoké (vDS, HAProxy/NSX, DRS) minimální nebo žádné
Komplexnost prvotního nasazení vysoká (hodiny až dny) nízká/střední (desítky minut až pár hodin)
Cena vysoká (Enterprise licence, vCenter, NSX-T?) prakticky nulová (Linux je zdarma)
Běh VM ✅ nativní, efektivní ✅ s KVM, dobrá virtualizace
Výkon velmi vysoký vysoký
Flexibilita nízká, vendor lock-in vysoká, plná kontrola
Upgrady centralizované, ale podmíněné licencemi plně v tvé režii

🎯 Realistický závěr:

Ano, když máš vlastní server (např. Dell 730xd), tak místo ESXi a Tanzu můžeš dát rovnou Linux (např. Debian/Ubuntu/AlmaLinux), a na něj postavit Kubernetes + KVM + všechno, co chceš – bez licencí, bez složitostí, s větší svobodou.

Tohle řešení:

  • bude výrazně levnější,

  • budeš ho víc ovládat, žádné vendor-locky,

  • Kubernetes můžeš rozběhnout snadno (K3s, kubeadm, MicroK8s, atd.),

  • virtuály můžeš rozjet přes KVM/QEMU, s webovým rozhraním (Cockpit) nebo CLI.

🧰 Konkrétní tipy na to, jak to udělat

 

Tady máš základní stavbu toho opensource „homelab cloudu“:

  1. 🐧 OS: Debian nebo Ubuntu Server

  2. ☸️ Kubernetes: K3s (lehčí, ideální pro jeden node) nebo kubeadm

  3. 🖥️ Virtualizace: libvirt + KVM + Cockpit (nebo Virt-Manager)

  4. 📦 Container registry: třeba Harbor nebo Docker Registry

  5. 🛡️ Ingress, monitoring, backup: Traefik/NGINX + Prometheus + Velero

  6. 🌐 GUI: Portainer (kontejnery), Cockpit (host), Rancher (K8s GUI)

  7. ⚡ Deployment: Ansible nebo bash script

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-3-tanzu-na-vsphere-vs-linux-kubernetes-kvm/

Čvc 11 2025

Co je Kubernetes 2 – Co je Tanzu (VMware)

  • 11. 7. 2025

🌱 Co je Tanzu?

Tanzu = Kubernetes platforma od VMware.

👷‍♂️ K čemu je:

Tanzu není jen „verze Kubernetesu“, ale celá sada nástrojů, která umožňuje:

  • instalovat a spravovat Kubernetes clustery ve vSphere (VMware),

  • integrovat Kubernetes do tvých VM prostředí,

  • spravovat kontejnery stejně snadno jako VM,

  • automatizovat CI/CD, bezpečnost, monitoring, síť a storage v K8s.

📦 VMware Tanzu Kubernetes Grid (TKG) je hlavní nástroj, který nasazuje čistý Kubernetes s podporou od VMware.

 

🔗 Můžeš propojit Kubernetes na vlastním serveru s Google Cloudem?

✅ Ano. Toto se jmenuje Hybridní Kubernetes (Hybrid Cloud) nebo Multi-Cloud Cluster Management.

Jak na to:

  • Propojíš svůj on-premise Kubernetes cluster (např. Tanzu, K3s, RKE, OpenShift…) s Google Kubernetes Engine (GKE) pomocí Anthos, VPN tunelů, nebo Federace.
  • Výsledkem je, že máš centralizovanou správu, monitoring, případně můžeš workloady „rozhazovat“ podle vytížení mezi on-prem a cloud.

🔧 Nástroje:

  • Anthos (Google) – propojí on-prem K8s (včetně Tanzu) s GKE.
  • Rancher, ArgoCD, FluxCD, kubeadm – jiné možnosti pro hybridní orchestraci.
  • Cloud VPN / BGP routing – propojí sítě mezi tvými servery a Googlem.

💻 Jak se Kubernetes na VMware instaluje a provozuje?

Dvě možnosti podle úrovně integrace:

🔧 1) Tanzu vSphere – integrace přímo do VMware prostředí

💡 Pouze pro vSphere 7 Enterprise+ a vyšší s vCenter Serverem a vSAN.

Co se děje:

  • VMware vSphere vytvoří Supervisor Cluster – Kubernetes běží nativně nad hypervisorem.

  • Kubernetes je součástí VMware – spravuješ ho z vSphere UI.

  • Můžeš vytvářet VM i kontejnery z jednoho prostředí.

  • Přidáš Tanzu Kubernetes Grid jako „template“ do prostředí → pak už jen klikáš clustery.

Výhoda:

  • Není třeba spouštět VM s Linuxem.

  • Kubernetes běží jako „first-class citizen“ v ESXi.

🧱 2) Manuální instalace Kubernetes ve virtuálním stroji

Funguje na jakékoli VMware verzi (i Workstation, ESXi Free).

Jak to vypadá:

  1. Vytvoříš virtuálku s Linuxem (Ubuntu, CentOS, Fedora…).

  2. Nainstaluješ kubeadm, kubectl, kubelet (nebo použiješ např. MicroK8s, K3s).

  3. Spustíš kubeadm init, nastavíš networking, storage, apod.

  4. Hotovo – běží ti plný Kubernetes cluster ve VM.

📦 Tip: Pokud chceš rychle a jednoduše, použij:

  • K3s (lehčí Kubernetes od Rancher Labs)

  • MicroK8s (od Canonical, jednoduše rozběhneš i lokálně)

🔁 Shrnutí rozdílů:

Možnost vSphere s Tanzu VM s Linuxem + Kubernetes
Podpora od VMware ✅ Plná ❌ Vlastní odpovědnost
Kubernetes nativně ve vSphere ✅ Ano ❌ Ne
Výkon ⚡ Vysoký (běží přímo na ESXi) 🐢 Závisí na VM
Komplexita instalace ⚙️ Vyšší na začátku, pak klikací ⚙️ Jednoduché, ale ruční
Možnost škálování ✅ Lepší ⚠️ Omezená kapacitou VM
Pro malé laby / domácí ❌ Náročné ✅ Ideální řešení

📌 Shrnutí pro tebe

  • Tanzu = platforma od VMware, která ti umožní spustit Kubernetes přímo na vSphere bez potřeby Linuxových VM.

  • Můžeš Kubernetes propojit s Google Cloudem (např. GKE) pro hybridní nasazení.

  • Pokud nemáš Tanzu licenci, běžná instalace do Linuxové VM ti dá plnohodnotný Kubernetes (např. K3s).

  • GKE je Kubernetes jako služba v cloudu, nemusíš se o nic starat – vhodné na produkci nebo testovací deploymenty.

Tanzu není „jen“ aplikace pod Linux, ale zároveň není tak integrovaná a pohodlná, jak by člověk čekal za ty prachy, co VMware vEnterprise stojí.

Tady je realita bez marketingu:

🧱 Jak se Tanzu instaluje pod VMware (vSphere 7)

🚨 Realita: „Tanzu“ nezapneš jedním tlačítkem jako VM – ale dá se to zautomatizovat, a jakmile to máš, je to pak „klikací“.

Tanzu = několik komponent dohromady:

Vrstva Co to je
Supervisor Cluster Kubernetes běžící přímo na ESXi (zabudovaný do hypervizoru)
Tanzu Kubernetes Grid (TKG) Sada nástrojů pro tvorbu dalších K8s clusterů
NSX-T nebo vDS Nutné pro síťování Kubernetesu
Harbor registry (volitelné) pro vlastní docker image
vSphere Namespace + Content Library Prostředí pro kontejnery a clustery

✅ Co musíš mít (kontrolní seznam):

Potřeba Detaily
✅ vSphere 7 Enterprise Plus Jinak Tanzu neaktivuješ
✅ vCenter Server 7 GUI, řízení clusteru
✅ Cluster s aktivním DRS (Distributed Resource Scheduler)
✅ vSphere Distributed Switch (vDS) nebo NSX-T Pro networking Kubernetesu
✅ Content Library Aby měl Tanzu odkud brát image
✅ Load Balancer (např. HAProxy) Pro přístup na služby v K8s
❗ Volitelné: DNS, NTP, storage policies, storage classes atd.

🔧 Instalace krok za krokem (v kostce)

  1. Vytvoř cluster ESXi hostů (musí mít DRS a sdílené storage)

  2. Vytvoř vSphere Distributed Switch + Port Groups pro komunikaci (pokud nemáš NSX-T)

  3. Zapni vSphere with Tanzu ve vCenteru:

    • Přes Workload Management (vSphere Client → Menu → Workload Management)

    • Vybereš cluster, DVS, IP Pool, storage policy, load balancer (např. HAProxy VM)

  4. vSphere vytvoří Supervisor Cluster:

    • Kubernetes běžící přímo na hypervizoru (ne v Linux VM)

    • Vytvoří se Namespace, které pak spravuješ

  5. Vytvoř Content Library s Tanzu Kubernetes Grid image

  6. Z ní pak vytváříš Tanzu Kubernetes clustery na jedno kliknutí

📦 Co je vlastně Tanzu Kubernetes Grid (TKG)?

  • Image, který se spouští jako VM s Linuxem + Kubernetes + agenti

  • Spouští se automaticky přes vSphere, pokud máš nastavený Supervisor

  • Můžeš ho mít i mimo vSphere, např. na AWS, Azure nebo bare-metal

💬 Takže shrnuto:

  • Supervisor Cluster = Kubernetes běžící nativně na ESXi (ne v Linuxu)

  • TKG = běžící Kubernetes v klasické VM (ale připraveno, automatizováno)

  • Všechno ovládáš z vSphere GUI přes Workload Management

  • Ale předtím musíš:

    • Mít licence

    • Síť (DVS nebo NSX-T)

    • Storage policy

    • Load Balancer (HAProxy / NSX Load Balancer)

🔗 Chceš to reálně zkusit?

Doporučuji začít s Tanzu přes HAProxy a vSphere Distributed Switch, protože NSX-T je peklo (složitý, drahý).

🧠 Myšlenka na závěr:

Ano, Tanzu běží „pod Linuxem“, ale tím Linuxem je v tomhle případě už samotnej hypervizor ESXi – takže Kubernetes běží natvrdo „na železe“, bez prostředníka v podobě klasické VM.

To je důvod, proč je to tak stabilní, ale zároveň složitější na setup.

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes-2-co-je-tanzu-vmware/

Čvc 11 2025

Co je Kubernetes?

  • 11. 7. 2025

🧠Pojďme to rozbalit od základů — co je Kubernetes, k čemu je dobrý, a jak to souvisí s VMwarem, cloudem a proč Google nabízí vytvoření Kubernetes clusteru.

Asi už pár z vás napadlo co je to za technologii, ale nikde to není kloudně popsaný. Člověk se dozví že jde o kontejnery co běží na nějakém linuxu, že to jede v Cluseru kvůli škálování, potřebuje to nějaké řízení a tak, ale ve finále když už na tom někdo něco chce provozovat, tak si to raději zaplatí u Googlu, protože to rozjet u sebe je na kulku do hlavy. Když potom ještě máte komerční řešení od VMware 7 Enterprise Plus a čekáte snad, že když je to komerční produkt, tak to bude snažší, tak si tu kulku lebkou proženete, protože je to ješte xnásobně složitější 🙂

vSphere 7 Enterprise Plus Features:

  • APIs for Storage Awareness
  • Big Data Extensions
  • Compatible with Tanzu Kubernetes Grid Service and Hybrid Infrastructure Service
  • Content Library
  • Cross Virtual Center vMotion
  • Direct Path vMotion
  • H.264 for Remote Console Connections
  • Hot-Pluggable virtual HW
  • MPIO / Third-Party Multi-Pathing
  • Persistent Memory
  • Reliable Memory
  • Remote virtual Serial Port Concentrator
  • Shared Smart Card Reader
  • SR-IOV
  • Storage APIs
  • Storage-Policy Based Management
  • Unlimited virtual SMP
  • vCenter agent for VMware host
  • vGPU
  • Virtual Volumes
  • vShield Endpoint
  • vShield Zones
  • vSphere API
  • vSphere App HA
  • vSphere Auto Deploy
  • vSphere Bitfusion
  • vSphere Data Protection
  • vSphere Distributed Switch
  • vSphere DRS
  • vSphere Encrypted vMotion
  • vSphere FT (up to 8 virtual CPUs)
  • vSphere HA
  • vSphere Host Profiles
  • vSphere Predictive DRS
  • vSphere Proactive HA
  • vSphere Replication
  • vSphere Storage APIs for Array Integration
  • vSphere Storage DRS
  • vSphere Storage I/O Control
  • vSphere Storage vMotion
  • vSphere Trust Authority
  • vSphere View Accelerator
  • vSphere VM Encryption
  • vSphere vMotion
  • vSphere vMotion Metro
  • X-Switch vMotion

🧠 Co je Kubernetes?

Kubernetes (zkráceně K8s) je open-source platforma na správu a orchestraci kontejnerů. Vyvinul ho Google a dnes ho spravuje CNCF (Cloud Native Computing Foundation).

🔧 Co to znamená jednoduše:

  • Máš aplikaci rozdělenou do malých izolovaných „krabiček“ = kontejnerů (např. pomocí Dockeru).

  • Kubernetes se stará o to, kde běží, jak běží, kolik jich běží, restartuje je, škáluje, rozmisťuje po serverech atd.

  • Vytváří tzv. cluster – skupinu fyzických nebo virtuálních strojů, na kterých kontejnery běží.

💡 K čemu je Kubernetes dobrý?

  • Automatická obnova – když něco spadne, znovu to nahodí.

  • Škálování – když máš víc návštěvníků, rozběhne víc instancí.

  • Rollout / rollback – snadno nasazuješ nové verze, můžeš se vrátit zpět.

  • Load balancing – rovnoměrně rozděluje zátěž.

  • Deklarativní konfigurace – všechno popíšeš v YAML nebo JSONu.

☁️ Google nabízí „Create a Kubernetes cluster“

Google Kubernetes Engine (GKE) = Google-hostovaná verze Kubernetesu.
Je to vlastně „klikací“ způsob, jak si vytvořit celý Kubernetes cluster bez toho, že bys musel všechno instalovat a spravovat ručně.

Je to:

  • Rychlé a pohodlné – nemusíš nic konfigurovat, všechno se děje v Google Cloudu.

  • Produkčně připravené – můžeš škálovat na tisíce instancí.

  • Integrace s ostatními službami (síť, storage, monitoring, AI, billing atd.)

VMware vSphere 7 už má nativní podporu Kubernetes (vSphere with Tanzu).
To znamená, že tvůj vlastní server nebo cluster s VMwarem může taky provozovat Kubernetes.

V praxi:

  • Vytvoříš Kubernetes cluster přímo na svých VM.

  • Využíváš vlastní infrastrukturu místo cloudu.

  • Máš větší kontrolu, ale větší nároky na správu.

VMware + Kubernetes = hybridní cloud ready řešení.

🆚 Google Kubernetes Engine vs. vlastní (třeba VMware) Kubernetes

Funkce / Rozdíl Google Kubernetes Engine Vlastní Kubernetes na VMware
Správa clustru Google (automatická) Ty nebo tvůj admin
Infrastruktura Cloud On-premise (tvé servery)
Cena Platíš za výpočetní výkon Platíš za HW + provoz
Rychlost nasazení Velmi rychlá (minuty) Delší (instalace, konfigurace)
Flexibilita a kontrola Omezená (cloud) Vysoká (tvůj svět)

👨‍💻 Jak se to používá?

  1. Vytvoříš cluster (v cloudu nebo lokálně).

  2. Máš aplikaci jako Docker image (např. moje-api:v1).

  3. V YAMLu definuješ nasazení (Deployment), službu (Service), volume, ingress atd.

  4. Používáš příkazy jako:

    kubectl apply -f moje-aplikace.yaml
    kubectl get pods
    kubectl logs moje-api-xyz

  5. Kubernetes se postará o zbytek – nasadí, restartuje, spravuje.

🧭 Shrnutí – co si z toho odnést?

  • Kubernetes je orchestrátor kontejnerů – umožňuje provozovat aplikace škálovaně, stabilně a automatizovaně.

  • Google Kubernetes Engine je způsob, jak si to pustit v cloudu bez starostí o infrastrukturu.

  • VMware 7 Kubernetes taky umí – pro případy, kdy si chceš všechno řídit lokálně.

  • Kubernetes má smysl, když:

    • máš více aplikací/služeb

    • řešíš výpadky, škálování, CI/CD

    • chceš být nezávislý na jednom serveru

    • chceš prostředí připravené na růst nebo mikroservisní architekturu

 

Přímý odkaz na tento článek: https://www.sympatika.cz/2025/07/11/co-je-kubernetes/

Lis 15 2018

Čím jsme jiní…

  • 15. 11. 2018

…citelně lepší bezpečnost (zabezpečení), která je na Internetu v poslední době důležitější než cokoli jiného, je pro nás posláním. Zabezpečení sítě bereme více než vážně, proto také, když nás občas některý klient podlehnuvší nabídce (na papíře jenž snese všechno) opustí, se nestačí divit, co útoků mu najednou jeho „antivirus*“ hlásí. Skutečně se nejedná o útok na něj z naší strany jako mstu, za to že nás opustil. Často ani nevíme ke komu odešel, ale faktem zůstává, že dvouúrovňovou ochranu na vstupu sítě kterou disponujeme, mají jen skutečně kvalitní datová centra, minimum i velkých podniků a organizací včetně těch státních. Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2018/11/15/cim-jsme-jini/

Led 17 2017

Win 10 nenačte z DHCP serveru IP adresu

  • 17. 1. 2017

Windows 10 se již nevypínají jako předchozí verze windows. Používají tzv. rapid start, což je v podstatě stejné jako hibernace. Při stisknutí vypínace se tak počítač v podstatě jen uspává. Stejné je to i v případě, kdy dáte menu start->napájení->vypnout. Také dojde pouze k uspání. Při delším používaní, např. 3-6 měsíců se „něco“ stane v socketu a začnou se dít tyto anomálie. MS zřejmě předpokládal, že tlačítko restartovat by potom bylo zbytečně nevyužité a navíc, že systém se díky častým aktualizacím restartuje tak často, že jej není potřeba znovu startovat při zapnutí. Možná je důvod jiný, nevím, MS jsem se neptal :). Režim spánku je tak uspání do paměti a VYPNOUT je režim HIBERNACE. Režim hybridní hibernace obsažený v předchozích verzích zmizel, stejně jako vypnutí, které na všech ostatních mě známých systémech dělá i nadále vypnutí. (vypnu/zapnu=rebootuji, jen u MS se tomu říká restartuji.)

Pokračovat ve čtení

Přímý odkaz na tento článek: https://www.sympatika.cz/2017/01/17/win-10-nenacte-z-dhcp-serveru-ip-adresu/

error: Obsah je chráněný