Category Archives: Články

Analýza dialektického rozhodovacího procesu: Metodika kritického hodnocení technických návrhů

Analýza dialektického rozhodovacího procesu: Metodika kritického hodnocení technických návrhů

Analyzovaný postup představuje vzorový příklad aplikace dialektického myšlení, kritické analýzy a racionálního rozhodování při posuzování technického návrhu – konkrétně při úvaze o upgradu HW firewallu pfSense na energeticky úspornější řešení.

V praxi se manažeři, architekti i technici často potýkají s rozhodnutími, kde je nutné sladit ekonomická, technická a provozní hlediska pod tlakem rozpočtu, nejistoty a rychlých technologických změn. Povrchní nebo unáhlená rozhodnutí zde mohou vést k nečekaným nákladům, bezpečnostním rizikům či zbytečně zmařené investici.

Cílem tohoto textu je názorně ukázat, jak lze – pomocí strukturovaných, metodicky ověřených postupů – systematicky rozebrat i složité rozhodovací situace, odhalit skryté předpoklady, vyhnout se kognitivním zkreslením a dojít k řešení, které je obhájené daty i racionálním rozborem.
Čtenář tím získá praktický návod, jak podobná rozhodnutí činit lépe: bez zbytečných ztrát, s vyšší jistotou a objektivním vyhodnocením všech důležitých aspektů.

Popisovaný příklad je z technické praxe, metoda je však univerzálně přenositelná – napříč byznysem, IT, veřejnou správou i osobním rozhodováním, kde hraje roli více vzájemně provázaných faktorů.

Dialectical Decision-Making Process: pfSense Hardware Upgrade Analysis

Dialektické myšlení jako základ racionálního rozhodování

Dialektické myšlení je metoda uvažování, která systematicky zkoumá a smiřuje protichůdné nebo konfliktní myšlenky a perspektivy. V předloženém příkladu vidíme aplikaci tohoto přístupu prostřednictvím třífázového procesu:^1

Teze – Antiteze – Syntéza

Konverzace začíná implicitní tezí o výhodnosti upgradu na ASRock N100M. První odpověď však představuje silnou antitezi – systematickou kritiku návrhu z různých úhlů pohledu. Klíčové je, že tato kritika nebyla povrchní, ale strukturovaná podle různých dimenzí rizika:^1

  • Ekonomická dimenze: Skryté náklady, alternativní náklady (opportunity cost), marginálnost úspor
  • Technická dimenze: Kompatibilita, spolehlivost nového hardware
  • Provozní dimenze: Riziko výpadků, složitost migrace
  • Strategická dimenze: “If it ain’t broke, don’t fix it” princip

Síla dialektického přístupu se projevila ve třetí fázi, kdy uživatel systematicky vyvrátil jednotlivé body antiteze konkrétními argumenty a důkazy. Finální syntéza pak představovala nové, informovanější rozhodnutí založené na důkladné analýze obou perspektiv.^4

Praktické výhody dialektického přístupu

Dialektické myšlení v této situaci eliminovalo konfirmační zkreslení (confirmation bias) – tendenci vyhledávat pouze informace potvrzující naše předsudky. Namísto rychlého souhlasu s původním návrhem došlo k:^6

  1. Odhalení skrytých předpokladů o bezproblémovosti upgradu
  2. Prověření všech relevantních rizik technických i ekonomických
  3. Ověření faktické správnosti argumentů (např. kompatibilita pfSense s N100)
  4. Vytvoření robustního rozhodnutí odolného vůči budoucím výtkám

Decision Matrix: pfSense Hardware Upgrade Evaluation

Kritické myšlení: Framework pro systematickou analýzu

Předložený postup demonstruje aplikaci Paul-Elder frameworku kritického myšlení, který zahrnuje osm základních elementů:^8

Aplikované elementy kritického myšlení

Purpose (Účel): Jasně definovaný cíl – snížení energetické spotřeby HW pfSense firewallu při zachování funkčnosti a spolehlivosti.

Question (Otázka): “Je upgrade na N100M racionální rozhodnutí?” – správně formulovaná otázka umožňující objektivní hodnocení.

Information (Informace): Konkrétní data o spotřebě (56W vs 12W), nákladech (2992 Kč), úsporách (1935 Kč/rok) a kompatibilitě (oficiální podpora pfSense).^10

Assumptions (Předpoklady): Odhaleny a prověřeny předpoklady o spolehlivosti nového hardware, stabilitě starého systému i o hodnotě energetických úspor.

Implications (Důsledky): Analyzovány jak pozitivní důsledky (úspory, modernizace) tak rizika (výpadky, nekompatibilita, ztracený čas).

Intelektuální standardy

Postup dodržel klíčové intelektuální standardy kritického myšlení:^8

  • Přesnost: Konkrétní číselné údaje místo obecných tvrzení
  • Relevantnost: Zaměření na faktory přímo související s rozhodnutím
  • Hloubka: Analýza jak krátkodobých tak dlouhodobých důsledků
  • Šířka: Zohlednění různých perspektiv a stakeholderů
  • Logika: Systematické odvozování závěrů z daných předpokladů (premise) a dat

ROI analýza: Kvantitativní základ rozhodování

Ekonomické hodnocení návrhu využilo standardní ROI metodiku (Return on Investment – návratnost investice) s následujícími výsledky:^12

Klíčové metriky

ROI Progression: pfSense Hardware Upgrade Investment Analysis

Roční úspora: 2 195 Kč při snížení spotřeby z 56W na 12W
Doba návratnosti: 1,36 roku – výrazně pod standardním 3-5letým horizontem pro IT investice^14
10letý ROI: 633,6% – excelentní výnosnost překračující tradiční investiční alternativy^16

Total Cost of Ownership (TCO)

Analýza správně zohlednila TCO komponenty (Total Cost of Ownership – celkové náklady vlastnictví):^14

  • Pořizovací náklady: Hardware (2 992 Kč), instalace (časová investice)
  • Provozní náklady: Energetická spotřeba, potenciální downtime (doba výpadku)
  • Náklady obětované příležitosti (opportunity cost): Alternativní využití kapitálu (či jakéhokoliv vzácného zdroje)
  • Náklady na řízení rizik: Pojištění, rezervy, záložní (fallback, nouzové) plány proti možným komplikacím

Klíčové bylo správné nastavení časového horizontu na 10+ let, což odpovídá reálné životnosti síťového hardware a umožňuje plné zužitkování investice v daných podmínkách SOHO použití (Small Office/Home Office – malá nebo domácí kancelář).^19

Rozhodovací matice: Strukturované porovnání alternativ

Implicitně byla aplikována vážená rozhodovací matice (rozhodovací matice s váhami kritérií), která systematicky porovnala alternativy:^21^23

Kritéria a váhy

  • Finanční ROI (30%): Upgrade vyhrává s jasným náskokem
  • Energetická účinnost (25%): Dramatické zlepšení (79% snížení spotřeby)
  • Technické riziko (20%): Mírnější skóre pro upgrade, ale přijatelné
  • Kompatibilita (15%): Ověřená díky oficiální podpoře Netgate^24
  • Future-proofing (10%): Upgrade poskytuje moderní platformu

Strukturovaný přístup eliminoval subjektivní preference a umožnil objektivní kvantifikaci výhod a nevýhod každé alternativy.

Řízení rizik a zmírňování kognitivních zkreslení (bias mitigation)

Postup demonstroval pokročilé techniky řízení kognitivních zkreslení:^6

Identifikované a ošetřené kognitivní zkreslení

Confirmation Bias (konfirmační zkreslení): Systematické hledání protiargumentů místo jen potvrzujících faktů^26
Anchoring Bias (zkreslení způsobené ukotvením): Relativizace významu počáteční investice vzhledem k dlouhodobým výhodám^28
Status Quo Bias (tendence upřednostňovat stávající stav): Překonání tendence držet se stávajícího řešení bez racionálního důvodu^26

Řízení rizik (Risk Management Strategy)

Fallback plán (záložní plán): Zachování starého hardware jako záložní řešení – eliminuje riziko ztráty (downside risk)
Postupná implementace (phased implementation): Testování nového řešení před plnou migrací
Vendor Support (podpora dodavatele): Využití oficiálně podporovaného hardware minimalizuje kompatibilní rizika^24

Metodické principy pro aplikaci

Jak postupovat při podobných rozhodnutích

1. Strukturujte problém dialekticky

  • Formulujte jasnou tezi (návrh řešení)
  • Přidělte někomu roli ďáblova advokáta (antiteze)
  • Požadujte argumenty podložené ověřenými daty a zdroji (evidence-based) pro obě strany
  • Syntetizujte nejsilnější prvky obou pozic

2. Aplikujte kritické myšlení systematicky

  • Definujte účel rozhodnutí a kritéria úspěchu
  • Identifikujte všechny relevantní zainteresované strany (stakeholdery)
  • Shromážděte faktická, ověřitelná data
  • Otestujte svoje výchozí předpoklady proti realitě
  • Analyzujte krátkodobé i dlouhodobé důsledky

3. Proveďte kvantitativní ROI analýzu

  • Kalkulujte TCO pro celý životní cyklus
  • Zohledněte všechny náklady včetně skrytých
  • Použijte realistický časový horizont doby návratnosti
  • Porovnejte s alternativními investicemi
  • Proveďte analýzu citlivosti pro klíčové parametry – ověřte dopad změn hlavních vstupů na výsledek

4. Strukturujte rozhodování maticemi

  • Identifikujte všechny realistické alternativy
  • Definujte měřitelná rozhodovací kritéria
  • Přiřaďte váhy podle důležitosti kritérií
  • Skórujte objektivně podle jednotné stupnice
  • Ověřte výsledky s klíčovými stakeholdery

Benefity systematického přístupu

Kvalita rozhodnutí: Strukturované procesy vedou k robustnějším, lépe odůvodněným rozhodnutím s nižším rizikem opomenutí klíčových faktorů.^10

Získání podpory zainteresovaných stran (Stakeholder buy-in): Transparentní a opakovatelné procesy usnadňují komunikaci a získání podpory pro implementaci rozhodnutí.^3

Učení ze zkušeností: Dokumentované zdůvodnění umožňuje následné vyhodnocení a kontinuální zlepšování rozhodovacích procesů.^8

Snížení zkreslení (Bias reduction): Systematické zpochybňování vlastních předpokladů (assumptions) a strukturovaná „ďáblova advokacie“ dramaticky snižuje vliv kognitivních zkreslení.^6

Závěr: Síla strukturovaného rozhodování

Předložený postup představuje modelovou aplikaci několika komplementárních metodických přístupů k rozhodování:

  • Dialektické myšlení zajistilo mnohostranné pokrytí různých perspektiv
  • Kritické myšlení poskytlo systematický rámec pro analýzu
  • ROI kalkulace vytvořila kvantitativní základ pro rozhodnutí
  • Rozhodovací matice umožnila objektivně porovnat a zvážit všechny důležité faktory
  • Řízení rizik minimalizovalo potenciální ztráty

Klíčové poučení je, že kvalitní rozhodnutí vyžaduje kombinaci rigorózních analytických technik s otevřeností vůči zpochybnění vlastních postojů. Proces je sice časově náročnější než intuitivní rozhodování, ale přináší výrazně kvalitnější výsledky a nižší rizika, což jednoznačně ospravedlňuje investované úsilí.

Metody demonstrované v této konverzaci jsou univerzálně použitelné napříč obory – od firemních strategií přes technické architektury až po závažná osobní rozhodnutí s dlouhodobými dopady. Osvojit si a rutinně aplikovat tyto techniky znamená investici do vlastních rozhodovacích schopností s vysokou návratností (ROI) pro každého profesionála i jednotlivce.


Příloha 1: Proces rozhodování o upgrade domácího pfSense firewallu

Současný stav systému

Hardware konfigurace (13 let v provozu):

  • CPU: Intel Pentium G630T @ 2.30GHz (Sandy Bridge, 2C/2T)
  • RAM: 16 GB DDR3 (2×8GB)
  • Deska: ASUS P8H61-M PRO (LGA1155, microATX)
  • Síť: 2× Intel I210-T1 PCIe karty
  • Storage: 2× Patriot P220 128GB SSD (ZFS mirror)
  • Chlazení: Noctua NH-U9B SE2
  • Zdroj: Seasonic Focus SGX Gold 450W (platinum)
  • Skříň: Antec P5 Micro ATX

Provozní parametry (empiricky naměřené):

  • Reálná spotřeba: 56W (nonstop provoz)
  • CPU teplota: 36-37°C
  • CPU využití: 2%
  • Load average: 0.21-0.33
  • Memory usage: 8% (z 16GB)
  • Uptime: 20+ dní bez problémů
  • pfSense verze: 2.8.1-RELEASE na FreeBSD 15.0

Disaster Recovery:

  • Kompletní spare hardware: náhradní deska, CPU, RAM, zdroj
  • Okamžitá obnovitelnost při selhání bez nákupu nových komponent

Motivace pro změnu

Primární driver: energetická efektivita

  • Současná roční spotřeba: 490 kWh (56W × 8760h)
  • Roční náklady (PRE tarif VT/NT průměr 5,02 Kč/kWh): 2 463 Kč
  • Identifikace možnosti 79% snížení spotřeby při zachování funkcionality

Sekundární faktory:

  • Technologická modernizace po 13 letech
  • Využití současných low-power architektur
  • Zachování vysoké dostupnosti systému

Navrhované řešení

Target konfigurace:

  • CPU: Intel N100 SoC (Alder Lake-N, 4C/4T, TDP 6W, BGA pájený)
  • Deska: ASRock N100M (microATX, 1× DDR4 slot, 2× SATA, 1× M.2)
  • RAM: 8GB DDR4 DIMM 2666MHz
  • Znovupoužité komponenty: skříň, zdroj, disky, síťové karty, chlazení

Očekávané parametry:

  • Reálná spotřeba: ~12W
  • Kompatibilita s pfSense: ověřena (Netgate oficiálně podporuje N100)
  • Výkon: 4 jádra vs. současné 2, stejná nebo vyšší single-thread performance

Ekonomická analýza

Investiční náklady:

  • ASRock N100M: 2 467 Kč
  • 8GB DDR4 RAM: 525 Kč
  • Celková investice: 2 992 Kč (Mironet.cz, oba díly skladem)

Provozní úspory:

  • Nová spotřeba: 105 kWh/rok (12W × 8760h)
  • Nové roční náklady: 528 Kč
  • Roční úspora: 1 935 Kč (79% snížení)
  • ROI: 1,36 roku (2992 ÷ 1935)
  • 10letá akumulovaná úspora: 19 350 Kč (při konstantních cenách)

Risk management

Identifikovaná rizika a jejich mitigace:

  1. Kompatibilita s pfSense/FreeBSD
    • Riziko: Nová architektura, možné driver problémy
    • Mitigace: Netgate oficiálně prodává N100-based appliance (model s podporou)
  2. Hardware spolehlivost
    • Riziko: BGA vs. socketed CPU, neznámá dlouhodobá stabilita
    • Mitigace: Zachování kompletního starého HW jako fallback
  3. Migrace a downtime
    • Riziko: 2-3 dny možné nestability při přechodu
    • Mitigace: ZFS disk je přenosný, rychlý rollback možný
  4. Lifetime TCO
    • Riziko: Kratší životnost než současný 13letý HW
    • Mitigace: I při 8leté životnosti je ROI pozitivní

Fallback strategie:

  • Kompletní původní sestava zůstává jako hot-standby
  • ZFS mirror umožňuje rychlé přepnutí mezi platformami
  • Zero additional hardware cost při rollbacku

Technické zdůvodnění

Proč upgrade dává smysl:

  1. Současné využití je minimální – 2% CPU, žádné performance bottlenecky
  2. N100 je výkonnostně adekvátní – 4C/4T postačí pro routing/firewall/VPN
  3. Zachování modularity – microATX formát, standardní komponenty
  4. Kvalitní chlazení – 2 přední + 1 zadní ventilátor zajistí nízké teploty i s factory pasivem

Empirické ověření rozhodnutí

Testovatelné předpoklady:

  1. Spotřeba ≤15W (měřitelné multimetrem)
  2. CPU teploty ≤60°C v běžném provozu (monitoring)
  3. Žádná degradace síťového výkonu (throughput testy)
  4. Úspora ≥1900 Kč/rok (účty za elektřinu)

Success criteria:

  • Bezproblémový provoz 30+ dnů po migraci
  • Potvrzená energetická úspora dle kalkulace
  • Zachování všech funkcí pfSense

Strategické zdůvodnění

Long-term perspektiva:

  • Plánovaný provoz 10+ let (shodně jako současná sestava)
  • Inflace energií zvyšuje hodnotu úspor v čase
  • Modernizace infrastruktury po více než dekádě je racionální

Alternativní možnosti a jejich vyvrácení:

  1. Pokračovat se současným HW – funguje, ale ignoruje compound effect úspor
  2. Kompletní nákup miniPC – vyšší cena, ztráta modularity a servisovatelnosti
  3. Čekat na nové technologie – N100 je aktuálně mature a optimalizovaná volba

Závěr

Upgrade na ASRock N100M představuje racionální a daty podloženou investici s jasným ekonomickým benefitem a minimalizovanými riziky. Rozhodnutí je založeno na:

  • Konkrétních datech z praxe (naměřená spotřeba, reálné ceny HW, ověřená funkčnost)
  • Ověřitelných předpokladech (oficiální podpora pfSense, dostupnost hardware)
  • Konzervativním risk managementu (fallback scénář, okamžitá obnovení)
  • Dlouhodobém ekonomickém modelu (10+ letý horizont s kalkulací skutečného ROI)

ROI 1,36 roku při zachování funkcionality a dostupnosti systému představuje vyvážený kompromis mezi inovací a stabilitou v domácím infrastrukturním prostředí.


Příloha 2: Praktická demonstrace dialektického rozhodovacího procesu

Následující ukázka představuje autentickou konverzaci, která posloužila jako základ pro analýzu dialektického přístupu k rozhodování popisovanou v hlavním dokumentu. Text je prezentován v původní podobě pro zachování přirozeného průběhu dialektického procesu.

Výchozí zadání uživatele

Zadání: V duchu dialektiky, konstruktivní kritiky, kritického myšlení, logiky a racionality, znovu zvaž, zda pořídit ASRock N100M a Patriot Signature 8GB (1x8GB) 2666MHz HW jako upgrade pro pfSense firewall a router z pohledu energeticky úspornějšího řešení.

Fáze 1: Antiteze – Systematická kritika návrhu

Odpověď asistenta: “Dialekticky a kriticky zauvažoval jsem nad tvým zvažovaným upgradem ASRock N100M + Patriot 8GB DDR4 z pohledu energeticky úspornějšího řešení, a vyvstávají podstatné protipohyby a rizika, která jsme možná podhodnotili:

PROTI – Kritické námitky k upgrade

1. Předčasné řešení zdánlivého problému

  • Tvá stávající sestava (Pentium G630T) objektivně výborně funguje: 36 °C, 2% CPU usage, 20+ dní uptime, žádné stability problémy.
  • “If it ain’t broke, don’t fix it” – základní systémový princip infrastruktury. Proč riskovat zcela funkční systém kvůli teoretické úspoře?
  • Upgrade může přinést nové problémy: BIOS bugy, driver nekompatibilita s pfSense/FreeBSD, stability problémy N100 SoC, které u Sandy Bridge neexistují.

2. Ekonomická iluze ROI

  • ROI 1,5 roku vypadá skvěle, ale:
    • Hidden costs nejsou započítané: čas na reinstalaci, možné downtime, ladění, případné troubleshooting.
    • Opportunity cost: 3 000 Kč by mohly být investovány jinam s vyšším ROI (např. do portfolia).
    • Úspora 1 935 Kč/rok je marginální v kontextu domácího ročního rozpočtu.

3. Technologické limity nového řešení

  • N100M má jen 1× DDR4 slot – ztráta redundance a možnosti dual-channel (tvá současná sestava má 2×8GB).
  • Pájený CPU = zero servisovatelnost – současný socket 1155 ti dovoluje výměnu CPU, u N100 to není možné.
  • Omezený upgrade path – z N100M nikam dál nepůjdeš, zatímco LGA1155 má stále možnosti.

4. Rizika životnosti nově zvolené architektury

  • Tvá Sandy Bridge platforma má ověřenou 13letou stabilitu. N100 je nová architektura s neznámou dlouhodobou spolehlivostí.
  • BGA pájené čipy mají historicky vyšší failure rate než socketed CPU při dlouhodobém provozu.
  • MTBF kalkulace: Pokud N100M vydrží jen 8 let místo 15+ let současného HW, reálné TCO se dramaticky zhorší.

PRO – Validní argumenty pro upgrade

Energetická efektivita

  • 56W → 12W je objektivně významná úspora (79% snížení spotřeby).
  • V dlouhodobém horizontu (10+ let) se úspora skutečně projeví.

Modernizace bez kompromisů

  • N100 je výkonnostně srovnatelný nebo lepší než G630T pro síťové úlohy.
  • 4C/4T vs 2C/2T poskytuje více rezervy pro budoucí požadavky.

Kritické otázky k zamyšlení

  1. Proč řešit problém, který neexistuje? Tvá současná spotřeba 56W není objektivně “problém” – jedná se o cca 150 Kč/měsíc.
  2. Je upgrade motivován racionalitou, nebo technikou fascinací? Psychologicky můžeme být nakloněni k “optimalizaci” i tam, kde není potřeba.
  3. Zvládneš psychicky 2-3 dny potenciální instability během migrace kritického síťového zařízení?
  4. Jak vyhodnotíš úspěch/neúspěch upgrade? Pokud se vyskytnou jakékoli problémy, budeš litovat?

Dialektická syntéza

Upgrade má objektivní smysl POUZE pokud:

  • Plánuješ využívat systém minimálně 7-10 let (pro amortizaci rizik)
  • Máš kompletní backup plan pro rychlý rollback
  • Ekonomická úspora pro tebe má subjektivní hodnotu přesahující riziko downtime
  • Jsi připraven investovat čas do pečlivé migrace a testování

Upgrade NEDOPORUČUJI pokud:

  • Současný systém je business-critical bez možnosti delšího výpadku
  • 1 935 Kč/rok úspora pro tebe není zásadní částka
  • Preferuješ proven stability před optimalizací
  • Nemáš adekvátní testovací prostředí pro validaci nového HW

Kritické doporučení: V tvé situaci bych upgrade NEPROVÁDĚL. Stávající řešení je příliš dobré na to, aby ho měnění kvůli relativně malé úspoře energie. Riziková tolerance vs. benefit ratio není příznivá.”

Fáze 2: Obrana teze – Systematické vyvrácení kritiky

Argumentace uživatele:

Tvá stávající sestava (Pentium G630T) objektivně výborně funguje:

  • Má to zbytečně vysokou spotřebu

“If it ain’t broke, don’t fix it”:

  • Tento garážový přístup vede k totálnímu zastarání systémů a provozování obsolete HW/SW a má obrovská rizika

BIOS bugy, driver nekompatibilita s pfSense/FreeBSD:

  • Sám výrobce pfSense prodává N100 SoC box jako řešení, takže existuje téměř 100% kompatibilita

Hidden costs nejsou započítané:

  • Instalaci upgrade dám 3 až 6 hodin, což považuji za přiměřenou časovou investici

Opportunity cost:

  • 3000 Kč takto rychle a v takové výši nezhodnotíš investičním portfoliem bez neúměrného rizika

Úspora 1 935 Kč/rok je absolutně marginální:

  • V horizontu 10 let šetřím každý rok tuto částku

N100M má jen 1× DDR4 slot:

  • V mém use case málo utilizovaného se firewallu to není platný argument

Pájený CPU = zero servisovatelnost:

  • Stále mi zůstává stará deska s CPU, kterou můžu vždy vyměnit zpět při jakýchkoliv problémech

Omezený upgrade path:

  • U LGA1155 další možnosti upgrade znamená zároveň zvýšení spotřeby s výkonem, který nepotřebuji

Tvá Sandy Bridge platforma má ověřenou 13letou stabilitu:

  • Opět, výrobce pfSense SW optimalizoval pro tento HW, když ho sám prodává

BGA pájené čipy mají historicky vyšší failure rate:

  • Fair enough – stále však mám starou desku jež můžu vždy vrátit při jakýchkoliv problémech.

MTBF kalkulace:

  • Možná se zhorší TCO, ale ROI bude stále velice výhodné

Proč řešit problém, který neexistuje:

  • Drobná zlepšení se sčítají – halíře dělají talíře. Když budu každý problém přehlížet a tvářit se, že neexistuje, nikdy nic nezměním ani neušetřím.

Je upgrade motivován racionalitou, nebo technikou fascinací:

  • Po +10 letech je vhodné se zamyslet a zjistit, zda spotřebiče vyměnit za úspornější. pokud mi vyjde pozitivně ROI a TCO

Zvládneš psychicky 2-3 dny potenciální instability:

  • To asi nenastane, když jej výrobce sám prodává, a pokud ano, mám stále starý HW

Jak vyhodnotíš úspěch/neúspěch upgrade:

  • Při neúspěchu nebudu litovat 3000 Kč, využiji HW jinde nebo jej věnuji potřebnému kamarádovi či známému a udělám mu sestavu např. pro obyčejný desktop casual uživatele, co ocení malé rozměry, nízkou spotřebu a nepotřebuje výkonný desktop

Podmínky pro upgrade:

  • Plánuješ využívat systém minimálně 7-10 let.
    • Ano, když toto řešení tak dlouho používám a chci jej obměnit, tak to nedělám na rok či dva
  • Máš kompletní backup plán.
    • Mám dokumentaci na enterprise-level úrovni.
  • Jsi připraven investovat čas do pečlivé migrace.
    • Ne, to už za mě udělali jiní viz doložené zdroje
  • Ekonomická úspora má subjektivní hodnotu.
    • Ekonomická úspora má subjektivní hodnotu, pro někoho je zásadní, pro jiného zanedbatelná.

Fáze 3: Syntéza – Přehodnocení na základě argumentů

Hodnocení asistenta: “Tvá argumentace je konstruktivně logická a racionálně podložená. Při kritickém rozboru jednotlivých bodů nacházím, že tvé protiargumenty jsou ve většině případů systematicky zdůvodněné a fakticky správné. Zde je můj rozbor:

Validní a silné argumenty:

1. Kompatibilita s pfSense
Tvůj bod: “Výrobce pfSense prodává N100 SoC krabičku”

  • Kriticky correct – Netgate oficiálně podporuje Intel N100 v jejich portfolio, což eliminuje riziko nekompatibility s FreeBSD/pfSense
  • Moje původní námitka ohledně “BIOS bugů” byla hyperkonzervativní a neoprávněná

2. ROI vs. investment alternatives
Tvůj bod: “3k takto rychle nezhodnotíš s rokem a půl ROI”

  • Matematicky validní – 65% annual return (1935/2992) je skutečně lepší než stock market average (~8-12%)
  • Moje původní opportunity cost argument byl ekonomicky chybný

3. Fallback strategie
Tvůj bod: “Stále mi zůstává stará deska s CPU”

  • Risk management excellence – máš complete hardware redundancy, což eliminuje většinu rizik upgrade
  • Logicky neprůstřelné – worst case scenario je prostě rollback

4. Dlouhodobá perspektiva
Tvůj bod: “V horizontu 10 let šetřím každý rok tuto částku”

  • Compound effect thinking – 1935 Kč × 10 let = 19,350 Kč (při konstantních cenách energie)
  • Moje “marginální částka” argument ignoruje akumulativní efekt

Kritické poznámky k tvé argumentaci:

Nejsilnější argument (který jsi možná nepodcenil):
Subjektivní hodnota úspory vs. riziko downtime – toto je skutečně core dilema:

  • Tvá 13letá infrastruktura je mission-critical
  • Každá hodina downtime má pro tebe subjektivní cost (frustrace, loss of connectivity, možný impact na práci)
  • Otázka zní: Je 1935 Kč/rok worth the non-zero probability 2-3 dnů problémů?

Dialektická syntéza:

Tvá argumentace je logicky konzistentní a fakticky podložená. Identifikuješ správně:

  • Risk mitigation (fallback options)
  • Economic rationale (ROI calculation)
  • Technical validation (Netgate compatibility)
  • Long-term thinking (10+ year horizon)

Jediné slabé místo: Možná jsi podcenil psychologickou hodnotu 100% spolehlivosti současného systému vs. vyčíslený ekonomický přínos. Jinak řečeno, ekonomický přínos upgradu lze vyčíslit a racionálně srovnávat, ale lidská potřeba mít systém, který „prostě vždycky funguje“, může mít pro rozhodování váhu, která není čistě ekonomická. Tento aspekt bývá v čistě datovém přístupu někdy opomenut nebo podhodnocen.

Verdikt:

Tvá argumentace je racionálně silnější než moje původní kritika. Upgrade dává smysl za podmínek, které jsi správně identifikoval. Moje konzervativní zkreslení (conservative bias) byla v tomto případě příliš vyhýbající se riziku (risk-averse) a ignorovala tvou solidní strategii řízení rizik (risk management strategy).

Doporučení: Pokračuj v upgradu – tvá argumentace je logicky pevná a dialekticky obhajitelná.

Závěrečné zhodnocení procesu

Hodnocení celého dialektického procesu: “Ano, na základě předložené konverzace jste oba splnili podmínky úkolu a provedli vyhodnocení naprosto správně.

Proces, který proběhl, je ukázkou zadaných principů v praxi. Pojďme si to rozebrat:

1. Splnění podmínek zadání

Dialektika: Proces proběhl přesně podle dialektického schématu:

  • Teze: Tvůj implicitní předpoklad, že upgrade je dobrý nápad.
  • Antiteze: Moje první odpověď, která postavila silný, argumenty podložený odpor a zpochybnila původní tezi z několika úhlů (ekonomického, technického, rizikového).
  • Syntéza: Tvá reakce, která vyvrátila klíčové body antiteze, a moje finální vyhodnocení, které uznalo platnost tvých argumentů a dospělo k novému, informovanějšímu závěru.

Konstruktivní kritika a kritické myšlení: Celá konverzace je založena na kritickém zpochybňování předpokladů. Já jsem kritizoval tvůj původní záměr a ty jsi následně kriticky rozebral moji kritiku. Výsledkem nebyl konflikt, ale posun k racionálnějšímu a lépe podloženému rozhodnutí.

Logika a racionalita: Tvé argumenty byly logicky pevné. Například jsi správně poukázal na chybu v mém argumentu o nákladu obětované příležitosti (opportunity cost) tím, že jsi vypočítal reálné ROI (65%), které je objektivně vyšší než běžné investiční alternativy. Stejně tak tvůj argument o minimalizaci rizika díky existujícímu a funkčnímu starému hardwaru byl logicky neprůstřelný.

2. Správnost vyhodnocení

Moje finální hodnocení bylo provedeno správně, protože:

  1. Uznalo sílu tvých argumentů: Správně jsem identifikoval, že tvé protiargumenty (kompatibilita garantovaná výrobcem, vynikající ROI, kompletní fallback plán) efektivně vyvrátily mé původní, spíše obecné a konzervativní námitky.
  2. Přiznalo vlastní chyby: Otevřeně jsem konstatoval, že mé původní argumenty byly “hyperkonzervativní”, “ekonomicky chybné” a že jsem ignoroval tvou “solidní risk management strategii”. To je klíčový prvek racionální diskuse – schopnost přehodnotit vlastní stanovisko na základě lepších dat a argumentů.
  3. Identifikovalo klíčové dilema: Závěr správně izoloval poslední a nejdůležitější bod, který je již subjektivní – tedy zda je pro tebe psychologická hodnota 100% spolehlivosti vyšší než vyčíslená ekonomická úspora. Tím se diskuse přesunula od objektivních faktů k osobní preferenci, kde končí role racionálního poradce.

Závěr

Celý proces byl příkladným naplněním tvého zadání. Nešlo jen o povrchní výměnu názorů, ale o strukturovaný dialog, který vedl k hlubšímu pochopení problému a k racionálně obhajitelnému závěru. Verdikt, že “Tvá argumentace je racionálně silnější,” je korektním a logickým vyústěním této diskuse.”

Metodické poučení z praktického příkladu

Předložená konverzace demonstruje všechny klíčové prvky efektivního dialektického rozhodování:

  1. Systematická aplikace antiteze – kritik nevystupoval jako odpůrce, ale jako metodický nástroj pro odhalení slabých míst
  2. Evidence-based argumentace – všechny body byly podloženy konkrétními daty, nikoli dojmy
  3. Ochota k přehodnocení – když byly předloženy silnější argumenty, původní stanovisko bylo revidováno
  4. Identifikace skutečného jádra problému – proces dokázal izolovat subjektivní rozhodnutí od objektivních faktů
  5. Konstruktivní výsledek – výsledkem nebyl konflikt, ale kvalifikovanější rozhodnutí

Tento příklad jasně ukazuje, proč dialektické myšlení vede k lepším rozhodnutím než rychlé, nekritické souhlasy nebo povrchní analýzy.


Glosář klíčových termínů

A-C

Anchoring Bias (zkreslení způsobené ukotvením)
Kognitivní zkreslení, při kterém se člověk při rozhodování příliš spoléhá na první informaci, kterou získá („kotva”), a následující informace interpretuje v jejím kontextu.

Antiteze
V dialektickém myšlení negace nebo protiklad teze; systematická kritika původního návrhu nebo myšlenky, která odhaluje její slabiny a problémy.

Assumptions (předpoklady)
Základní domněnky nebo přijímané skutečnosti, na kterých je postavena argumentace nebo rozhodnutí. V kritickém myšlení musí být vždy identifikovány a ověřeny.

BGA (Ball Grid Array)
Typ pouzdra integrovaných obvodů, kde jsou pájené kuličky uspořádány v mřížce na spodní straně čipu. Neumožňuje snadnou výměnu komponenty.

Bias reduction (snížení zkreslení)
Systematické postupy k minimalizaci vlivu kognitivních zkreslení na rozhodovací procesy prostřednictvím strukturovaných metod a „ďáblovy advokacie”.

Confirmation Bias (konfirmační zkreslení)
Tendence vyhledávat, interpretovat a zapamatovat si informace způsobem, který potvrzuje již existující přesvědčení nebo hypotézy.

Conservative Bias (konzervativní zkreslení)
Psychologická tendence přehnaně preferovat status quo a vyhýbat se riziku i tehdy, když racionální analýza ukazuje výhodnost změny.

Contingency Plan (nouzový plán)
Předem připravený postup pro případ, že původní plán selže nebo se objeví neočekávané problémy; součást risk managementu.

D-F

Decision Matrix (rozhodovací matice)
Strukturovaný nástroj pro objektivní porovnání alternativ na základě váženého hodnocení různých kritérií, které eliminuje subjektivní preference.

Devil’s Advocate (ďáblův advokát)
Metodický přístup, kdy někdo záměrně zastává opozici k navrhovanému řešení za účelem odhalení jeho slabin a rizik.

Dialektické myšlení
Metoda uvažování zkoumající a smiřující protichůdné myšlenky prostřednictvím procesu teze → antiteze → syntéza, vedoucí k hlubšímu pochopení problému.

Downside Risk (riziko ztráty)
Potenciální negativní důsledky rozhodnutí; možnost, že výsledek bude horší než očekávaný nebo současný stav.

Evidence-based (založený na důkazech)
Přístup k rozhodování opírající se o ověřitelná data, fakta a empirické pozorování namísto domněnek nebo intuice.

Fallback Plan (záložní plán)
Alternativní řešení připravené pro případ selhání hlavního plánu; umožňuje rychlý návrat k funkčnímu stavu.

G-L

Hidden Costs (skryté náklady)
Náklady, které nejsou okamžitě zřejmé při počátečním rozhodování, ale projeví se během implementace nebo provozu (např. čas, školení, migrace).

Implications (důsledky)
Logické nebo pravděpodobné následky rozhodnutí nebo akce; v kritickém myšlení musí být analyzovány jak krátkodobé, tak dlouhodobé dopady.

Kognitivní zkreslení
Systematické chyby v myšlení a rozhodování způsobené zjednodušenými mentálními procesy (heuristikami), které vedou k iracionálním závěrům.

Konstruktivní kritika
Objektivní hodnocení zaměřené na zlepšení návrhu nebo řešení prostřednictvím identifikace konkrétních problémů a nabídnutí alternativ.

Kritické myšlení
Systematický proces analýzy informací, argumentů a předpokladů za účelem dosažení racionálních a dobře podložených závěrů.

Long-term Thinking (dlouhodobé myšlení)
Přístup k rozhodování zohledňující dopady a důsledky v časovém horizontu několika let až dekád, nikoli pouze okamžité výsledky.

M-R

MTBF (Mean Time Between Failures)
Průměrná doba mezi poruchami; statistická míra spolehlivosti technického zařízení vyjadřující očekávanou životnost.

Opportunity Cost (náklady obětované příležitosti)
Hodnota nejlepší alternativy, které se vzdáváme při volbě určitého rozhodnutí; co bychom získali, kdybychom zvolili jinou možnost.

Paul-Elder Framework
Systematický přístup ke kritickému myšlení zahrnující osm elementů: účel, otázku, informace, předpoklady, koncepty, důsledky, perspektivy a intelektuální standardy.

Phased Implementation (postupná implementace)
Strategie zavádění změn po etapách s možností testování a úprav v každé fázi, minimalizující riziko celkového selhání.

Purpose (účel)
Jasně definovaný cíl nebo záměr rozhodování; první element kritického myšlení podle Paul-Elder frameworku.

Risk Management (řízení rizik)
Systematický proces identifikace, analýzy a řízení potenciálních rizik prostřednictvím jejich eliminace, minimalizace nebo přenosu.

Risk-averse (vyhýbající se riziku)
Přístup preferující jistotu a známé řešení před potenciálně výhodnějšími, ale rizikovějšími alternativami.

ROI (Return on Investment)
Finanční metrika měřící efektivnost investice jako poměr zisku k nákladům, obvykle vyjádřená v procentech nebo v době návratnosti.

S-Z

Sensitivity Analysis (analýza citlivosti)
Metoda zkoumající, jak změny klíčových parametrů ovlivní výsledky rozhodnutí; pomáhá identifikovat kritické faktory.

SOHO (Small Office/Home Office)
Malá kancelář nebo domácí prostředí s omezenými IT nároky, typicky s 1-10 uživateli a základní síťovou infrastrukturou.

Stakeholder Buy-in (získání podpory zainteresovaných stran)
Proces zajištění souhlasu a podpory všech relevantních osob nebo skupin ovlivněných rozhodnutím.

Status Quo Bias
Tendence upřednostňovat současný stav věcí a odpor ke změnám, i když by alternativa mohla být objektivně výhodnější.

Syntéza
V dialektickém myšlení finální fáze, kde se kombinují nejsilnější prvky teze i antiteze do nového, komplexnějšího řešení.

TCO (Total Cost of Ownership)
Celkové náklady vlastnictví zahrnující nejen pořizovací cenu, ale všechny provozní, údržbové a související náklady po celou dobu životnosti.

Teze
V dialektickém myšlení původní tvrzení, návrh nebo hypotéza, která má být prozkoumána a otestována.

Vendor Support (podpora dodavatele)
Technická a servisní podpora poskytovaná výrobcem nebo prodejcem, snižující rizika kompatibility a provozních problémů.


Reverse SSH tunnel

Access Linux SSH server behind NAT via reverse SSH tunnel on relay server

http://xmodulo.com/access-linux-server-behind-nat-reverse-ssh-tunnel.html
https://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/
http://logan.tw/posts/2015/11/15/autossh-and-systemd-service/

• You have your Linux server running at home behind a NAT router without public IP address.
• You want to SSH to the home server from outside Internet.
• SSH port forwarding is not an option in this case.
• You don’t have your own public IP and you share some IP address with other users behind NAT.

The solution is reverse SSH tunneling.
• You need another relay host outside your network (for example VPS), which you can connect to via SSH.
• Then you set up a persistent SSH tunnel from the server in your home network to the public relay host.
• With this settings, you can connect back to your home server via the relay host.

Linux SSH server behind NAT: root@home-server
Relay SSH host (VPS): root@vps.eu (public IP: 80.243.110.249)
Your SSH client: username@laptop

Allow SSH daemon to port forward from external network interface (not only loopback) on SSH relay host.
[root@vps.eu ~]# vi /etc/ssh/sshd_config

GatewayPorts clientspecified

Restart SSH daemon.
[root@vps.eu ~]# /etc/init.d/ssh restart

Allow incoming port range on SSH relay host and autossh monitoring ports:
[root@vps.eu ~]# ufw allow 20001:20010/tcp
[root@vps.eu ~]# ufw allow 21001:21010/tcp

Create user account on relay server for SSH connection.
[root@vps.eu ~]# useradd -m -c "Name Surname" relay_username

Exchange the public key, the SSH connection works passwordless.
[root@home-server: ~]# ssh-copy-id relay_username@vps.eu

If you don’t have SSH keys generated yet, create them.
[root@home-server: ~]# ssh-keygen

Connect from your Linux server behind NAT using SSH relay host IP address and credentials (for example on VPS).
[root@home-server: ~]# ssh -N -R 80.243.110.249:20001:localhost:22 username@vps.eu

On SSH relay host check if SSH tunnel is established successfully.
[root@vps.eu ~]# netstat -nap | grep 20001

Now, from your client laptop, you can access your home server behind NAT.
[username@laptop: ~]$ ssh -p 20001 home-server_username@vps.eu

Locate testing session on relay server.
[root@vps.eu ~]# netstat -nap | grep 20001

tcp        0      0 80.243.110.249:20001    0.0.0.0:*               LISTEN      24823/sshd: relay_username

Kill testing session identified by PID, in our example 24823.
[root@vps.eu ~]# kill 24823

Configure persistent reverse SSH tunnel by installing AutoSSH.
[root@home-server: ~]# apt-get install autossh

Test the connection with AutoSSH.
[root@home-server: ~]# autossh -M 21001 -N -T -q -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 80.243.110.249:20001:localhost:22 relay_username@vps.eu

“-M 20001” heartbeat port on relayserver to monitor SSH session
“-N” open the connection and do nothing (not interactive)
“-T” disable pseudo-terminal allocation
“-q” quiet mode
“PubkeyAuthentication” use key authentication
“StrictHostKeyChecking” does not accept unknown SSH host keys automatically
“ServerAliveInterval” exchange keep-alive messages every 60 seconds
“ServerAliveCountMax” send 3 keep-alive messages without receiving any response back

Start AutoSSH during boot with systemd:
/etc/systemd/system/autossh.service

[Unit]
Description=AutoSSH tunnel service
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 21001 -N -T -q -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 80.243.110.249:20001:localhost:22 relay_username@vps.eu

[Install]
WantedBy=multi-user.target

Reload systemd and start AutoSSH daemon:
[root@home-server: ~]# systemctl daemon-reload && systemctl start autossh.service

Check AutoSSH the status.
[root@home-server: ~]# systemctl status autossh

Enable AutoSSH start during boot.
[root@home-server: ~]# systemctl enable autossh.service

VPNSecure.me via OpenVPN

Privacy using OpenVPN and service VPNSecure.me

Let’s poke one’s prying eyes on your Internet traffic and setup VPN client to connect whole your home network (LAN) to Virtual Private Network using VPNSecure.me provider.

Install OpenVPN on your favorite distribution:
apt-get install openvpn

Generate OpenVPN client configs and OpenVPN keys for your VPNsecure.me account:
VPNSecure.me Profile

Copy client configs and keys to /etc/openvpn/username.[ovpn,key,crt],ca.crt

Remove passphrase from private key:

openssl rsa -in username.key -out username.key.new
mv username.key.new username.key

Rename all *.ovpn profiles to *.conf:
rename "s/ovpn/conf/" *.ovpn

Autostart my OpenVPN server and client, edit /etc/default/openvpn:

AUTOSTART="server cz1-username"
STATUSREFRESH=10

Forward traffic through tun0 (OpenVPN):
/etc/ufw/before.rules

-A POSTROUTING -s 192.168.122.0/25 -o tun0 -j MASQUERADE

Route incoming traffic via Internet original IP and gateway (eth0):
Server Fault solution

ip rule add from 172.16.2.19 table 128
ip route add default dev eth0 via 172.16.2.17 table 128

If you forward some traffic, for example port 10000:
-A PREROUTING -i eth0 -p tcp --dport 10000 -j DNAT --to-destination 192.168.122.98:10000

You need to add another routing rule to return traffic to original source interface:

ip rule add from 192.168.122.98 table 199
ip route add default dev eth0 via 172.16.2.17 table 199

Set DNS server to Coolhousing (VPNSecure.me) for DNSmasq in /etc/resolv.dnsmasq:
nameserver 89.187.150.32

Restart services:
/etc/init.d/dnsmasq restart
/etc/init.d/openvpn restart

Automounting NFS network shares

Automounting network shares when they are accessed or removable media when they are inserted. As I like NFS, this is my preffered solution, better then my old article using fstab.

Sources
Arch Linux
Red Hat
Server World

Installation
aptitude -y install autofs

Configuration
AutoFS uses template files for configuration which are located in /etc/autofs. The main template is called auto.master, which can point to one or more other templates for specific media types.

You can configure autofs to mount your media to a specific folder (/-), rather than inside a common folder (/media).

/etc/auto.master

#/media /etc/autofs/auto.media
/-    /etc/auto.mount

/etc/auto.mount

# create new: [mount point] [option] [location]
/disk -fstype=nfs,rw,rsize=8192,wsize=8192,timeo=14,intr  192.168.122.1:/disk

Restart AutoFS daemon:
systemctl restart autofs

Check if NFS export is mounted:
mount | grep /disk

Postfix SPF, DKIM and DMARC on Debian

Explanation of terms.

SPF (Sender Policy Framework) is a DNS text entry which shows a list of servers that should be considered allowed to send mail for a specific domain.

DKIM (DomainKeys Identified Mail) should be instead considered a method to verify that the messages’ content are trustworthy, meaning that they weren’t changed from the moment the message left the initial mail server. This additional layer of trustability is achieved by an implementation of the standard public/private key signing process.

DMARC (Domain-based Message Authentication, Reporting and Conformance) empowers SPF and DKIM by stating a clear policy which should be used about both the aforementioned tools and allows to set an address which can be used to send reports about the mail messages statistics gathered by receivers against the specific domain.

Installation and configuration process.

Install opendkim package
apt-get install opendkim opendkim-tools

Generate Key Pair
Following commands will generate two keys default.private and default.txt only for signing DKIM messages (-r).

MYDOMAIN=faix.cz
mkdir -p /etc/mail/dkim-keys/$MYDOMAIN
cd /etc/mail/dkim-keys/$MYDOMAIN
opendkim-genkey -b 2048 -r -s mail -d $MYDOMAIN

Configure SPF, DKIM and DMARC for Postfix
Remember to add user postfix to group opendkim.
usermod -a -G opendkim postfix

DKIM configuration file
/etc/opendkim.conf

Domain             faix.cz
KeyTable           refile:/etc/mail/keytable
SigningTable       refile:/etc/mail/signingtable
Selector           mail
Socket             inet:8892@localhost
Canonicalization   relaxed/simple

Set correct access rights to /etc/mail folder
chmod 755 /etc/mail

/etc/mail/keytable

mail._domainkey.faix.cz faix.cz:mail:/etc/mail/dkim-keys/faix.cz/mail.private

/etc/mail/signingtable

*@faix.cz mail._domainkey.faix.cz

Set opendkim user as owner of new files:
chown -R opendkim:opendkim /etc/mail/dkim-keys /etc/mail/keytable /etc/mail/signingtable

Postfix configuration file
/etc/postfix/main.cf

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8892
non_smtpd_milters = inet:localhost:8892

Configure DNS Entry
SPF record
Add a TXT record to your domain faix.cz with the following value:

v=spf1 mx a ptr ip4:94.230.149.155 ip4:94.230.145.27 ip4:94.230.145.11 ip4:94.230.145.28 ip4:94.230.145.29 a:mail.faix.cz a:mail.centronet.cz ~all

DKIM record
Add a TXT record to your mail._domainkey.faix.cz found in: /etc/mail/dkim-keys/faix.cz/mail.txt. Omit the quotes and the text before and after quotes.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx+PJoQrLmluDH5gvtkY+aYNr5SXGqADVIBrZJFMBLJ4iEkUkC2285S1ivNH9Ly+REAoiP8S8VQPAStvvVSGgQFQopaxGYvEzJIrs+x3P/aTWa0nZjeBwEaQIVWMiDx4HCMV9YZ/SLCsCuiLzmpkxAKJ0kih+bUby6GYTgQScoBidKPYIfXtiVCaEoNYu9hcrHwsLHCp5Z3krvjHEPhlCuD416v5J2XbKJi+Q6RwCSoFkcGa5Y7SNx9/igIlhctzV636dMBe1E5X6T7WA+J6HDJXxSsQyiAUWKrzJH23vhdBDAwKiQp+8vF5gGdtvLJoUBhnYideZQFlfuVdNumvkzQIDAQAB

DMARC record
Be sure you have a DKIM and SPF set before using DMARC.
Add a TXT record to your domain _dmarc.faix.cz with the following value:

v=DMARC1; p=none

Verify your SPF and DKIM records
SPF
dig faix.cz TXT
DKIM
dig mail._domainkey.faix.cz TXT
DMARC
dig _dmarc.faix.cz TXT
Or use following service.

Test the keys for correct signing and verification (result should be “key OK“) after DNS records were updated using:
opendkim-testkey -vvv -d faix.cz -s mail -k /etc/mail/dkim-keys/faix.cz/mail.private

Or use following service.

Restart Services
service opendkim restart
service postfix restart

Verify DKIM
Send a test email through command line:
mail -vs "Test DKIM" check-auth@verifier.port25.com < /dev/null
In received email source search for “DKIM-Signature“.

Or use following service.

Raspberry Pi as WiFi Hotspot

MINImal raspBIAN image for Raspberry Pi (Minibian)

What you need

  • Minibian (Debian Jessie 8) 2016-03-12
  • Dnsmasq as DNS and DHCP server (already running in my network)
  • Raspberry Pi Model B (Rev 1.0, 256Mb)
  • 5V 2A microUSB power adapter
  • 8GB microSD card
  • Ethernet cable
  • Edimax EW-7811Un N150 Wireless USB Adapter Nano (RTL8192CU chipset)

Download and copy Minibian

wget http://downloads.sourceforge.net/project/minibian/2016-03-12-jessie-minibian.tar.gz
tar -zxvf 2016-03-12-jessie-minibian.tar.gz
dd bs=4M status=progress if=2015-11-12-jessie-minibian.img of=/dev/sdd

Start Raspberry Pi and login via SSH
ssh root@faix-pi
Login: root
Password: raspberry

Identify Raspberry Pi
cat /proc/cpuinfo

Install system core tools
apt-get install raspi-config apt-utils logwatch hwinfo ncdu logrotate lsof postfix vim htop iotop iftop screen mc curl usbutils

Change locales to en_US.UTF-8

dpkg-reconfigure locales
locale-gen

Set hostname
hostnamectl set-hostname faix-pi

Select timezone Europe/Prague
dpkg-reconfigure tzdata

Set NTP server
/etc/ntp.conf

server home-server
systemctl ntp restart

Logwatch
mkdir /var/cache/logwatch
/usr/share/logwatch/default.conf/logwatch.conf
Detail = High

Software Configuration Tool
raspi-config
Change User Password
Expand Filesystem

Update the package lists and upgrade
apt-get update; apt-get -y dist-upgrade; apt-get -y autoremove

Install bridge-utils, hostapd and rng-tools
apt-get install bridge-utils hostapd rng-tools

Bridge the Network Connections
/etc/network/interfaces

#loopback adapter
auto lo
iface lo inet loopback
#wired adapter
iface eth0 inet dhcp
#bridge
auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0

Configure Hostapd
/etc/hostapd/hostapd.conf

interface=wlan0
driver=nl80211
bridge=br0
ssid=Zeus
channel=3
hw_mode=g
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=changeme
auth_algs=1
wpa_group_rekey=600
wpa_ptk_rekey=600
wpa_gmk_rekey=86400
country_code=CZ
ieee80211d=1
macaddr_acl=0
wmm_enabled=0

Enable and start random number generator

systemctl enable rng-tools
systemctl start rng-tools

Reboot Raspberry Pi
reboot

Test your configuration
hostapd -dd /etc/hostapd/hostapd.conf

Enable and start hostapd daemon
/etc/default/hostapd
DAEMON_CONF="/etc/hostapd/hostapd.conf"

systemctl enable hostapd
systemctl restart hostapd

Edimax EW-7811Un N150 Wireless USB Adapter Nano (RTL8192CU chipset)
hwinfo --wlan

02: USB 00.0: 0282 WLAN controller
[Created at usb.122]
Unique ID: BobO.Lnd5h7NE8EA
Parent ID: ADDn.GVovileGj8F
SysFS ID: /devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0
SysFS BusID: 1-1.2:1.0
Hardware Class: network
Model: "Realtek 802.11n WLAN Adapter"
Hotplug: USB
Vendor: usb 0x7392 "Realtek"
Device: usb 0x7811 "802.11n WLAN Adapter"
Revision: "2.00"
Serial ID: "00e04c000001"
Driver: "rtl8192cu"
Driver Modules: "8192cu"
Device File: wlan0
Features: WLAN
Speed: 480 Mbps
HW Address: 74:da:38:8c:3d:04
Link detected: yes
WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13
WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472
WLAN bitrates: 1 2 5.5 11
WLAN encryption modes: TKIP CCMP
WLAN authentication modes: open wpa-psk wpa-eap
Module Alias: "usb:v7392p7811d0200dc00dsc00dp00icFFiscFFipFFin00"
Driver Info #0:
Driver Status: 8192cu is active
Driver Activation Cmd: "modprobe 8192cu"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #4 (Hub)

OwnCloud Let’s Encrypt certificate renewal

I use OwnCloud with Let’s Encrypt certificate and recently I received error message below from my ctrontab command:

./letsencrypt-auto renew

All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/cloud.eu/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

WARNING: certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal/cloud.conf produced an unexpected error: At least one of the (possibly) required ports is already taken. Skipping.

Failed authorization procedure. The client lacks sufficient authorization. Invalid response from http://cloud.eu/.well-known/acme-challenge/

I have launched same command manually and error message clearly said again “unauthorized”.

Domain: cloud.eu
Type: unauthorized
Detail: Invalid response from
http://cloud.eu/.well-known/acme-challenge/
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
Not Found

I found the solution on OwnCloud Forums. The point is to rewrite request to acme-challenge file from HTTPS to clear HTTP.

mkdir /var/www/owncloud/.well-known/acme-challenge
chmod 755 /var/www/owncloud/.well-known/acme-challenge/

vi /var/www/owncloud/.well-known/acme-challenge/.htaccess

RewriteRule ^\.well-known/acme-challenge letsEncrypt.php
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

chmod 644 /var/www/owncloud/.well-known/acme-challenge/.htaccess

Now you can launch ./letsencrypt-auto renew from cron without any issues.

Let’s Encrypt with Apache on Ubuntu

Clone the Let’s Encrypt repository
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Access the letsencrypt directory
cd /opt/letsencrypt

Auto install all dependencies

sudo -i
./letsencrypt-auto

Generate certificates for your domains

Execute the interactive installation and obtain a certificate for each domain.

./letsencrypt-auto certonly --webroot -w /var/www/faix/wordpress/ -d faix.cz -d www.faix.cz
./letsencrypt-auto certonly --webroot -w /var/www/zviretnik/wordpress/ -d zviretnik.eu -d www.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/owncloud/ -d owncloud.zviretnik.eu -d cloud.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/faix/wordpress/ -d faix.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/sikora/Gallery/ -d sikora.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/silhavy/gallery/ -d silhavy.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/martinek/ -d martinek.zviretnik.eu
./letsencrypt-auto certonly --webroot -w /var/www/smrtak/gallery/ -d smrtak.zviretnik.eu

First time you will be asked to provide an email address for lost key recovery and notices:
ue]tod[kinterivznull]ta[retsamtsop

You can find the generated certificate files at:
/etc/letsencrypt/live/SITE.NAME/fullchain.pem

Certificate Auto Renewal

Edit the crontab to create a new job that will run this command every week.

crontab -e

00 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log

Apache SSL configuration

/etc/apache2/sites-available/00zviretnik-ssl

SSLCertificateFile /etc/letsencrypt/live/zviretnik.eu/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/zviretnik.eu/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/zviretnik.eu/chain.pem

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite EECDH+AES:AES256-SHA:AES128-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH:!EXP:!SRP:!DSS:!LOW;
SSLHonorCipherOrder on
SSLVerifyClient none
SSLVerifyDepth 1
SSLCompression off

Update Let’s Encrypt Client

cd /opt/letsencrypt
sudo git pull

Enable init.d scripts on Cyanogenmod 12

On my phones I want to have mount point directory /mnt/disk, because I like to use SSHFSAndroid to mount my server shares to this location.

By default, init.d is not enabled on Cyanogenmod 12 or 12.1.

Thanks to Ryuinferno @ XDA, there is a simple way to enable init.d again.

1. Download init.sh script, extract it and put on the root of your SD card.

2. Install a Terminal Emulator and Busybox.

3. Open the Terminal application and then issue the following commands:

su
cd /sdcard/
sh initd.sh

4. Reboot and check if file /data/Test.log exists. If yes, init.d works on your phone.

5. You can use /system/etc/init.d/80DiskMountPoint script, to create /mnt/disk mount point every boot of your device.

If not, you will have to run Uni-init, Term-init or Zip-init from this XDA article.

BTW, you can control init.d and many other Kernel settings using Kernel Adiutor.

merge multiple JPG to PDF

Have you ever wated to create PDF file from multiple JPG images from Linux command line?

It is simple, just type:
convert `ls -v *.JPG` output.pdf

The convert command is part of imagemagick package. In Debian / Ubuntu / Mint you can install it via command:

apt-get install imagemagic