As I noted, this post is to submit where I am with the
roadmap towards a new configuration system with
an available web-based front-end (optional).
First of all, this is an idea that I am sure several people
on the devel-list don't wish to participate in So if possible
please add the [config] sub-Subject in posts on this subject
so list-members can selectively disregard the topic easily
if they wish. TY
Second, what I am suggesting is not entirely functional on my
system at this time. What successful testing I do have is
very similar to what Eric has made available. I hope to
have tested and made available something closer to what
I am about to describe within a week or so.
This being said, I'll get into some actual substance now.
What was last agreed on when the topic was last actively
discussed was along the lines of this:
1) A new back-end (actual configuration, backup, etc...) was going
to be needed. There is not a variant out there that doesn't have
some of the same information in several places/packages as Eric
has stated. A good example of this would be interface/network
ip information, hostname, package-name information, etc.... which
affects the core of a working system. There are two approaches
to working with this: Either we can set the backend to modify the
same information in 'x' number of places that are not necessarily
known or we can save this information in a file of set of files that
can be used by anything needing this information. The latter option
would break drop-in compatibility and reworking existing packages,
but would allow for easy portibility between different variants if desired.
The latter option was also what was earlier agreed on, as was the
use of Bering for testing since Bering is the lead into the future of LEAF
variants.
2) The back-end will not depend on any one front-end application.
Although a web-based front-end has been a highly-desired feature,
there will always be a higher security risk involved with the inheirent
protocol(s) used. Many people will always use a script or hand-editted
configuration system when available, so it would be necessary to allow
the front-end itself to be modular with ideal options of configuration by
http(s), CLI-script, hand-editting, and/or CLI-menu systems using the
same core back-end.
3) If using the web-based front-end, integrating atleast one optional form of
authentication/encryption for any un-trusted access (WAN or LAN). Although
OpenSSL/SSH would be the ideal method, SSH alone won't fit on a standard
single floppy Bering image; I suggest adding the capabilities of tunneling
through zebedee and/or stunnel as smaller, feasible alternatives.
4) Package modification will have to be made to maximize the use of a newer
more advanced configuration back-end. Many discussions have passed over
a feasible alternative to the standard '*.lrp' format including the *.udeb
and *.ipkg formats. Ipkg is a small replacement for Debian Dpkg and
works with any .[x}deb packages, so I personally could see it as a valuable
addition to the back-end application as well. Mandatory additions to
any packaging format could include a parsable file list, any package-dependant
scripts or http/cgi/menu files, and a dependancy list.
5) Package loading, saving, backup, and installing. 'lrpkg' can now be
considered quite limited in the desires and demands of the present
day OS's. The only easily feasible alternative that I am aware of for
LEAF would David D.'s 'apkg' system. Alternatives to 'apkg' would
need to be built from the ground up in the back-end, so I can provide
a few idea's if anyone want's to play with them. Ipkg, as mentioned
before, provides easy loading/unloading of packages from *any* source
and uses a standard and flexible package format that has been well
tested, however there are not many options for configuration and none
for backing up a package in the scope of LEAF.
6) Use of compiled binaries in the configuration system has been discussed
before in regards to back-end programs, boot-management, and CGI. As I am
not much more than a familiar "interpreter" of C, Jscript, xForth, etc...
I don't plan on digging too deep into this topic since there are many others
in the development team that are far more qualified to suggest an opinion
than myself.
*) Back to the web-end topic. I have been playing with this idea:
http -> cgi-sh -> read-running-config
-> /tmp/config.files
-> verify /tmp/config.files
-> call suid-C binary to save new-configuration
-> call suid-C binary to backup new-configuration
'new-configuration' in the core system would be a file or set of files
that would be source-able by any existing conf file through variable
substitution of the present conf files. Any package should be modified
to add the necessary 'new-configuration' file and variables in the
existing conf file(s).
*All untrusted http should be encrypted and authenticated.
*http and cgi does not run as 'root' or over-write configuration itself.
*All over-writes are done by a suid-C binary like 'su-wrapper'.
*All front-ends and packages should be 'modular'.
*Since new and different necessities will be needed from the
packages themselves, dedicated binary download trees should
be available.
I'm done for the moment.... the brain is now somewhat fried! ;-)
Thoughts, comments, suggestions, or flames???
--
~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
