Pokyny k přechodu na novou verzi (Upgrade notes)
Obsah
- 1 Obsah
- 2 Obecné pokyny
- 2.1 Základní pravidla
- 2.2 Upgrade versus update
- 2.2.1 Update
- 2.2.2 Upgrade
- 2.2.3 Jak kombinovat
- 2.3 Doporučený postup update nebo upgrade
- 2.3.1 Nutné kroky
- 2.3.2 Volitelné, ale doporučené, kroky
- 3 Specifické pokyny k jednotlivým verzím
- 3.1 Verze 2.3.11
- 3.2 Verze 2.3.0
- 3.3 Verze 2.2.0
- 3.4 Verze 2.1.0
- 3.5 Verze 2.0.3
- 3.6 Verze 2.0.0
- 3.7 Verze 1.6 a starší
- 4 Speciální případy
Obecné pokyny
Bez ohledu na verzi aplikace z které a na kterou probíhá update nebo upgrade, platí následující pravidla a doporučení.
Základní pravidla
Je doporučeno provádět update a upgrade pravidelně. Zejména při vydání nové větší verze aplikace.
Není doporučeno přeskakovat větší verze a následně provádět velký upgrade přes více větších verzí. Pokud však k tomuto přesto dojde, je nutné projít všechny specifické pokyny k těmto verzím a postupně ve vzestupném pořadí verzí provést patřičné kroky, viz níže.
Před update nebo upgrade je doporučeno provést zálohu, např. ve formě snapshotu VM, nebo jiným odpovídajícím způsobem, kterým je aplikace zálohována. V případě neočekávaného problému by mělo být možné vrátit se ze zálohy zpět.
Upgrade versus update
Do verze 2.0.6 existoval pouze update, který vždy provedl aktualizaci aplikace na poslední vydanou verzi. Od verze 2.0.6 (včetně) byl proces rozdělen na dva odlišné kroky: update a upgrade.
Update
Update aplikace provede aktualizaci na poslední vydanou verzi v aktuální řadě. tj. například z 2.0.6 na 2.0.8, nebo z 2.1.1 na 2.1.5. Nikdy už neprovede přechod mezi řadami, tj. neprovede aktualizaci z 2.0.x na 2.1.x. (To platí zpětně i pro starší verze, tj. update ve verzi 2.0.1 aktualizuje na poslední 2.0.x a neskočí na řadu 2.1.x nebo dál.)
Upgrade
Upgrade aplikace provede aktualizaci na další vyšší řadu, pokud je nějaká k dispozici. Tedy například upgrade provede přechod z aktuální verze 2.0.x na poslední verzi další řady 2.1.x. Pokud nová řada k dispozici není, upgrade nic neprovede. Není tedy možné používat upgrade k aktualizaci v rámci stávající řady.
Jak kombinovat
Aplikaci běžně aktualizujeme pomocí update. Pokud dojde k vydání nové řady (např. 2.1.0), pak je pro aktualizaci na tuto novou řadu třeba provést upgrade. Následně opět používáme update pro aktualizace na další verze v této řadě.
Doporučený postup update nebo upgrade
Nutné kroky
Pro update aplikace SOFiE (na poslední verzi v aktuální řadě) je třeba spustit následující příkaz z příkazové řádky:
sofie update
Tento příkaz automaticky provede:
zálohu databáze aplikace
stáhne rpm balíčky s novou verzí a nainstaluje je
provede migraci struktur databáze na novou verzi (aktualizace schématu)
restartuje služby aplikace SOFiE
Pro upgrade aplikace SOFiE (na poslední verzi v další vyšší řadě) je třeba spustit následující příkaz z příkazové řádky:
sofie upgrade
Tento příkaz provede přechod na novou řadu aplikace, pokud existuje a následně spustí update. Pokud nová řada neexistuje, neprovede se nic, ani update.
Dále je nutné provést specifické kroky pro všechny verze aplikace, kterými update nebo upgrade prošel a na které skončil. Viz podrobnosti k jednotlivým verzím níže.
Volitelné, ale doporučené, kroky
Před i po update nebo upgrade je doporučeno ověřit aktuální verzi a stav následujícími příkazy:
# vypíše stav služeb, měl by být u všech active (running)
sofie status
# vypíše aktuální verzi, vhodné pro zjištění z které a na kterou upgradujeme
sofie version
Kromě samotného update nebo upgrade aplikace SOFiE je rovněž doporučeno provést aktualizaci operačního systému, v systémech na bázi RHEL lze provést např. příkazem:
Potom je doporučeno provést restart serveru, aby se ověřilo, že i po všech aktualizacích systém a aplikace v případě restartu znovu korektně nastartuje:
Nakonec ověříme, že aplikace korektně běží. Například aplikačním testem, kdy odešleme uživateli zkušební zásilku a ověříme, že dorazila a uživatel jí může stáhnout. Z pohledu administrátora zkontrolujeme, zda nad zásilkou byly provedeny všechny nastavené kontroly a že audit log neobsahuje žádné chyby.
Specifické pokyny k jednotlivým verzím
Zejména při upgrade na novou větší verzi aplikace (např. 1.3.x na 1.4.x) se často stává, že automatický proces aktualizace nemůže provést všechny potřebné kroky a některé je nutno udělat ručně (typicky úprava konfigurace nginx).
Dále je při zavedení nových funkcí či změn volen obvykle konzervativní postup, kdy pokud je to možné, tak nedochází po upgrade ke změně chování aplikace. To ale znamená, že nové funkce mohou po upgrade být vypnuté a pro jejich využití je třeba upravit konfiguraci aplikace.
Verze 2.3.11
Nutné manuální kroky při upgrade
Pokud používáme od verze 2.3.0 nový modul “Content Disarm and Reconstruction (CDR)“, je pro jeho optimální funkci třeba provést úpravy spuštěním následujících příkazů v příkazové řádce:
Verze 2.3.0
Nutné manuální kroky při upgrade
Pokud chceme využívat nový modul “Content Disarm and Reconstruction (CDR)“, je třeba ho nejprve nainstalovat dle návodu zde: Instalační příručka | Instalace CDR modulu (volitelné)
Doporučená úprava a kontrola konfigurace
Verze 2.3 obsahuje nové či upravené funkce. Administrátor aplikace by měl po provedení upgrade projít zejména následující části nastavení a zvážit, zda a jak chce tyto funkce využívat:
Nastavení → API Tokeny → pro jednotlivé tokeny:
IP rozsahy
Nastavení → Konfigurace → Bezpečnost:
nová sekce: Omezení přístupu, včetně:
Omezení přístupu - IP filtr
Omezení přístupu - reverzní záznam
Omezení přístupu - země
Omezení přístupu - hlavička User-Agent
Nastavení → Konfigurace → Šifrování dat:
Seznam klíčů šifrujících klíče (KEK)
nový doporučený typ klíče HPKE
Nastavení → Konfigurace → Uživatelé:
Výchozí nastavení nových uživatelů, nová práva:
Nastavit zásilku jako trvalou
Trvalý učet
Nastavení → Nastavení detekce:
CDR (Content Disarm and Recontruction)
nový integrovaný nástroj pro konverzi kompatibilního obsahu do bezpečné formy
Avast, Trellix
nově podporované antiviry
Nastavení → ADFS:
nový atribut: ID adresáře (tenanta)
po upgrade není třeba měnit, aby fungovalo jako dříve, pro ADFS má být vyplněno “adfs”
nově zobrazeno: Identifikátor URI pro přesměrování
Nastavení → OpenID Connect:
celá nová sekce umožňující integraci na OIDC zdroje uživatelů a přihlášení (včetně Azure AD nebo Google)
Verze 2.2.0
Nutné manuální kroky při upgrade
Nejsou nutné žádné manuální kroky.
Doporučená úprava a kontrola konfigurace
Verze 2.2 obsahuje nové či upravené funkce. Rovněž v této verzi došlo k podstatným úpravám struktury menu Nastavení → Konfigurace. Administrátor aplikace by měl po provedení upgrade projít zejména následující části nastavení a zvážit, zda a jak chce uvedené funkce využívat:
Nastavení → Uživatelé → pro jednotlivé uživatele:
Email aliasy uživatele
Nastavit schvalovatele
Nastavení → Konfigurace → Základní:
Správa konfigurace - Export konfigurace
Nastavení → Konfigurace → Zásilky → Obecné:
Uživatelé mohou používat aktovku
Uživatelé mohou vytvářet kooperativní zásilky
Nastavení → Konfigurace → Zásilky → Expirace:
Skartované zásilky
Automaticky mazat metadata skartovaných zásilek
Expirace metadat skartovaných zásilek
Nastavení → Konfigurace → Zásilky → Řízení přístupu:
Uzavřené prostředí
IP rozsahy uzavřeného prostředí
Povolit přenos uzavřené → uzavřené
Povolit přenos uzavřené → otevřené
Povolit přenos otevřené → uzavřené
Povolit přenos otevřené → otevřené
Povolit nahrávání zásilek z uzavřeného prostředí
Povolit nahrávání zásilek z otevřeného prostředí
Nastavení → Konfigurace → Zásilky → Schvalování odeslání:
Preferovaný schvalovatel
Uživatel si může vybrat schvalovatele
Schvalovatel má přístup ke všem zásilkám vyžadujícím schválení
Nastavení → Konfigurace → Uživatelé:
Výchozí nastavení nových uživatelů, nová práva:
Používat aktovku
Přístup ke všem zásilkám vyžadujícím schválení
Zvolit schvalovatele odesílaných zásilek
Přístup k podrobným výsledkům kontrol
Vytvářet kooperativní zásilky
Přístup k podrobným výsledkům kontrol souborů
Přihlášení uživatelé
Anonymní uživatelé
Nastavení → Konfigurace → Protokol aplikace:
Uchovávání auditních záznamů
Automaticky mazat staré auditní záznamy
Smazat záznamy starší než
Nastavení → Šablony:
Upraveny některé existující výchozí šablony.
Nastavení → Nastavení detekce:
MIME
Maximální počet uložených záznamů o nalezených objektech
Verze 2.1.0
Nutné manuální kroky při upgrade
Od této verze došlo k podstatné úpravě struktury konfigurace nginx a zároveň ke zlepšení automatizace celého procesu aktualizace tak, aby ve většině případů již nebyly potřeba ruční zásahy. Aby tento automatický proces korektně fungoval, je třeba, aby instalace odpovídala instrukcím z instalačního manuálu, včetně:
Instalace by měla být na vyhrazeném serveru pro tento účel. Neměla by zejména obsahovat žádné ruční úpravy nginx konfigurace. Pokud takové ruční úpravy obsahuje, budou při upgrade na verzi 2.1 přepsány a administrátor je bude muset znovu ručně opravit / provést.
Pokud je instalován vlastní SSL/TLS certifikát pro HTTPS, předpokládá se výchozí cesta uvedená v instalačním manuálu. Pokud by byla použitá jiná cesta, platí totéž co v předchozím bodě o ruční úpravě nginx.
Upgrade konkrétně přepíše soubory /etc/nginx/conf.d/default.conf a /etc/nginx/nginx.conf. Vytvoří však zálohy původních před jejich přepsáním, které vypadají např. takto:
Doporučená úprava a kontrola konfigurace
Verze 2.1 obsahuje nové či upravené funkce. Administrátor aplikace by měl po provedení upgrade projít zejména následující části nastavení a zvážit, zda a jak chce nové funkce aktivovat a využívat:
Nastavení → Konfigurace → Základní nastavení:
Povolené jazyky pro administrátory
Povolené jazyky pro uživatele
Nastavení → Konfigurace → Bezpečnost:
nová sekce: Pravidla hesel pro zásilky, včetně:
Povinné heslo zásilky - nepřihlášený uživatel
Povinné heslo zásilky - přihlášený uživatel
Doba platnosti přihlášení a autorizace:
Doba platnosti jednoho přístupu k zásilce s omezeným počtem přístupů
nová sekce: Nastavení → Konfigurace → Bezpečnostní limity, včetně:
sekce Omezení pokusů o autentizaci
sekce Omezení žádostí o obnovu hesla
sekce Omezení pokusů o přístup k zásilce s heslem
sekce Omezení pokusů o přístup k výzvě s heslem
sekce Omezení pokusů o přístup k neexistující zásilce
sekce Zásilky s omezeným počtem přístupů
Nastavení → Konfigurace → Upozornění:
nová sekce: Schválení odeslání zásilky
Systémová upozornění
Upozornit při překročení kvóty detekčního nástroje
Nastavení → Konfigurace → Vzhled:
nová sekce: Zobrazit podmínky užití
Nastavení → Konfigurace → Nastavení uživatelů:
Výchozí nastavení nových uživatelů, nová práva:
Nevynucovat vícefaktorovou autentizaci
Schvalovat odeslání zásilek
Odesílat zásilky bez dodatečného schválení
Odesílat zásilky sám sobě
Stahovat soubory ze svých odeslaných zásilek
nová sekce: Vícefaktorová autentizace:
Vyžadovat vícefaktorovou autentizaci pro lokální uživatele
Vyžadovat vícefaktorovou autentizaci pro AD uživatele
Vyžadovat vícefaktorovou autentizaci pro ADFS uživatele
nová sekce: Omezení uživatelů podle IP rozsahů
nová sekce: Nastavení odeslaných zásilek, včetně:
Uživatelé mohou odesílat zásilky sami sobě
Uživatelé mohou stahovat soubory ze svých odeslaných zásilek
Uživatelé mohou odesílat zásilky bez schválení
Povolit přístup ke schvalovaným zásilkám bez zadání jejich hesla
Nastavení → E-mailové šablony přejmenovány na Šablony:
Upraveny některé existující výchozí šablony.
Zavedeny nové šablony: DETECTION_ENGINE_QUOTA_EXCEEDED, EMAIL_TEMPLATE_CSS, EMAIL_TEMPLATE_PREFIX, EMAIL_TEMPLATE_SUFFIX, PACKAGE_APPROVE_REQUEST, SEND_PACKAGE_APPROVED, SEND_PACKAGE_DISAPPROVED, TERMS_OF_USE.
Verze 2.0.3
Nutné manuální kroky při upgrade
Upravit soubor /etc/nginx/proxy.conf a nakonec přidat řádek:
Po této úpravě je třeba provést restart nebo reload nginx:
Verze 2.0.0
Nutné manuální kroky při upgrade
Zejména z důvodu změny chování aplikace, kdy stahované soubory již nevydává přímo nginx server, ale až aplikace SOFiE, je nutné upravit konfiguraci nginx jak je uvedeno níže.
Smazat soubory:
/etc/nginx/download-auth.conf
/etc/nginx/download.conf
Upravit soubor: /etc/nginx/conf.d/default.conf
Smazat zde bloky:
Na jejich místo přidat nově bloky:
Vytvořit nový soubor /etc/nginx/proxy.conf s obsahem:
Po těchto úpravách je třeba provést restart nebo reload nginx:
Doporučená úprava a kontrola konfigurace
Verze 2.0 obsahuje velké množství nových či upravených funkcí. Administrátor aplikace by měl po provedení upgrade projít zejména následující části nastavení a zvážit, zda a jak chce nové funkce aktivovat a využívat:
Nastavení → Konfigurace → Základní nastavení:
Povolit přidávat soubory do odeslané zásilky
Povolit mazat soubory v odeslané zásilce
Nastavení → Konfigurace → Bezpečnost:
Zvlášť pravidla hesel pro administrátory a uživatele, včetně nově:
Zakázat použití uniklých hesel
Doba platnosti přihlášení a autorizace
Nastavení → Konfigurace → Šifrování dat:
celá nová sekce s konfigurací pro novou funkcionalitu
Nastavení → Konfigurace → Integrita dat:
celá nová sekce s konfigurací pro novou funkcionalitu
Nastavení → Konfigurace → Protokol aplikace:
Jazyk syslog záznamů (dříve dle výchozího jazyku aplikace)
Nastavení → Konfigurace → E-mail:
Primární a volitelně sekundární jazyk (dříve dle výchozího jazyku aplikace)
Nastavení → Konfigurace → Upozornění:
nová sekce Systémová upozornění
Nastavení → Konfigurace → Nastavení uživatelů:
nové právo uživatele “Šifrovat odesílané zásilky heslem“
nová funkce “Zamknout neaktivní uživatele“
nové funkce “Smazat neaktivní uživatele“
Nastavení → Administrátoři → založení/editace administrátora:
nová práva administrátora pro novou funkci šifrování zásilek
Nastavení → Uživatelé → práva uživatele:
nové právo uživatele pro novou funkci šifrování zásilek
Nastavení → Uživatelé → založení/editace uživatele:
Preferovaný jazyk uživatele - ovlivňuje e-maily zasílané uživateli (dříve dle výchozího jazyku aplikace)
funkce Dočasný uživatel - umožňuje automatické mazání uživatelů po určeném datu
Nastavení → E-mailové šablony:
Upraveny některé existující výchozí šablony.
Zřízeno větší množství nových šablon.
Nastavení → Nastavení detekce:
podpora nového anti-viru FortiClient (nutno instalovat a licencovat samostatně mimo aplikaci)
Verze 1.6 a starší
Tyto verze nemají veřejné upgrade notes, všechny aktualizace byly řešeny individuálně ve spolupráci se Sonpo či partnerem.
Speciální případy
Zejména je-li třeba upgradovat operační systém na novou verzi (RHEL7 → RHEL9) z důvodu končící podpory verze staré, ale třeba i databázi aplikace (PostgreSQL) nebo jinou klíčovou komponentu (Kafka) mimo samotnou aplikaci SOFiE, doporučujeme postupovat tak, že provedeme Migrace SOFiE na nový server .