I was reading through the config files, and noticed that many of them would be well suited by being replaced or supplemented with an (optionally optional) shiny new XML format that would allow the user to specify only the needed attributes and not have to fill in -s where not needed. Would prevent such mishaps as 1-too-many or 1-too-few -s resulting in entries being placed in the column, and as I understand it perl already has simple to use XML tools. Complicated files may end up longer in some cases, but overall specification of rules would be.. simpler to write and understand, if a bit more verbose. Examples: <rule> <action>DNAT</action> <source>net</source> <dest>loc:10.0.0.1</dest> <proto>tcp</proto> <port>80</port> <mark>88</mark> <!-- this is the line that makes it simpler --> </rule> <!-- also, reading this in a console is a lot more intuitive when you come back 6 months later than an ass-ton of columns with no header information (because it''s three page-ups away, not because it''s deleted, obviously --> ------------------------------------------------------------------------------ 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
Christ Schlacta wrote:>I was reading through the config files, and noticed that many of them >would be well suited by being replaced or supplemented with an >(optionally optional) shiny new XML format that would allow the user to >specify only the needed attributes and not have to fill in -s where not >needed. Would prevent such mishaps as 1-too-many or 1-too-few -s >resulting in entries being placed in the column, and as I understand it >perl already has simple to use XML tools.Perhaps it''s just me being somewhat "old fashioned" but I prefer flat format files and find them a lot easier to work with. Mind you, part of that may be that I''m used to using unix text tools for working with files - and they just don''t work with XML. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
On Sun, 25 Sep 2011 13:53:20 +0100 Simon Hobson <linux@thehobsons.co.uk> wrote:> Christ Schlacta wrote: > >I was reading through the config files, and noticed that many of them > >would be well suited by being replaced or supplemented with an > >(optionally optional) shiny new XML format that would allow the user > >to specify only the needed attributes and not have to fill in -s > >where not needed. Would prevent such mishaps as 1-too-many or > >1-too-few -s resulting in entries being placed in the column, and as > >I understand it perl already has simple to use XML tools. > > Perhaps it''s just me being somewhat "old fashioned" but I prefer flat > format files and find them a lot easier to work with. Mind you, part > of that may be that I''m used to using unix text tools for working > with files - and they just don''t work with XML.I concur. Furthermore I''d like to suggest a nice trick. If you''re editing the files with vim, you could use folds. That''s how I do it and it keeps your window very tidy. Two examples: # all icmp and public ssh {{{ COMMENT To mybox ACCEPT all all icmp COMMENT # }}} COMMENT public ssh # {{{ ACCEPT:$LOG wan fw tcp 22 COMMENT # }}} Then, on the bottom of the file, I have: # vi: nowrap foldmethod=marker noet (Usually I use ''et'' or ''expandtabs'', but in these files I prefer actual tabs) And, to make sure that this is parsed, I have "set modeline" in my .vimrc. There are some caveats when modeline parsing is enabled, so be sure to search for that online. If I open the file, I see: + -- 5 lines: all icmp and public ssh -------------------------------- + -- 3 lines: COMMENT public ssh ------------------------------------- ... I simply move my cursor to the line I want to unfold, press space, edit, and to close it I press ''zc'' from within the unfolded space. You can also open/close all folds at once, and it''s even possible to have multiple fold levels. A great feature of vim. For more info on folds, vim -c '':help usr_28'' Good luck, 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
On Sun, 2011-09-25 at 01:20 -0700, Christ Schlacta wrote:> I was reading through the config files, and noticed that many of them > would be well suited by being replaced or supplemented with an > (optionally optional) shiny new XML format that would allow the user to > specify only the needed attributes and not have to fill in -s where not > needed. Would prevent such mishaps as 1-too-many or 1-too-few -s > resulting in entries being placed in the column, and as I understand it > perl already has simple to use XML tools. Complicated files may end > up longer in some cases, but overall specification of rules would be.. > simpler to write and understand, if a bit more verbose. Examples: > > <rule> > <action>DNAT</action> > <source>net</source> > <dest>loc:10.0.0.1</dest> > <proto>tcp</proto> > <port>80</port> > <mark>88</mark> <!-- this is the line that makes it simpler --> > </rule> > <!-- also, reading this in a console is a lot more intuitive when you > come back > 6 months later than an ass-ton of columns with no header information > (because > it''s three page-ups away, not because it''s deleted, obviously -->I agree that the rules file, in particular, is outgrowing the columnar format but I am reluctant to accept that XML is the answer. I worry that if the ruleset is represented in XML, you won''t be able to see the forest for all of the trees. I''ll think about it, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On Sep 25, 2011, at 8:21 AM, Mark van Dijk wrote:> On Sun, 25 Sep 2011 13:53:20 +0100 > Simon Hobson <linux@thehobsons.co.uk> wrote: > >> Christ Schlacta wrote: >>> I was reading through the config files, and noticed that many of them >>> would be well suited by being replaced or supplemented with an >>> (optionally optional) shiny new XML format that would allow the user >>> to specify only the needed attributes and not have to fill in -s >>> where not needed. Would prevent such mishaps as 1-too-many or >>> 1-too-few -s resulting in entries being placed in the column, and as >>> I understand it perl already has simple to use XML tools. >> >> Perhaps it''s just me being somewhat "old fashioned" but I prefer flat >> format files and find them a lot easier to work with. Mind you, part >> of that may be that I''m used to using unix text tools for working >> with files - and they just don''t work with XML. > > I concur. Furthermore I''d like to suggest a nice trick. >In emacs, I simply ^X 2 (open a second ''window'') and resize the upper window to just show the column headings. The bottom window can then be scrolled and the headings are always in view at the top of the screen. Problem is that I widen some of the columns and now the heading won''t fit on the screen unless I use a very small font. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
Perhaps a format similar to BIND or dhcpd would be more beneficial? On 09/25/2011 08:49 AM, Tom Eastep wrote:> On Sun, 2011-09-25 at 01:20 -0700, Christ Schlacta wrote: >> I was reading through the config files, and noticed that many of them >> would be well suited by being replaced or supplemented with an >> (optionally optional) shiny new XML format that would allow the user to >> specify only the needed attributes and not have to fill in -s where not >> needed. Would prevent such mishaps as 1-too-many or 1-too-few -s >> resulting in entries being placed in the column, and as I understand it >> perl already has simple to use XML tools. Complicated files may end >> up longer in some cases, but overall specification of rules would be.. >> simpler to write and understand, if a bit more verbose. Examples: >> >> <rule> >> <action>DNAT</action> >> <source>net</source> >> <dest>loc:10.0.0.1</dest> >> <proto>tcp</proto> >> <port>80</port> >> <mark>88</mark> <!-- this is the line that makes it simpler --> >> </rule> >> <!-- also, reading this in a console is a lot more intuitive when you >> come back >> 6 months later than an ass-ton of columns with no header information >> (because >> it''s three page-ups away, not because it''s deleted, obviously --> > I agree that the rules file, in particular, is outgrowing the columnar > format but I am reluctant to accept that XML is the answer. I worry that > if the ruleset is represented in XML, you won''t be able to see the > forest for all of the trees. > > I''ll think about it, > -Tom > > > ------------------------------------------------------------------------------ > 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------------------------------------------------------------------------------ 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
On Sun, 25 Sep 2011 08:49:47 -0700 Tom Eastep <teastep@shorewall.net> wrote:> On Sun, 2011-09-25 at 01:20 -0700, Christ Schlacta wrote: > > I was reading through the config files, and noticed that many of > > them would be well suited by being replaced or supplemented with an > > (optionally optional) shiny new XML format that would allow the > > user to specify only the needed attributes and not have to fill in > > -s where not needed. Would prevent such mishaps as 1-too-many or > > 1-too-few -s resulting in entries being placed in the column, and > > as I understand it perl already has simple to use XML tools. > > Complicated files may end up longer in some cases, but overall > > specification of rules would be.. simpler to write and understand, > > if a bit more verbose. Examples: > > > > <rule> > > <action>DNAT</action> > > <source>net</source> > > <dest>loc:10.0.0.1</dest> > > <proto>tcp</proto> > > <port>80</port> > > <mark>88</mark> <!-- this is the line that makes it simpler --> > > </rule> > > <!-- also, reading this in a console is a lot more intuitive when > > you come back > > 6 months later than an ass-ton of columns with no header > > information (because > > it''s three page-ups away, not because it''s deleted, obviously --> > > I agree that the rules file, in particular, is outgrowing the columnar > format but I am reluctant to accept that XML is the answer. I worry > that if the ruleset is represented in XML, you won''t be able to see > the forest for all of the trees. > > I''ll think about it, > -TomNo, don''t think about it. No offense intended to anyone, but it''s a bad idea. XML files lend themselves to editing via graphical user interface and machine processing, but not rapid human separation of signal from noise and manual editing. There are numerous ways to work around the issue of heading visibility, using two vertically-tiled views of the file being the most obvious (as provided by any split-screen editor or screen-like application). If the file (or files) are going to XML format (no thank you), then provide a curses-based editing interface that looks like a spreadsheet and scrolls while maintaining visibility of the headers, while hiding the XML tags. My two cents. ------------------------------------------------------------------------------ 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
On Sun, 2011-09-25 at 08:49 -0700, Tom Eastep wrote:> I agree that the rules file, in particular, is outgrowing the columnar > format but I am reluctant to accept that XML is the answer. I worry > that > if the ruleset is represented in XML, you won''t be able to see the > forest for all of the trees.Please, no XML.. -- Homer Parker <hparker@homershut.net> ------------------------------------------------------------------------------ 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
On Sunday, September 25, 2011, 17:49:47, Tom Eastep wrote:> I agree that the rules file, in particular, is outgrowing the columnar > format but I am reluctant to accept that XML is the answer. I worry that > if the ruleset is represented in XML, you won't be able to see the > forest for all of the trees.From personal experience, I'd advise against XML. It's hard to edit as plaintext, and even if you don't get everything in a single line, it's way too verbose. If you're looking to change to a more structured format, I'd suggest to look at JSON or YAML. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > Always leave room to add an explanation if it doesn't work out. -- Rule of the Way Out ------------------------------------------------------------------------------ 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
I agree with some of the opposition about xml being harder to read. I suggest it mainly because of it''s ease of deployment. Perl has well documented easy to use libraries for XML. I''m certainly open to other options, and really just want something easier to use than the large tabular format. Perhaps something custom would work. I have another idea. Pick a constant to (optionally) terminate the end of the rule, such as ";" by itsself in any column. then parse after the ; key-value pairs where COLUMNNAME="value", in my example below DNAT net loc:10.0.0.1 tcp 80 ; MARK="88" just an arbitrary example, but it might inspire you :) On 9/25/2011 08:49, Tom Eastep wrote:> On Sun, 2011-09-25 at 01:20 -0700, Christ Schlacta wrote: >> I was reading through the config files, and noticed that many of them >> would be well suited by being replaced or supplemented with an >> (optionally optional) shiny new XML format that would allow the user to >> specify only the needed attributes and not have to fill in -s where not >> needed. Would prevent such mishaps as 1-too-many or 1-too-few -s >> resulting in entries being placed in the column, and as I understand it >> perl already has simple to use XML tools. Complicated files may end >> up longer in some cases, but overall specification of rules would be.. >> simpler to write and understand, if a bit more verbose. Examples: >> >> <rule> >> <action>DNAT</action> >> <source>net</source> >> <dest>loc:10.0.0.1</dest> >> <proto>tcp</proto> >> <port>80</port> >> <mark>88</mark> <!-- this is the line that makes it simpler --> >> </rule> >> <!-- also, reading this in a console is a lot more intuitive when you >> come back >> 6 months later than an ass-ton of columns with no header information >> (because >> it''s three page-ups away, not because it''s deleted, obviously --> > I agree that the rules file, in particular, is outgrowing the columnar > format but I am reluctant to accept that XML is the answer. I worry that > if the ruleset is represented in XML, you won''t be able to see the > forest for all of the trees. > > I''ll think about it, > -Tom > > > ------------------------------------------------------------------------------ > 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------------------------------------------------------------------------------ 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
On Sep 25, 2011, at 12:04 PM, Christ Schlacta wrote:> I agree with some of the opposition about xml being harder to read. I suggest it mainly because of it''s ease of deployment. Perl has well documented easy to use libraries for XML. I''m certainly open to other options, and really just want something easier to use than the large tabular format. Perhaps something custom would work. I have another idea. Pick a constant to (optionally) terminate the end of the rule, such as ";" by itsself in any column. then parse after the ; key-value pairs where COLUMNNAME="value", in my example below > > DNAT net loc:10.0.0.1 tcp 80 ; MARK="88" > > just an arbitrary example, but it might inspire you :) >I''ve been thinking along similar lines. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On Sun, 25 Sep 2011, Homer Parker wrote:> On Sun, 2011-09-25 at 08:49 -0700, Tom Eastep wrote: >> I agree that the rules file, in particular, is outgrowing the columnar >> format but I am reluctant to accept that XML is the answer. I worry >> that if the ruleset is represented in XML, you won''t be able to see the >> forest for all of the trees.> Please, no XML..+1000 ------------------------------------------------------------------------------ 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
I thought of another benefit to a shiny new XML format All the files could be merged into a single shorewall.xml file with different sections. <config> <adminisabsentminded>true</adminisabsentminded> </config> <rules> <rule> ... </rule> </rules> <tcclasses> ... </tcclasses> etc... Again, this could optionally be accomplished with any format that can implement nested key-value pairs like json. I''m not familiar with yaml. On 9/25/2011 14:38, Steve Thompson wrote:> On Sun, 25 Sep 2011, Homer Parker wrote: > >> On Sun, 2011-09-25 at 08:49 -0700, Tom Eastep wrote: >>> I agree that the rules file, in particular, is outgrowing the columnar >>> format but I am reluctant to accept that XML is the answer. I worry >>> that if the ruleset is represented in XML, you won''t be able to see the >>> forest for all of the trees. >> Please, no XML.. > +1000 > > ------------------------------------------------------------------------------ > 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------------------------------------------------------------------------------ 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
On Sep 25, 2011, at 3:08 PM, Christ Schlacta wrote:> I thought of another benefit to a shiny new XML format > > All the files could be merged into a single shorewall.xml file with > different sections. > <config> > <adminisabsentminded>true</adminisabsentminded> > </config> > <rules> > <rule> > ... > </rule> > </rules> > <tcclasses> > ... > </tcclasses> > etc… >I really don''t see that as a benefit.> Again, this could optionally be accomplished with any format that can > implement nested key-value pairs like json. I''m not familiar with yaml. > >I''ve implemented the simple extension that you suggested earlier. That will have to do. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On 9/25/2011 16:20, Tom Eastep wrote:> I''ve implemented the simple extension that you suggested earlier. That will have to do.Much appreciated :) Thank you very much~ ------------------------------------------------------------------------------ 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
Christ Schlacta wrote:>I thought of another benefit to a shiny new XML format > >All the files could be merged into a single shorewall.xml file with >different sections. ><config> ><adminisabsentminded>true</adminisabsentminded> ></config> ><rules> ><rule> >... ></rule> ></rules> ><tcclasses> >... ></tcclasses> >etc...Good grief, what are you smoking ? Part of the complaint is that some files (particularly rules) are too long, and so you propose to merge everything into one huge file. Realistically that would only be editable using a custom XML editor that would split out the components and offer them for editing a chunk at a time - instead of (as is the case now) being able to use any editor of your choice. Out of interest, do you do your editing on a system with graphical desktop GUI ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
On 9/25/2011 23:45, Simon Hobson wrote:> Christ Schlacta wrote: >> I thought of another benefit to a shiny new XML format >> >> All the files could be merged into a single shorewall.xml file with >> different sections. >> <config> >> <adminisabsentminded>true</adminisabsentminded> >> </config> >> <rules> >> <rule> >> ... >> </rule> >> </rules> >> <tcclasses> >> ... >> </tcclasses> >> etc... > Good grief, what are you smoking ? > Part of the complaint is that some files (particularly rules) are too > long, and so you propose to merge everything into one huge file. > Realistically that would only be editable using a custom XML editor > that would split out the components and offer them for editing a > chunk at a time - instead of (as is the case now) being able to use > any editor of your choice. > > Out of interest, do you do your editing on a system with graphical > desktop GUI ? >I manage a handful of linux systems remotely from a windows 7 desktop, and on occasion I do fire up xming, I primarily use putty, byobu (enhanced screen replacement), and vim. However, the implication, which I failed to make effectively, is that SIMPLE configs (like the Universal) could be merged into a single file, or more complex configs merged into a single file for distribution to multiple systems. I never intended to imply that I thought editing long complex configs in a single XML file routinely was better. ------------------------------------------------------------------------------ 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
On Mon, 2011-09-26 at 00:02 -0700, Christ Schlacta wrote:> > However, the implication, which I failed to make effectively, is that > SIMPLE configs (like the Universal) could be merged into a single file, > or more complex configs merged into a single file for distribution to > multiple systems.If you distribute the same configuration to multiple systems, you might want to consider switching to Shorewall-lite on the firewalls and run Shorewall under Cygwin on your Windows 7 box. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On 9/26/2011 07:04, Tom Eastep wrote:> On Mon, 2011-09-26 at 00:02 -0700, Christ Schlacta wrote: > >> However, the implication, which I failed to make effectively, is that >> SIMPLE configs (like the Universal) could be merged into a single file, >> or more complex configs merged into a single file for distribution to >> multiple systems. > If you distribute the same configuration to multiple systems, you might > want to consider switching to Shorewall-lite on the firewalls and run > Shorewall under Cygwin on your Windows 7 box. > > -Tom > > > ------------------------------------------------------------------------------ > 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-usersI don''t, but I have considered making upgrades that would have me using the same config on multiple systems in the past, so it''s not a major leap. Also, Every time I look at shorewall-lite, I don''t get it. :( ------------------------------------------------------------------------------ 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
On Sun, 2011-09-25 at 16:20 -0700, Tom Eastep wrote:> I''ve implemented the simple extension that you suggested earlier. That > will have to do.Thanks! One other suggestion that may help with long lines is postfix style, any line starting with white space is a continuation of the line above. -- Homer Parker <hparker@homershut.net> ------------------------------------------------------------------------------ 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
On Sep 26, 2011, at 8:50 AM, Homer Parker wrote:> On Sun, 2011-09-25 at 16:20 -0700, Tom Eastep wrote: >> I''ve implemented the simple extension that you suggested earlier. That >> will have to do. > > Thanks! One other suggestion that may help with long lines is postfix > style, any line starting with white space is a continuation of the line > above.Shorewall already supports line continuation: see http://www.shorewall.net/configuration_file_basics.htm#Continuation -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On 26/09/11 00:20, Tom Eastep wrote:> I''ve implemented the simple extension that you suggested earlier. That will have to do. > > -TomIn the docs for this (I''m looking at http://www.shorewall.net/configuration_file_basics.htm#Pairs) there is a trivial typo that might conceivably cause confusion: "After that, at any point, you can enter a semicolon ('':'')" [i.e. the quoted character is actually a colon, although the example further down is correct] Good job on the feature, though! - Dominic ------------------------------------------------------------------------------ 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
On Mon, 2011-09-26 at 17:50 +0100, Dominic Benson wrote:> On 26/09/11 00:20, Tom Eastep wrote: > > I''ve implemented the simple extension that you suggested earlier. That will have to do. > > > > -Tom > > In the docs for this (I''m looking at > http://www.shorewall.net/configuration_file_basics.htm#Pairs) there is a > trivial typo that might conceivably cause confusion: > > "After that, at any point, you can enter a semicolon ('':'')" > > [i.e. the quoted character is actually a colon, although the example > further down is correct]Corrected. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On Mon, 2011-09-26 at 09:37 -0700, Tom Eastep wrote:> Shorewall already supports line continuation: see > http://www.shorewall.net/configuration_file_basics.htm#ContinuationI guess I ought to review the basics periodically :P Thanks again for great software! -- Homer Parker <hparker@homershut.net> ------------------------------------------------------------------------------ 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
On Sep 26, 2011, at 8:22 AM, Christ Schlacta wrote:> On 9/26/2011 07:04, Tom Eastep wrote: >> >> If you distribute the same configuration to multiple systems, you might >> want to consider switching to Shorewall-lite on the firewalls and run >> Shorewall under Cygwin on your Windows 7 box. > I don''t, but I have considered making upgrades that would have me using the same config on multiple systems in the past, so it''s not a major leap. Also, Every time I look at shorewall-lite, I don''t get it. :( >What, exactly, confuses you about Shorewall-lite? -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
On 9/26/2011 16:49, Tom Eastep wrote:> What, exactly, confuses you about Shorewall-lite?The config is there, but it''s here, and there''s also another config here and there.. I''m sure if I sat down and did it, I''d get it eventually, but it''s imposing. ------------------------------------------------------------------------------ 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
On Sep 26, 2011, at 5:31 PM, Christ Schlacta wrote:> On 9/26/2011 16:49, Tom Eastep wrote: >> What, exactly, confuses you about Shorewall-lite? > The config is there, but it''s here, and there''s also another config here > and there.. I''m sure if I sat down and did it, I''d get it eventually, > but it''s imposing.Ignore the config on the firewall. It is only there for emergency use and I doubt that anyone has actually had to use it. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
I think my largest issue with it is that I''m not sure I understand how all the pieces fit together, so I''m hesitant to dive in. for example: the config gets compiled on one system, but applied on another system. the systems may or may not have the same interfaces, and may or may not have the same routes, etc. Combine that with the use of a make file, and I just don''t see how it all fits together. :-S On 9/26/2011 17:35, Tom Eastep wrote:> On Sep 26, 2011, at 5:31 PM, Christ Schlacta wrote: > >> On 9/26/2011 16:49, Tom Eastep wrote: >>> What, exactly, confuses you about Shorewall-lite? >> The config is there, but it''s here, and there''s also another config here >> and there.. I''m sure if I sat down and did it, I''d get it eventually, >> but it''s imposing. > > Ignore the config on the firewall. It is only there for emergency use and I doubt that anyone has actually had to use it. > > -Tom > > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > 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------------------------------------------------------------------------------ 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
On Mon, 2011-09-26 at 21:10 -0700, Christ Schlacta wrote:> I think my largest issue with it is that I''m not sure I understand how > all the pieces fit together, so I''m hesitant to dive in. > for example: the config gets compiled on one system, but applied on > another system. the systems may or may not have the same interfaces, > and may or may not have the same routes, etc.So? The compiler doesn''t look at the current system''s configuration other than to determine it''s capabilities. When compiling for export, a capabilities file is used (one is generated automatically by the ''load'' and ''reload'' commands if it doesn''t exist).> Combine that with the use of a make file, and I just don''t see how > it all fits together. :-SUse of the make file is entirely optional. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
> <rule> > <action>DNAT</action> > <source>net</source> > <dest>loc:10.0.0.1</dest> > <proto>tcp</proto> > <port>80</port> > <mark>88</mark> <!-- this is the line that makes it simpler --> > </rule> > <!-- also, reading this in a console is a lot more intuitive when you > come back > 6 months later than an ass-ton of columns with no header information > (because > it''s three page-ups away, not because it''s deleted, obviously --> >Introducing the xml format into Shorewall would be the most hideous thing to do imo! I can''t see a single benefit from this at all. Shorewall is most commonly used on machines without shiny guis or even graphics cards, so I can''t see these files being processed by the gui tools suggested or having network admins falling themselves over to get the latest xml tool to read those config files, because, lets face it - without a proper tool to see the different options one could easily get lost in all the markup. The best thing, as already suggested in this thread, is to keep the existing format, with maybe introducing the few vim improvements - that would be good. My two pence worth, of course! ------------------------------------------------------------------------------ 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
On 25/09/2011 09:20, Christ Schlacta wrote:> I was reading through the config files, and noticed that many of them > would be well suited by being replaced or supplemented with an > (optionally optional) shiny new XML format that would allow the user to > specify only the needed attributes and not have to fill in -s where not > needed. Would prevent such mishaps as 1-too-many or 1-too-few -s > resulting in entries being placed in the column, and as I understand it > perl already has simple to use XML tools. Complicated files may end > up longer in some cases, but overall specification of rules would be.. > simpler to write and understand, if a bit more verbose. Examples: >Hi, I have been away for some weeks. Actually this is something I have some interest in because I would like to support a limited web interface for users to customise their firewall config. My current thinking on a solution is to store my configuration in some json file (json is a subset of yaml. Remember yaml is a massive specification and to some extent even xml is a kind of subset of yaml! (with different syntax of course..)) I am considering parsing the json files to create the normal text files and run shorewall as normal. However, if this ends up as a completely literal 1:1 mapping then I guess I would look to try and submit back to shorewall the ability to directly read .json files? I really haven''t researched a proper integration, but if the parser is easy to separate then it would seem possible for shorewall to scan for say "rules.json" or "rules" and pick it''s preferred option. If the parser should become very separate (in time) then it would seem that interested parties could add xml/yaml/sql format support as they prefer? At the back of my mind is that sqlite support might be nice, but I''m trying to stick to simple text files in my project at the moment... Regards 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
On Wed, 2011-09-28 at 10:38 +0100, Ed W wrote:> Actually this is something I have some interest in because I would like > to support a limited web interface for users to customise their firewall > config. My current thinking on a solution is to store my configuration > in some json file (json is a subset of yaml. Remember yaml is a massive > specification and to some extent even xml is a kind of subset of yaml! > (with different syntax of course..)) > > I am considering parsing the json files to create the normal text files > and run shorewall as normal. However, if this ends up as a completely > literal 1:1 mapping then I guess I would look to try and submit back to > shorewall the ability to directly read .json files? I really haven''t > researched a proper integration, but if the parser is easy to separate > then it would seem possible for shorewall to scan for say "rules.json" > or "rules" and pick it''s preferred option. If the parser should become > very separate (in time) then it would seem that interested parties could > add xml/yaml/sql format support as they prefer? > > At the back of my mind is that sqlite support might be nice, but I''m > trying to stick to simple text files in my project at the moment...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. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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
Hi, On Wed, 28 Sep 2011 07:07:23 -0700 Tom Eastep <teastep@shorewall.net> wrote:> 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. A better idea is that someone who needs this would write up some separate program that can take whatever input, XML or otherwise, and can export it to what shorewall currently supports. So to put it in bug tracker terms, I''d mark this as INVALID WONTFIX and I think it''s safe to say that the majority of people who replied to the original idea agrees. There is nothing wrong with admins who write up their own wrappers which customise methods that are in use by the distribution or application. I, for one, replaced all of our networking init scripts with suitable alternatives that we control and are not rewritten or deleted when a package or distribution undergoes upgrades. - Mark ------------------------------------------------------------------------------ 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
Mark van Dijk wrote:>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. A better idea is that someone who needs >this would write up some separate program that can take whatever input, >XML or otherwise, and can export it to what shorewall currently >supports.+1 -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
On 9/29/2011 01:33, Simon Hobson wrote:> Mark van Dijk wrote: > >> 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. A better idea is that someone who needs >> this would write up some separate program that can take whatever input, >> XML or otherwise, and can export it to what shorewall currently >> supports. > +1 >I like the idea of drawing a nice clean line between the parser and the compiler, and documenting that interface well (perhaps something as simple as a generic object interface or array of arrays). THe vast majority of users will still be serviced by the default (and supported) flat file interface (and with the new fix, I''m quite content with it again!) but specific applications can now plug in whatever config backend suits their purpose. Great for embedded solutions, and all-in-ones, where the flexibility and power of shorewall is useful, but the interface currently in place is infeasible to interface with (like someone suggested using shorewall with a web interface). Benefits: Shorewall will now be able to be used in more places and for more purposes cons: Extra code to write (probably) and a new interface to document. Useful only for edge cases and integrated solutions I don''t know how much work it would be though, and I''d rather see new features and and more bug fixes if it''s a lot of work to implement. ------------------------------------------------------------------------------ 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
On Wed, 28 Sep 2011 17:40:20 +0200 Mark van Dijk <mark@voidzero.net> wrote:> Hi, > > On Wed, 28 Sep 2011 07:07:23 -0700 > Tom Eastep <teastep@shorewall.net> wrote: > > > 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. ------------------------------------------------------------------------------ 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
On 29/09/2011 19:45, John Brendler wrote:> On Wed, 28 Sep 2011 17:40:20 +0200 > Mark van Dijk <mark@voidzero.net> wrote: > >> Hi, >> >> On Wed, 28 Sep 2011 07:07:23 -0700 >> Tom Eastep <teastep@shorewall.net> wrote: >> >>> 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... 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. 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. 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? Good luck Ed W ------------------------------------------------------------------------------ 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
Ed W wrote:> >> 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... 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.Actually the point hasn''t been missed. The config file format is quite simple and easily generated from <some other system> if you want to do that. The suggestion above is simply to keep Shorewall as it is, and if someone wants something more complicated then they can script it. However, for things like shorewall, I think you''ll find the majority of configs are hand edited, and the comparison with HTML is completely bogus since there is no comparison whatsoever with the level of non-complexity found in a typical shorewall config.>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 alsoAnd no-one is stopping you from doing that. You can store your config in anything you like. All you have to do is write a script/query that will generate Shorewall''s config files - just as you''d have to write a script/query o generate the much more complex XML some people are suggesting. So I''m all for Tom keeping Shorewall just as it is. The config files are easy to work with as a human, and simple enough to machine generate for those that want to do it. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ 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
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