Hi, > >>> I'm frankly not interested in having to document and support > >>> different flavors of configuration representation. I would be > >>> willing to include hooks in the compiler for doing the conversion > >>> and for matching up filenames and line numbers in the error > >>> messages to where an error or warning occurred in the original > >>> source text, but I would prefer that these alternate configuration > >>> formats be separate products that are documented, maintained and > >>> supported by their creators. > >> Actually, I'd like to go one step further and suggest to not bring > >> this extra overhead into the project. It is a clear example of > >> putting the cart in front of the horse. > > I agree. Shorewall is easy to configure; all xml would do is make > > it harder. If somebody thinks this is not the case, they need to > > learn how to use an editor. GUI is an unnecessary additional layer > > of abstraction, a potential source of errors, an expanded attack > > surface, and a maintenance burden. > > > > You are missing the point that not all config files are written by > humans...
I'm not missing that point. We're talking about shorewall, which has config files that are designed to be edited manually. > To highlight the point, consider the ratio of html websites > written by humans vs database driven (or other cgi built sites). cgi > generated sites dominate by a massive proportion. Yes, but we are not talking about this. Of course you make a valid point in general. Your point, however, is beyond the scope of my argument with regards to shorewall. > > Personally I don't dig xml all that much, but sometimes it makes sense > to store data in a particular format. eg many applications find either > sql or ldap storage useful for common centralisation of configs. > Others find json (or yaml) useful for integrating with web > applications. XML has it's place also > > Note I'm not particularly trying to influence any direction of > shorewall here. For the time being I'm planning to store my config > in json and generate flat files via a simple "compiler". However, if > this works out I will investigate deeper integration into shorewall. > I think that any attempt at influencing the direction of shorewall is as equally welcome as a yes or no answer to whatever idea has been proposed :) To reiterate, the point I made was that a tool that can create XML for shorewall is absolutely welcome, and it would handy especially after a parser has been made that would convert XML to plain shorewall files. :) And I also said that it is, in my view, not a task of the core developer. But I read your answer to this below: > Digressing: Anyone who hasn't played with YAML should have a poke > around the basics. eg Rails uses it for it's database config and a > quick google search should turn up some examples of syntax. Notice > that it's kind of "XML done better" and XML can be viewed as a > complete subset of YAML. Of particular interest is the use of > "references", ie you can define a bunch of attributes (a tempate) and > then insert this reference anywhere else (this would be quite fun to > have in shorewall). Personally I find YAML a similar overkill to XML > and prefer JSON (which is technically a syntax compatible subset of > YAML) for most purposes. Also the perl JSON parsers seem faster and > more mature than the mammoth YAML parsers..? > > It seems fairly trivial to have a one way conversion from xml, json, > yaml, etc to shorewall. I will try and contribute anything I produce, > but perhaps others will contribute alternatives sooner. Also note > that it should be reasonably easy to link such a "compiler" into the > shorewall "make"-alike feature, so you could easily achieve a > cascading effect where "rules.json" gets compiled to "rules" and then > normal shorewall compiles that down as normal? This likely achieves > most of what users currently desire? Personally I prefer the entry to shorewall that it currently has, because it's what I'm used to. I'm pretty fast with a terminal, in any way faster than with any other tool. If I would have proper, real-time and adequate logging^W^W^W^W^W detected a possible security breach on my firewall, I would have needed to edit the files as quickly as possible. Not via the so often seen 'start -> all programs -> Shorewall Config Editor -> Shorewall Config Editor *click* -> wait' sequence. Sorry for sounding so pedantic and/or instructive. (and/or elitist - ^W may be read as "remove last typed word" - I said it jokingly) - Mark ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
