Re: [Leaf-devel] Webbased Configuration
Hello Erich, list. sorry for the late reaction ( I did have to work yesterday.) > Hi everyone > > I like Eric's 2nd drawing and the model it presents. I am XML illiterate > and therefore can not judge how complex a translator for the actual > templates to be deployed might be. This translator is everywhere available. With the xml you can use an "transform Stylesheet". ( it is something like CSS if you are more familiar with that. for each item you can define what the interpretator has to do with the xml script as an example (attention this is pseudocode and doesn't work, It is only to express my idea) if in a configration file there is an optional option "us" "ch" "nl" that determines the nationality this would look something like : us ch nl select your nationality this option can be used ..dsdfsffsdfdfff< /doc> You could have a stylescript "webpage.xsl" that would do ; for each item if it is an option then write in the html file the content of the attribute name for each option write content of option ( I know this is only pseudocode) Another stylesheet "documentation" for each item write name and content of doc file. Another stylesheet "simple setup" for each item with attribute basic write the option otherwise select the options that is indicated. The stylesheet parsing rules option="" [ `grep ^option ` ] && option=checked etc. So you use the xml file as database and extract from it just what you need. The stylesheets are not only useable for ppp.lrp but also for isdn, shorewall or whatever you want. Advantage from xml over a database is that it is operatingsystem independent. It can be created with an editor, everybody that want another display can adapt a stylesheet, even without nowing something about the module at all. The "intelligence" is in the database (xml ) Eric's model has the potential to not > only be applied to a configuration UI but actually to the build of a > custom distribution, but this strays off the topic I am afraid. > > Charles pointed us at Forth, which sounds like an engineers choice. It > might be a good choice but I believe the strength of the LEAF project (and > many other OSS projects) lies in its quality and adaptability by a > prospective user. I believe in this aspect Forth will not qualify. I can see the use of Forth for certain aspects of the distro. ( how often does the user look at the /linuxrc script. What would it matter, if the whole start-up would be done in forth and not by shell scripting. Even the parsing-rule script I wrote about before could be possible automatically generated in Forth ( as far as I remember is this a stack orientated language.) And this would run a lot faster. As a user and even as a developer of the configuration, I wouldn't mind being Forth "intermediate" between the part I read and can edit " xml script" and the part that gives me my variables. ;) > Using simple HTML templates with placeholders for the actual values to be > drawn and standardising such templates would allow anyone to contribute > easilyy. Tools for this simple model are easy and abundant. Agreed see above. > Nathan wanted embedded inline scripting in the HTML and a few other goodies > on the server. I have a very reserved opinion about scripting in HTML, in > my opinion it clutters data with presentation even worse than normal HTML. > On top of that it requires an interpreter on the server and I believe we > should stay tiny here. But that of course is just an opinion ;-) We still need a kind of an interpreter on the server, as long as we don't want to be dependent of the browser. Somebody has to do the calculation, and the only side I can control ( as a developer) is the server side. ( for example I don't like to have to use javascript ). > Eric, where do you see the benefit of generating the parsing rules from > XML, would it not rather add another level of complexity? I hope I explained why . I think it would simplify the development for the second and third packages :) > > > I think I prefer the first option (xml). > > > > > > I would prefer this method as well. I have only one question, > > > will the XML need an interpreter on the www-server? > >No it is not even available on the router as the xml files are only used > >to generate the > >"parsing rules", "html template" and "config template". > >I just have to be more precise with describeing ; ) > > cheers > > Erich Cheers Eric --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] developer.xml
Hi Mike At 08:43 30/08/02 -0700, Mike Noyes wrote: >On Fri, 2002-08-30 at 08:18, Julian Church wrote: > > I got a > > bit confused with editing the log file, so didn't put anything at all, and > > I don't know what to do to control the version numbers either - the CVS > > says the file is at 1.1 but I was going to call this version 1.2.1. > >Log messages are important to let other project members know what you >did with your modification/addition. You can see examples of this in our >cvs-commits list archive. > >http://www.mail-archive.com/leaf-cvs-commits%40lists.sourceforge.net/ Thanks for the link. I see the kind of thing I should have done now. Is there any way to go back and amend my log message? >The CVS version numbers are for CVS, and have little or nothing to do >with release version numbers. Right - I may have messed up a bit then. I've based my version numbers on those I found in CVS for the original developer guide, developer.rtf. From what you say that might have been a mistake. >Tags are used to indicate release >versions. Tags? You mean in the XML, or is this another CVS thing? >Maybe someone else will have the time to attend to the creation of the >other formats. I'm still working on it - I'll let you know if I get anywhere. cheers Julian -- [EMAIL PROTECTED] www.ljchurch.co.uk --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] developer.xml
On Mon, 2002-09-02 at 03:55, Julian Church wrote: > At 08:43 30/08/02 -0700, Mike Noyes wrote: > >Log messages are important to let other project members know what you > >did with your modification/addition. You can see examples of this in our > >cvs-commits list archive. > > > >http://www.mail-archive.com/leaf-cvs-commits%40lists.sourceforge.net/ > > Thanks for the link. I see the kind of thing I should have done now. Is > there any way to go back and amend my log message? Julian, Yes. $ cvs admin -m 1.1:"your revised commit message" developer.xml Changing A Log Message After Commit http://cvsbook.red-bean.com/cvsbook.html#Changing_A_Log_Message_After_Commit > >The CVS version numbers are for CVS, and have little or nothing to do > >with release version numbers. > > Right - I may have messed up a bit then. I've based my version numbers on > those I found in CVS for the original developer guide, developer.rtf. From > what you say that might have been a mistake. I looked in David's rtf releases, and I was unable to locate revision numbers. I'm fairly certain this document was updated a few times. You should talk with David about the revision history. > >Tags are used to indicate release > >versions. > > Tags? You mean in the XML, or is this another CVS thing? It's another CVS command. $ man cvs tag -- Specify a symbolic tag for files in the repository. By default, tags the revisions that were last synchronized with your working directory. (Changes repository directly; uses working directory without changing it.) Marking A Moment In Time (Tags) http://cvsbook.red-bean.com/cvsbook.html#Marking_A_Moment_In_Time__Tags_ -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Webbased configuration
Everyone, I propose the creation of a config tree in our CVS src tree. All of the components necessary for this project can be placed there, and write access granted to team members. The structure of the config tree is left to the team members discretion. Example: leaf/src/config + | /core | /text | /ncurses | /web | /doc Alternate: leaf/src/config + | /sh-httpd | /weblet | /lrcfg | /acfg | /apkg On Sun, 2002-09-01 at 23:13, Richard Amerman wrote: > We can take a look at how far I have gotten and decide if it is on > track and ready to put in CVS. I have mainly been working on > abstracting everything so that it is easy to construct content in a > dynamic way. I'm interested in modules that include the configuration > piece, but also inhanced log viewes, live statistics in as much of a > dashboard fashion as possible, and other similar ideas. While some of > these modules may be sizable, I, like the rest of you wish to keep the > base system as small as possible -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Webbased configuration
On Fri, 2002-08-30 at 14:12, Erich Titl wrote: > - Let's try to build the configurator in a modular way, someone on the list > suggested to build kind of plugin to a generic configuration webpage which > would have to be implementd in each package. I think this is an excellent > idea and we should try to write specs for the interface. The developers and > maintainers of the current distributions/packages will certainly be the > most valuable resource. Everyone, If we're considering a change to our .lrp package structure, I strongly suggest an evaluation of "udeb" for the new format. This would allow us to piggyback off of Debian installer package development. They already have udpkg, netcfg, niccfg, busybox, ash, etc. They even have a stripped down apt-get called anna. modules.txt http://cvs.debian.org/debian-installer/doc/ http://ftp.debian.org/debian/dists/sid/main/debian-installer/binary-i386/Packages > - Can we build up a small subtree in the CVS structure for the > configuration tool which can be accessed by everyone just for development > purposes. A start could be the POST sh-httpd so we would not have to ask > for copies explicitly. Suggestions for the structure please. This could > help as a coordination point for our efforts. Erich, Agreed. I propose the creation of a config tree in our CVS src tree. All of the components necessary for this project can be placed there, and write access granted to team members. The structure of the config tree is left to the team members discretion. Example: leaf/src/config + | /core | /text | /ncurses | /web | /doc -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Webbased configuration
> > Similarly, we could say that the security of lrcfg is the strength of > > your root password for the internal interface, and whether you allow > > inbound telnet or ssh on your external interface. Once the someone > > gets in as root, I really don't care if he abuses lrcfg - he already > > owns the box. :-) > > I'm following you now that makes since and it would make it > necessary to bring up the default (index?) page as a login only > page (duh!). There may (or may not) be a defaut password to > enter the configuration menu via www. It would also be advisable > to run the server on something like port 81 so it would not be as > likely to be "accidentally" accessed in the first place. This has been my thinking...the existing linux password system provides the authorization. Users are responsible for understanding the consequences of running configuration tools requiring password access (ie telnet, un-encrypted web access, etc) over insecure networks...while I think this should be supported, "out of the box" the system should default to only allowing local interface logins (ie user has to explicitly enable remote access, with warnings about security when they do). Also, once we get a remote configuration system that becomes a standard part of a distribution, I think it's almost mandatory we do something to force the user to create a password. How many LEAF systems are running today with the default of no password? How many linksys/netgear/black-box router/firewall boxes are running with the factory defalt password? Perhaps the init scripts can simply check for the default null password for root, and require the user to set a password before continuing at the first login... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] More Docbook XML conversion
Hi All I'm about to start work converting another document to Docbook XML. I think I'm moving onto the install guides for the different distributions that are in the doc/guide part of the cvs tree. My initial instinct was to start with the most recently released distribution, and work back, but the formatting of the Bering guide resembles a lot of guides that I know were originally authored in DocBook, so I'm going to start with the Dachstein Installation guide while I investigate to avoid uselessly duplicating work. I'm still working on getting a Docbook --> PDF/HTML etc system going. Once I've got my full-size Linux (Debian 3.0) box up and running at home things should start to move. thanks all Julian -- [EMAIL PROTECTED] www.ljchurch.co.uk --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More Docbook XML conversion
Julian Church wrote: > Hi All > > I'm about to start work converting another document to Docbook XML. I > think I'm moving onto the install guides for the different > distributions that are in the doc/guide part of the cvs tree. > > My initial instinct was to start with the most recently released > distribution, and work back, but the formatting of the Bering guide > resembles a lot of guides that I know were originally authored in > DocBook, so I'm going to start with the Dachstein Installation guide > while I investigate to avoid uselessly duplicating work. > Hi Julian and list FYI the Bering documentation (users and install guides) and my package doc are available in XML from http://leaf.sf.net/devel/jnilo/xml I will move them to CVS when I will have some time. I use jade to convert them in html --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More Docbook XML conversion
On Mon, 2002-09-02 at 10:13, Jacques Nilo wrote: > Hi Julian and list > FYI the Bering documentation (users and install guides) and my package > doc are available in XML from > http://leaf.sf.net/devel/jnilo/xml > I will move them to CVS when I will have some time. Jacques, I just did this for you. The XML source for both Bering guides is now in our CVS repository. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/doc/guide/install-bering/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/doc/guide/user-bering/ -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Webbased Configuration
Hi, some remarks about using forth: - certainly forth is missing all that nice pattern matching like awk or perl, all this has to be coded. - I assume that even arrays are not available in forth - because forth uses very unusual semantics (reverse polish notation) it is not easy to understand and to maintain (you have always to keep in mind, what is in this moment at which position on the stack). mawk is 49K compressed perl4 is 136k compressed Manfred Eric Wolzak schrieb: > > Hello all, > > I agree with Erich that it would be wise to get an architecture before > thinking about the implementation. > IMHO it should be : > -easy to configure. > -flexible , so adding new packages is possible without much > programming. > -flexible 2- so it is possible to use the same system on oxygen, > bering ,dachstein, Wisp by merely changeing the Tools configuration > file. > -useable also on "slow" systems. > > I thought about it sometime and came up with a kind of a flowchart ( I > am afraid , I am not good at Ascii art, so I put it up my webserver: > http://wolzak.de/leaf/config1.jpg > After some looking at this graphic I noticed that 1. > The cgi and the primary Part have a common Trunk > Useing a template with the variables to create a html or config file. > 2. The intelligenz of this programm is on the firewall. > With each call , there is a lot of computeing. > 3. The configuration Template is created dynamically, but doesn't > change . So why not create it "offline" or better of the box. > > So I came up with the next Idea: > http://wolzak.de/leaf/config2.jpg > > The first Action is created on whatever computer under whatever > system to create the "Parsing rules" The HTML Template and the > Config Template. > > The Idea behind this is that as soon as the external Parser is written, > it can create any HTML.template , parsing rules or config template > just by creating a modules or package config file. > What is this parsing rule thing. > > This is a file build something like > `grep -q ^noauth` && var1=noauth > var2=$NETWORK_INTERFACE > var3=`ls /etc/` > > now after running this shell script or any other (Forth, Java alike) you > would have the variables var1, var2, var3 set > Those are combined with the HTML template just by catting the > template with the variables at the appropriate place. > What kind of place is told by the Module configuration file. > The kind of field the vars are placed in is destined by the kind of data > it expect ( options, filenames, freetext etc) > > The Modules Config file (which could also be a database can be > different formats: > 1. xml in that case the template, parsing rules and config template > can be generated by merely applying a xsl stylesheet. > > 2. something with different fields > example: > field 1 = 0 (optional) /1 demanded > field 2 = 0 (single) /1 (repeatedly possible) > field 3= variable looks like > 1 NAME=value > 2 NAME value > 3 value > 4 filename > 5 name= (value1 or value2 or value3) > 6 name (value1 or value 2 or value3) > 7 ( value1 or value2 or value 3) > 8 ... > > 3 Database. > > I think I prefer the first option (xml). > ... > > Any Comments , Reactions, flames > > Eric Wolzak > member of the Bering Crew. > > --- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > ___ > Leaf-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Manfred Schuler Beerenweg 4 31275 Lehrte Tel.: (0 51 75) 66 54 Fax: (07 21) 1 51 22 22 17 E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
On Sat, 2002-08-24 at 20:42, guitarlynn wrote: > I've been doing some thinking about a good way to setup the > LEAF src tree, as there is still nothing there. As I need to upload > my own src for a package binary and working on others, I need > somewhere to put it within the tree. My thoughts on a tree structure > are as follows: > > src +bering > +dachstein > +oxygen > +packetfilter > +wisp-dist Everyone, Oxygen and WISP-Dist trees are now in our CVS src tree. I created modules for each of them. You can now check them out with: $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf co oxygen $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf co wisp-dist Note: replace yourname with your SF unix user name. -- Mike Noyes <[EMAIL PROTECTED]> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
