Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Erich Titl wrote: Tom At 18:02 13.04.2004, Tom Eastep wrote: Erich Titl wrote: Does it have to be populated? I think so if the /var/lib/lrpkg/shorwall.conf file points to it. It could just use it if it exists (and makes sense). My point is that /var/lib/lrpkg/shorwall.conf should not point to files that do not exist. I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. Well, I believe they are not necessarily mutually exclusive. If we include let's say /etc/shorewalluser/* in /var/lib/lrpkg/shorewall.list and /etc/shorewalluser/shorewall.conf in the /var/lib/lrpkg/swconf.list then, if swconf.lrp _was_ installed, the user configuration would be saved to swconf.lrp, else it would be saved to shorewall.lrp. In any case you would not need to populate /etc/shorewalluser/shorewall.conf as the backup script would take care of user config data. This sounds complicated, but from a user's perspective would be almost invisible. Well, it sounds complicated to me -- I'm lost :-) The main point I would like to see is a fallback configuration file which would be used if the user configuration is missing or produces a failure, so shorewall does not abort completely. I assume that by "configuration file" you mean shorewall.conf (as opposed to shorwall.conf in /var/lib/lrpkg/). -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom At 18:02 13.04.2004, Tom Eastep wrote: Erich Titl wrote: Does it have to be populated? I think so if the /var/lib/lrpkg/shorwall.conf file points to it. It could just use it if it exists (and makes sense). If Shorewall has a fallback set up which would be overridden by user configuration data then Shorewall would have a default configuration initially unless there is a user configuration file present. The shorewall.list would include the user configuration file but initially this file would be missing in the shorewall.lrp file. Loading a new release would thus not overwrite user configuration data. As soon as this configuration is saved then the newly created shorewall.lrp would contain the user configuration data valid at save time and therefore hold the complete configuration. Is this feasible? I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. Well, I believe they are not necessarily mutually exclusive. If we include let's say /etc/shorewalluser/* in /var/lib/lrpkg/shorewall.list and /etc/shorewalluser/shorewall.conf in the /var/lib/lrpkg/swconf.list then, if swconf.lrp _was_ installed, the user configuration would be saved to swconf.lrp, else it would be saved to shorewall.lrp. In any case you would not need to populate /etc/shorewalluser/shorewall.conf as the backup script would take care of user config data. This sounds complicated, but from a user's perspective would be almost invisible. The main point I would like to see is a fallback configuration file which would be used if the user configuration is missing or produces a failure, so shorewall does not abort completely. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [Fwd: Re: Mike Noyes]
Am Dienstag, 13. April 2004 13:09 schrieb Charles Steinkuehler: > Mike Noyes has been in a bicycle accident (see message below). > > If I get any more details, I'll let everyone know. Thx for info Charles - bad news. Best wishes to Mike - I hope he'll be back soon and healthy again. kp --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Charles Steinkuehler wrote: I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. Are you referring to the lrcfg configuration menu, created from the .conf files in /var/lib/lrpkg? Yes. If so, I think you can 'cheat', within limits. If both the main and configuration shorewall packages are distributed as a unit and always used as a pair (except maybe by folks who really know what they're doing), I don't think there would be a problem with making the *.conf file part of the main shorewall package, rather than the config package. If people always install these packages in pairs then we may as well just keep the single package. I suppose that when a new configuration file is added, we can have the user manaually copy the new file from /etc/shorewall to /etc/shorewalluser then back up the swuser package. While it might seem odd to have the .conf file in a different package than the actual files it's setup to edit, it really makes sense when you consider the second package is for actual user-modified configuration files, rather than being a true stand-alone package. The .conf file is *NOT* a user-modified config file, so putting it in the main shorewall package seems reasonable. I agree. With the additional manual steps I've outlined above, this could be workable. People would just have to retrain themselves to backup swuser rather than shorwall. I've even thought of making a packaging system that would do this sort of thing automatically, using for example .lrp for the released package, and .cfg for the user-modified files. This would only take a very slight re-working of my current backup scripts to implement. I have not yet done anything like this because: - I don't really need it personally (the current scripts work well for CD-ROM based systems, which is mainly what I run). - I don't have a lot of time for development (8 month old twins!) - I don't want to pull the rug out from under the new configuration scheme and hopefully a more full-featured packaging system. Nod. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom Eastep wrote: Erich Titl wrote: Does it have to be populated? I think so if the /var/lib/lrpkg/shorwall.conf file points to it. If Shorewall has a fallback set up which would be overridden by user configuration data then Shorewall would have a default configuration initially unless there is a user configuration file present. The shorewall.list would include the user configuration file but initially this file would be missing in the shorewall.lrp file. Loading a new release would thus not overwrite user configuration data. As soon as this configuration is saved then the newly created shorewall.lrp would contain the user configuration data valid at save time and therefore hold the complete configuration. Is this feasible? I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. Are you referring to the lrcfg configuration menu, created from the .conf files in /var/lib/lrpkg? If so, I think you can 'cheat', within limits. If both the main and configuration shorewall packages are distributed as a unit and always used as a pair (except maybe by folks who really know what they're doing), I don't think there would be a problem with making the *.conf file part of the main shorewall package, rather than the config package. While it might seem odd to have the .conf file in a different package than the actual files it's setup to edit, it really makes sense when you consider the second package is for actual user-modified configuration files, rather than being a true stand-alone package. The .conf file is *NOT* a user-modified config file, so putting it in the main shorewall package seems reasonable. Essentially, this is doing with two differently named packages what I do with two identically named packages from different sources: Splitting the modifiable configuration files and 'static' content. I've even thought of making a packaging system that would do this sort of thing automatically, using for example .lrp for the released package, and .cfg for the user-modified files. This would only take a very slight re-working of my current backup scripts to implement. I have not yet done anything like this because: - I don't really need it personally (the current scripts work well for CD-ROM based systems, which is mainly what I run). - I don't have a lot of time for development (8 month old twins!) - I don't want to pull the rug out from under the new configuration scheme and hopefully a more full-featured packaging system. On the other hand, support for .cfg files would be very easy to add (maybe a couple hours of scripting, since the bulk of the support is already in place), and would be very handy for folks running on flash, hdd, or similar (I'm not sure if the floppy folks would have enough room for many extra files, especially if partial/.cfg backups of /etc include pretty much the whole directory as they do now (another 20+ KB)). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Erich Titl wrote: Does it have to be populated? I think so if the /var/lib/lrpkg/shorwall.conf file points to it. If Shorewall has a fallback set up which would be overridden by user configuration data then Shorewall would have a default configuration initially unless there is a user configuration file present. The shorewall.list would include the user configuration file but initially this file would be missing in the shorewall.lrp file. Loading a new release would thus not overwrite user configuration data. As soon as this configuration is saved then the newly created shorewall.lrp would contain the user configuration data valid at save time and therefore hold the complete configuration. Is this feasible? I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom At 16:05 13.04.2004, you wrote: Erich Titl wrote: As I suggested some time ago could this be solved by falling back to the default shorewall.conf file if the file pointed to by CONFIG_PATH did not exist? Let say that for LEAF, the CONFIG_PATH is: /etc/shorewalluser:/etc/shorewall:/usr/share/shorewall Shorewall continues to release its configuration files into /etc/shorewall. a) It seems like the entries in /var/lib/lrcfg/shorwall.conf need to point to /etc/shorewalluser. b) Shorewall can't release files into /etc/shorewalluser because then a Shorewall upgrade will overwrite those files. So how does /etc/shorewalluser get populated initially? Does it have to be populated? If Shorewall has a fallback set up which would be overridden by user configuration data then Shorewall would have a default configuration initially unless there is a user configuration file present. The shorewall.list would include the user configuration file but initially this file would be missing in the shorewall.lrp file. Loading a new release would thus not overwrite user configuration data. As soon as this configuration is saved then the newly created shorewall.lrp would contain the user configuration data valid at save time and therefore hold the complete configuration. Is this feasible? cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom Eastep wrote: Erich Titl wrote: As I suggested some time ago could this be solved by falling back to the default shorewall.conf file if the file pointed to by CONFIG_PATH did not exist? Let say that for LEAF, the CONFIG_PATH is: /etc/shorewalluser:/etc/shorewall:/usr/share/shorewall Shorewall continues to release its configuration files into /etc/shorewall. a) It seems like the entries in /var/lib/lrcfg/shorwall.conf need to point to /etc/shorewalluser. b) Shorewall can't release files into /etc/shorewalluser because then a Shorewall upgrade will overwrite those files. So how does /etc/shorewalluser get populated initially? I'm not sure I'm following along completely, but this sounds a lot like the general problem encountered when trying to update any *.lrp package: the configuration files are in the same package as the application, and the whole filesystem is re-created from scratch every boot (so there's no "remembering" the configuration data from a previously installed package version). I know of two ways to work around this: 1) Put configuration data in a seperate package, ie: swconf.lrp would 'own' files in /etc/shorewalluser (or even /etc/shorewall), so replacing shorewall.lrp with a new version wouldn't overwrite existing configuration data. 2) Use partial backups (implemented in Dachstein and Bering). This isn't a real graceful solution for someone with a single boot disk, but can work well if you're running from CD, HDD, or can otherwise configure two (or more) package repositories. One holds the unconfiugred distribution packages (the CDROM in my case), while the other holds partial backups (typically just the configuration data) that get loaded on top of the default configuration files provided with the base package. There is a new package file in /var/lib/lrpkg (.local) which defines which files are to be included or excluded when doing a partial backup. If this file doesn't exist, the scripts default to putting any files in /etc or /var/lib/lrpkg that are defined in the .list file in the partial backup. #2 works really well for CDROM based systems (or systems that can configure two package storage locations). To upgrade shorewall, ssh, or whatever, I simply burn a new CD containing the updated packages, insert it into my firewall (with it's single configuration floppy), and reboot. Excuse the interruption if I'm not correctly understanding your problem...I haven't been closely monitoring this thread. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Erich Titl wrote: As I suggested some time ago could this be solved by falling back to the default shorewall.conf file if the file pointed to by CONFIG_PATH did not exist? Let say that for LEAF, the CONFIG_PATH is: /etc/shorewalluser:/etc/shorewall:/usr/share/shorewall Shorewall continues to release its configuration files into /etc/shorewall. a) It seems like the entries in /var/lib/lrcfg/shorwall.conf need to point to /etc/shorewalluser. b) Shorewall can't release files into /etc/shorewalluser because then a Shorewall upgrade will overwrite those files. So how does /etc/shorewalluser get populated initially? -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom At 18:31 10.04.2004, Tom Eastep wrote: Tom Eastep wrote: Stijn Jonker wrote: It works fine here after a small modification in "firewall" on line 5757: Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... /usr/share/shorewall/firewall: line 5757: [: missing `]' firewall:5757 [ -n "$CONFIG_PATH"] || CONFIG_PATH=/etc/shorewall:/usr/share/shorewall changed it to: [ -n "$CONFIG_PATH" ] || CONFIG_PATH=/etc/shorewall:/usr/share/shorewall Maybe it has to do with the version of sh/bash: Just a plain ordinary bug -- thanks. I've updated CVS with the correction. Now that this feature is implemented, I would like to re-open our earlier discussion about how the Shorewall LRP should be structured. As a starter, I would be happy to release the LRP's shorewall.conf file with a special CONFIG_PATH. I would think though that a change in the /var/lib/lrcfg/shorwall.conf file would also be in order so that the entries pointed to a directory that wasn't overwritten when a new Shorewall LRP was loaded. What is unclear to me is how this directory gets populated initially. As I suggested some time ago could this be solved by falling back to the default shorewall.conf file if the file pointed to by CONFIG_PATH did not exist? Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [Fwd: Re: Mike Noyes]
Mike Noyes has been in a bicycle accident (see message below). If I get any more details, I'll let everyone know. -- Charles Steinkuehler [EMAIL PROTECTED] Original Message Subject: Re: Mike Noyes Charles, Mike was in a accident. He is in the hospital. He asked me to let you know that he would not be working on the WEB page for a while. He hit his head while riding his bicycle. He was in surgery for 3.5 hours. It looks good for a full recovery. I do not expect him to start work on the WEB page before next week. Phil Noyes --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
