Warden

Pro prehlednost doplnuji mailovou komunikaci mezi TP a PK:

Ahoj,

   jasně, pcapové filtry znám, v podstatě obvyklé logické výrazy a trochou
syntaktického cukru pro sítě.
   Takový jazyk ale znamená gramatiku, parser a AST s implementací
operátorů, je otázka, jestli tak daleko chceme jít.  Na druhou stranu už se
do takové věci pouštíme v Mentatu (s ambicí na Coddovy podmínky), pokud
bychom došli k tomu, že je to pro Warden rozumné, půjde to využít.

-- ph

> From: Tomas Plesnik <plesnik@ics.muni.cz>, Date: Jul 31, 2012
>
> Cau Pavle,
>
> tak jsem se na to dival a v podstate se jedna o tcpdump (pcap) filter.
> Je mi jasne, ze tento filter pro nas neni vhodny, ale na druhou stranu
> si myslim, ze si z nej muzeme vzit co se nam libi a zbytek zahodit.
> Ukazka je na strance http://nfdump.sourceforge.net/ pod nadpisem Filter
> Syntax.
>
> Tom
>
> On 31.7.2012 18:02, Pavel Kácha wrote:
>> Ahoj,
>>
>>    pošli mi pls odkaz nebo jméno toho filtrování, o kterém jsi mluvil (v
>> souvislosti s netflow).
>>
>> -- ph
>>

Pro prehlednost doplnuji mailovou komunikaci mezi TP a PK ohledne zpusobu pouzivani "any" jakozto identifikatoru pro prijem vsech typu zprav:

   Záleží na úhlu pohledu. Jako 'nestandardní typ' ano. Jako 'interní
placeholder' ne.
   V zásadě bych byl pro, ale to bychom bývali museli udělat už na začátku.
Teď je to v dokumentaci, v databázi událostí, lidi jsou na to zvyklí... 
   Naopak _any_ je interní věc, která se nebude vyskytovat mimo databázi
klientů, resp.  to do ní bude zadávat jen správce při vytváření klienta, a
je snadné ji v případě potřeby změnit.  Takže bych se teď v 2.X nesnažil být
konzistentní na úkor práce s dokumentací a přeučováním lidí na _test_, když
se stejně _any_ velmi pravděpodobně měnit bude.

   A jinak myslím, že přesně takovéhle diskuse můžou být součástí tasků,
když už jsme je začali - pak budou zadokumentované motivace k některým
rozhodnutím.

-- ph

> From: Tomas Plesnik <plesnik@ics.muni.cz>, Date: Aug 02, 2012
>
> Jasny rozumím. Ve  své podstatě aby se oddělil jakoby řidiči znak. Ok, beru. Tím padem to bude vypadat následovně: "_any_". Ještě me tak napadlo, jestli by nebylo dobře tímto zpusobem používat i "test" který slouží k identifikaci testovacích zpráv. 
>
> Tom
>
> Tomas Plesnik                                                            plesnik@ics.muni.cz
> CSIRT-MU, Network Security Department            http://www.muni.cz/csirt
> Institute of Computer Science, Masaryk University, Brno, Czech Republic
> PGP key ID: 0x9D3722F3
>
> 1. 8. 2012 v 16:57, Pavel Kácha <ph@cesnet.cz>:
>
>>> From: Tomas Plesnik <plesnik@ics.muni.cz>, Date: Aug 01, 2012
>>>
>>> Super. Jinak jsem premyslel jak nejlepe representovat volbu stahovani
>>> vsech typu zprav. Ve sve podstate jako pouzitelne se zdaji byt:
>>>
>>> - all
>>> - _all_
>>> - ALL
>>> - _ALL_
>>> - *
>>> - null
>>> - any
>>> -_any_
>>>
>>> Me osbone se nejvice libi a priklanim se k "any".
>>
>>   Podtržítka jsem tam strčil jen proto, aby bylo na první pohled zřejmé, že
>> se jedná o zvláštní volbu proti ostatním, zvaž.  A "any" je ok.
>>
>> -- ph

Prave jsem do serveru pridal podporu "ridiciho znaku" any aby bylo mozne ze serveru stahnout vsechny typy udalosti. Upravil jsem dokumentaci, kod bezi na serveru warden-dev. Uprava je do GITu nakomitovana pod Revizi 078fc14f.

Díky. Vystřelil jsem any z dokumentace (824646d1), je to interní záležitost. Je potřeba upravit dokumentaci registerReceiver.pl, aby vytvářející správce věděl, co použít.

Do README a helpu skriptu registerReceiver.pl jsem doplnil popis

_any_

Moje poznámka k registraci na any - osobně si myslím, že parametr $requested_type v getNewEvents je pozůstatek z návrhu a bude rozumné se ho v budoucnu zbavit - filtr je definován při registraci klienta a dosud nebyl měnitelný (parametr musel být při volání stejný, jako je uveden v db) a při any je řada možností chování. Jaký je Tvůj názor?

Eh, sorry, první část (List::Util) patří k #524.

V aktualnim stavu je to tak, ze klient by musel mit dve registrace, jednu pro any a druhou pro zvoleny 'type'. Neni problem udelat drobnou upravu tak, aby klient, ktery ma zaregistrovany typ any a prijde pouze s konkretnim typem aby jej take dostal, jelikoz pro any to vlastne znamena, ze ma pristup ke vsem typum udalosti.

Na druhou stranu je ale pravda, ze promenna $requested_type je v podstate zbytecna a muze se dotahovat z db registrovanych klientu. Takze bych ji pri major verzi vyhodil...

Už se z db stejně tahá (protože se proti ní autorizuje $requested_type dodaná klientem), byl bych pro to, udělat $requested_type ještě ve 2.1 verzi volitelný, označit v dokumentaci „deprecated“ a prdět na něj (tj. použít rovnou ten vytažený z db). Je to poziční parametr, a je druhý, takže ho volající může bezbolestně vynechat. Tebe se týká server, klienta může udělat Suki. Co si o tom myslíš?

Souhlasim a nemam s tim problem. Pokud mi jej ale nekdo i presto ze u nej bude popisek "deprecated" vyplni, tak jej na serveru zahodit a stejne si jej vytahnout s DB?

Byl bych pro. Kód bude jednodušší, a pokud bude explicitně řečeno, že je deprecated a nepoužívá se, je to korektní.

Dobra poznamka od Kosteje:

Takze moznost, kdy si klient natahne jen pozadovany typ (pokud jich ma registrovanych vice), uz nebude k dispozici? To je zvlastni.

Kostej ma v tomto pravdu. Pokud bude mit nekdo zaregistrovanych vice klientu (pro stahovani vice typu udalosti) a ja na serveru zahodim $requested_type, tak nebudu vedet ktere zpravy (zpravy jakeho typu) mu mam vlastne poslat, protoze v db klientu bude mit vic registraci na ruzne typy udalosti. Resenim tohoto problemu by mohla byt kontrola, ze pokud prijde s nejakym konkretnim typem, tak se podivam zdali jej ma zaregistrovany a dam mu udalosti odpovidajici tomuto konkretnimu typu. Pokud nema registraci pro tento konkretni typ, tak bych se podival jestli ma zaregistrovany any, pokud ano tak mu je muzu taky dat. Pokud ale nema ani jedno, tak mu nedam nic.

Tomáš Plesník wrote:

Dobra poznamka od Kosteje:

[...]

Kostej ma v tomto pravdu. Pokud bude mit nekdo zaregistrovanych vice klientu (pro stahovani vice typu udalosti) a ja na serveru zahodim $requested_type, tak nebudu vedet ktere zpravy (zpravy jakeho typu) mu mam vlastne poslat, protoze v db klientu bude mit vic registraci na ruzne typy udalosti. Resenim tohoto problemu by mohla byt kontrola, ze pokud prijde s nejakym konkretnim typem, tak se podivam zdali jej ma zaregistrovany a dam mu udalosti odpovidajici tomuto konkretnimu typu. Pokud nema registraci pro tento konkretni typ, tak bych se podival jestli ma zaregistrovany any, pokud ano tak mu je muzu taky dat. Pokud ale nema ani jedno, tak mu nedam nic.

Toto reseni ale znamena, ze $requested_type budeme pouzivat i nadale.

Jo, má pravdu, to jsem přehlédl.

V zásadě jsem se chtěl hlavně zbavit nutnosti uvádět "_all_", protože to je věc, kterou by klienti neměli vidět, a vycházel jsem z dojmu, že máme jen klienty, stahující jeden typ zpráv, nebo všechny typy.

To domýšlení typu v jednom případě a v druhém ne už se mi příliš nezdá, není to konzistentní. Jednodušší verze - neuvedený typ nebo undef = all?

Pavel Kácha wrote:

Jo, má pravdu, to jsem přehlédl.

V zásadě jsem se chtěl hlavně zbavit nutnosti uvádět "_all_", protože to je věc, kterou by klienti neměli vidět, a vycházel jsem z dojmu, že máme jen klienty, stahující jeden typ zpráv, nebo všechny typy.

To domýšlení typu v jednom případě a v druhém ne už se mi příliš nezdá, není to konzistentní. Jednodušší verze - neuvedený typ nebo undef = all?

Pouzil bych undef, pokud je typ nastaven na undef, tak se to na serveru prelozi jako all.

Ok, pokud přijde nedefinovaný (tj. klient ho neuvedl, nebo zavolal s undef), přelož ho na all. Pak to přehodím na Sukiho, zkontrolujeme, jestli v klientovi není někde zádrhel.

Hotovo a ulozeno do GITu.

Otestoval jsi to?

Useless use of a constant (any) in void context at Warden.pm line 251.

Opravdu bude potřeba || nebo závorky.

or jsem vymenil za || a uz to funguje. Neotestovany rychli preklep. Pardon a diky za upozorneni.