Video 2014-06-18T14:00:00¶

• opravit indexy (#1450)
• mongo hlásí krátký průběh dotazu, ale webové rozhraní ale laguje (zřejmě patří také hlavně do #1450)
  • chyba v driveru monga pro perl?
  • postupné nebo kompletní vyčítání výsledků?
  • změní výkon pokud si řekneme jen o sloupce, které chceme, vs když čteme celé zprávy
  • ... i přestože máme limit 30 ???
  • nějaký mangling nebo vytváření objektů v perlovém driveru? nejspíš ne
  • -> vyzkoušet samostatným perlovým skriptem, bez vlivu naší abstrakční vrstvy
• zvednout prozatím timeout na selektory (#1638)
  • až vyřešíme nesrovnalost v délce trvání dotazu, zaměříme se na to:
    • který z dotazů to dělá? distinct vs bez distinct?

• zvednout timeout db
• přidat měření až kolem samotného volání monga, nejen nad abstrakční vrstvou

• vyrobit tiket na zápisy (#1658)

Video 2014-06-24T14:00¶

• nevíme, zda je dotaz z mongo shellu výkonnější, náš pokus nebyl, Radek ale měl pocit, že ano, bude chtít vyzkoušet
• dotaz, který vrací jednotky výsledků, je překvapivě hodně ovlivněn použitím limitu, skipu, sortu. Mongo nebo něco nad ním přidává vždy při jejich použití nějaký overhead
• find_msg přidává cca 5 vteřin overhead (zřejmě díky xml knihovně)
• explain a získání počtu přidává také několik vteřin

• explain jen když je povolená konzole

• Platí předchozí, tj. zjistit najít úzká místa, nebo identifikovat, že je nemáme a víc už nevyřešíme (Mongo hlásí krátký průběh dotazu, ale webové rozhraní ale laguje (zřejmě patří také hlavně do #1450))
  • chyba v driveru monga pro perl?
    • srovnání find.sort.limit.skip s run_command a mongo shellem
  • postupné nebo kompletní vyčítání výsledků? (asi cursor->next vs cursor->all)
  • změní výkon pokud si řekneme jen o sloupce, které chceme, vs když čteme celé zprávy
  • nějaký mangling nebo vytváření objektů v perlovém driveru? nejspíš ne
  • vyzkoušet samostatným perlovým skriptem, bez vlivu naší abstrakční vrstvy

Další schůzka: problém dovolených a služebek, v týdnu od 14. července se domluvíme

Domluva z 2014-07-14T13:56¶

Radek frčí podle předchozího zápisu (viz také jabberová domluva s Mekem), ve středu 23. 7. pošle shrnutí, na co přišel, další domluvíme offline kanály nebo se podle potřeby sejdeme v pátek 25. 7. na videu.

Poté další VC v úterý 5. 8. v 10:00 (v Praze malá zasedačka).

Změna termínu VC tedy na čtvrtek 7. 8. 10:00. Dnes ale nefunguje rezervační systém, pokud by mě někdo předběhl rezervováním všech zasedaček, až se rozběhne, ozvu se a domluvíme se znovu operativně.

V Praze velká zasedačka, schůzka tedy platí.

• lim 30, skip 0, count 1000: count + index dělá rozdíl 23 s, samotný count 20 s, s náročností dotazu roste, ale ne nad minutu
• lim 1000, 50k výsledků, drasticky horší, mentat storage 389 s vs ostatní cca 1-2 s
  • bez limitu a indexů srovnatelné s ostatními metodami
  • roste s počtem dostupných výsledků
  • Mek: vyzkoušet pager bez countu či zjišťování countu až po fetchi, zobrazování indexů jen s debug toolbarem
• lim 10000: chyba "getMore runner error: Overflow sort stage buffered data usage"
  • https://jira.mongodb.org/browse/SERVER-14299
  • zřejmě opraveno v 2.7.4, my máme 2.6.3
  • reporter vyčítá půl mega, bez sortu, neměl by narazit, v hawatovi limitujeme na 30, neměl by narazit, tj. netrápí nás, počkáme si na verzi s opravou
• Radek pošle Mekovi skript pro replikaci chyby, Mek zhodnotí, zda by to nešlo odchytit a třeba vyrobit relativně standardní výjimku
• cursor_next vs cursor_all * malé limity - zanedbatelné * velké limity - cursor_all lepší, dává smysl
• Radek - celé zprávy vs jen sloupce * tj. celá zpráva vs detected, source, destination, classification * hlavně u dotazů které nás bolí, tj. několikaminutové (byť s malým limitem)
• Radek - možnosti optimalizace conf parametrů Monga pro jednu instanci
• Radek - zbývá ještě něco v #1450 (případně #1658)?

• všichni - k příští diskusi: čím se zabývat dál a proč?
  • dashboard?
  • optimalizace Monga?
    • dala by se optimalizovat jedna instance?
    • více shardů?
    • více instancí skriptů najednou
    • obecně zatížení db při vícenásobném přístupu

Video 20014-08-19T10:00¶

• Mek: vyzkoušet pager bez countu či zjišťování countu až po fetchi, zobrazování indexů jen s debug toolbarem (pracuje na tom, není jednoduché to dostat do spodních vrstev)
• Radek pošle Mekovi skript pro replikaci chyby DONE, Mek zhodnotí, zda by to nešlo odchytit a třeba vyrobit relativně standardní výjimku
• Radek - celé zprávy vs jen sloupce
  • tj. celá zpráva vs detected, source, destination, classification
  • hlavně u dotazů které nás bolí, tj. několikaminutové (byť s malým limitem)
  • viz #1450, příspěvek 32: bez omezení vs bez idmef vs jen sloupce pro Alerts - 6.16 vs 5.41 vs 3.33 na 100k zpráv, mělo by tedy smysl pro Reporter, pro Alerts ne. Zvážíme u Reporteru po přechodu na Ideu.
  • Pozor: Radek zjistil, že v projekci je možné použít jen jeden atribut typu pole, což může být problém.
• Optimalizace Monga
  • noatime
  • timeout flushe doporučují pro hot data 300ms
  • vypnout profiling
  • Radek po několika testech nenarazil na rozdíly
  • projekce využívá jen jeden procesor
  • Hawat precache - mongostat hlásí hodně pagefaults
• Radek vyzkouší sharding, hlavně na skriptu pro prekešování detektorů, což je select distinct + banda malých selektů, které vytikávají. Pokud se projeví tam, je šance, že to bude mít význam i u dashboardu a pokusu přepsat to z agregačního frameworku na selecty
• ph najde příklady z 10gen kursu a pošle Radkovi, je možné, že tam byl setup shardů na jedné mašině
• další schůzka úterý 26. 8. 10:00

Video 2014-08-28T10:00¶

• Mek odhadne abychom se dostali cca na 20-25%, minimum 6, pomůže compact?
• Pokud nepomůže, naplánujeme repair s externím úložištěm a pak si musíme hlídat růst db souboru (a průběžně mazat).
• Poznámka po Idee: uchovávání orig zpráv omezenou dobu (1-3 měsíce) a jinde (na disku), k ukládání máme vlastně pouze ladící důvody.

• Vyzkoušeno:
  • 4 instance, config, mongos, 2 shardy
  • shardkey - detect time/class/analyzer id/analyzer name
  • Mizivé rozdíly 2shardu proti singlu, shard lehce horší
• Radek
  • konverze singlu na shard, dynamické přidávání/ubírání shardů bez dlouhých importů
  • zkusit zjistit rebalance
  • bylo by fajn vyzkoušet na 2, 4, 6, 12
  • (teď na mentat-dev 2 mil záznamů zabírají 12G na každý shard)

Další schůzka ve středu 3. 9., 10:00, v Praze VZ.

Video 2014-09-23T10:00¶

Zjistil jsem, že jsem nezapsal zápis, tedy opožděně napravuji.

• místo na disku?
• Sharding
  • při přidávání kolekce do shardu je potřeba mít existující indexy pro shardovací klíč
  • rebalance - v okně se balancuje samo, bez okna kdykoliv
    • je možné použít movechunk, ale to je explicitní vyvolání přesunu na konkrétní cíl
• Radek
  • rychlý test repair shardované db, ať víme, zda mongo pustí alokované místo
  • jiný shardovací klíč?
  • shardy na více mašinách?
  • test na větších datech (mentat-dev) oněch vhodných násobků
  • vytipovat a zkusit jiný cpu-bound dotaz (než jen selektory)
  • co replikace, nepomohla by?

Další schůzka pondělí 29. 9. 10:00.

• otestovat podobně i replikaci, zda by nepomohla (ph: zkusit se podívat po skriptech na setup lokální replikace)
• test na rychlých discích (SSD)
• V budoucnu:
  • v současné době generování selektorů na ostrém nedoběhne, bude potřeba řešit, inkrementy přes cog nebo přes cron?

• Hotovo:
  • Validátor, Mek napsal vlastní na JSON Schema
  • Reporter - oprava DNS, pořád synchroní
  • Async: při příjmu zprávy, až bude Idea
  • Stránka Events - popis událostí pro uživatele
  • promazávání starých událostí z db
  • přílohy reportů na disku
  • posun devel módu do nižších vrstev abstrakce (možnost nevypisovat některé věci, jen role developer má stránkovač s počtem a explain, etc.)
  • templaty zpráv v JSONu i s metadaty pro reporter a poznámkami, vše na jednom místě
• Úkoly (plán přechodu na IDEA cca do konce roku)
  • Rowanetu (Kraj Vysočina, AS 48091) bude Cesnet dělat handling dat z externích zdrojů
    • doplnění lokálních abuse informací (nejen z Negistry) - dočasně, dokud ph a spol. nedostanou do Negistry
    • možnost změny master šablony per abuse@
  • konvertor idmef/idea
  • přechod na IDEA
    • (postup: konvertor, šablony, reporter, gui zobrazuje IDEA, kromě dashboardu)
• Průběžně, příležitostně:
  • cache A/A v session
  • statistiky - zhruba jako PV pro Andreu
  • agregace/stats pro ukládání před smazáním
  • lepší dokumentace šablon, aby to mohli dělat i jiní
  • lepší kontroly průběhu reportování
  • změna šablon na keywordové argumenty
  • hawat_cli + mentat-controller, práce s jednotlivými démony
  • konfigurace JSON#
  • inflate/deflate reportů

Další schůzka 6. 10. 14:00 velká

Video 2014-10-06T14:00¶

Radek

• test na rychlých discích
  • hawat-precache na mentat-dev 18s vs 7s na mentat.vsb
  • Mongodb.pl 1m5s vs 45s
  • (na 32G dat, 2mil událostí)
  • Radkův závěr: na mentat.cesnet.cz jsme tak rychlí, jak můžeme být
  • nespěcháme tedy na nové disky, s novým železem bude stát za zvážení

• replikace
  • ./Mongodb.pl: 0m55.935s vs 1m4.756s
  • ./hawat-precache: 0m4.592s vs 0m5.149s

• Replikace vypadá zajímavě. Co dál:
  • otestovat ještě na větších datech
  • otestovat na jednom stroji (rozložení na víc procesorů)

• Rowanet
  • editovatelné výjimky ("podsítě s vlastním miniabusem") budou součástí skupiny, tím pádem nebude třeba koukat do JSON whois dat, ale jen z nich updatovat skupiny
  • možnost změny master šablony per abuse@
• konvertor idmef/idea
• přechod na IDEA (postup: konvertor, šablony, reporter, gui zobrazuje IDEA, kromě dashboardu)

Příští schůzka na semináři 707+709 20.-21. 10.

Schůzka ve Vranovské vsi 2014-10-21T11:35:00

• kešování výběrů
  • distinct - bez podnímky je snappy, s query je pomalý
  • zkusit přehodit složený index @analyzerid+@name, zda to nepomůže
  • pokud ne, tak Radkova vtipná metoda s county -> výsledek do ostrého kódu

• SSD disky: cachování výběrů – žádné zrychlení; ale sada testovacích dotazů na 22M eventů - zrychlení o polovinu (16G paměti)
  • platí z minulé schůzky - na ostrém mentatu habakuk ramky, takže nemáme jistotu, nakolik by SSD pomohly, ale vedeme v patrnosti pro další upgrady železa

• replikace na velkých datech (22M eventů) a na strojích na různých sítítch - téměř žádný rozdíl
  • otestovat ještě na jednom stroji s rozložením na víc procesorů)

Další schůzka 31. 10. v 9:30 (před cvičením na polygonu, které začne v 10:00)

Mailová komunikace 2014-10-31

• kešování výběrů - distinct bez podnímky je snappy, s query je pomalý
  • přehození složeného indexu @analyzerid+@name nepomohlo
  • Radkova vtipná metoda s county je v kódu a nasazená, bude potřeba ještě doupravit pro korektní použití našeho Mongo API

• replikace na velkých datech (6321966 záznamů)
  • nepomáhá, ani na jednom stroji není znatelný rozdíl

Další schůzku ještě domluvíme, zamyslete se nad dalším pokračováním, hlavně pro Radka. Sharding a replikaci vidím jako dokončenou, takže hodíme brainstorming kudy, co a kam dál.

2014-11-05 Live pokec s Mekem - data od Jakuba Šafaříka a pro Vaška Bartoše¶

Vašek bude potřebovat klienta i server (ale zřejmě ne Hawat), chce se hrabat ve vlastním Mongu, ale nelíbí se mu IDMEF, ještě se s ním domluvíme

• dohodli jsme se, že Mek upraví překladovou tabulku na dočasný atribut, ať lze nové uživatele komplet odmanagovat z rozhraní
• máme rozhraní k editaci šablon, bylo by rozumné, aby se klient updatovali sami
  • buď rychlé řešení - Hawat vygeneruje soubor na disku, na URL vyřazeném z Catalystu, autentizovaném na certifikát klientů Mentatu
    • (časem je možné přešamonit na korektní URL online spravované a generované Hawatem/Catalystem)
  • nebo odložíme do úkolu na později (po Idee) s tím, že Jakub bude mít víc práce se synchronizací šablon
• nezapomenout jeho klienty vyřadit z rozesílání reportů, než se usadí data

Narazili jsme na nekonzistenci ve zpracování abuse, resp. rozesílání reportů - hlavní abuse+grid by měly odejít oběma, ale už ne abuse LIRa (např. 195.113/16), je tedy potřeba rozlišit bloky LIRa a přidělené bloky. Mek vyrobí nový úkol (na později - po Idee).

A ještě zapomenutá poznámka - Dan Kouřil/Michal Procházka by rádi nějaký ACK na přijímané mailové reporty, aby jim nechodily, pokud se jimi zabývají. Meku, vyrob pls opět úkol na později, někdy se o tom pobavíme (nese řadu nejasností jak se chovat ke granularitě reportů, jejich archivování apod.), a odepiš jim něco ve smyslu, že takovou funkcionalitu nemáme, nese to s sebou právě řadu nuancí k vyřešení (a možností, kde něco rozbít) a holt teď máme vyšší priority.

VC 2014-12-12T10:00 - Šablony pro Ideu¶

• Poodle - zbytečně hromada strukturovaných dat, stačí nějak smysluplně naskládat do poznámky (Note by mělo být čitelné člověkem)
• Bylo by fajn kde to jde přidat CVE
• Pro třídění reportů Mek přidá vlastní lokální větev _CESNET_.CamelCase, do ní nějaký klíč, kam strčí jméno šablony (macro, anyone? )
• V Compromised CMS Report je pořád problém s češtinou
• Vulnerable.Open - ano, je to zranitelnost
• ph: zvážit přidání Vulnerable.Config - např. backscatter, kde jsme netestovali my, tudíž nevíme, zda je to skutečně otevřené; ale jen víme, že je to blbě
• je potřeba přidat i Node
  • SW z IDMEF Alert/Analyzer/@name, Tags má být Type, a z @class (u Wardenu nejspíš nemá @class význam)
• Source.Note: "HTTP method: POST"
• Aby protokol dával smysl, měl by být i u Source i u Dest
• Warden - IPv4 a IPv6 v jednom poli, IDEA různá pole. Mek vytvoří(l ) makro pro automatické zvolení správného klíče
• http versus http-www - v současné době máme zřejmě jen "http", u XSS, resp. u zranitelností, které se týkají CSS, JS a obecně obsahu stránky by možná bylo korektní "http-www" (viz http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http)
• Protokol - pokud známe jen číslo, bude potřeba přeložit na text (makro? Ale zatím ten problém zřejmě nemáme), pokud máme i číslo i text, číslo zahodíme
• Logline do Attach
• DDoS - může být pro zdroj i cíl; o co jde je zřejmé z toho, že existuje Source a/nebo Target
• Nevíme-li, která z kategorií Malware.* to je, použijeme jen Malware
• ph: warden-webattack - Attempt.? (zkouknout o co vlastně jde a zvážit)
• Další schůzka středa 7. 12. 14:00 platí, v Praze malá zasedačka

VC 2014-12-19T10:00 - Šablony pro Ideu¶

• tagy (type) CamelCasem, protokoly podle spec (tj. minusky)
• makro pro IPv4 vs IPv6 do všech src/target, bude to robustnější
• n6-029 (Zeus) - Botnet+Malware; Botnet+CC

• Diskuse na téma Source/Target - leckdo může chápat zdroj/cíl jako zdroj a cíl komunikace, my ale nepopisujeme komunikaci, zdroj je zdroj problému, cíl je cíl či oběť poškození, takže ve zprávě mohou být i dva zdroje, přestože komunikace putovala z jednoho na druhý, protože jsou oba členy botnetu
  • ph - bude potřeba lépa zdokumentovat Source/Target v Idee
  • Mek - totéž v popiscích v Mentatu
  • "Problem source" - variace: "Troublemaker", "Harm origin"
  • Další možnost je vrátit sémantiku k popisu "spojení", ale pak je třeba dostat informaci o tom, kdo je dobrý a kdo špatný někam jinam, např. do tagů ("Victim")
  • Další možnost je přidat popis spojení, např. ConnectionInitiator=id, ConnectionReceiver=id
• ph - zdůraznit pořadí protokolů (ISO-OSI)

• Radek také zapracoval hromadu poznámek z mailů

• Poodle - zbytečně hromada strukturovaných dat, stačí nějak smysluplně naskládat do poznámky (Note by mělo být čitelné člověkem)
• Bylo by fajn kde to jde přidat CVE
• Pro třídění reportů Mek přidá vlastní lokální větev _CESNET_.CamelCase, do ní nějaký klíč, kam strčí jméno šablony (macro, anyone? )
• V Compromised CMS Report je pořád problém s češtinou
• Vulnerable.Open - ano, je to zranitelnost
• přidáme Vulnerable.Config (ph přidá do taxonomie)
• je potřeba přidat i Node
• Source.Note: "HTTP method: POST"
• Aby protokol dával smysl, měl by být i u Source i u Dest
• Warden - IPv4 a IPv6 v jednom poli, IDEA různá pole. Mek vytvoří(l ) makro pro automatické zvolení správného klíče
• http versus http-www - v současné době máme zřejmě jen "http", u XSS, resp. u zranitelností, které se týkají CSS, JS a obecně obsahu stránky by možná bylo korektní "http-www" (viz http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http)
• Protokol - pokud známe jen číslo, bude potřeba přeložit na text (makro? Ale zatím ten problém zřejmě nemáme), pokud máme i číslo i text, číslo zahodíme
• Logline do Attach
• DDoS - může být pro zdroj i cíl; o co jde je zřejmé z toho, že existuje Source a/nebo Target
• Nevíme-li, která z kategorií Malware.* to je, použijeme jen Malware
• ph: warden-webattack - Attempt.? (zkouknout o co vlastně jde a zvážit)

• Další schůzka pátek 9. 1. 2015 10:00 platí, v Praze malá zasedačka

VC 2014-01-09T10:00 - Šablony pro Ideu¶

• Vulnerable.Open vs Vulnerable.Config
  • Open - řešitelné patchem
  • Config - řešitelné konfigurací
  • návrh jak to popsat do klasifikace
• Doplnit Node.Tag podle https://csirt.cesnet.cz/IDEA/Classifications#NodeTag
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• další poznamenan(é/á) CVE?
• Doplnit Node/Software
• sql -> ms-sql, mysql, etc.

• tagy (Category a všechny Type) CamelCasem, protokoly podle spec (tj. minusky)
• makro pro IPv4 vs IPv6 do všech src/target, bude to robustnější
• n6-029 (Zeus) - Botnet+Malware; Botnet+CC
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)

• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)
• Pro třídění reportů Mek přidá vlastní lokální větev _CESNET_.CamelCase, do ní nějaký klíč, kam strčí jméno šablony (macro, anyone? )
• Source.Note: "HTTP method: POST"
• Aby protokol dával smysl, měl by být i u Source i u Dest
• Logline do Attach

• CVE - nevíme, zda je rozumné přidávat:
  • n6-013
    • https://csirt.cesnet.cz/Slu%C5%BEby/N6
    • http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks/
    • je rozumné přidat CVE-2013-5211 ???
• Protokol - pokud známe jen číslo, bude potřeba přeložit na text (makro? Ale zatím ten problém zřejmě nemáme), pokud máme i číslo i text, číslo zahodíme
• DDoS - může být pro zdroj i cíl; o co jde je zřejmé z toho, že existuje Source a/nebo Target
• Nevíme-li, která z kategorií Malware.* to je, použijeme jen Malware
• http versus http-www - v současné době máme zřejmě jen "http", u XSS, resp. u zranitelností, které se týkají CSS, JS a obecně obsahu stránky by možná bylo korektní "http-www" (viz http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http)

• Další schůzka pátek 16. 1. 2015 10:15, v Praze malá zasedačka

VC 2015-01-20T10:15¶

• Vulnerable.Open vs Vulnerable.Config - upravit tedy v šablonách, kde je potřeba
  • Open - řešitelné patchem
  • Config - řešitelné konfigurací
  • návrh jak to popsat do klasifikace
  • ph zakomponovat do Idey
• Doplnit Node.Tag podle https://csirt.cesnet.cz/IDEA/Classifications#NodeTag
  • Doladit drobnosti, na kterých jsme se domluvili
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• další poznamenan(é/á) CVE?
• tagy (Category a všechny Type) CamelCasem, protokoly podle spec (tj. minusky)
• makro pro IPv4 vs IPv6 do všech src/target, bude to robustnější
• n6-029 (Zeus) - Botnet+Malware; Botnet+CC
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)
• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)
• Pro třídění reportů Mek přidá vlastní lokální větev _CESNET_.CamelCase, do ní nějaký klíč, kam strčí jméno šablony (macro, anyone? )

• Konverze dashboardu na Ideu (Radek)
  • jedná se o přípravu nové verze dashboardu, která ale bude pracovat s Ideou v db místo IDMEFu
  • NE na ostrém, ale např. na mentat-dev
  • bude na to potřeba si vygenerovat Handymanem do db pár testovacích Idea zpráv
  • bylo by fajn na tom pracovat, resp. commitovat, do vedlejší větve v GITu, která se mergne do hlavního kódu až zavelíme včul

• Další schůzka pátek 30. 1. 2015 14:00, v Praze malá zasedačka

VC 2015-01-30t14:00¶

• Vulnerable.Open vs Vulnerable.Config - upravit tedy v šablonách, kde je potřeba
• Doladit drobnosti, na kterých jsme se domluvili
• n6-029 (Zeus) - Botnet+Malware; Botnet+CC
  Tímto bereme šablony za finální, další se odladí při běhu, Radku, díky za odvedenou práci!

• ph zakomponovat Vulnerable.* do Idey (Open - řešitelné patchem, Config - řešitelné konfigurací)
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)
• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)
• Pro třídění reportů Mek přidá vlastní lokální větev _CESNET_.CamelCase, do ní nějaký klíč, kam strčí jméno šablony (macro, anyone? )
  • Poznámka: úpravy spec Idey čekají na přesun webu csirt.cesnet.cz Vláďou Třeštíkem na DokuWiki - už je zkonvertovaný obsah, ale ještě není vypublikovaný a musel bych to pak měnit znovu

• Konverze dashboardu na Ideu (Radek)
  • (jedná se o přípravu nové verze dashboardu, která ale bude pracovat s Ideou v db místo IDMEFu)
  • úpravy práce s poli
  • Classification odpovídá v Idee Category (vhodné změnit i v popiscích na webu)
  • Detector -> Node.Name
  • bude potřeba upravit indexy

• Konverze Alerts
  • Mek:
  • upraví saved queries (aby si Radek mohl ukládat testovací dotazy)
  • přejmenuje základní indexy
  • a bude pokračovat v další Ideové práci (detektory a otestování šablon v nich, reporter, atd.)
  • Radek:
  • po saved queries se pustí do konverze případně prozkoumání (ne)možností indexů nad Ideou

• Poznámky na později:
  • možná se bude hodit prohledávat informace z Description v Idee, v Idmefu nahrazovaly Category - ale pak bychom se měli zamyslet nad fulltextem
  • v Alerts by se možná hodil další výběrový box na SW - zatím ale převedeme 1:1, tj. node.name/node.sw

• Další schůzka čtvrtek 5. 2. 2015 15:00, v Praze malá zasedačka

VC 2015-02-15¶

• ph zakomponovat Vulnerable.* do Idey (Open - řešitelné patchem, Config - řešitelné konfigurací)
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)
• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)
  • Poznámka: úpravy spec Idey čekají na přesun webu csirt.cesnet.cz Vláďou Třeštíkem na DokuWiki - už je zkonvertovaný obsah, ale ještě není vypublikovaný a musel bych to pak měnit znovu

• Konverze dashboardu na Ideu (Radek)
  • (jedná se o přípravu nové verze dashboardu, která ale bude pracovat s Ideou v db místo IDMEFu)
  • úpravy práce s poli
  • Classification odpovídá v Idee Category (vhodné změnit i v popiscích na webu)
  • Detector -> Node.Name
  • bude potřeba upravit indexy

• Konverze Alerts
  • Mek:
  • upraví saved queries (aby si Radek mohl ukládat testovací dotazy)
  • přejmenuje základní indexy
  • a bude pokračovat v další Ideové práci (detektory a otestování šablon v nich, reporter, atd.)
  • Radek:
  • po saved queries se pustí do konverze případně prozkoumání (ne)možností indexů nad Ideou

• v 2.6 chyba https://jira.mongodb.org/browse/SERVER-14636 ("planError" : "InternalError No plan available to provide stats")
• Speciální indexy nepomáhají (spíš naopak), indexy přes pole nemohou být multi. Závěr: zůstaneme tedy u základních indexů, ukládat si dotazy, kde bude problém s výkonem, budeme řešit.

• Mek: styl dashboardu, chybějící grafy?
• Mek: styl, zkusit vypnout pevnou hlavičku/patičku, třeba kalendář nebude mizet mimo
• Mek: Useless use of private variable in void context at /home/mentat/mentat/www/hawat/script/../lib/Hawat/Model/Groups.pm line 1416.
• Mek: Catalyst - defaultní logování ještě před konfigurací?

• Radek: vyzkoušení mapování ntpstampu do 64 integeru (problém, že dashboard používá insert time místo DetectTime)

• Radek: Paralelní test (simulace víc uživatelů)
• Radek: Mongo 3, hlavně WiredTiger (také ve spojitosti s tím, že 2.7 na cca 30 minutách 8 minut pomalejší)

• Měli bychom si všichni udělat čas a pokusit se trochu poklikat a zatížit to dotazy

• Další schůzka pátek 27. 2. 2015 13:00, v Praze velká zasedačka

VC 2015-03-04 14:00¶

• Mek: styl dashboardu, chybějící grafy?
• Mek: styl, zkusit vypnout pevnou hlavičku/patičku, třeba kalendář nebude mizet mimo (hotovo, uvidíme, jak to bude vypadat)
• Mek: Useless use of private variable in void context at /home/mentat/mentat/www/hawat/script/../lib/Hawat/Model/Groups.pm line 1416. (opraveno)
• Mek: Catalyst - defaultní logování ještě před konfigurací?

• Radek: vyzkoušení mapování ntpstampu do 64 integeru (problém, že dashboard používá insert time místo DetectTime)
  • rozsah znaménkového integeru (Monga) je -2^63 až +2^63-1
  • rozsah neznaménkového integeru (ntpstamp) je 0 až 2^64-1
  • převodní funkce musí převést textový čas na ntpstamp a ten posunout do rozsahu znaménkového integeru, tak, aby nula byla na -2^63 - tj. 2^63 odečíst
  • zpětná funkce musí 2^63 přičíst, tím získá ntpstamp, a převést na textový čas
  • abychom věděli, že převádíme korektně na monotónní posloupnost, je potřeba otestovat relace mezi textovými časy, které se zkonverují na čísla u hraničních hodnot, tj. v Mongu to budou čísla blízko -2^63 (tj. ntpstamp u nuly), čísla nad a pod nulou (tj. ntpstamp kolem půlky rozsahu) a blízko 2^63-1 (tj. ntpstamp blízko 2^64-1)

• Radek: Mongo 3, hlavně WiredTiger (také ve spojitosti s tím, že 2.7 na cca 30 minutách 8 minut pomalejší)
  • nalezen pomalý dotaz (category + time), cca 50 sec, 2.6 rozšířené indexy timeoutují, 3.0 také, základní indexy cca 80 sec
  • jiné dotazy zanedbatelný rozdíl mezi 2.6 a 34
• padla úvaha, zda nemůžou hrát roli integerové nebo stringové s malou kardinalitou indexy versus indexy nad binary s proměnlivou délkou
  • tj. při vhodné příležitosti převedeme časy a IPv4 na int, a pokud to bude mít vliv, zvážíme/otestujeme uložení IPv6 jako dvou dlouhých integerů
• Radek: Paralelní test (simulace víc uživatelů)
• Radek: Test při současném zápisu (to by měla být výhoda Wired Tigera)
• Měli bychom si všichni udělat čas a pokusit se trochu poklikat a zatížit to dotazy
• Poznámka k Mongu 3 - Radek narazil na to, že s Wired Tigerem se Hawat tváří, že nemůže najít kolekci groups

• ph zakomponovat Vulnerable.* do Idey (Open - řešitelné patchem, Config - řešitelné konfigurací)
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)
• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)

Další schůzka středa 11. 2. 2015 14:00, v Praze velká zasedačka

Přehled změn za únor 2015 a příprava na schůzku s Andreou 2015-03-05¶

Aktuální verze: commit:d1dd7c07

V průběhu února byly v systému Mentat naimplementovány následující vlastnosti:¶

• Manuální přidání síťového rozsahu pro ROWANET (195.93.216.0 - 195.93.217.255) pro abuse@kr-vysocina.cz, Pavel Vachek už udajně vykomunikoval příjem událostí od ShadowServeru, N6, ..., takže Mentat pro ně již nyní reportuje
• Reimplementace autorizačního mechanismu webového rozhraní, revize přístupových práv ke všem stránkám a akcím webového rozhraní. Byl naimplementován nový mechanismus, který umožňuje jednotnou práci s oprávněními v obou požadovaných režimech (1: může aktuální uživatel přistupovat k této aktuální akci?, 2: může aktuální uživatel přistupovat k dané akci s volitelnými argumenty). První režim zajišťuje automatickou kontrolu oprávnění při přístupu na každou stránku webového rozhraní, druhý režim se používá pro složitější detekci oprávnění (např. přístup ke skupině má admin, manažer skupiny a členové skupiny) a zejména pro skrývání nedostupných prvků webového rozhraní (např. běžný uživatel nevidí administrativní prvky). Veškerá ACL pravidla se nyní konfigurují na jednom místě v hlavním JSON souboru.
• Pro lepší možnost dohledu naimplementován ChangeLog pro webové rozhraní, každá změna objektů je logována (přidání role uživateli, přidání filtru, ...)
• Pro lepší možnost dohledu naimplementován AccessLog pro webové rozhraní, každý přístup je nyní zalogován do databáze
  • AccessLog umožnil implementaci kontroly přečtení reportu. U každého reportu se nyní zobrazuje seznam uživatelů, kteří ho četli, u každého uživatele se zobrazuje seznam přečtených reportů.
• Implementace access control politik pro přístup k reportům. Reporty mohou číst pouze administrátoři, nebo členové dané abuse skupiny.
• K šablonám událostí byl přidán atribut severity
  • Prozatím nastavena výchozí hodnota low pro všechny události, ale PV už má draft klasifikace závažností pro každou událost
• Implementace klikacích filtrů pro abuse skupiny
  • Události vstupující do reportétu je nyní možné filtrovat pomocí klikacích filtrů (analyzer, category, ip), k dispozici je i stromový náhled výsledného filtru.
• Dohled nad průběhem skriptů - script a daemon runlogs
  • Přehled ve webovém rozhraní, kontrola délky běhu, čas posledního běhu, ...
  • Zatím jen několik skriptů, další pořeba dodělat
• Redesign webového rozhraní
  • Vylepšení statistické a grafické knihovny
  • Kompletní změna stylu webového rozhraní
  • Velký úklid pod kapotou webového rozhraní - vyčištění CSS stylů, zabalíčkování komponent webového rozhraní pro jednoduché vícenásobné používání (paginator, side boxy, ...)
  • Tlačítka předchozí/další pro správu uživatelů/skupin/šablon událostí
  • Panel seznamu všech uživatelů/skupin/šablon na příslušné stránce pro rychlejší navigaci
  • Redesign detailu alertu
    • Změna stylu a layoutu, nové prvky
  • Redesign detailu reportu
    • Změna stylu a layoutu
    • Seznam čtenářů
    • Seznam aplikovaných filtrů
    • Grafy pro každý report
  • Redesign procházení šablon událostí
  • Zlepšení prolinkování mezi jednotlivými komponentami webového rozhraní (např. hyperlinkové odkazy ze seznamu/detailu reportu do seznamu detailu alertu a naopak), sjednocení filtračních ikonek
  • Aktualizace fontello ikonkové knihovny
• Naimplementován a spuštěn démon pro obohacování dat. V tuto chvíli démon přidává do namespace _CESNET/ResolvedAbuses seznam abuse kontaktů pro všechny IP adresy obsažené v alertu. Příprava pro lepší práci s relevantními daty, nyní bude možné z databáze jednoduše získávat data, která mají pro nás větší váhu a umožní následující:
  • Implicitní filtrování, uživatelům se při vyhledávání odfiltruje vše, co nepatří pod jejich abuse skupiny
  • Inteligentnější mazání - ponechání mnohem starších relevantních dat, smazání více nepodstatných
  • Informace o konkrétním abuse u každého alertu pravděpodobně konečně umožní lepší konfigurovatelný reporting (něco reportovat jen jednou týdně, měsíčně, ...)
• Větší bugfixy
  • Reporty se neukládaly do DB, pokud proběhlo nějaké filtrování (v tom případě totiž dokument na místě seznamu aplikovaných filtrů obsahoval tečky na místě klíčů a mongo takový dokument odmítne uložit) (zjistil Jirka Ráž)
  • Při exportu IDEA do JSON se čísla ukládála jako string, což neprocházelo validací (zjsitil Pavel Kácha)
• Spousta dalších menších vylepšení a bugfixů

Návrh dalšího postupu:¶

• Dependency checking
• Vylepšení reportéru
  • Změna formátování událostí z dvojice Analyzer:Klasifikace na ID použité šablony
  • Rozšíření šablon událostí o specifikaci, které položky se mají exportovat do přílohy emailu a následná implementace do reportéru
  • Vymyšlení a implementace algoritmu, který umožní posílat hlášení pro konkrétní stroje přímo administrátorovi, kopie půjde na abuse. Jak?
    1. Poslat sumář na abuse, pak zvláštní specifické reporty přímo adminům a na abuse ještě kopii
    2. Poslat specifické reporty adminům, na abuse kopie a navíc vše, co nešlo specificky
    3. Poslat specifické reporty adminům, na abuse sumář všeho (nedává smysl, abuse nebude mít informaci o tom, co řeší konkrétní admini)
• Další vylepšení a sjednocení statistické a grafické knihovny, použití jiné grafické knihovny než GD
• Vylepšení filtrační knihovny
  • Refaktoring a redesign tak, aby umožňovala filtrování libovolných objektů, nejenom Mentat::Message::IDEA
  • Použití vylepšené filtrace všude na webu pro lepší vyhledávání v alertech, reportech, logách, ...
    • V tuto chvíli např. nelze napsat vyhledat všechny zprávy, které daný filtr v konrétním reportu odfiltroval
• Redesign zbytku webového rozhraní (detail skupiny, uživatele, ...)
• Vymyšlení algoritmu pro reportér, který umožní hlášení jednou týdně/měsíčně

Další otázky k prodiskutování¶

• Polish si zažádal o filtraci všech Nemea událostí - nebyli schopni nikde najít důkazy, že se provoz skutečně uskutečnil
• Jiří Ráž by rád v emailu nějak formuloval, že report a příloha obsahují veškerá dostupná data, aby nežádali o více
• Severity, co s ní

Příprava na schůzku s Andreou 2015-03-20¶

Aktuální verze: commit:f25aa3d1

Od posledního zápisu #22 byly v systému Mentat naimplementovány následující nové vlastnosti a provedeny následující práce:¶

1. Redesign webového rozhraní:
   1. Redesign detailu uživatele (/user/view)
   2. Redesign detailu skupiny (/group/view)
   3. Redesign detailu události (/event/view)
   4. Odstranění fixní hlavičky a patičky
   5. Vytvoření prototypu zabudované nápovědy, vytvoření nápovědy k reportovacím filtrům.
   6. Odstranění nepotřebných souborů (obrázky)
   7. Oprava chyby v rozhraní pro tvorbu reportovacích filtrů
2. Zobecnění filtrační knihovny. V předchozí implementaci byla filtrační knihovna úzce spojena s objekty třídy Mentat::Message. Toto bylo naprosto nešťastné řešení, které neumožňovalo její použití pro filtrování/vyhledávání jiných objektů. Konkrétně např. ve webovém rozhraní nebylo možné použít implementovaný filtrační jazyk např. pro vyhledávání reportů, skupin, ... Toto omezení již neplatí, filtrační knihovna umožňuje práci s libovolnými objekty.
3. Implementace jednoduchého nástroje pro dependency checking. Některé Perl knihovny nejsou v Debianu dostupné prostřednictvím připravených deb balíčků. V případě instalace pomocí TAR archivu chybí kontrola přítomnosti nezbytných knihoven úplně. Instalace tedy v tuto chvíli probíhala částečně metodou pokus-omyl, kdy uživatel musel postupovat podle návodu (který může rychle zastarat), systém zkusit spustit a doinstalovat případné návodem opomenuté závislosti ručně. Byl naimplementován mechanismus, který provede kontrolu závislostí a vypíše seznam nedostatků.
4. Polishing klíčových částí sdílených a klientských knihoven, vylepšení dokumentace.
5. Implementována nová vlastnost do Handymana - v případě zapnutí přepínače se automaticky do každé generované zprávy přidá kategorie Test. Tato možnost najde využití při testovacích provozech.
6. Příprava na reportovací algoritmus nové generace. Vytvoření dokumentační wiki stránky, tvorba diagramů a návrh reportovacího algoritmu
7. Odstranění podpory pro IDMEF zprávy. Veškerý kód související s prací se zprávami typu IDMEF byl archivován a odstraněn z hlavního aplikačního kódu i balíčků.
8. Nastavení hodnot severity každému typu události v databázi Mentatu podle návrhu Pavla Vachka (email z 12.3.2015 08:34)
9. Sepsání do této chvíle všude se povalujících plánovaných úprav a změn na jedno dostupné místo (#2322)

Shrnutí od předchozích VC, 2015-04-03¶

• Radek: vyzkoušení mapování ntpstampu do 64 integeru (problém, že dashboard používá insert time místo DetectTime)
  • rozsah znaménkového integeru (Monga) je -2^63 až +2^63-1
  • rozsah neznaménkového integeru (ntpstamp) je 0 až 2^64-1
  • převodní funkce musí převést textový čas na ntpstamp a ten posunout do rozsahu znaménkového integeru, tak, aby nula byla na -2^63 - tj. 2^63 odečíst
  • zpětná funkce musí 2^63 přičíst, tím získá ntpstamp, a převést na textový čas
  • abychom věděli, že převádíme korektně na monotónní posloupnost, je potřeba otestovat relace mezi textovými časy, které se zkonverují na čísla u hraničních hodnot, tj. v Mongu to budou čísla blízko -2^63 (tj. ntpstamp u nuly), čísla nad a pod nulou (tj. ntpstamp kolem půlky rozsahu) a blízko 2^63-1 (tj. ntpstamp blízko 2^64-1)

• ph zakomponovat Vulnerable.* do Idey (Open - řešitelné patchem, Config - řešitelné konfigurací)
• Zdůraznit v klasifikacích, kterých tagů (Category, Type, ...) se týká, např. v examples (ph)
• Source/Target - nekomplikovat spojeními a zůstat u sémantiky source of problem ; zdůrazňovat v popisu Idea (ph) a v popiscích Mentat (Mek)
• zdůraznit pořadí protokolů v Idee (ISO-OSI) (ph)
• přidáme Vulnerable.Config (ph přidá do taxonomie)

• Radek: Mongo 3, hlavně WiredTiger (také ve spojitosti s tím, že 2.7 na cca 30 minutách 8 minut pomalejší)
  • nalezen pomalý dotaz (category + time), cca 50 sec, 2.6 rozšířené indexy timeoutují, 3.0 také, základní indexy cca 80 sec
  • jiné dotazy zanedbatelný rozdíl mezi 2.6 a 34
• padla úvaha, zda nemůžou hrát roli integerové nebo stringové s malou kardinalitou indexy versus indexy nad binary s proměnlivou délkou
  • tj. při vhodné příležitosti převedeme časy a IPv4 na int, a pokud to bude mít vliv, zvážíme/otestujeme uložení IPv6 jako dvou dlouhých integerů
• Radek: Paralelní test (simulace víc uživatelů)
• Radek: Test při současném zápisu (to by měla být výhoda Wired Tigera)
• Měli bychom si všichni udělat čas a pokusit se trochu poklikat a zatížit to dotazy
• Poznámka k Mongu 3 - Radek narazil na to, že s Wired Tigerem se Hawat tváří, že nemůže najít kolekci groups

• Rozbitá čeština Events vs Administration/Events
• Sada reprodukovatelných db (a jiných) testů
• Optimalizace Dashboardu

Poznámka - Radek nyní pracuje hlavně na Wardenu, tudíž žádné přímé Mentatí úkoly.

Poznámka na některou z dalších schůzek:

• hledání konkrétní IP adresy volá svižný dotaz:
  • {"Source.IP4.ip":"HexData(0,\"9BE80002\")"}
• hledání na rozsah (třeba 155.232.0.0/16) vyvolá dotaz s fullscanem:
  • {"Source.IP4.max" : { "$lte" : BinData(0,"m+j//w==") }, "Source.IP4.min" : { "$gte" : BinData(0,"m+gAAA==") }}

Tzn. jedna IP se hledá přes IP4.ip, rozsah přes IP4.max/min, které nejsou indexované. Což nejspíš ovlivňuje i mizerný výkon dashboardu.

• index na min/max?
• neměl by se i dotaz na jednu ip ptát {Source.IP4.min:HexData(0,"9BE80002"), Source.IP4.max:HexData(0,"9BE80002")}

A vlastně:

• nemáme teď s Ideou ip/min/max redundantní? V IDMEF byla možnost celé adresy i s netmaskou, v Idee máme prosté rozsahy, takže by nejspíš stačilo min/max a ip se zbavit

Tj. postup: zaindexovat min a max; zajistit, aby všude ip==min; změnit dotazy, které používají ip, na současně min a max; zrušit index pro ip; přestat přidávat ip

Pouštím ensureIndex na min/max.

Ad ip==min, pro čtyřkové adresy to platí (0 v _id je výsledek $cmp, tedy rovno):

> db.alerts.aggregate([
... {$unwind: "$Source"},
... {$unwind: "$Source.IP4"},
... {$project: {_id: "$_id", src_ip: "$Source.IP4.ip", src_min: "$Source.IP4.min"}},
... {$project: {_id: "$_id", cmp: {$cmp: ["$src_ip", "$src_min"]}}},
... {$group: {_id: "$cmp", sum: {$sum: 1}}}
... ])

{ "_id" : 0, "sum" : 69464457 }

> db.alerts.aggregate([
... {$unwind: "$Target"},
... {$unwind: "$Target.IP4"},
... {$project: {_id: "$_id", src_ip: "$Target.IP4.ip", src_min: "$Target.IP4.min"}},
... {$project: {_id: "$_id", cmp: {$cmp: ["$src_ip", "$src_min"]}}},
... {$group: {_id: "$cmp", sum: {$sum: 1}}}
... ])

{ "_id" : 0, "sum" : 62638372 }

Ad ip==min, pro čtyřkové adresy to neplatí, ale docela zajímavě ip<min, ale vzhledem k tomu, že min má 17 oktetů místo 16, myslím, že to bude nějaká bota v konverzní funkci (-1 v _id je výsledek $cmp):

> db.alerts.aggregate([
... {$unwind: "$Source"},
... {$unwind: "$Source.IP6"},
... {$project: {_id: "$_id", src_ip: "$Source.IP6.ip", src_min: "$Source.IP6.min"}},
... {$project: {_id: "$_id", cmp: {$cmp: ["$src_ip", "$src_min"]}}},
... {$group: {_id: "$cmp", sum: {$sum: 1}}}
... ])

{ "_id" : -1, "sum" : 864 }

> db.alerts.aggregate([
... {$unwind: "$Target"},
... {$unwind: "$Target.IP6"},
... {$project: {_id: "$_id", src_ip: "$Target.IP6.ip", src_min: "$Target.IP6.min"}},
... {$project: {_id: "$_id", cmp: {$cmp: ["$src_ip", "$src_min"]}}},
... {$group: {_id: "$cmp", sum: {$sum: 1}}}
... ])

{ "_id" : -1, "sum" : 1 }

K předchozímu:

Přidal jsem index:

    {
        "v" : 1,
        "key" : {
            "Source.IP4.min" : 1,
            "Source.IP4.max" : 1
        },
        "name" : "source_ip4_min_max",
        "ns" : "mentat.alerts",
        "background" : 1
    }

Pokud by někoho překvapilo, že šel vyrobit složený index nad dvěma položkami, které jsou v poli (a dokonce v poli v poli), překvapilo to i mě, ale je to proto, že jsou v jednom společném poddokumentu, tudíž pro každou položku pole bude jeden záznam ve složeném indexu, ve kterém je min i max. Viz Multikey Index Bounds

• stálo by za to na Mongu zapnout logování dlouhých dotazů (třeba nad minutu), ať máme přehled, co vytikává, a nehádáme z větru
• možná by stálo za to přidat na konec indexu, používaných z Alerts dotazů, i správně směrovaný DetectedTime, protože se podle něj řadí a když je na konci, Mongo ho obvykle umí použít, a není potom problém s vytikáváním při přechodu na daleké stránky pageru (limit 30, skip $hafomoc). "Možná" píšu proto, že to nemusí mít význam při složitějších dotazech.
• všiml jsem si v db.currentOp(), že v některých agregačních dotazech se po sobě dělá dvakrát stejný unwind, to mi přijde divné, ale hlouběji jsem to nezkoumal
• percentuální grafy v dashboardu teď nedávají smysl, protože jedna událost může mít víc kategorií, a započítá se víckrát (100xRecon.Scanning + 100xTest, ale celkem 100 událostí, neznamená 50% Recon.Scanning a 50% Test)
• bylo by fajn mít v simple formu možnost zadat nejen rozsah, ale i víc zdrojů či cílů, oddělených čárkami

Zápis z VC 2015-09-07 13:00¶

Nějak nám uhynuly zápisy, takže tuto pěknou tradici obnovuji.

• Radek: testovací skript na výkon events
  • posbírat dotazy
  • + vygenerované variace pro simpleform
  • volitelný krátký/dlouhý test
  • volitelně mongo debug nebo bez
  • rozumný výstup (alespoň diffovatelný)
  • python
  • (mentat-dev)
• Tradiční mail do neděle 13.

Další VC 21. 9. 13:00 (v Praze malá)

Zápis ze schůzky na semináři 1416 ve Vranovské vsi 2015-10-12¶

Testovací skript na výkon events (posbírané dotazy + vygenerované variace pro simpleform)¶

• Radek zmínil chybu s časy
• Návrh definice hodnot a typů (je pak v kódu jednodušší konvertování a můžou se jmenovat libovolně):
  • "blabla": {value: "2015-10-12T21:39:08", type: "datetime"}
• stačí slovník s výsledky vysypat do JSONu (se sortkeys, indent, separators natvrdo), každý běh v jednom souboru s datem ve jméně, pro každý profil db vlastní soubor (a teď mě napadá, že jméno souboru by mohlo být generováno natvrdo ze jména profilu, ani by nemuselo být v konfiguraci, tj. třeba 2015-10-12T22:23:24_Mongo28.json)
• možnost definovat očekávaný rozsah počtu výsledků u testu:
  • assert: { min_count: 13241243, max_count: 3452345 }
• ve výsledku i count a explain dokumentů, ale změřit čas před jejich zjišťováním; --{fast,quick,rapid} bez nich
• indexy taky v konfiguraci profilu, návrh:
  Config:
  

  mongo3: {
      indexes: {
          "ts": {fields=[("ts", 1))], bflm="ahoj", psvz="cau"}
       }
  }
  

  
  Volání:
  

  for name, val in indexes.items():
      fields = val["fields"]
      del val["fields"]
      collection.create_index(fields, name=name, background=True, **val)
  

Nápad¶

Pokud se parsování JSONového configu zavolá zhruba takto:

data = json.loads('{"foo":1, "bar": 2}', object_pairs_hook=collections.OrderedDict)

Další iterace jako obvykle (video dle potřeby) v úterý 20. 10.