Hi
>> Consider two other interesting alternatives (not claiming either is
>> *better*, just alternatives)
>>
>> Perl style:
>> proto=>udp, port=>1024:1033,1434,5948,23773
>> networks=>221.192.199.48
> It's trivial to support that notion in addition to what I have currently
> implemented.
Actually, can I suggest that you *don't* support too many formats here?
I only intended to show that there are various options, but I really
think after that you should limit shorewall to "fewer" formats? (reduces
scope for bugs and misunderstandings)
> I notice that you used a comma after the first pair and
> below you mention the possibility of adding a comma separator. That's
> okay so long as we require that the comma be followed by whitespace.
> Otherwise, the syntax is ambiguous in as much as comma is used
> frequently as a separator in column values.
Agreed and understood. I can see a disadvantage in the comma from the
point of view of this syntax, but equally I can see people putting it in
accidentally when learning... Personally don't have an opinion either way?
>> "web" style
>> {proto:"udp" port:"1024:1033,1434,5948,23773"},
>> {networks:"221.192.199.48"},
>>
> I assume that the curly braces denote column/value pairs and that the
> semicolon is unnecessary in this syntax.
Aha, see now you come to a format which I think is quite interesting in
that give or take some syntax tweaking it's JSON. Hence my original email.
Roughly the syntax maps to a perl hash or array. An element is
surrounded by brackets, either { } for a perl hash, or [ ] for an
array. The semicolon could easily be done away with here because it's
quite clear when we drop into "web" format.
If you don't see a problem with this style then I would recommend going
all the way and eliminate any corner cases so that you can accept
literal JSON format for the entire file? (The main thing I can think of
is that the line needs to end with a comma, ie "{ ... },") ie it a file
can be round tripped using:
use JSON;
#slurp
local $/;
open( my $fh, '<', '/etc/shorewall/rules' );
$rules_json = <$fh>;
# decode
$rules = decode_json($rules_json);
# encode again (just for kicks...)
$rules_json = encode_json($rules);
Obviously shorewall can't use the json parser this way because it has to
support columnar format also, but I think the advantages for
guis/editors is obvious if the file format can be completely round
tripped this way?
It's also cool in that at least some tools can then use off the shelf
parsing tools, without needing to build a new config file reader?
If I risked sticking my neck out again, personally for automated third
party shorewall utilities (ie my hypothetical web based editor) I think
the easiest formats to parse are the pure column format (ie existing)
and the pure other config files above (key-value, perl, web, etc).
Hybrids are the easiest to get wrong or make mistakes parsing and so
less desired.
As such whilst I don't have strong feelings over which format you
finally stabilise on, I think desirable properties would be:
- entire file can be column or..
- entire file can be alternative style (as with your key-value)
- ideally whole file can be parsed by off the shelf parsers from cpan or
trivial code (true of column formats, key-value formats and many others)
Note, I'm definitely not claiming your key value format doesn't fit
those criteria, it does! Just highlighting that it's so very close to a
couple of other formats it might be worth considering if one of those is
a good/better alternative?
>> 2) I don't know if there are currently any values which might contain
>> spaces, however, it seems something that may happen in the future. I
>> couldn't quickly see whether the current config file allows something
>> like key="value with spaces", but is that something you might want to allow?
> There are no instances of that and never will be. There really isn't a
> lexical analyzer in the compiler; it rather simply uses "split(' ',
> $line)" to isolate the individual columns. That precludes embedded
> whitespace in column values.
Oh, one last thing: This really sounds like the kind of feature you
might require at some future point? OK, I'm struggling to figure out the
what right now, but as you say it's because it wasn't possible before.
Just some random ideas, but
- what about allowing the logging text to be specified as as one of the
key-value pairs?
- Could some of the new "conditions" matches stuff need spaces?
- I guess it will be any feature of iptables/tc which is expressed in
".." ? Are there many others right now?
Just trying to think ahead!
Cheers
Ed W
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
