pondělí 18. února 2019

Proč byla v Nahlížení do KN neaktuální data

Na Twitteru jsem slíbil, že napíši něco k problému, díky kterému byla na Nahlížení do KN  (dále jen Nahlížení) neaktuální data. Ostřílené Oraclisty prosím o shovívavost, protože jsem v rámci čtivosti občas něco zjednodušil.

Pokud čirou náhodou Nahlížení neznáte, tak se ve zkratce jedná o www aplikaci, ve které můžete získat vybrané údaje týkající se vlastnictví parcel, staveb, jednotek evidovaných v katastru nemovitostí, informace o stavu řízení a další užitečné informace.  

Architektura replikací

Nahlížení má svoji samostatnou databázi, do které se replikují data z interní databáze ISKN:

Replikuje se cca 200 databázových tabulek, replikace probíhají každé 2 hodiny a jsou založeny na Oracle Materialized View. Pro zachování logické konzistence dat a cizích klíčů (Foreign Key) jsou všechny tabulky umístěny v jedné  replikační skupině (Materialized View Group), což znamená, že se v rámci jednoho průběhu replikací musí úspěšně zreplikovat všechny tabulky v dané skupině, jinak replikace zhavarují. Takže systém vše nebo nic. 
Pozn.: ve skutečnosti je replikační model košatější. Replikačních skupin tam mámě několik, včetně opačného směru, a ještě se do Nahlížení replikují data z databáze ISÚI.

Kódové stránky

Další věc, která je v tomto případě podstatná, je tzv. character set databáze, což je zjednodušeně řečeno kódová stránka. Protože v době vzniku ISKN nebyla v Oracle rozumná podpora pro Unicode, tak databáze ISKN využívá EE8ISO8859P2 se single-byte  kódováním (každý znak je uložen právě v jednom byte). 
Nahlížení je novější a využívá character set AL32UTF8, což odpovídá Unicode ve verzi 6.2 a je doporučován samotným Oracle. Tento character set je vícebytový (Multibyte) a využívá proměnnou délku kódování (Variable-width encoding), kdy je každý znak podle potřeby uložen v 1-4 byte.  
Pozn 1.: české znaky se tuším vejdou do 2 byte, ale ruku do ohně za to teď nedám.
Pozn 2.: jsou i Multibyte kódování s pevnou délkou, např. UTF-32.

V Oracle se velikost sloupců pro ukládání textu (typicky VARCHAR2) dá definovat dvěma způsoby - v bytech nebo znacích (Char). Velikost v bytech je maximální počet byte, které do sloupečku půjdou uložit, velikost ve znacích udává maximální počet znaků.

V Singlebyte databázi (EE8ISO8859P2) je to jedno, ale v Multibyte (AL32UTF8) je to podstatné, protože do sloupečku s definicí "VARCHAR2 9 Byte" nejde vložit řetězec "nahlížení", neboť má sice jen 9 znaků, ale jeho skutečná reprezentace má délku 12 byte (3 byte navíc jsou díky 3 českým znakům, každý je reprezentován 2 byte). Proto je v obou databázích  ISKN a Nahlížení použita definice pomocí znaků (Char), což eliminuje problém s rozdílnou délkou skutečného uložení řetězců.

Vznik chyby a její příčina

V pátek 8.2.2019 nám dopoledne začal systém indikovat, že se nedaří provést replikace z ISKN do Nahlížení. Replikace končily na chybu:

ORA-12008: error in materialized view or zonemap refresh path
ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2952
ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2370
ORA-12899: value too large for column "ISKN"."AK_JINE_PRAV_VZTAHY"."POPIS_PRAVNIHO_VZTAHU" (actual: 4379, maximum:
4000)

Jednalo se o sloupec tabulky AK_JINE_PRAV_VZTAHY, do kterého se ukládá popis jiného právního vztahu a který je v obou databázích definován shodně, jak délka 4000, tak jednotky Char: 
SQL> desc AK_JINE_PRAV_VZTAHY
Name                    Type
---------------------------------------
ID                      NUMBER(30)
VERZE                   NUMBER(30)
OPSUB_ID_K              NUMBER(30)
TYPRAV_KOD              VARCHAR2(4 CHAR)
POPIS_PRAVNIHO_VZTAHU   VARCHAR2(4000 CHAR)
TEL_ID                  NUMBER(30)
(zkráceno...)

V ten okamžik jsme začali jsme tušit větší problém. Po detailním trasování jsme zjistili, že problém dělá řádek, který má v ISKN délku 3963 znaků a měl by se tedy do 4000 znaků v Nahlížení, kde jeho velikost díky českým znakům v AL32UTF8 naskočila na 4379 byte, s rezervou vejít. 

Zapojili jsme do pátrání i pracovníky podpory české pobočky Oracle a ti po dalším zkoumání přišli s tím, že Oracle sice povolí pro datový typ VARCHAR2 použít maximální velikost 4000 Char, ale ve skutečnosti je strop na 4000 byte, bez ohledu na použití jednotky char. Je to interní limit, což je v případě vícebytového AL32UTF8 docela průšvih. 

Zrádné je to navíc v tom, že se na limit narazí, až pokud se blíží oné maximální velikosti 4000. Pokud je sloupec definován jako "VARCHAR2 500 CHAR", tak se do něj v AL32UTF8 bez problémů 500 českých znaků uloží, přestože zabírají například 560 byte. V našem případě byla velikost problémového záznamu v ISKN (Singlebyte EE8ISO8859P2) 3963 znaků, ale po přenosu do Nahlížení se díky Multibyte AL32UTF8 zvětšila na 4379 byte a narazilo se na strop 4000 byte.

Hledání řešení

Možných řešení bylo několik.

1) Změna character set databáze

Character set se v Oracle definuje při vytváření databáze a následně jíž nejde jednoduše změnit. Je potřeba vytvořit databázi novou, přeexportovat data atd. Je šílená práce, která by v případě Nahlížení trvala několik dnů (export dat, nová databáze, import dat, vše znovu nastavit atd) a musela by se ještě předem důkladně vyzkoušet. 
Existují sice nějaké neoficiální postupy jak to změnit, ale to si nemůžeme u takového systému jen tak dovolit. V Oracle 12c se také objevil oficiální nástroj Database Migration Assistant for Unicode, pomocí kterého by měl jít character set změnit, ale od jeho použití nás v produkčním prostředí odrazovali samotní pracovníci Oracle, protože je (zatím) velmi problémový a plný chyb. Vše by se muselo nejprve vyzkoušet na kopii databáze a ani tak by jistota funkčnost nebyla a navíc jsme nechtěli přecházet z Unicode zpět.

2) Změna parametru max_string_size

Další možností bylo změnit parametr max_string_size na hodnotu "extended", což zvýší limit ze 4000 byte na 32767 byte, což by bohatě stačilo:
STARTUP UPGRADE;
ALTER SYSTEM SET max_string_size=extended;
@?/rdbms/admin/utl32k.sql
SHUTDOWN IMMEDIATE;
STARTUP;

Jenže je zde obdobný problém jako u předchozího řešení. Po dlouhém zkoumání opět samotný Oracle tento postup nedoporučil, protože součástí změny je nutnost spustit script utl32k.sql pro úpravu Oracle Dictionary (katalog - interní tabulky popisující strukturu samotné databáze), na který v Oracle Supportu zrovna chvála není:

Důsledkem by také byla byla fragmentace řetězců v databázi. Zároveň bychom museli změnit inicializačního parametr "compatible", který mám vliv i na chování CBO optimalizátoru dotazů. takže to není bez důkladného testování možné. Opět tedy několik dnů testování a zkoušení, navíc s nejistým výsledkem.

Pozn.: Pokud by databáze byla vytvořena přímo s parametrem max_string_size nastaveným na extended, tak by odpadl problém s fragmentací řetězců a nemusel by se spouštět script utl32k.sql. To je ale jen teoretická možnost, protože to znamená vytvořené nové databáze, viz předchozí řešení 1). Navíc jsme od pracovníků podpory Oracle dostali následující informaci:
"ani po delším pátrání se mi nepodařilo najít reference na použití max_string_size = extended. To znamená, že nemůžeme vyloučit komplikace, bugy apod.".

3) Redefinice MVIEW AK_JINE_PRAV_VZTAHY

Jako jednoduché řešení se nabízelo vytvořit v Nahlížení znovu Materialized View pro dotčenou tabulku AK_JINE_PRAV_VZTAHY  tak, že by se problémový sloupec rozdělil na dvě části, každá o velikosti 4000 CHAR. Reálně by se tedy, díky limitu, do každé části vešlo až 2000 českých znaků, celkem 4000 znaků, což je maximum, které lze v ISKN zapsat:
create mview as 
select id,
substr(popis_pravniho_vztahu,1,2000) as popis_pravniho_vztahu, substr(popis_pravniho_vztahu,2001) as popis_pravniho_vztahu_1,
…. from ak_jine_prav_vztahy@iskni 

To však narazilo z více důvodů. Prvním důvodem byla nutnost upravit aplikaci, která by musela interně oba sloupce zase zpět spojovat. To by nějakou dobu zabralo, ale asi by to šlo za víkend provést a otestovat (+ předělat  MVIEW, i to nějakou dobu trvá, protože by se musela znovu přenést všechna data). 

Druhý důvod byl závažnější. V Nahlížení je na replikované tabulky navázáno přes databázové triggery hlídání přicházejících změn, na jejichž základě se následně provádějí další změny v grafické části (mapě). Novou definicí MVIEW bychom tedy přišli o možnost zpracovat o změny, které v tu dobu již byly nachystané v replikační frontě v ISKN a příslušná část grafiky by se musela kompletně od začátku znovu spočítat, což je časově velmi náročná akce (dny) a navíc jsme neměli vyzkoušen postup, kdy se přepočte jen jedna část. 

4) Aplikační úprava problémového textu v ISKN

Toto řešení by spočívalo v tom, že by se v ISKN upravil problematický text tak, aby se i s českými znaky v Nahlížení vešel do 4000 byte. Použil by se standardní postup přes aplikaci ISKN, jako každá jiná změna v ISKN. Takže založit řízení a provést aktualizaci dat se vším, co k tomu formálně patří. To by ale znamenalo čekat až do pondělí, protože o víkendu nikoho z daného katastrálního pracoviště, které daný jiný právní vztah zapsalo, neseženeme, a do práce nenaženeme.

Následně jsme si ale uvědomili, že bychom tím problém vlastně nevyřešili. Datový model ISKN je navržen takovým způsobem, aby bylo možné zjistit stav data k jakémukoli času. Proto je možné dělat např. výpisy KN k zpětně. Funguje to tak, že pro každou entitu (jiný právní vztah, parcela, stavba, ...) existují 3 tabulky:

  • AK_JINE_PRAV_VZTAHY
  • AK_JINE_PRAV_VZTAHY_B
  • AK_JINE_PRAV_VZTAHY_M

Tabulka AK_JINE_PRAV_VZTAHY (bez suffixu) slouží k uložení aktuálně platných dat, tzv. přítomnost.
Tabulka AK_JINE_PRAV_VZTAHY_B (budoucnost) slouží k vytváření budoucího stavu dat, který bude platit po tzv. zplatnění řízení (navrhují se v ní změny dat).
Tabulka AK_JINE_PRAV_VZTAHY_M (minulost) slouží k uložení již neplatných dat a využívá se právě pro zpětné výpisy, zjištění vývoje změn atd.

Zaměstnanec při zápisu změny navrhne v _B tabulce stav, jak by data měla vypadat. Poté proběhne kontrola jiným pracovníkem a pokud je úspěšná, tak se provede zplatnění řízení, což znamená, že se z přítomnostní tabulky (bez suffixu) data přesunou do minulostní (suffix _M) a z budoucnosti (suffix _B se přesunou do přítomnosti).
Z toho plyne, že bychom aplikační aktualizací problém s délkou textu jen přesunuli z tabulky pro přítomnost (AK_JINE_PRAV_VZTAHY) do tabulky pro minulost (AK_JINE_PRAV_VZTAHY_M).

Pozn.: Rozdělení na 3 tabulky a ne např. použitím atributu v jedné tabulce je dáno historicky. Bylo na zvoleno začátku tvorby ISKN (1997) pro optimalizaci výkonu, protože většina dotazů je na přítomnost, která oddělením od minulosti není velká. 
V ISKN se následně pro přístup využívají tzv. Partitioned views, což v současné době není doporučované technika a působí problémy při migraci na vyšší verze (zhavaroval na ní pokus o přechod na Oracle 11, protože se k takovýmto view přistupuje přes opět hodně zabugovaný JPPD).  Aktuálně se v rámci migrace na Oracle 12c připravuje změna založena na sloučení těchto 3 tabulek do jedné s využitím Oracle Partitioningu, což udělá docela vítr v datovém modelu a celé aplikaci, ale je to koncepční řešení.

5) Úprava problémového textu v ISKN na úrovni databáze

Protože jsme administrátoři, tak můžeme provést update záznamu na úrovni databáze. pomocí SQL příkazu. Jenže to si nemůžeme jen tak dovolit. Někdo ten záznam vytvořil, je za jeho obsah odpovědný a my bychom mu to změnili. Záznam vznikl na základě nějaké listiny, která byla doručena spolu s  návrhem na vklad. Zasáhnout do zapsaného textu není tak jednoduché a mohlo by to znamenat problém, přestože bychom to provedli v dobré víře zprovoznění replikací.

Problém je v tom, že změna by se projevila nejen v Nahlížení, ale i v ISKN, ze kterého pracovníci vydávají veřejné listiny, a také ve výstupech Dálkového přístupu, které mají také charakter veřejné listiny a jsou opatřeny kvalifikovanou pečetí.

Další komplikací by mohlo být, pokud by někdo v rozmezí od okamžiku zápisu daného textu v ISKN do provedení této "tvrdé" opravy na úrovni databáze získal Výpis z KN,  ať už z Dálkového přístupu nebo na přepážce, případně by odebral data ve výměnném formátu nebo jako geodet přes WS GP. Pokud bychom do textu sáhli takto natvrdo, mimo aplikační logiku, tak by se při vyhotovení výpisu ke zpětnému časovému okamžiku toulaly po světě dva výpisy z KN s platností ke stejnému časovému okamžiku, ale s jinými texty. U výměnného formátu bychom zase porušili logiku změnových vět.

Ačkoli by tedy technicky tato změna byla jednoduchá (jeden SQL příkaz), tak z formálního hlediska zase tak jednoduchá není.  

Řešení 

Nějak jsme situaci ale vyřešit museli. Replikace stály už více jak 24 hodin, což není dobré ani pro uživatele, ani pro systém, protože se hromadí data v replikačních frontách a následné spuštění replikací je o to delší.

Varianty 1) a 2) byly hodně rizikové. Komplikuje je také fakt, že v databázi  s replikacemi se nemůžete jen tak v případě problémů vrátit v čase zpět. Kdyby se nějaký problém objevil po tom, co by úspěšně do Nahlížení proběhly replikace z ISKN nebo ISÚI, tak už by se nešlo vrátit zpět a následně zkusit jiné řešení, protože by se replikace rozsynchronizovaly (v ISKN nebo ISÚI  by byla data, která by se tvářila, že už jsou zreplikovaná i v Nahlížení, ale tam by díky vrácení v čase se zpět nebyla). Data by se musela  přenést všechna znovu (provést tzv. complete refresh, který přenese vše, ne pouze fast refresh, který přenáší jen změny). Complete refresh je na dlouho a ještě komplikovaný tím, že ve zdrojové databázi (ISKN, ISÚI) nesmí v tu dobu pro aktuálně přenášení MVIEW probíhat žádné změny. Následně by se v Nahlížení musela kompletně znovu spočítat grafika, viz konec bodu 3). V neposlední řadě bychom vrácením se zpět také přišli o všechna data pořízení přímo v Nahlížení.

Varianta 3) by sice byla funkční a bez problémů, ale časově velmi náročná (dny) a řešila by jen jednu tabulku. Varianta 4) by nepomohla a tak nám po dlouhém zvažování (pořád jsme přemýšleli nad 1) a 2) ) zbyla varianta 5).

Varianta 5) také nebyla ideální, nicméně jsme se pro ni rozhodli s tím, že nám umožní vyřešit co nejrychleji aktuální problém a získáme čas na provedení koncepčního řešení.

Přemýšleli jsme, co s tím, jak změnit text, aby z toho nebyl problém. Nakonec jsme se rozhodli, že zkusíme jen odstranit diakritiku. Nejprve jsme zkontrolovali, že se odstraněním diakritiky nijak nezmění význam textu. Pak jsme prověřili vydané výpisy, výstupy výměnného formátu atd., viz popis ve variantě 5). Naštěstí proběhl jen relativně krátký časový okamžik a ještě to bylo v pátek. Odešlo sice vyrozumění o zápisu daného řízení a s ním výpis, ale to je kontrolovaný a podchycený proces. Do karet nám také hrál fakt, že se by se "jen" odstranila diakritika, takže i kdyby byl výpis vydaný, nebyl by to takový průšvih, nicméně příjemné by to nebylo.

Museli jsme také ověřit, že daným zásahem nezpůsobíme nějakou aplikační nekonzistenci. Některé akce v ISKN jsou hlídány přes databázové triggery a jejich nové spuštění by mohlo vyvolat např. duplicity v navázaných datech atd.

Po prověření jsme požádali vedení o schválení provedené této "tvrdé" úpravy přímo v databázi a po vysvětlení situace, našich zjištění a možných řešení jsme obdrželi souhlas. Zazálohovali jsme tedy měněný záznam a provedli jeho aktualizaci jednoduchým příkazem:
update ak_jine_prav_vztahy set
popis_pravniho_vztahu=convert(popis_pravniho_vztahu,'US7ASCII')
where id=1234

Za dalších 30 minut už všechny replikace na Nahlížení úspěšně proběhly. 

Závěr

Řešení tedy bylo triviální a otázka 5 sekund. Než jsme k němu ale dospěli, tak to trvalo 1.5 dne (1/2 pátku a sobotu) perné práce, protože jsme museli zkoumat možné varianty, ověřovat je atd.

Není to ale řešení trvalé a teď zvažujeme co dál. Naštěstí pravděpodobnost, že by se situace mohla opakovat velká není (délka textu byla opravdu extrémní). Do definitivního vyřešení jsme přijali i organizační opatření. Zatím váháme, zda se v rámci připravovaného cross-platform upgrade (v rámci konsolidace prostředí přechod databáze Nahlížení z Linuxu na AIX) pustit do řešení podle poznámky v bodu 2), které by bylo sice systémovější, ale s možnými problémy, nebo zda půjdeme řešením 3) a sloupec (vlastně sloupce, celkem takových s VARCHAR2(4000) máme v různých tabulkách 4) v Nahlížení rozdělíme na 2. Pokud bychom to dělali řízeně, s prázdnou replikační frontou, tak bychom nepřišli o žádné změny a nebylo by nutné přepočítávat grafickou část.



Pár zajímavostí a poznámek pod čarou


1) Kdybychom nebyli "pokrokoví" a databází Nahlížení udělali také v Singlebyte kódování a nikoli Unicode s proměnnou délkou, tak jsme si tyto problémy ušetřili, obzvláště v kombinaci s replikacemi databází databází s různým character set.

2) Pokud vás zajímá, na čem ztroskotal náš předchozí pokus o upgrade ISKN na Oracle 11g nebo  problematika Partiton Views zmíněná v řešení 3) s bugy JPPD, tak si přečtete naši podrobnou analýzu. Výživné a velmi poučné čtení.

3) Chyba "ORA-12899: value too large for column"  se při replikacích začala objevovat až po nedávné migraci (prosinec 2018) databáze Nahlížení na Oracle 12.2. Ten samý problém ale byl i v předchozích verzích, jenže Oracle při replikacích chybu nehlásil, ale data prostě bez jakéhokoli upozornění ořezal, což je ještě horší.

4) Tvrdým limitem 4000 byte pro VARCHAR2 byli překvapení i samotní pracovníci podpory Oracle. Nemohli ve svých interních systémech dohledat hlášený obdobný problém, což zase překvapilo nás. Zřejmě se kombinace tak dlouhých VARCHAR2 položek v kombinaci s proměnnou délkou kódování a znaky, které se nevejdou do 1 byte, tak často neobjevuje a používá se spíše CLOB.

5) Chování Oracle při použití Multibyte s proměnnou délkou (Nahlížení, AL32UTF8) je opravdu zákeřné, příklad:
(funkce length(rpad('X',4000,'X')) doplní řetězec "X" až do délky 4000 znaků dalšími "X")

SQL> select length(rpad('X',4000,'X')) as delka from dual;
DELKA
--------------------------
                      4000 (očekávaný výsledek)

Když místo US znaku X použijete znak český, tak najednou dostanete pouze 2000 znaků (reprezentovaných 4000 byte): 

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;
DELKA
--------------------------
                      2000 

Pro mě neočekávaný výsledek, který je daný tím, že interní reprezentace v rámci implicitního kurzoru pro 2000 českých znaků je v Multibyte 4000 byte a Oracle to prostě na 2000 znacích bez uzardění ořízne. Když ten samý dotaz spustíte v Singlebyte databázi (ISKN, EE8ISO8859P2), tak je vše OK:

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;
DELKA
--------------------------
                      4000 

Dotaz vypadá nevinně a různý výsledek v různých databázích docela zaskočí. Na takových věcí pak narazíte spousty, pokud už víte, co hledat. 

6) V dokumentaci Oracle se píše: 
The VARCHAR2 datatype stores variable-length character strings. When you create a table with a VARCHAR2 column, you specify a maximum string length (in bytes or characters) between 1 and 4000 bytes for the VARCHAR2 column
Je to zavádějící a jak jsem psal, překvapilo to i samotné pracovníky Oracle. Tohle vám prostě nedocvakne, když o tom nevíte. O nutnosti používat v Multibyte jednotky Char jsme věděli (narazili jsme na to v replikacích již dříve u kratších polí), ale o tvrdém limitu 4000 byte při použití Char ne. Chtělo by to velké červené varování.

7) Z mého textu mohlo zdát, že Oracle je ten nejvíce zabugovaný SW na světě a je prakticky nepoužitelný. Přesto si myslím, že Oracle je v oblastí SQL databází špička, daleko před ostatními (např. technologie RAC), a jinou databází bychom si nijak nepolepšili. Bugy jsou všude a u nás většinou bohužel narazíme na nějaké speciality, které se jinde neřeší. Navíc český support se opravdu snaží. Ale je pravda, že si Oracle jak za licence, tak služby supportu, nechá řádně zaplatit.

8) K druhé větě v odstavci Řešení - někteří uživatelé jsou tak nedočkaví, že se občas stane situace, že náš zaměstnanec zplatní řízení a než připraví a odešle účastníkům řízení vyrozumění o zápisu (to jde i Datovou schránkou), tak se data stihnou zreplikovat na Nahlížení (replikace mohou proběhnout třeba za 5 minut), kde si uživatelé hlídají jejich řízení/LV a volají našemu zaměstnanci, kdy si mohou přijít pro výsledek atd. :-)

středa 13. února 2019

Pozor na KeePass

KeePass je jeden z často používaných správců hesel, který je uvolněný pod General Public Licencí veze 2.

Na rozdíl od různých cloudových správců funguje tak, že máte hesla uložené v jeho "databázi" (soubor), ke které získáte přístup po zadání hlavního klíče ("master password") nebo např. použitím souboru klíče v souboru ("Key File"). Způsobů existuje více.


Tento nástroj má implementovanou jednu vlastnost, na kterou mě dnes upozornil kolega Jirka V. Publikoval jsem ji na Twitteru, ale pak jsem usoudil, že si zaslouží samostatný článek.

V jeho konfiguraci lze nastavit tzv. triggery, což jsou události, které se spustí při určité akci. Na tuto událost lze pak provést další akce.  Jednou z událostí je i otevření/odemčení databáze s hesly a jednou z akcí je export této databáze. Stačí do KeePass.config.xml dopsat níže uvedenou část a při každém odemčení se současně databáze vyexportuje do souboru c:\temp\hesla.txt:

<TriggerSystem>
  <Enabled>true</Enabled>
  <Triggers>
    <Trigger>
      <Guid>esN+2TpQpUSxHM2rzGhXmw==</Guid>
      <Name>test</Name>
      <Events>
        <Event>
          <TypeGuid>5f8TBoW4QYm5BvaeKztApw==</TypeGuid>
          <Parameters>
            <Parameter>0</Parameter>
            <Parameter/>
          </Parameters>
        </Event>
      </Events>
      <Conditions/>
      <Actions>
        <Action>
          <TypeGuid>D5prW87VRr65NO2xP5RIIg==</TypeGuid>
          <Parameters>
            <Parameter>c:\temp\hesla.txt</Parameter>
            <Parameter>KeePass CSV (1.x)</Parameter>
            <Parameter/>
            <Parameter/>
          </Parameters>
        </Action>
      </Actions>
    </Trigger>
  </Triggers>
</TriggerSystem>

V domácím použití to není úplně kritické, protože pokud se vám někdo dostane do počítače, aby vám bez vašeho vědomí změnil konfigurační soubor KeePass.config.xml, tak máte velký problém tak jak tak. Horší je ale, pokud je KeePass používán ve firemním prostředí jako úložiště hesel pro více uživatelů, což je scénář, který KeePass přímo podporuje a uvádí.  

Představme si tedy scénář, kdy je databáze s hesly uložena na sdílení a přístup k ní mají jen oprávnění uživatelé, mezi které ale nepatří administrátor systému, na kterém je databáze a konfigurace uložena. Když takový administrátor do konfigurace doplní výše uvedenou část, tak stačí, aby někdo jiný (oprávněný), otevřel databázi s hesly, na což zareaguje trigger a spustí export hesel do textového souboru. V podstatě ji dostane naservírovanou na talíři. 

Pozor tedy na tuto (dokumentovanou) vlastnost, není to chyba. Jen mám pochybnosti, zda je tato vlastnost ve všeobecné známosti uživatelů, kteří KeePass používají. Já KeePass nepoužívám a nevěděl jsem o tom, ale i kdybych ho používal, tak upřímně, zase tak detailně nápovědu a možnosti konfigurace nestuduji a určitě bych o tom nevěděl.

Možná je čas se poohlédnout po nějakém jiném řešení, obzvláště v podnikovém prostředí. Inspirovat se můžete třeba na následujících stránkách:
https://smallbiztrends.com/2018/01/best-password-manager-apps-small-business.html

Na závěr přidávám doplnění od Michala Špačka, uznávaného odborníka na bezpečnost:
Asi je dobré poznamenat, že dávat do firemního správce hesel "nefiremní" přístupy, kde by vadilo, že se k nim dostane např. správce, který nakonfiguruje triggery, není dobrý nápad a ani dokumentace KeePassu takovou věc nezmiňuje. Zákeřný admin systému se k heslům v databázi vždy dostane, triggery, netriggery. 

úterý 22. ledna 2019

Mají být všechna data státu zdarma?

Velmi často se někde objeví názor, že by měl stát dávat všechna data, která má, a které nepodléhají utajení, zdarma. Prakticky to samé platí i pro poskytované služby. Na jednu stranu je to představa poměrně líbivá, i pro mě. Jsem informatik a v datech se rád hrabu, takže bych s tím souhlasil. Na první poslech logicky zní i argument typu "zaplatili jsme si to z daní", který je občas v těchto souvislostech slyšet. Proti faktu, že by to mohlo rozjet další podnikání a služby občanům, také nelze nic namítat. Bohužel to má ale i druhou stránku, kterou si lidé hned neuvědomí.

Stanovené příjmy

O tomhle faktu se moc veřejně neví, nebo jsem na něj alespoň zatím nikde, u podobných diskuzí,  nenarazil. Státní úřady, přinejmenším některé, mají ze zákona, který reprezentuje Zákon o státním rozpočtu, stanoveny příjmy, které musí splnit (lidově řečeno "vybrat peníze"). Jsou dvoje typy příjmů - daňové (typicky správní poplatky) a nedaňové, mezi které patří příjmy za úplatu (neplést s úplatkem :-), pojem je opakem k bezúplatně poskytovaným věcem).

ČÚZK měl pro rok 2017 rozpočtem stanoveny následující podmínky (zdroj Výroční zpráva ČÚZK za rok 2017):
"Schválený státní rozpočet pro kapitolu 346 Český úřad zeměměřický a katastrální na rok 2017 byl stanoven ve výši 700 mil. Kč pro příjmy a v objemu 3 048,8 mil. Kč pro výdaje. Rozpočet daňových příjmů zahrnující správní poplatky byl stanoven ve výši 550 mil. Kč, jeho plnění dosáhlo objemu 651,8 mil. Kč, tj. 118,5 %. Nedaňové příjmy v roce 2017 byly kapitole stanoveny ve výši 150 mil. Kč a byly naplněny objemem 237,7 mil. Kč, tj. plnění na 158,5 %. "

Pokud tyto stanovené příjmy nejsou splněny, tak dochází směrem k nám ke krácení výdajů ze státního rozpočtu, což má přímý dopad do investičních činností atd. a není to příjemná situace. Takže i státní úřady jsou nuceny vybrat peníze za svoji činnost a pokud se tak nestane, jsou penalizovány. Není to tak, že je jedno, kolik příjmů mají. Pokud bychom měli všechna data poskytovat zdarma, tak o část těchto příjmů přijdeme. To by bylo třeba zohlednit ve státním rozpočtu, aby s tím počítal. To se ale dnes neděje a i proto se musíme snažit data prodávat.

Je to komplikované i tím, že zdaleka nemůžeme být tak pružní, jako soukromé firmy. Nemůžeme si udělat "Black friday". Nemůžeme jednoduše upravit výši správních poplatků a úplat. To, co soukromá firma je schopna udělat lusknutím prstu, musí státní instituce prohnat přes zákony a vyhlášky, což je věc minimálně na 1/2 roku, když to jde velmi dobře. Naše ceny jsou stanoveny vyhláškou 358/2013 Sb., o poskytování údajů z katastru nemovitostí.

Problém z příjmů byla také jeden ze zásadních připomínek, které jsme v roce 2017 zasílali při připomínkování návrhu usnesení vlády ČR  "o zveřejňování dat, která jsou vedena v informačních systémech veřejné správy spravovaných ústředními správními úřady, jako otevřených dat".

Obecný přístup

I kdyby se problém příjmů vyřešil, tak zde je podle mě ještě závažnější otázka. Opravdu chceme, aby byla všechna státní data zdarma? Z jakého důvodu? Pořízení dat něco stojí, zadarmo nic není. Státní úřady mohou všechna data dávat zdarma, ale tím se se sníží příjmy rozpočtu a pravděpodobně se tak budou muset zvýšit daně, aby tento výpadek pokryly. 
Co je ale správná cesta? Mají všichni plošně platit za něco, co je nezajímá? Proč by si to nemohli zaplatit pouze Ti, kterých se to týká? Já nechci z daní platit data pro Pepíka z Horní dolní. Jsem zastáncem toho, že by daně měly být stanoveny tak, aby pokrývaly pouze široké plošné výdaje státu, u kterých by bylo ve výsledku dražší platit položkově. Za věci, které plošné nejsou, by měly platit jen zájmové osoby, ne všichni. Jaké procento lidí je využije? Bude to většina obyvatel? To mi připomíná spíše socialismus. 

Závěr 

Poskytovat plošně státní data mi z výše uvedeného důvodu nedává smysl. Je ale určitě obtížné najít tu správnou hranici, aby byly spokojeny obě strany, jak stát, tak jeho obyvatelé. Tato problematika není jednoduchá a celá věc není tak černobílá, jak by se na první pohled mohlo zdát.

PS: Pokud chceme data zdarma, musíme ulevit státnímu rozpočtu. Můžete to udělat i vy, třeba tím, že si zřídíte jako fyzické osoby datovou schránku. V našem případě to v našem rozpočtu (nikoli v rozpočtu státu, ale i tak je to celkově levnější) ušetří náklady na poštovné (zdroj Výroční zpráva ČÚZK za rok 2017) a budeme je moci použít na jiné věci:
Služby pošt byly čerpány ve výši 138,1 mil. Kč a vykázaly po loňském snížení opět nárůst o 2 mil. Kč oproti roku 2016

čtvrtek 3. ledna 2019

Otevřenost katastru v EU

Občas se vyskytnou diskuze, zda je správně, že je katastr nemovitostí v České republice veřejný a otevřený. Kolegové prošli lokální katastry (land register, LR) některých států a vyrobili přehled, jak je to v EU (+ i někde jinde). Výsledek jejich zkoumání naleznete v tabulce s přehledem otevřenosti katastru v EU.

Raději upozorňuji, že je to pojato zjednodušeně a získáním informací se myslí výpis na jednotlivou nemovitost. Mnohde totiž vůbec nelze nijak získat žádný přehled vlastnictví ani kopii listiny. Někde to získat lze, ale po prokázání právního zájmu (pro listiny to platí s tímto omezením dokonce i na Slovensku, pro přehled vlastnictví zase v Rakousku). 

Primárním zdrojem dat byla stránka http://www.doingbusiness.org/.  


pondělí 22. října 2018

Následky plánované odstávky el. energie aneb co se může pokazit, to se pokazí ...

V naší budově bylo potřeba provést kompletní odstávku el. energie. Kompletní znamená, že jsou vypnuty i zálohované rozvody, které jsou napojené na UPS a diesel generátor. Taková akce je poměrně náročná na přípravu. Ačkoli máme primární produkční hardware pro naše hlavní systémy (ISKN, RÚIAN, ISÚI, VDP atd.) umístěn v housingu, tak přesto je v budově spousta další techniky, včetně záložního centra, pomocných serverů atd. Pro představu, je to několik desítek fyzických serverů (virtuály ani nepočítám), pár enterprise diskových polí, páskové knihovny, switche, firewally a spousta dalších zařízení.


Proces vypínání i zapínání není jednoduchý a obě části trvají vždy několik hodin. Je potřeba jednotlivé zařízení, včetně virtuálních, vypínat ve správném pořadí. Nemůžete např. vypnout diskové pole před vypnutím všech serverů, které jsou na něj napojeny atd. Existuje spousta závislostí, včetně závislostí mezi systémy a opravdu to není legrace. Nakonec se vypnou všechny jističe, i z důvodu zamezení špičky během zapínání. Zapíná se také postupně a je na to plán, jako na vypínání.

Při takové akci vždy něco, jak se lidově říká, odejde. Není to otázka zda, ale kolik. Většinou to odnese pár disků a zdrojů. Ovšem tentokrát se opravdu zadařilo. Mohlo nás už varovat, že ještě před odstávkou odešel disk v poli IBM Storwize V7000. Disk se vyměnil a těsně před započetím odstávky se stihl dopočítat. Uff.
IBM Storwize V7000

Vypínání 

Vlastní akce pak začala v pátek po 15:00 vypínací fází. Těsně po začátku volal technický pracovník budovy, který má na starost rozvody, našim administrátorům, zda může vypnout zálohované zásuvky v kancelářích. Byl ujištěn, že ani náhodou, protože z PC v kancelářích se kompletně řídí a provádí vypínání techniky. Za dalších 20 sekund napájení zásuvek vypnul... Tím se celé vypínání, za nadávání administrátorů, zkomplikovalo a protáhlo. Po vypnutí, včetně jističů, byly zahájeny nutné práce na el. rozvodech a po jejich dokončení, kolem 22:00, se začalo s druhou fází, zapínáním.


Zapínání 

Nebudu to moc protahovat a použiji slova kolegy, který celou akci řídil: "napájení bylo zapnuto před desátou a pak se začaly dít věci"

Nenastartovaly tři LAN switche (součást páteřních rozvodů budovy). Dva jsme postupně vyměnili za náhradní, porty z třetího se dočasně rozdělily do jiných switchů a bude nahrazen v pondělí.

Nenastartoval jeden z centrálních switchů. Po několika marných pokusech jsme to vzdali. Následně jsme to kolem čtvrté ráno zkusili znovu a switch nastartoval – hlásí ale critical chybu na supervisoru (řídící karta switche) a dále vadnou kartu 16x10Gbit. Ostatní karty momentálně fungují.

Nebylo funkční spojení mezi primární a záložní lokalitou (housingové centrum a naše budova v Kobylisích). Konzultací s technikem z Alef0 bylo zjištěno, že v obou DWDM (Dense Wavelength Division Multiplexing) v Kobylisích odešly stejné karty s optickým zesilovačem. Technik nabídnul zapůjčení jedné jejich karty ze skladu (ceníková cena cca 17 000 USD). Přivezl ji po půlnoci a kolem 01:00 bylo spojení lokalit obnoveno alespoň po jedné trase.
Pozn.: Druhou možností bylo, že v housingu vykrademe jedno z funkčních DWDM, abychom zprovoznili alespoň tu jednu trasu.

Nenastartovalo diskové pole IBM Storwize V7000. Do Kobylis přijel v noci technik z GC System a řešil to na místě s podporou IBM. Postupně se došlo k tomu, že velmi pravděpodobně během startu  pole zhavaroval jeden z disků tak nešťastně, že se rozhodila konfigurace řadičů. Podpoře IBM se  přes vzdálenou správu pole podařilo problém vyřešit a data byla zpřístupněna kolem 02:30. Vadný disk byl následně vyměněn.

Zhavaroval jeden z dvou zdrojů police s řadiči na diskovém poli HPE 3PAR. Náhradní zdroj byl objednán u HPE a dorazil v sobotu ráno kolem 08:00 a byl následně vyměněn.
HPE 3PAR
Ve dvou dalších serverech odešel disk, z toho u jednoho takovým způsobem, že byla poškozena data v celém mirroru a zřejmě bude nutná reinstalace.

U databázového serveru testovacích prostředí EPVDS došlo k poškození souborových systémů, naštěstí se to podařilo opravit.

U jednoho serveru v infrastruktuře DMS odešel zdroj.

Na centrálním firewallu došlo k poškození pravidel, byla nutná jejich úprava.
Pozn.: To zřejmě nebyl přímý následek vypnutí, spíše restartu, dále to zkoumáme.

Celou noc se bojovalo NAS clusterem, pravděpodobně nezvládnul věci kolem problémů s komunikací (a s nedostupnými některými síťovými porty u serverů v Kobylisích). Občas to znamenalo výpadek některých systémů a vyvrcholilo to kolem osmé totálním rozpadem NAS clusteru. Podařilo se ho zprovoznit, znamenalo to ale problémy v některých databázích (např. Nahlížení). Navíc, pravděpodobně z důvodu delší nedostupnosti druhého HPE 3PAR během odstávky, vyjmul Oracle clusterware voting disky mapované z tohoto pole tím pádem při každých problémech kolem NAS docházelo k restartu databází.

Databázaři si pak také užili své. Museli opravovat chybějící voting disky  a udělat rekonfiguraci všech disků datových skupin ASM, které jsou umístěny v záložní lokalitě a které byly po nastartování ve stavu missing apod.

Celá akce skončila v sobotu ráno kolem 09:00, kdy všechny systémy opět běžely. Z naší strany ji řídil Jirka V., kterému sekundovali Petr S., Karol J., Ondřej R., Tomáš R. a Martin D. a Jirka K. Patří jim velký dík, stejně jako GC System a Alef0 za noční spolupráci.


Závěr

Přemýšlím, jaké si z toho vzít ponaučení. To, že při vypínání, při našem množství techniky v budově, odejdou disky nebo zdroje, je už běžná věc a máme náhradní (nebo jsou redundantní). To, že sebou disk vezme celý RAID nebo znefunkční diskové pole už tak běžné není, ale i to se stane. Ale např. na to, že v obou DWDM  odejdou optické zesilovače, se prostě připravit nemůžete (mimo přípravy mít nasmlouvaný dobrý servis).

Kritickou infrastrukturu a produkční část systémů máme v housingu, ale i přesto je v budově velká spousta techniky, která tam už z principu být musí. Pohrávám si s myšlenkou, zda bychom naopak neměli vypínání dělat čestěji. Nikoli najednou, ale během celého roku, postupně, v kolečku, aby nebyly tak fatální následky. Možná by se tak podařilo odchytit načatý HW bez vážnějších dopadů. Možná by toho ale naopak díky častějšímu vypínání odešlo ještě více. Kdo ví...

pondělí 7. května 2018

Jak jsem hledat problém s uváznutím (deadlock) v aplikaci Návrh na vklad

ČÚZK vytvořil a provozuje www aplikací Návrh na vklad, která umožňuje uživatelů připravit formulář s návrhem na vklad do katastru nemovitostí. Její součástí jsou i webové služby, které pro generování návrhů využívají např. banky. Vývoj a provoz této aplikace mám na starost se svým týmem.

Při provozu jsme registrovali, že se občas vyskytuje chyba ORA-00060: deadlock detected while waiting for resource, což je problém s uváznutím, kdy se databázové transakce uzamknou proti sobě a ani jedna nemůže pokračovat dál.

Vytvořit deadlock je poměrně jednoduché. Stačí si otevřít dvě session a navodit například následující stav:
Krok Transakce 1 Transakce 2 Popis
    1 UPDATE platy SET plat=1000 WHERE zamestanec_id=1 Transakce 1 si v tabulce PLATY uzamkne záznam pro zaměstnance s ID 1
    2 UPDATE odmeny SET castka=2000 WHERE zamestanec_id=10 Transakce 2 si v tabulce ODMENY uzamkne záznam pro zaměstnance s ID 10
    3 UPDATE odmeny SET castka=500 WHERE zamestanec_id=10 Transakce 1 se pokouší v tabulce ODMENY uzamknout záznam pro zaměstnance s ID 10, což se ji nedaří, protože zámek drží transakce 2 a transakce 1 tedy musí čekat na dokončení transakce 2.
    4 UPDATE platy SET plat=300 WHERE zamestanec_id=1 Transakce 2 se pokouší v tabulce PLATY uzamknout záznam pro zaměstnance s ID 1, což se ji nedaří, protože zámek drží transakce 1 a transakce 2 tedy musí čekat na dokončení transakce 1.

V tento okamžik jsou obě transakce zacyklené. Transakce 1 čeká na dokončení transakce 2, ale ta zase čeká na dokončení transakce 1 a problém s uváznutím je na světě:

(obrázek z http://oracledbpro.blogspot.com/)

Oracle tento stav pomocí backgroud procesu DIAx detekuje, provede roolback příkazu, který ho způsobil a vyhlásí chybu ORA-00060: deadlock detected while waiting for resource.

Malá odbočka. Ohledně deadlocku v Oracle panuje několik mýtů, které je vhodné vyjasnit:
  • Oracle neprovede kill žádné session,
  • Oracle provede rollback příkazu, ale neprovede rollback celé transakce,
  • Oracle background proces PMON (Process Monitor) neuvolní předchozí zámky.
Deadlock se nemusí týkat jen řádků tabulce. Je to jeden ze synchronizačních problému a takto se může uzamknout prakticky cokoli. Hodně se to řeší v operačních systémech a je to velmi zajímavá problematika.

Zpět k naší aplikaci. Chyba ORA-00060 se nám občas vyskytovala v situaci, kdy uživatel, nebo automatický proces, mazal návrh na vklad. Vyskytovala se poměrně zřídka, ale časem začala narůstat na několik výskytů denně. 99 % bylo vyvoláno z automatického procesu, bez vlivu na uživatele, který chybu ani nepoznal.

Pokud se problém s deadlockem vyskytuje v aplikaci, tak je jeho příčina nejčastěji buď chyba v návrhu aplikace nebo chyba v datovém modelu. Většinou se špatně hledá.

Naše aplikace má jednoduchý datový model, který se skládá z cca 70 tabulek. Chyba se vyskytovala při mazání jedné z tabulek NEMOVITOSTI, STAVBY nebo PARCELY. Datový model této části vypadá zhruba takto:
část datového modelu


Při kontrole mazací procedury jsem nenarazil na problém, tak jsem se zaměřil na datový model. Ten jsem prošel, ale také mě nic do oka netrklo, tak jsem musel zkoumat dál. Oracle při výskytu chyby zapíše událost do alert logu (píši se zde všechny důležité události, která v databázi vznikly) a vytvoří trace soubor:
ukázka alert logu

ukázka trace (mívá jednotky až stovky MB)


Otevřel jsem trace a viděl, že problém v tomto případě vznikl při mazání záznamů z tabulky STAVBY:
mazané tabulky

Znovu jsem prověřil danou část modelu, ale vše vypadalo OK. Pátral jsem tedy dál. V trace je graf deadlocku:

Z něj jde vyčíst, že je problém v resource se jménem TM-003f719d-00000000 (viz (1)), kdy transakce má zámek typu SX a čeká na typ SSX. Zámek typu SX, na rozdíl od SSX, může získat pouze jedna transakce. Podle toho, že se nečekalo na uzamknutí řádků (viz (2)), bylo jasné, že se jednalo o problém přímo s uzamknutím celého databázovém objektu (tabulka, index, ...). Jak ho ale zjistit? 
Struktura jména resource TM-003f719d-00000000 mi nic neříkala a nedokázal jsem odvodit, z čeho je složena. Oracle má sice metadata o svých objektech, ale jsou to ID typu NUMBER (sloupec OBJECT_ID), takže tudy cesta nevedla:
pohled DBA_OBJECTS 

Po dalším pátrání na Oracle Metalinku se mi podařilo dohledat dokument Doc ID 62365.1, ve kterém se píše:
dokument Doc ID 62365.1

Takže TM je typ zámku a 003f719d je ID objektu, ale v HEX formátu (pozn.: také mě to mohlo napadnout :-) ). Převedl jsem tedy 003f719d do desítkové soustavy (4157853) a podíval se do metadat, kterému databázovému objektu patří:
identifikace objeku

Problém tedy vznikl při pokusu o uzamknutí tabulky PARCELY_PARCELY.  Při kontrola dalších trace se vždy jednalo pouze o tuto tabulku. Struktura tabulky je jednoduchá, její účel je pouze vazba mezi původními a nově vznikajícími parcelami. Má jen dva sloupce VZNIKAJICI_PARCELY_ID a PUVODNI_PARCELY_ID a oba se přes cizí klíče (FK) odkazují do tabulky PARCELY. Proč se ale zamykala celá? 
Podíval jsem se na indexy a bylo jasno. Tabulka měla sice složený index nad oběma sloupci, ale ne nad sloupcem PUVODNI_PARCELY_ID:
indexy na tabulce PARCELY_PARCELY

To je sice v pořádku pro logiku aplikace, protože se k tabulce vždy přistupuje i přes VZNIKAJICI_PARCELY_ID, ale problém vznikne, když se má mazat záznam v tabulce PARCELY (kde se maže i při mazání STAVBY nebo NEMOVITOSTI). Oracle se musí v ten okamžik podívat do tabulky PARCELY_PARCELY, zda tam nejsou záznamy, které by mazání bránily. Pokud se kontroluje obsah sloupce VZNIKAJICI_PARCELY_ID, tak použije index a je to OK. Ale pokud se kontroluje obsah sloupce PUVODNI_PARCELY_ID, tak se díky chybějícímu indexu uzamkne celá tabulka, což je problém. Aplikace sama o sobě index na tom sloupci nepotřebuje, ale Oracle už ano. 

Řešení bylo jednoduché - vytvoření nového indexu nad sloupcem PUVODNI_PARCELY_ID. Oracle tak při kontrole FK využije index, uzamkne pouze dané záznamy a nikoli celou tabulku. Tohle pracovníkovi při návrhu databáze nedošlo a bývá to poměrně častá chyba. Po vytvoření indexu chyba zmizela, jako mávnutím kouzelného proutku. Problém byl vyřešen a tím mé pátrání skončilo. 

Na závěr bych chtěl dodat, že by z toho mohl plynout závěr, že by se měl na každý sloupec, který obsahuje FK, udělat index a byl by pokoj. Mělo by tedy stačit zkontrolovat, např. jednoduchým dotazem do metadat Oracle, zda každý takový sloupec index má. To ale není dobrý přístup. Sice se vyhnete těmto problémům, ale budete nutit Oracle tento index udržovat, což stojí nějaké zdroje (disk, I/O, CPU). Je to třeba posuzovat případ od případu. Pokud se například odkazujete na číselníkovou položku, která se nemaže (číselníkové položky se typicky jen zneplatní), tak index potřeba není, protože tam žádná kontrola neprobíhá.


čtvrtek 28. prosince 2017

Recenze audioknihy „Peter May – Pán ohně“

Kniha tvoří první díl série Čínské thrillery, kterou jsem se rozhodl poslechnout. Aktuálně jsou ve formě audioknihy zpracovány první dva díly.



Kniha vypráví příběh americké soudní lékařky Margaret Campbelové, která se z osobních důvodů rozhodne jet na 6 týdnů do Číny, kde má přednášet na vysoké škole. V Číně se seznámí s čerstvě povýšeným detektivem Li, se kterým následně vyšetřují podivnou vraždu.
Přemýšlím, co o knize dobrého napsat, abych jen neprskal. Možná bych za malý klad vyzvedl mírné uvedení do života v Číně, tedy pokud se mu dá nějak věřit. To bohužel neposoudím. Bohužel nic dalšího pozitivního mě na knize nenapadá a útlocitnější povahy varuji před dalším čtením, protože si nebudu brát servítky.

OK, jdeme na to. Představte si hrdinku, která chce zapomenout na své životní komplikace a tak odjede do Číny. Na nic se nepřipraví, nepřečte si ani pokyny, jak to v Číně chodí a jak by se měla chovat, aby se vyvarovala problémům. Po příjezdu dělá jeden problém za druhým a chová se tak, že se posluchač občas diví, jak svého vzdělání mohla dosáhnout. Nemyslím teď z odborného hlediska, kde naopak působí jako supermanka, ale z hlediska chování a nějakého pudu sebezáchovy. Neuvědomuje si, že je v Číně, kde to chodí jinak a je velmi překvapena, že jí mohou třeba zkrátit vízum, když se úřadům znelíbí, nebo že je jako Američanka pod drobnohledem místních úřadů. Občas se prostě chová jako nesvéprávná a naivní osoba.

O vlastní zápletce je také škoda hovořit. Z počátku vypadá trochu zajímavě, ale pak tomu autor bohužel nasadí korunu v podobě nevyhnutelné apokalypsy a konce světa. To byl okamžik, kdy jsem přemýšlel, že s knihou seknu a smažu ji. Pak ale převážila zvědavost, jak se z toho autor nakonec vykroutí, protože to je první díl z celé série, takže to musí minimálně s hlavními hrdiny dopadnout dobře. Tak jsem statečně poslouchal až do konce.

Zajímá vás, jak to celé dopadlo? Pokud se nechcete připravit o překvapení, tak přesto můžete klidně číst dále, protože mě to zajímá také. Hlavní zločin byl sice objasněn, ale jak dopadne ona avizovaná apokalypsa vyjasněno není a také není zřejmé, co se stalo s hlavními hrdiny (bez spoileru bohužel nemohu být detailnější). Jejich příběh není uzavřen a chybí mi dořešení všech skutečností, které se staly. Když jsem četl recenze na další díl, tak jsem z nich pochopil, že se autor nějakého vysvětlování zřejmě raději vzdal (nečetl/neslyšel jsem ho, nemohu to potvrdit, ale nemám po tomto zážitku sílu to zjišťovat). To rozhodnutí vlastně celkem chápu, protože dostat se z této šlamastyky se ctí, nejde.

Na druhou stranu musím ale uznat, že kniha může sloužit i jako červená knihovna, což je vlastně přidaná hodnota :-).

Audio verzi namluvila dvojice Martin Myšička a Jana Plodková. Přednes je slabší a osobně preferuji spíše vypravěčský styl. Není to ale zase úplná tragédie.

Série má 5 dílů a jak jsem již psal, do audioverze jsou převedeny první dva díly. To je přesně o 2 díly více, než by bylo vhodné. S knihou nedoporučuji ztrácet čas, na trhu je spousta zajímavějších detektivek (například Honicí psi).

úterý 26. prosince 2017

Recenze audioknihy „Jørn Lier Horst – Honicí psi“

Když jsem tuto audioknihu kupoval, tak jsem moc netušil, co od ní čekat a přemýšlel, zda má vůbec smysl kupovat 8. díl11 dílné série, protože pouze tento díl vyšel jako audiokniha.


Hlavním hrdinou je policista William Wisting, kterému do profesního života zasáhne případ vraždy mladé dívky. Stal se sice před 17 lety a pachatel byl odsouzen a odpykal si trest, ale po svém propuštění za pomocí advokáta vznesl obvinění, že byly zmanipulovány důkazy a byl odsouzen neprávem. Vyšetřování před 17 lety vedl právě William Wisting, který teď musí čelit obvinění ze zanedbání povinností a falšování důkazů. Současně se rozjede paralelní příběh týkající se jeho dcery, novinářky Line, která se snaží usilovnou prací na jiném případu odložit zveřejnění obvinění jejího otce a dát mu čas se na vše připravit.

Nečekejte zde žádný humor, jako například v Případech oddělení Q (mimochodem, také skvělá věc). Styl knihy mi velmi připomněl mou oblíbenou sérii Joona Linna. William Wisting je stejně jako Joona Linna starší a zkušený policista. Není to žádný „střelec“ ale rozvážný člověk, který nad vším detailně přemýšlí a uvažuje.  

Příběh je psán bez výraznějších hluchých míst a rychle vás do sebe vtáhne. Líbí se mi, že zakončení je úplné, vše je řádně vysvětleno a objasněno. Přesně víme, co se s každou důležitou postavou stalo. Mile mě překvapil překlad, který je částečně uzpůsoben našim pojmům. Setkáváme se například s pojmem generální inspekce bezpečnostních sborů a dokonce i se slovníkem z mého oboru - katastrální úřad, katastrální mapa, číslo popisné a evidenční, letecký snímek, které jsou správně použity, což jsem snad ještě neviděl.

Ke knize mám pár výtek. Nepochopil jsem dělení do kapitol, kterých je 84. Občas jsem měl pocit umělého rozdělení textu. Kdyby jich byla polovina a byly delší, vůbec by to neuškodilo. To je ale detail.
Druhá výtka je ve vlastnímu audiu - nezvykl jsem si na hlas Zdeňka Kupky. Je to hodně subjektivní věc, ale Pavel Rímský by mi zde sedl o mnoho lépe.
Třetí výtka souvisí s kombinací textu a audia. Vlastně to není výtka, spíše problém, který tímto spojení vznikl. V knize jsou dvě postavy – Line a Linea. Jejich jména znějí velmi podobně a při poslechu jsem byl z počátku zmaten, než mi došlo, že to jsou dvě postavy a dokázal je rozlišovat. To by se zřejmě při čtení knihy nestalo. Když to ale už víte a budete si na to dávat pozor, tak s tím problém mít nebudete.

S knihou jsem byl i přes výtky velmi spokojen a je škoda, že nejsou do audioverze převedeny všechny díly této série. Mohu ji vřele doporučit.

pondělí 30. října 2017

Pozor od 1.1.2018 na komunikaci s ISZR

Aktualizace 22.5.2018

Protože se ze SZR nikdo neozýval, tak jsme se začali vyptávat a rozesílat e-maily. Dozvěděli jsme se, že  upgrade proběhl 7.5.2018 (nikomu nedali vědět) a máme to vyzkoušet. První testy vypadají OK, takže se snad konečně podařilo celou kauzu uzavřít. Sice ještě stále nefunguje TLS 1.2 na eGON9, ale eGON4 a eGON 5 se už tváří v pořádku.

Aktualizace 23.4.2018

Podpora SZR na naši žádost požadavek #30473 zpětně otevřela, dokud nebude vyřešen související požadavek #31122 na nový firmware F5 (reverzní proxy a zřejmě i jejich SSL terminace), což je dobrá zpráva. 

Špatná zpráva je tak, že ISZR má architekturu udělanou tak, že produkční i testovací prostředí ji nějak sdílí s produkčním a plánovaný upgrade firmware F5 na testovacím prostředí (to je upgrade, po kterém by snad konečně, skoro po roce, měla chodit komunikace přes TLS 1.2 i v novějších systémech) ovlivní i produkci a proto ji nelze provést rychle, protože se musí některé AIS na produkci přizpůsobit.


Co z toho plyne? Že u tak kritické věci, jakou jsou základní registry, nelze poměrně závažnou věc, jakou je upgrade firmware, otestovat předem na testovacím prostředí, ale bude se dělat přímo na produkci, protože je minimálně částečně (F5) sdílena s testovacím. To bude možná na produkci nějaké nemilé překvapení (přál bych si, aby nebylo).

Celá kauza se táhne už od srpna 2017 a stále to nefunguje :(.

Aktualizace 29.3.2018

Podpora SZR označila náš požadavek #30473 v helpdesku za vyřešen s tím, že byla nalezena příčina a bude se řešit v novém požadavku #31122. Takto se zřejmě vylepšují statistiky.  Požadavek z mého pohledu vyřešen není, testovací prostředí ISZR nefunguje správně. To, že byla nalezena (možná) příčina neznamená, že se problém vyřešil.

A jaká je vlastně příčina? Zřejmě je problém v reverzní proxy F5 a bude se muset provést její upgrade, aby podporovala RSA_SHA256. Není mi z jejich vyjádření zřejmé, zda bude stačit upgrade softwarový, nebo bude nutný nový HW. 
SZR dostala za úkol do příštího jednání Rady základních registrů, která se má konat 26.4.2018 upřesnit, zda i za této nejisté situace je termín přechodu na TLS 1.2 k 1.8.2018 stále platný.

Aktualizace 27.3.2018

Konečně známe příčinu, proč rozumně nefunguje ISZR po přechodu na TLS 1.2 (aktuálně na testovacím prostředí, které má být už v konečné konfiguraci).

Problém je v tom, že jejich SSL terminace neumí zpracovat signaturu založenou na RSA_SHA256 a vyšší (byť ji při handshake jejich server nabízí), ale pouze RSA_SHA1. Takže z novějších systémů (např. Windows 10), které již RSA_SHA256 standardně používají, si neškrtnete (pozn.: novější asi není to správné slovo, Windows 10 jsou již 2,5 roku). Z Windows 7, které používají standardně RSA_SHA1, to funguje. Ale opravdu chce ISZR přecházet na TLS 1.2 a používat RSA_SHA1? Navíc RSA_SHA256 při SSL handshake nabízejí, ale neumí a Windows 10 nejdou pak přinutit používat RSA_SHA1. 



Komunikace z Windows 7:

Komunikace z Windows 10:




Pokud tohle půjde na produkční ISZR, tak tím odříznou minimálně systémy pracující na Windows 10 nebo Server 2016 R2. 

Přechod na TLS 1.2 se začal řešit loni v říjnu a stále nefunguje.

Aktualizace 7.3.2018

Podařilo se nám spolu s ROS prosadit, že se zruší RC4 a DES, takže tohle by údajně měla být konečně konečná definitivní a finální verze:
Má to jednu vadu - pořád to nefunguje:
System.ServiceModel.Security.SecurityNegotiationException: Nelze vytvořit zabezpečený kanál pro režim SSL/TLS s autoritou pub.egon.cms. ---> System.Net.WebException: Požadavek byl přerušen

Pátráme dál. Více informací o vypnutí TLS 1.0 a 1.1 si můžete přečíst na webu SZR. 

Aktualizace 5.2.2018

Na provozní poradě SZR byl (zcela vážně) prezentován návrh, že problém bude "vyřešen" tak, že se povolí cipher suite TLS_RSA_WITH_RC4_128_SHA. Spolu se zástupci ROS jsme se snažili protestovat, ale asi to nebude moc platné.

Aktualizace 30.11.2017

Na provozní poradě SZR nám bylo sdělena zásadní informace, že přechod na TLS 1.2 a nové Cipher Suite se v plánovaném termínu neuskuteční.
Dodavatel (AutoCont) nejprve opraví chyby, aby bylo prostředí v souladu s dokumentem, pak bude následovat nové testování a pak teprve někdy později v roce 2018 (zatím odhad březen) dojde k přechodu na TLS 1.2 a vypnutí starších verzí.

Aktualizace 9.11.2017

SZR (resp. Autocont) dnes udělalo nějaké změny, takže se na pub.egon.cms lze dostat přes TLS 1.2 s TLS_RSA_WITH_AES_128_CBC_SHA. Bohužel ale stále stav nesouhlasí s popisem, protože je například povolen Cipher Suite TLS_DHE_RSA_WITH_AES_256_GMC_SHA384, který by být povolen neměl.

Aktualizace 1.11.2017

Podařilo se nám získat neoficiální vyjádření (není od SZR):

O níže popsaných problémech při komunikaci s ISZR u některých připojených AISů víme a snažíme se je řešit. V současné době pracujeme na řešení, které problémy odstraní. Nápravné opatření však zahrnuje rizikové činnosti jak na testovacím, tak na produkčním prostředí. Tyto rizikové činnosti nám však SZR zatím nepovolilo. Se SZR jednáme o termínech.

Z toho a dřívejších zjištění plynou dvě základní věci:
  • prostředí EGON-4 (https://egon.gov.cz, https://pub.egon.cms) a EGON-5 (https://edit.egon.gov.cz, https://edit.egon.cms) neodpovídají stavu podle  Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1 a podporují pouze Cipher Suite s RC4, který je ale dle dokumentu zakázán a naopak nepodporují Cipher Suite s AES, které by měly být povoleny a podporovány,
  • pokud jste si podle výše uvedeného dokumentu otestovali změnu na TLS 1.2, která má být v produkci od 1.1.2018, tak jste neotestovali vůbec nic a paradoxně, pokud vám testy prošly, tak zřejmě s RC4, což je špatně,
  • vnitro o problémů ví, ale na odbornou veřejnost, vývojáře a provozovatele AIS zvysoka dlabe a neobtěžuje se upozornit na to, že testování, o kterém píší, je zcela bezzubé a zavádějící,
  • vůbec nemáme jistotu, jak skutečně bude produkční prostředí po 1.1.2018 z hlediska podporovaných Cipher Suite vypadat a zda budeme fungovat.
Zatím stále čekáme na oficiální vyjádření vnitra, resp. SZR na náš záznam v helpdesku ID 28313.

Aktualizace 31.10.2017

Problém jsme zapsali do helpdesku SZR pod ID 28313. Již dříve jsme zapsali problémy ID 27025 a 27786, ale oba byly uzavřeny následujícím způsobem, v přímém rozporu s Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1 (Cipher Suite s RC4 tam není povolen):

Status: 08-VYŘEŠEN, Dobrý den jako dočasné řešení nastavte šifrování TLS_RSA_WITH_RC4_128_SHA na úrovni klienta. IE 10 používá protokkoly, které splňují podmínky nastaveni 128 bit šifrování.

Status: 08-VYŘEŠEN, Dobrý den, rozhodně je třeba používat pouze IE. FF 50 a vyšší ani ostatní nepodporují RC4. V odkazu je postup aktivace požadovaného šifrování v IE.


Původní text

Správa základních registrů (SZR) zveřejnila dokument s názvem Oznámení o vypnutí protokolů TLS 1.0 a TLS 1.1, ve kterém od 1.1.2018 oznámila vypnutí protokolů TLS 1.0 a TLS 1.1. Podporovaný bude pouze protokol TLS 1.2 a následující Cipher Suite (CS):

  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256

Protože jsou naše systémy na ISZR napojené, tak jsem začal upravovat konfigurace a aplikace. Podle popisu SZR má být na testovacím prostředí změna provedena a je tedy možné odladit systémy:

"V období od 1. 8. 2017 do 31. 12. 2017 otestujte v testovacím prostředí, že váš AIS bezproblémově komunikuje s ISZR i s takto změněným nastavením kryptografických protokolů."

Dva dny jsem se snažil rozchodit připojení na testovací prostředí (pub.egon.cms), ale marně. Neustále jsem končil na chybě, že se nepodařilo sestavit bezpečné spojení. Měl jsem podezření, že mám něco špatně nakonfigurované a aplikace nejede přes TLS 1.2 nebo podporované CS. Klesl jsem až tak hluboko, že jsem sáhl po Microsoft Message Analyzer (něco jako Wireshark) a monitoroval jsem TCP komunikaci. Ověřil jsem, že nabízím podporované protokoly:


Podle odpovědi serveru jsem usoudil, že akceptuje CS TLS_RSA_WITH_AES_128_CBC_SHA:

Vše vypadalo OK, ale spojení stále padalo. Po dvou dnech kolega zkusil aplikaci na jiném, starém stroji, kde je ještě Windows 2008 (ani to není R2). K mému překvapení aplikace fungovala. Tak jsem opět hledal v TCP a zjistil jsem, že spojení jede s CS TLS_RSA_WITH_RC4_128_SHA:

Problém je v tom, že TLS_RSA_WITH_RC4_128_SHA podle dokumentu SZR nemá být podporován a také, že od 1.1.2018 nebude podporován na produkčním prostředí:
Částečně tento stav potvrzuje i fakt, že helpdesk SZR mému kolegovi, který řešil spojení z Internet Exploreru na testovací prostředí (chtěl získat WSDL), odpověděl, že si musí povolit RC4.

Z toho plyne, zřejmě testovací prostředí ISZR neodpovídá tomu, co je v dokumentu uvedeno. Pokud jste si podle pokynů SZR vaše systémy otestovali proti testovacímu prostředí, tak to ještě neznamená, že vám od 1.1.2018 budou fungovat. Vypadá to, že testovací prostředí má nějaký problém s CS jako TLS_RSA_WITH_AES_128_CBC_SHA a funguje jen s CS založenými na RC4, což je přesně opak toho, v jakém stavu by to mělo být. 

Jestli proti jejich testovacímu prostředí ISZR fungujete, nenechte se tím ukolébat a prověřte, že nepoužíváte CS na RC4, ale nějaký CS uvedený v tom dokumentu, jinak od 1.1.2018 nemusíte fungovat (pokud RC4 vypnou a nevyřeší se pravděpodobný problém s neakceptací jiných CS).

Budu to řešit přes Helpdesk SZR a dám vědět, jak to dopadlo. Problém samozřejmě může být na mé straně. Je to zvláštní. Pochopil bych, že jen vypnuli TLS 1.0 1.1, zapnuli TLS 1.2 a zapomněli odstranit RC4. Ale to, že zřejmě neakceptují např. TLS_RSA_WITH_AES_128_CBC_SHA je podivné, i v souvislosti s tím, co je na druhém obrázku, kdy mi jejich serveru odpoví, že je to OK a přesto se spojení nenaváže (zkoušeno z více strojů bez podpory RC4). 

PS: Má aplikace (založena na .NET 4.7), se kterou to zkouším, je OK, protože na produkčním prostředí s TLS 1.0 jede bez problémů. Problém se objeví pouze tehdy, pokud jdu na testovací prostředí, zapnu natvrdo TLS 1.2 a zakážu všechny CS na RC4.