I was wondering if there could be a slight change to the Shorewall configuration files. It''s a Gentoo-specific issue but some other distributions might find some interest in this. Basically, whenever a Gentoo user updates his/her shorewall from portage via # emerge shorewall the ebuild asks the user to update the config files in /etc/shorewall and proposes going through diffs. The problem is that most of the time the user just has to update the header (i.e. documentation) of each config file. The user entries (e.g. shorewall rules) are usually left untouched unless there''s a new column in the new version, etc. So maybe if the Shorewall config files could source/include other "custom" config files then the upgrade process would be a lot easier. For example, default shorewall installation puts the rules file in /etc/shorewall. If the default rules file could contain a statement such as ". rules_custom" or "include rules_custom" the only real "diff" that the user would have to worry about is uncommenting this line in the new version. Of course one could define a different config file path in shorewall.conf and point to something like /etc/shorewall_custom. But by upgrading for example from 3.0 to 3.2 the user would have to deal with more than just file content. One would have to move over new files such as route_rules, etc. In other words the Gentoo emerge procedure would be to my understanding a lot simpler if the default configuration files could include custom files. I believe FreePBX/Asterisk does something of the sort (e.g. sip.conf can include sip_custom.conf). Maybe I''m overlooking something and I would greatly appreciate advice on this. Vieri __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> I was wondering if there could be a slight change to > the Shorewall configuration files. > > It''s a Gentoo-specific issue but some other > distributions might find some interest in this. > > Basically, whenever a Gentoo user updates his/her > shorewall from portage via > > # emerge shorewall > > the ebuild asks the user to update the config files in > /etc/shorewall and proposes going through diffs. > The problem is that most of the time the user just has > to update the header (i.e. documentation) of each > config file. The user entries (e.g. shorewall rules) > are usually left untouched unless there''s a new column > in the new version, etc.The issue is not Gentoo specific. With rpm based distributions, rpm doesn''t even try to merge configs. I have my own script to do that so I always have the original header after an upgrade. Your idea with includes sounds like a possible solution. Maybe there are other solutions as well, let''s wait for more people to think about. Simon ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Simon Matter wrote:> > The issue is not Gentoo specific. With rpm based distributions, rpm > doesn''t even try to merge configs. I have my own script to do that so I > always have the original header after an upgrade. Your idea with includes > sounds like a possible solution. Maybe there are other solutions as well, > let''s wait for more people to think about. >My preferred solution is to remove documentation from the config files entirely and move it somewhere else. I see no point in having the conf files INCLUDE the documentation or vice versa. My second choice would be to include Simon''s script (or a flavor of that script) in the product and allow users to generate configuration files that have documentation in them. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
On 10/26/06, Vieri Di Paola <vieridipaola@yahoo.com> wrote:> I was wondering if there could be a slight change to > the Shorewall configuration files. > > It''s a Gentoo-specific issue but some other > distributions might find some interest in this. > > Basically, whenever a Gentoo user updates his/her > shorewall from portage via > > # emerge shorewall > > the ebuild asks the user to update the config files in > /etc/shorewall and proposes going through diffs. > The problem is that most of the time the user just has > to update the header (i.e. documentation) of each > config file. The user entries (e.g. shorewall rules) > are usually left untouched unless there''s a new column > in the new version, etc.I don''t really see the point of updating the headers of the files, but not the content. AFAIK shorewall is usually able to run with ''older'' config files by assuming reasonable defaults. What you are proposing would be very confusing, because the rules that follow the header might not match the documentation in the header anymore. If you update one, you should also update the other, and the rules can''t be updated automatically, so it''s better to do this by hand alltogether.> So maybe if the Shorewall config files could > source/include other "custom" config files then the > upgrade process would be a lot easier. > For example, default shorewall installation puts the > rules file in /etc/shorewall. If the default rules > file could contain a statement such as ". > rules_custom" or "include rules_custom" the only real > "diff" that the user would have to worry about is > uncommenting this line in the new version. > > Of course one could define a different config file > path in shorewall.conf and point to something like > /etc/shorewall_custom. > But by upgrading for example from 3.0 to 3.2 the user > would have to deal with more than just file content. > One would have to move over new files such as > route_rules, etc. > In other words the Gentoo emerge procedure would be to > my understanding a lot simpler if the default > configuration files could include custom files. > I believe FreePBX/Asterisk does something of the sort > (e.g. sip.conf can include sip_custom.conf).Debian I believe does not do automatic updates of shorewall configuration files, for the reason mentioned above.> Maybe I''m overlooking something and I would greatly > appreciate advice on this. > > Vieri~David ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
David Mohr wrote:> On 10/26/06, Vieri Di Paola <vieridipaola@yahoo.com> wrote: >> I was wondering if there could be a slight change to >> the Shorewall configuration files. >> >> It''s a Gentoo-specific issue but some other >> distributions might find some interest in this. >> >> Basically, whenever a Gentoo user updates his/her >> shorewall from portage via >> >> # emerge shorewall >> >> the ebuild asks the user to update the config files in >> /etc/shorewall and proposes going through diffs. >> The problem is that most of the time the user just has >> to update the header (i.e. documentation) of each >> config file. The user entries (e.g. shorewall rules) >> are usually left untouched unless there''s a new column >> in the new version, etc. > > I don''t really see the point of updating the headers of the files, but > not the content. AFAIK shorewall is usually able to run with ''older'' > config files by assuming reasonable defaults. What you are proposing > would be very confusing, because the rules that follow the header > might not match the documentation in the header anymore. If you update > one, you should also update the other, and the rules can''t be updated > automatically, so it''s better to do this by hand alltogether. > >> So maybe if the Shorewall config files could >> source/include other "custom" config files then the >> upgrade process would be a lot easier. >> For example, default shorewall installation puts the >> rules file in /etc/shorewall. If the default rules >> file could contain a statement such as ". >> rules_custom" or "include rules_custom" the only real >> "diff" that the user would have to worry about is >> uncommenting this line in the new version. >> >> Of course one could define a different config file >> path in shorewall.conf and point to something like >> /etc/shorewall_custom. >> But by upgrading for example from 3.0 to 3.2 the user >> would have to deal with more than just file content. >> One would have to move over new files such as >> route_rules, etc. >> In other words the Gentoo emerge procedure would be to >> my understanding a lot simpler if the default >> configuration files could include custom files. >> I believe FreePBX/Asterisk does something of the sort >> (e.g. sip.conf can include sip_custom.conf). > > Debian I believe does not do automatic updates of shorewall > configuration files, for the reason mentioned above.Debian only populates /etc/shorewall with shorewall.conf and Makefile. shorewall.conf has been an ongoing headache because people blindly update it with the new options and their values then wonder why their Shorewall configuration suddenly stopped working. I''ve given up trying to change Shorewall''s default behavior over time by changing shorewall.conf -- from now on, any additions that I make to that file will set all new options to preserve the existing behavior rather than to produce the new more desirable behavior. In 3.4, I will start including a modified shorewall.conf in the sample configuration so that new users will get the new behavior while existing users will stop shooting themselves in the foot each time that they upgrade. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--- Tom Eastep <teastep@shorewall.net> wrote:> Simon Matter wrote: > > > > > The issue is not Gentoo specific. With rpm based > distributions, rpm > > doesn''t even try to merge configs. I have my own > script to do that so I > > always have the original header after an upgrade. > Your idea with includes > > sounds like a possible solution. Maybe there are > other solutions as well, > > let''s wait for more people to think about. > > > > My preferred solution is to remove documentation > from the config files entirely > and move it somewhere else. I see no point in having > the conf files INCLUDE the > documentation or vice versa. > > My second choice would be to include Simon''s script > (or a flavor of that script) > in the product and allow users to generate > configuration files that have > documentation in them.Just a thought but maybe most of the comments in the config files could be moved to separate documentation files. However, I think it is very useful especially during upgrades to have a quick overview of available parameters and general format (such as number of columns which may vary between versions). A trimmed rules file could look something like this: # Shorewall version X # Columns are: # # ACTION # ACCEPT # ACCEPT+ # NONAT # DROP # REJECT # DNAT # DNAT- # SAME # SAME- # REDIRECT # REDIRECT- # CONTINUE # LOG # QUEUE # <action> # <macro> # # SOURCE # [<zone>][:<interface>][:<address>] # # DEST # [<zone>][:<address>] # # PROTO # <protocol name or number> # # DEST PORT(S) # <port> # # CLIENT PORT(S) (Optional) # <port> # # ORIGINAL DEST (0ptional) # <address> # # RATE LIMIT # <rate>/<interval>[:<burst>] # # USER/GROUP # [!][<user name or number>][:<group name or number>][+<program name>] # #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP #SECTION ESTABLISHED #SECTION RELATED SECTION NEW #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE It''s more like keeping general synopsis so that people know at a glance what changed and where. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Vieri Di Paola wrote:> > --- Tom Eastep <teastep@shorewall.net> wrote: > >> Simon Matter wrote: >> >>> The issue is not Gentoo specific. With rpm based >> distributions, rpm >>> doesn''t even try to merge configs. I have my own >> script to do that so I >>> always have the original header after an upgrade. >> Your idea with includes >>> sounds like a possible solution. Maybe there are >> other solutions as well, >>> let''s wait for more people to think about. >>> >> My preferred solution is to remove documentation >> from the config files entirely >> and move it somewhere else. I see no point in having >> the conf files INCLUDE the >> documentation or vice versa. >> >> My second choice would be to include Simon''s script >> (or a flavor of that script) >> in the product and allow users to generate >> configuration files that have >> documentation in them. > > Just a thought but maybe most of the comments in the > config files could be moved ...Can we move this to the development list? Seems like a more appropriate forum. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642