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 <package>.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 <package>.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 <package>.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 <package>.lrp for the released package, and <package>.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 <package>.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
