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.
>
> > #comment lines
>
> 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 several packages gets put in the global section.
That is one of the primary reasons for a change.
> >> 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.
>
> Charles, the GUI is goal 3.
> The package system is goal 2.
> The central config system is goal 1.
Let's say that the GUI is to be the most considered option in goal 3.
There are any number of developers that would/write a different
non-GUI (optional) front-end to goal 3.
> > 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 three sorts
> > of NAT'd configuration --
> >
> > modem dialup connections
> > Ethernet external connections (including static, DHCP, and PPPoE
> > addressing)
> > both of the above with and without a 3d interface for a DMZ
To start with and get something functional, yes. I think use of Charles'
'walklist ()' could feasibly expand the options here on a dynamic basis.
> 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.
>
> It'd be easy enough, but I don't know if it could handle
> complex setups too easily without endless revisions to
> deal with new options. It also requires a complete analysis
> of all possible network setups and the ability to create
> the necessary glue in .conf files.
>
> A gui is begining to sound unsimple :)
Why not a template page for 'add interface'? You could set
everything from this page: WAN/LAN/DMZ, ip info, dhcp, pppX,
allow, filter, module, bridge, proxy-arp, etc..... It's conceivable with
a db and thought out backend.
> > If we accept this limitation ... and if the automatic hardware detection
> > requirement really just means the ability to find the external and
> > internal NICs, not to auto-configure anything more exotic ... the
> > biggest problem I see is with older modules like ne.o that require a
> > specified iobase ... then we can look to the config systems of the
> > embedded routers for guidence about how to proceed. The other limitation
> > they consistently impose (on their Web-based config systems, anyway) is
> > that the LAN IP address of the router, and its network, are
> > pre-specified, at least for starting configuration. This presents both
> > costs and benefits.
PacketFilter auto-detects ethernet/ppp/pppoe connections on the first-boot
script. There might be something there to include.
> Autodetecting hardware is fun, but it has to be run
> on the LEAF box, and that's not necessary or always
> logistically feasable.
Let's say you just load every NIC module you can fit on the floppy.
Then do something like:
for i in /lib/modules/net/*
do
test=`lsmod $module | grep $module | sed -n "/1.$/p"`
if [ "$test" -eq "1" ]; then echo "MOD_$I = $module" >>/tmp/cfg.db
++i; ++I
fi;
done
Food for thought anyway.
--
~Lynn Avants
Linux Embedded Firewall Project developer
http://leaf.sourceforge.net
-------------------------------------------------------
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
