Re: [leaf-devel] Config system
On Tuesday 04 February 2003 09:20 pm, Matt Schalit wrote: > * Ok Ray. I agree with you on the need for a simple file >of name=value pairs. > > * Ok Charles, I agree that the format shouldn't matter much, >and that XML has many advantages. XML and nested directories are extremely nice and convient IF you have a language that works well with it. How are you supposed to parse it on the LEAF box??? I can gather the advantages on an external pre-config, but I don't figure to write the back-end in C, perl, or awk to run on the LEAF box itself. I really don't care how the front-end (GUI/whatever) gets the information to the backend (*cfg), I worry about how to parse the file(s) generated with the backend regardless of whatever front-end is being used. I feel forced to assume that the file(s) generated by the pre-/post- config MUST be compatible. If a 'tree' like proc is used, is there an example of a decent way to parse "unexpected" variables (from a new package) with the shell or is someone volunteering to do this in C? My opinion (at the moment) is that there is nothing simpler to parse than a single file of variables. especially if 'cut' would use whitespace as a delimiter. ;-) > But it was pointed out to me that the XML database in Chad's idea > was something to be kept seperate from LEAF and not stored on it. > I think that the XML is used on seperate OS to configure the system. > I think the idea of Chad's was to combine an XML config-db with a > remote based gui and produce template-built runtime conf files > that would be used on the LEAF. I hate to say it, but it sounds like putting a pretty picture on what we have now to some degree. Now, if it would generate a flat-db or 'tiny' set of files, I could see the advantage. > Proposed Solution: > == > Can we merge the two ideas by making the master-db maybe XML > but also unleash sed on it to output a running config of > name=value pairs to a single file, /var/run/flat? > > > If we do that, then you'd have your choice of using the api > to access the XML db, or using /var/run/flat: > > a) If you use the api to change the xml, the api also updates > /var/run/flat. > > b) If you hand edit /var/run/flat, you would run leafill which would > "refill" the XML db and trigger all dependant files to be reloaded. > > > Sound good? > > It's merely an extra sed and an update.sh. It may be worth it to > have this redundancy. Anyone concur? It would mean a big XML > or similar db stored on your leaf diskette and an api to handle it. It does. Any guesses on the size of the code bloat? Size of 'leafill'? I'm guessing ~x3-x4" for the combined option. Out of the packages I'm auditing, only Shorewall sticks out as being a PITA to handle, but I think Eric has a grasp on that one. Then again I assume there will (or can be) several front-end options available. If a GUI was all that was desired, most of us would be using Mosquito or BBIagent. Just for kicks, someone run off a PacketFilter floppy and run it on a router to the login prompt and give me an opinion.. I think there is an incrediable value to a prompt script more times than not. > > To be used with LEAF, packages typically require some modification > > anyway. Why not adopt a "one-stop-shopping" standard for config > > variables that makes them easily available to any package? > > I think we all concur on this, Ray. OT, but the additions I would suggest for the packages would be a $package.opt file that contains all variables in that package with the default first and a $package.dep that contains non-base dependant packages. This would work regardless of the db-format. > > Then when > > someone adapts a package, he or she at least has the option of having it > > get its config info from a standard place in an easy fashion. What I > > mean here is a single text file, with a simple name=value format, that > > contains all the basic information needed by networking packages, in a > > form that init and config scripts can use easily (like the old > > network.conf, which used a format that allowed all entries to be loaded > > as shell variables). The key to keeping this manageable is that it > > contains nothing but > > > > VARIABLE_NAME=value lines > > Yes. > > > #commentlines > > Yes. That will be fine you can use the #descript as a package identifier or a trigger of sorts. Just avoid using: VAR = value #descript you'll end up with a unusual prompt when parsed. ;-) > > and lines that do minor manipulation of VARIABLE_NAME lines > > (e.g., something like > > NETWORK_INTERNAL=$INTERFACE_INTERNAL/$NETMASK_INTERNAL > > ) This could be done just as easy in the existing *.conf file that we are adding the variables into. I don't think it belongs in the db either. > I think we all concur. Any variable that can be common > to severa
[leaf-devel] Where I've been...
It's been a long and winding road Mostly, I've had other things to divert my attention. There's been installs of FreeBSD, KDE, SuSE, and Yellow Dog along the way. I'm also gained a couple of certifications, and have also had fun working with Red Hat's Kickstart. Very recently, I've been working with Knoppix - beautiful! I've also had my main mail server switch ISPs and IPs in the last six months. Ouch. I want to get Oxygen development going again. Once I get geared up for cvs again, then I'll start updating the packages and shooting for Linux 2.4. I've been working with 2.4.19-aa1; anybody use Andrea's kernels on 12M machines? My experience with my SuSE kernel is that it has "swap storms" that come out of nowhere - and this in 192M with KDE and X. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The ideas presented so far...
On Tue, 2003-02-04 at 14:19, Matt Schalit wrote: > > > Chad Carr wrote: > > > > May I suggest that the config-db be maintained as a "config-tree," with > > the root at /leaf-cdb (or something shallow like that) and keys may be > > nested as deeply as needed by creating directory levels. I.e. you could > > make the key > > > > interfaces/eth0/ipaddr > > > > like this: > > > > echo -n "172.24.8.24" > /leaf-cdb/interfaces/eth0/ipaddr > > > > I also like the idea of a config-tree, Chad. It's proven > itself useful for Linux a la /proc. > > > I wish the config-tree api to have significant lattitude in how > it displays the data: > > >a) Something along the lines of a -H argument the way "who -Hu" > prints out column headers. >b) The ability to dump var=value pairs to stdout. That's cool. I am game for anything. It seems that the second way would be most useful for operation, but perhaps the first would be good for display purposes, or something. > Would you like to remark any furthur on how a tree is significantly > better than a single config-db file and how the tree would store a > variable's "type" information, for instance? The main reason we (at Toshiba) chose a tree is that it allows for the display of complex data structures without the use of any parser. It also allowed us to separate centralized configuration data into separate files that would not wreak havoc with RPM's (we used RedHat at Toshiba) hellish dependency structure and would not require the use of carefully hand-rolled postinstall scripts to modify global configuration files. Not as much of an issue here since packages are not dependent on LEAF, but what the hell. It also allows a package to "own" (and back up) a piece of the central config-db without fear of it getting overwritten by another package, horked up by another package, deleted by another package, etc. The main part of the system is the templating and trigger system that abstracts the config-db away from the runtime requirements of the packages themselves. It allows any sort of transformation to take place between the config-db and the actual configuration of the running application. As far as type info, there should be none. The storage should be strings (everything in the file is considered part of the "value"; we may have to consider a proper shell escaping feature in the api) and the caller should determine how he is going to interpret the data. What is an example of needed a real "type" and what would they be? The hierarchy could handle just about anything, in my opinion, but I don't think type information is really needed. I could be wrong. --- Chad Carr [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system (long)
On Tue, 2003-02-04 at 19:20, Matt Schalit wrote: > But it was pointed out to me that the XML database in Chad's idea > was something to be kept seperate from LEAF and not stored on it. > I think that the XML is used on seperate OS to configure the system. > I think the idea of Chad's was to combine an XML config-db with a > remote based gui and produce template-built runtime conf files > that would be used on the LEAF. I think I haven't been following this thread closely enough. Or maybe I have not been perfectly clear. Or maybe you are talking about a different Chad. Sorry for the mixup and long post on any of the above. I do not think that XML is suitable for LEAF (pre or post config). My config-db-as-filesystem-hierarchy idea consists of a key-value pair "database" that happens to be made up of separate files for each key-value pair. The "api" generates sourceable name-value pairs that can be eval'd by shell scripts. It is meant to be used _on_ the system. Please do not confuse this with what I actually have in my devel source tree. The two are not interrelated (and I have not done any actual work on this one ;-)) This is a slightly modified version of what I sent Lynn offlist this morning to better explain my _theory_ (emphasis on theory since I haven't actually done any of it yet). The basic idea is that there is an api that gives you sourceable material from the tree relative to the path /leaf/cdb, something like this: leaf-cdb get interfs/eth0/ipaddr returns: interfs_eth0_ipaddr=172.24.8.24 if the /hydra/cdb/interfs/eth0/ipaddr file contains 172.24.8.24 so the calling script can just eval it like so eval `leaf-cdb get interfs/eth0/ipaddr` This also works for entire trees or arrays of material from the "database:" eval `leaf-cdb get tree interfs/eth0` # now I can use relative paths; ipaddr, netmask, gateway, etc The templating system is much harder. I am afraid it would need to be written in C. Ideally, you could use it like this: leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces would generate the /etc/network/interfaces file using the "symbol table" from the output for the leaf-cdb command. This may, however, be really very hard without perl. The piece de resistance is the trigger system. The template and config-db systems are just support. The trigger system makes it go. Something like: leaf-trig fire ip_change eth0 would use run-parts to run all the scripts dropped into the /leaf/trig/ip_change directory with the argument eth0. One of these scripts will call leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces and then restart the network. The scripts are prioritized like rc scripts to resolve temporal coupling. If I need to respond to the ip_change event, I can simply drop a script into /leaf/trig/ip_change. If I do not care when ppp* interfaces change, I can bail immediately if the first argument starts with ppp. So, for a web interface, the work flow could go something like this: # optionally feed name-value pairs on stdin leaf-cdb set tree interfs/eth0 ipaddr 172.24.8.24 netmask 255.255.255.0 gateway 172.24.8.1 leaf-trig fire ip_change eth0 Then the handler scripts take it away: - file /leaf/trig/ip_change/001interfaces: modifies interfaces and restarts network - #!/bin/sh leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces /etc/init.d/network restart - file /leaf-trig/ip_change/10minhttpd: modifies minhttpd startup script that has ip address in it, then restarts minhttpd - #!/bin/sh leaf-cdb get tree interfs | leaf-tmpl -o /etc/init.d/minhttpd /etc/init.d/minhttpd restart Simple to use, if it is designed properly. However, the technical hurdles of the implementation may prove to be too much. It is easily done with perl (as are many things), but the power and simplicity of shell and C, especially when used together, are great (as all UNIX folks know) and I think it can be done. The beauty of this is that the trigger responder does not know who fired the trigger, the one responsible for firing the trigger does not know (or care) who is listening, and the config-db is just an anonymous backend data store (strangely, it can even be used to store the results of temporal events, like the result of a particularly sensitive templating operation, for anonymous retrieval later) decoupled from any specific package. I am not trying to convince folks. I am not even sure that the technical hurdles can be overcome without perl. I am no C guru, but I can hold my own and would be willing to work on it if shell does not suffice to create the interfaces we are looking for. So, to recap my carefully considered opinion (if anyone cares): - No XML (especially not on the box) - one file per name-value pair - hierarchy is still hand-editable - h
Re: [leaf-devel] Config system
Matt Schalit wrote:
Ray Olszewski wrote:
At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote:
But it leaves one thing out ... an important way to simplify the
interface for configuration is to restrict the range of choices
available.
LEAF tends to be pulled in two directions all the time --
simplicity, so that common uses of it can be configured
easily by relatively inexperienced users.
flexibility, so that unusual uses of it are possible for
relatively skilled, experienced users.
My interest has always been in the first direction, but the diversity
of our interests means that both directions need to be accommodated.
My interests have always been the latter...
David D. tried to go down this road with Oxygen, and
once he started, his development here drifted off.
So I can't tell you much about it, because it didn't
work very well, but here's what he did.
He made a syslinux boot option to boot into setup
mode where you were presented with several options
on the overall use of your LEAF box: router, print-server,
DMZ, some other choices along those lines. I probably
got them wrong, but you get the idea. I thought it
was bad to begin with.
What I think is a good idea, however, is a gui-based, drag
and drop interface where you have a big outline of a computer,
and you drag a couple of nic icons onto it. Then you drag a
clock icon onto it (ntpdate) and then you drag a firewall
icon into the middle of it, and maybe some other objects.
Then you are walked through configuring each one.
When I designed my setup program, I thought about what would Adam
Average want to do? He wants to boot the disk, and be led through all he
needs. Someone said he needed a router - so he picks that. Each dialog
was designed to lead the uninformed individual along. If there was no
getting around the gear talk ("what's your IP?") it specifically
suggested asking for technical help.
The alternative suggested poses some problems. Suppose Eva Everybody
wants to set up something to go between her PC and her DSL. I can hear
the questions Eva might be asking:
"NIC? What's a nic? What's that card thing? Why do I need ntpdate?
What is it? Where do I get it? What's an IP?"
My goals for Oxygen evolved into creating a floppy-based, network-based
Linux that was as UNIX-compatible as possible - no surprises for UNIX
admins.
My goals for the setup program was much different: create a
configuration set which was extremely flexible, extensible, and
compatible with X. If you specified a DISPLAY variable, you could use
and X display and answer the same questions there
Biggest problem I had was trying to keep the quotes straight for using
dialog and Xdialog. Perhaps I should have used a different shell?
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
Ray Olszewski wrote: At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote: A few quick points about some of the recent discussion: Regarding the config-db format: It really doesn't matter. The files should be human-readable (plain text), with enough structure (probably via filesystem directories and filenames) to be easily navigated, but all access to the database information by the packaging and any configuration system will be through a defined API, allowing the back-end format to change if required. Who knows...future versions might move to a packed binary format with small C or assembly programs for access, to save space and/or gain speed. While initially a lack of tools may require "power-users" to hand-edit database entries, I would generally consider this unsafe and discourage the practice. I'd like to disagree with this. It really does matter. One of the big strengths of the anscestral LRP (Dave Cinege's version, I mean) was the simplicity of its basic network.conf file. As LRP first went to the mountains, then evolved into LEAF, and as LEAF tried harder and harder to incorporate many specialized packages, each with its own config files and syntax, much of this simplicity was lost. Yes there was some amount of simplicity across a LRP release that stemmed from his tight-a## control over it. I guess that was a pretty big benefit. I think part of that simplicity was inherent to the lack of complex networking it could do combined with it's lack of firewall. When Charles built those into his releases, combined with PPPoE and ipchains and all the other new challenges, it made spaghetti at first glance. I think the central config-db idea gets us right back to simplicity. I've probably typed more keystrokes on this subject than it would take to gather all the variables and make a test config-db. Let me say that I am only one voice, with no expectations that I'm right about these discussions, but that being said, I'll voice my thoughts, if only to flesh this out a bit * Ok Ray. I agree with you on the need for a simple file of name=value pairs. * Ok Charles, I agree that the format shouldn't matter much, and that XML has many advantages. But it was pointed out to me that the XML database in Chad's idea was something to be kept seperate from LEAF and not stored on it. I think that the XML is used on seperate OS to configure the system. I think the idea of Chad's was to combine an XML config-db with a remote based gui and produce template-built runtime conf files that would be used on the LEAF. But back to the discussion of a LEAF based XML or flat db Proposed Solution: == Can we merge the two ideas by making the master-db maybe XML but also unleash sed on it to output a running config of name=value pairs to a single file, /var/run/flat? If we do that, then you'd have your choice of using the api to access the XML db, or using /var/run/flat: a) If you use the api to change the xml, the api also updates /var/run/flat. b) If you hand edit /var/run/flat, you would run leafill which would "refill" the XML db and trigger all dependant files to be reloaded. Sound good? It's merely an extra sed and an update.sh. It may be worth it to have this redundancy. Anyone concur? It would mean a big XML or similar db stored on your leaf diskette and an api to handle it. To be used with LEAF, packages typically require some modification anyway. Why not adopt a "one-stop-shopping" standard for config variables that makes them easily available to any package? I think we all concur on this, Ray. Then when someone adapts a package, he or she at least has the option of having it get its config info from a standard place in an easy fashion. What I mean here is a single text file, with a simple name=value format, that contains all the basic information needed by networking packages, in a form that init and config scripts can use easily (like the old network.conf, which used a format that allowed all entries to be loaded as shell variables). The key to keeping this manageable is that it contains nothing but VARIABLE_NAME=value lines Yes. #commentlines Yes. and lines that do minor manipulation of VARIABLE_NAME lines (e.g., something like NETWORK_INTERNAL=$INTERFACE_INTERNAL/$NETMASK_INTERNAL ) I disagree. I'd want the db to be literal. "name" = "some value" so spaces and special characters don't matter, and the # comment lines. I'm not sure why, but I don't think it's the db's responsibility to do 2nd level substitutions. The other key is to enter each value exactly once. Consider again the recent thread on leaf-user where someone wanted to change his (Dachstein) internal network to 10.10.10.0/24. After he made way too many separate changes in network.conf, he had to edit the DHCP config file
[leaf-devel] kpalived.lrp now available, [minor] update to bgpd.lrp and zebra.lrp
I have completed my high-availability package for .lrp systems, "kpalived.lrp", based on Alexandre Cassen's excellent open-source software. Due to limitations in keepalived's code AFAIK it wouldn't compile on glibc 2.0.x. This version was compiled on gcc 2.2.x system. My LRP system is Bering uClibc + libc225 and it works fine for me, YMMV. FYI, It is very possible that keepalive might compile on a gcc 2.1.x or uClibc system. I'm unfortunately not a programmer nor did I have a 2.1.x or 2.0.x system lying around. I didn't think tinkering with makefiles & destroying existing machines was such was a good idea. If you get it to compile on one of those platforms (especially 2.0.x) please let me know! I created a few packages to provide libraries that Keepalived needs. You need to download these and add them to your syslinux.cfg file in order for kpalived.lrp to work. Here's the list of files: (Sorry for the size. I did strip what I could, it's unfortunate that all these lib files are so damned big and required) http://download.sidestep.com/lrp/kpalived.lrp 33244 http://download.sidestep.com/lrp/libcrpto.lrp 342800 http://download.sidestep.com/lrp/libpopt.lrp 26598 http://download.sidestep.com/lrp/libssl2.lrp 81400 http://download.sidestep.com/lrp/libz.lrp 26766 I have also modified zebra & bgpd (by Eric Kiser - www.eric.kiser.com/glacier.htm) to include /etc/init.d files. The binaries are still gcc 2.0.x. Note : I needed to install an additional library in order to make these function with Bering-uClibc. I've listed it below. http://download.sidestep.com/lrp/zebra.lrp 164145 http://download.sidestep.com/lrp/bgpd.lrp 57368 http://download.sidestep.com/lrp/libm.lrp 142068 Could someone please put these on the sourceforge or mirror page somewhere? This is not my website and I'm able to provide these files only for a little while, especially if there's too much usage. FYI this is my first LRP so please be gentle in your flames ;) Thanks much, Peter Mueller # cat /var/lib/lrpkg/kpalived.help ### Keepalived 1.0.0 *.lrp This file was compiled and packaged for the LEAF Project. This package is designed to simulate HSRP on Linux routers through the use of the program Keepalived. Please visit Keepalived.org for more information on this software. kpalived.lrp For compile, package, and dependency information: [EMAIL PROTECTED] ### # Keepalived 1.0.0 *.lrp information # Last Update: 2003-01-?? Peter Mueller ### Keepalived 1.0.0 Mailing List Information: http://www.keepalived.org/mailinglist.html Documentation: http://www.keepalived.org/documentation.html Summary:Keepalived VRRPv2 Name: Keepalived Version:1.0.0 Source: keepalived.1.0.0.tar.gz URL:http://www.keepalived.org Copyright: GPL Description: Keepalived is an excellent implementation of VRRP, the same protocol that Cisco bases HSRP on. This configuration of Keepalived is setup for use with the Zebra routing package for HA-linux routers running bgp v4. It's easy to modify for vanilla-HA or other routing packages. I compiled Keepalived on a RH 7.2 x86-SMP-based system for use with Bering-uClibc + libc225. AFAIK Keepalived does not compile on gcc 2.0.x, but it might compile on uClibc. Please write me an email if you can get it to work. Please modify the keepalived.conf file with your own settings. I'd rather not get email from your routers :). Best of luck, Peter Mueller [EMAIL PROTECTED] ### # keepalived 1.0.0 Information # Last Update: 2003-02-04 Peter Mueller ### -Original Message- From: Peter Mueller [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 5:29 PM To: 'Charles Holbrook'; [EMAIL PROTECTED] Subject: RE: [leaf-user] shorewall and keepalived Hi Charles, > I am just curious if anyone has used the shorewall package as well as > keepalived on the same system. And how did you overcome the > issue of both > shorewall and keepalived wanting to do VRRP for the ip > addresses? Just got > this dropped in my lap and not really sure how to proceed with this. I am getting close to getting something working with LRP & keepalived. I was planning on posting both a keepalived LRP (using, as it turns out, bering-uclibc + libc225 compat) and an image of my LRP when it's done, but you're welcome to what I have in the meantime. Just drop me a mail off-list. Peter --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com
[leaf-devel] [ leaf-Feature Requests-680525 ] Update packages
Feature Requests item #680525, was opened at 2003-02-04 16:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680525&group_id=13751 Category: Release/Branch: Oxygen Group: None Status: Open Priority: 5 Submitted By: David Douthitt (ddouthitt) Assigned to: David Douthitt (ddouthitt) Summary: Update packages Initial Comment: Oxygen needs a version audit of all packages. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680525&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Feature Requests-680520 ] Audit startup scripts
Feature Requests item #680520, was opened at 2003-02-04 16:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680520&group_id=13751 Category: Release/Branch: Oxygen Group: None Status: Open Priority: 5 Submitted By: David Douthitt (ddouthitt) Assigned to: David Douthitt (ddouthitt) Summary: Audit startup scripts Initial Comment: Oxygen probably has the most extensive startup scripts; perhaps shifting some to rc or lua would be better? Audit the configuration scripts and simplify. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680520&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Feature Requests-680518 ] Convert to Linux 2.4
Feature Requests item #680518, was opened at 2003-02-04 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680518&group_id=13751 Category: Release/Branch: Oxygen Group: None Status: Open Priority: 8 Submitted By: David Douthitt (ddouthitt) Assigned to: David Douthitt (ddouthitt) Summary: Convert to Linux 2.4 Initial Comment: Use the Linux 2.4 kernel; try to implement with patches for gr-security, lvm, xfs, and jfs... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=363751&aid=680518&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The ideas presented so far...
Chad Carr wrote: May I suggest that the config-db be maintained as a "config-tree," with the root at /leaf-cdb (or something shallow like that) and keys may be nested as deeply as needed by creating directory levels. I.e. you could make the key interfaces/eth0/ipaddr like this: echo -n "172.24.8.24" > /leaf-cdb/interfaces/eth0/ipaddr I also like the idea of a config-tree, Chad. It's proven itself useful for Linux a la /proc. I wish the config-tree api to have significant lattitude in how it displays the data: a) Something along the lines of a -H argument the way "who -Hu" prints out column headers. b) The ability to dump var=value pairs to stdout. Would you like to remark any furthur on how a tree is significantly better than a single config-db file and how the tree would store a variable's "type" information, for instance? Matt. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Shorewall Futures
As I announced today on the Shorewall lists, I am about to release Shorewall 1.3.14. That will definitely be the last 1.3 release and will probably be the last of the Shorewall 1.x.x releases. I am going to be concentrating on Shorewall 2. I will continue to support Shorewall 1.3 but will not be adding any new features. If anyone is interested in taking over the development of Shorewall 1, please let me know. Shorewall 2 will be written in a language other than Bourne Shell so it is likely that Shorewall 2 will not work with LEAF releases/branches, at least in their smaller configurations. Shorewall 2 will: a) remove some of the cruft that has accumulated in the externals of Shorewall 1 (Old Ping Handling, MERGE_HOSTS=No, 'routestopped' option for hosts and interfaces). b) be smarter than Shorewall 1 (principle reason for moving to a richer programming language). c) have some sort of GUI. d) be able to import Shorewall 1 configurations. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline,\ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote: A few quick points about some of the recent discussion: Regarding the config-db format: It really doesn't matter. The files should be human-readable (plain text), with enough structure (probably via filesystem directories and filenames) to be easily navigated, but all access to the database information by the packaging and any configuration system will be through a defined API, allowing the back-end format to change if required. Who knows...future versions might move to a packed binary format with small C or assembly programs for access, to save space and/or gain speed. While initially a lack of tools may require "power-users" to hand-edit database entries, I would generally consider this unsafe and discourage the practice. I'd like to disagree with this. It really does matter. One of the big strengths of the anscestral LRP (Dave Cinege's version, I mean) was the simplicity of its basic network.conf file. As LRP first went to the mountains, then evolved into LEAF, and as LEAF tried harder and harder to incorporate many specialized packages, each with its own config files and syntax, much of this simplicity was lost. To be used with LEAF, packages typically require some modification anyway. Why not adopt a "one-stop-shopping" standard for config variables that makes them easily available to any package? Then when someone adapts a package, he or she at least has the option of having it get its config info from a standard place in an easy fashion. What I mean here is a single text file, with a simple name=value format, that contains all the basic information needed by networking packages, in a form that init and config scripts can use easily (like the old network.conf, which used a format that allowed all entries to be loaded as shell variables). The key to keeping this manageable is that it contains nothing but VARIABLE_NAME=value lines #commentlines and lines that do minor manipulation of VARIABLE_NAME lines (e.g., something like NETWORK_INTERNAL=$INTERFACE_INTERNAL/$NETMASK_INTERNAL ) The other key is to enter each value exactly once. Consider again the recent thread on leaf-user where someone wanted to change his (Dachstein) internal network to 10.10.10.0/24. After he made way too many separate changes in network.conf, he had to edit the DHCP config file separately. If he were to use other .lrp packages, he'd have to do this again and again. (I've never actually set up Bering. How many individual changes would it require to its config files to accomplish a change in internal network number?) This is the sort of complexity I would like us to find a way around, at least for the core packages used on a LEAF router/firewall. Ideally, to handle the example change, a config file would need only to have the router's internal address changed (and perhaps the netmask, if it also changed) and would calculate everything else it needed from that information (in much the same way that typical network-init scripts can figure out a basic routing table from the interface info). You could accomplish something similar with a complex configuration editor that made changes to a bunch of behind-the-curtain files ... but doing it that way forces use of the config tools, which (for a reason I suggest later on) is unduly restrictive. That is, I also disagree with Charles' final sentence above, but I leave that discussion for later in this message. This is all about making a GUI configuration tool: Wrong. Trying to make a simple web or other GUI configuration system simply points out the complexity and inconsistencies in the existing configuration system. This is about *SIMPLIFYING* configuration, making it easier to configure and maintain a LEAF install. Once simplified, front-ends to the configuration system can be provided for plain text (to replace the existing lrcfg system), web browsers, palm-pilots, pocket pagers, hexadecimal keypads, or whatever someone wants to implement. The key is to simplify and organize the configuration process enough to make such things possible. I think I agree with this, if we mean the same thing by "configuration process". But it leaves one thing out ... an important way to simplify the interface for configuration is to restrict the range of choices available. LEAF tends to be pulled in two directions all the time -- simplicity, so that common uses of it can be configured easily by relatively inexperienced users. flexibility, so that unusual uses of it are possible for relatively skilled, experienced users. My interest has always been in the first direction, but the diversity of our interests means that both directions need to be accommodated. Perhaps, though, not in the same configuration system. A very simple but restrictive configuration interface that supports (say) just thr
[leaf-devel] Config system
A few quick points about some of the recent discussion: Regarding the config-db format: It really doesn't matter. The files should be human-readable (plain text), with enough structure (probably via filesystem directories and filenames) to be easily navigated, but all access to the database information by the packaging and any configuration system will be through a defined API, allowing the back-end format to change if required. Who knows...future versions might move to a packed binary format with small C or assembly programs for access, to save space and/or gain speed. While initially a lack of tools may require "power-users" to hand-edit database entries, I would generally consider this unsafe and discourage the practice. This is all about making a GUI configuration tool: Wrong. Trying to make a simple web or other GUI configuration system simply points out the complexity and inconsistencies in the existing configuration system. This is about *SIMPLIFYING* configuration, making it easier to configure and maintain a LEAF install. Once simplified, front-ends to the configuration system can be provided for plain text (to replace the existing lrcfg system), web browsers, palm-pilots, pocket pagers, hexadecimal keypads, or whatever someone wants to implement. The key is to simplify and organize the configuration process enough to make such things possible. Pre-Configuration: I like the concept, but in my mind, this also benifits greatly from a simplified configuration system. The biggest benifit to pre-configuration is the ability to use powerful tools unavailable on most LEAF systems to deal with the complexity of configuring current distributions. With the configuration system simplified, a lot of this becomes moot. I think the real driving force for pre-configuration is automatic hardware detection, which would be a good thing. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
