Re: [leaf-devel] New LEAF Configuration System
On Tue, 2003-02-18 at 20:28, Tom Eastep wrote: > I have been watching the progress of the new LEAF configuration > mechanism with some interest and while I haven't had the time to follow > the various threads closely, I have formed some impressions and I have > some concerns. > > From what I understand, the new configuration system relies heavily on > (attribute,value) pairs. The idea seems to be to define these pairs > centrally and then propagate them into the various packages using some > sort of configuration API. I wouldn't worry. The config-db that Lynn, Eric and I are working on is actually based on a filesystem hierarchy. It is basically like a big perl nested hash, with the ability to nest arrays as well. It is actually working out pretty well. It can be accessed with full paths or relative paths. It can generate and be fed with name=value pairs, but that is where the nvp paradigm ends. The most recent code is in my cvs repository at devel/ccarr/devel/leaf-tools/cdb Take a look and see what you think. The documentation for cdb is devel/ccarr/devel/leaf-tools/cdb.help It is pretty close to complete. The test harness is in devel/ccarr/devel/leaf-tools/test-cdb.sh That will give some examples of different ways to use it, as well. > The bottom line is that (attribute,value) configuration is much less > flexible than the table-oriented configuration technique supported by > Shorewall and by reducing Shorewall configuration to (attribute,value) > pairs, you confine yourself to a very limited set of firewall > applications. When users outgrow that limited set, they must undergo a > paradigm shift and use a totally different configuration method. I think that the current filesystem hierarchy method will be able to represent any information currently in any of your files (carrying with it even more symbolic information than in a columnar table representation). Since the goal is to be able to configure shorewall and other applications, if we cannot ultimately represent everything in your configuration files, we have failed. Please let me know if you have any other fears when you see the implementation. > As I said at the outset, these impressions/concerns are formed from an > understanding of the current proposals that is far from complete. > Corrections and criticisms are welcome... Your input and code review is _greatly_ appreciated. As I said before, your code is extraordinarily well written and I have learned a lot about /bin/sh from reading it. If you find a construct in your configuration that you feel cannot be represented by this method, I will be happy to take a look at it and modify cdb if necessary. -- --- Chad Carr [EMAIL PROTECTED] --- --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] New LEAF Configuration System
I have been watching the progress of the new LEAF configuration mechanism with some interest and while I haven't had the time to follow the various threads closely, I have formed some impressions and I have some concerns. From what I understand, the new configuration system relies heavily on (attribute,value) pairs. The idea seems to be to define these pairs centrally and then propagate them into the various packages using some sort of configuration API. In one of my weaker moments, I introduced (attribute,value) pairs into Shorewall configuration management and it was a disaster. The idea was similar to today's sample Shorewall configurations but in my braindead implementation, each sample configuration included an /etc/shorewall/params file that tried to parameterize the user's entire Shorewall configuration via (attribute,value) pairs. The notion worked extremely well for first-time users with simple requirements -- they were able to get their first firewall working very easily and were very happy; UNTIL... they had to make their first configuration change where I hadn't included an (attribute,value) pair that expressed their particular requirement. These users were then left with the choice of: a) Pleading to me for help. b) Trying to understand BOTH the standard Shorewall configuration method AND my parameterizing scheme so they could extent the latter to conform to the former. c) Abandoning the (attribute,value) method of configuration and using the native Shorewall configuration technique. My conclusion was that the native Shorewall configuration method (table oriented) was the correct one for ALL users even if it required a bit more understanding on the part of the user to get their first firewall running. And that requirement for understanding Shorewall configuration has been largely ameliorated by the availability of the sample configurations and the QuickStart Guides. The bottom line is that (attribute,value) configuration is much less flexible than the table-oriented configuration technique supported by Shorewall and by reducing Shorewall configuration to (attribute,value) pairs, you confine yourself to a very limited set of firewall applications. When users outgrow that limited set, they must undergo a paradigm shift and use a totally different configuration method. As I said at the outset, these impressions/concerns are formed from an understanding of the current proposals that is far from complete. Corrections and criticisms are welcome... -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Ntpdate RCDLINKS
Le Mardi 18 Février 2003 20:03, Matt Schalit a écrit : > Lynn Avants wrote: > > On Monday 27 January 2003 02:06 pm, Matt Schalit wrote: > > > > > >>This can't work during boot, as my network needs the > >>firewall and nameservice to be completely functional. > >> > >> > >> > >>Am I the only one who thinks ntpdate should run here, > >>not in rcS, but in rc2? RCDLINKS="2,S90" > > > > > > > > I would have to agree with you there Matt in fact, I see > > ntpdate as more of a userspace utility and might be more > > proper in runlevels 3,4,5 instead of single-user. In any case, > > the network and preferrably name-service should be up > > when it runs. > > Is there anyone listening who's responsible for ntpdate.lrp, > and if so, have you considered making the suggested change? > OK done. This is a Debian bug by the way (at least in Woody) I fixed it to "2,S51". New packages have been uploaded . Jacques --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF planned outage 2003-02-18
On Tue, 2003-02-18 at 11:49, Larry Platzek wrote: > On 18 Feb 2003, Mike Noyes wrote: > > SF.net will be off-line tonight for planned maintenance. > > > > https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 > > (2003-02-18 04:53:29 - SourceForge.net Web Site) A scheduled outage > > of the SourceForge.net site (for system maintenance and performance > > tuning) will occur on 2003-01-18 at 16:00 Pacific, with an expected > > duration of not more than seven hours. > > > Mike: > How to they "Plan" an outage in the past? Read the date when they > posted the notice and planned outage. I think it is poor planning on there > part to give notice on day of planned outage. Larry, Thanks for noticing the problem. I informed the SF staff of the error. As for the short notice, I suspect this maintenance is related to cvs performance. A very high priority for the SF staff. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF planned outage 2003-02-18
On 18 Feb 2003, Mike Noyes wrote: > Date: 18 Feb 2003 11:35:15 -0800 > From: Mike Noyes <[EMAIL PROTECTED]> > To: leaf-devel <[EMAIL PROTECTED]> > Subject: [leaf-devel] SF planned outage 2003-02-18 > > Everyone, > SF.net will be off-line tonight for planned maintenance. > > https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 > (2003-02-18 04:53:29 - SourceForge.net Web Site) A scheduled outage > of the SourceForge.net site (for system maintenance and performance > tuning) will occur on 2003-01-18 at 16:00 Pacific, with an expected > duration of not more than seven hours. > > -- > Mike Noyes > http://sourceforge.net/users/mhnoyes/ > http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ > Mike: How to they "Plan" an outage in the past? Read the date when they posted the notice and planned outage. I think it is poor planning on there part to give notice on day of planned outage. Oh well, I guess people will live with the outage. Larry Platzek [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] SF planned outage 2003-02-18
Everyone, SF.net will be off-line tonight for planned maintenance. https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 (2003-02-18 04:53:29 - SourceForge.net Web Site) A scheduled outage of the SourceForge.net site (for system maintenance and performance tuning) will occur on 2003-01-18 at 16:00 Pacific, with an expected duration of not more than seven hours. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Ntpdate RCDLINKS
Lynn Avants wrote: On Monday 27 January 2003 02:06 pm, Matt Schalit wrote: This can't work during boot, as my network needs the firewall and nameservice to be completely functional. Am I the only one who thinks ntpdate should run here, not in rcS, but in rc2? RCDLINKS="2,S90" I would have to agree with you there Matt in fact, I see ntpdate as more of a userspace utility and might be more proper in runlevels 3,4,5 instead of single-user. In any case, the network and preferrably name-service should be up when it runs. Is there anyone listening who's responsible for ntpdate.lrp, and if so, have you considered making the suggested change? No rush, but not sure if this has happened yet. Thanks, Matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Ann: LEAF Bering-uClibc 1.1 and LEAF Bering-uClibc 1.0.3
LEAF Bering-uClibc 1.1 is ready for download at: http://sourceforge.net/project/showfiles.php?group_id=13751 This release is an upgrade for LEAF Bering-uClibc 1.0.x, in sync with Bering-1.1 and partly based on the wonderful work of the original Bering crew. Some of the new features: - Kernel 2.4.20 - updates of various packages (shorewall, tinylogin, ipsec,...) - cleanup of etc.lrp - usual bugfixes For details, you may read the changelog: http://leaf.sourceforge.net/mod.php?mod=userpage&menu=91003&page_id=39 A bootable ISO-image with all packages currently available for the Bering-uClibc environment can be downloaded from the cvs repository: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/bering-uclibc/cd/Bering-uClibc-1.1.iso This image is bootable via a floppy bootdisk image and not with isolinux - allowing it to boot on older PC's with a "defect" BIOS, but please note, some may still not work as noted by HP Anvin. For more information about syslinux/isolinux browse to: http://syslinux.zytor.com In addition LEAF Bering-uClibc 1.0.3 is available at: http://sourceforge.net/project/showfiles.php?group_id=13751 This is a maintenance release for Bering-uClibc 1.0 series. The only change to from 1.0.2 to 1.0.3 is a bugfix for ash compiled against uClibc, which solves a few problems with weblet.lrp. Every help improving Bering-uClibc and getting it ready for download, has been appreciated. Thanks for your attention. on behalf of Bering-uClibc team kp --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The future of Bering
Chad Carr wrote: Unfortunately, this fact is a monument to the level of skill and dedication that a product of this caliber demands. It is extraordinarily complete, and I believe that the person who takes it over (even if they are an iptables master) will be in learning mode for a long time to come. Also, the code is a dream. It is modular, tightly written, beautifully documented and well commented. Whoever has the balls to take this one over will learn a lot about good software coding practices. Thanks, Chad -- I believe that the 1.3 code is still very maintainable and the 1.4 code will be even more so because it removes a fair bit of built-up cruft. Tom, how much assistance (and for how long) are you willing to give the apprentice? Once I get 1.4 out the door (middle of next month is the target), I can devote all of my "Shorewall time" to the transfer. I'm willing to answer questions indefinitely. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Patches-688526 ] safe boot/backup
Patches item #688526, was opened at 2003-02-18 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=688526&group_id=13751 Category: Release/Branch: Bering Group: None Status: Open Resolution: None Priority: 5 Submitted By: Przmyslaw Rudy (prudy) Assigned to: Jacques Nilo (jnilo) Summary: safe boot/backup Initial Comment: Originally when you do the backup of the lrp files they will overwrite the original files from the floppy. In the case of any mistake (e.g. wrong firewall settings) it is possible that you will prevent yourself from remote access to the system. The four files below are modified to add the test boot/backup option: root.linuxrc - from the initrd.lrp package lrcfg - from the root.lrp package lrcfg.back.script - from the root.lrp package lrcfg.back - from the root.lrp package How does it work? After enable test backup/boot in the backup menu all packages will be created in the testbkp directory and original files will not be overwritten. As well the lrpkg.cfg file can be manually created in this directory. Finally, the tbmark file is created on the floppy to indicate the next boot is the test boot. If the test boot is fine, the system will be rebooted to the original configuration automatically after 5 min. Additional menu option allows to disable automatic reboot. As well there are three options in the backup menu to decide what to do with the tested files (including use them during the next boot as the default files, etc.) In the case of any problem during the test boot time, original configuration will be used instead. Reboot depends on the /sbin/shutdown which must be uncompressed correctly. Note: From the obvious reason the test backup option does not work for the initrd.lrp package. Note: I have noticed that in the root.linuxrc the gunzip does not return error code if the *.lrp is corrupted (I tested it on 0 size file), so I changed the lines: gunzip -c $mnt/$f.lrp > /dev/null if [ $? -eq 0 ]; then to: RVAL=`gunzip -c $mnt/$f.lrp 2>&1 > /dev/null` if [ $? -eq 0 -a "x$RVAL" = "x" ]; then -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=688526&group_id=13751 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
