RE: [Leaf-devel] RE: [leaf-user] Webbased configuration
I also agree perl would be an overkill. What we need is to create a framework like we have for lrps for web based management. Every lrp must have a web based config template that will be used by a master web script. The template format and scripting needs to be developed and standardised. What an excelent idea! That way, the package builder knows exactly which areas os the config files need to be changed and how. He would then write the proper code to access them, without having to worry. On the other hand, I guess that if you use thttp, it may be larger but I guess that it will save some CPU cycles. I have now an LCD showing uptime and CPU. Every access to the weblet, puts the CPU at 100% for some seconds. My cpu is a P133... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of guitarlynn Sent: 30 August 2002 00:33 To: Eric Wolzak Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [leaf-user] Webbased configuration On Wednesday 28 August 2002 12:56, Eric Wolzak wrote: (snip) I agree with your summary Eric. Advantage of webmin, there are all kinds of modules. Adaption is much easier than building from scratch. Disadvantage memory and CPU. I would be against using Perl personally. Porting Webmin would not necessarily be any better or faster than starting from scratch IMHO. Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. Advantage probably, less memory and cpu consuming. ... I think any how, this should be a project for a group, who wants to contribute. I agree here as well. A group along these lines was discussed ~2 months ago. A couple of people were working on formatting Weblet and reworking it and I have developed a shell-atmosphere that will allow generating conf files from either GET or POST sh-httpd atmosphere. Modularization has always been in the plan, however nothing but test coding exists at this time being as I needed to jump through a few hoops to get the CGI environment working with sh-httpd. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. In previous discussions with Mike N and Charles, the use of the leaf-devel mailing-list is encouraged for this project. This project would be beneficial to work under the LEAF umbrella and stay independant of releases. As everyone else was working with a Bering base, I am presently working with Bering as well (though I have worked on a Dachstein base as well). I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? Thx, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- 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 --- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [leaf-user] Webbased configuration
On Thursday 29 August 2002 14:59, Charles Steinkuehler wrote: I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. Great! I had JamesSturdevant send me his patched sh-httpd binary since several of us had major problems applying the diff he had posted. I can send it to you off-list. I haven't dug through it or done a diff myself, but the POST function does work per my testing. Please send me a copy... The thttpd and uncgi combination is great, however uncgi has not worked with sh-httpd in my testing due to CGI path restrictions. Uncgi uses /cgi-bin/uncgi/'cgi-script' to interpret a CGI file and sh-httpd does not support the /path/binary/option format. Exactly what kind of su wrapper are you using to overwrite existing configuration files or are you running thttpd as 'root'? I'm not familiar with uncgi, but sh-httpd *SHOULD* support options passed after the CGI program name, as long as your SCRIPT_ALIAS variable in sh-httpd.conf is set properly. The extra path info is exported as the PATH_INFO environment variable...is this supposed to work some other way? * *New thoughts* *To ease compatibility of many packages needing specific duplicate information/variables, a break-up of certain conf files should be made and a check for depending packages should be made within the web module. The other option is building a new LEAF version that fits this format (successor to Dachstein???). Internal network and DMZ information would be excellent examples of possible problems. Modifying the existing package database would not be a good option, unless we are going through them anyway and following something along the lines of David D's Port system. *The CGI scripts should only setup the environment and call executables. If the actual executable is not integrated in CGI, a CLI configuration script could use the same code and minimize the total codebase that would need to be written. There are several of us that have already written configuration code for existing LEAF variants, possibly some of this code may be portable. I like this idea in general. The config system should make it easy to put a text, web, or whatever front end on the actual configuration utilities. Then, we could replace most of the existing lrcfg menu with something a bit more user friendly. I personally don't mind if existing packages need to be modified or extended for full/best compatability with the new auto-config system, but the new system should do something reasonable by default with existing packages (ie allow you to view/edit files that would show up in the lrcfg menu trees). 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] developer.xml
On Fri, 2002-08-30 at 08:18, Julian Church wrote: At 07:57 21/08/02 -0700, Mike Noyes wrote: I think it would be a good idea to place your DocBook XML version of David's Developers Guide in our CVS repository. OK, I've done that - it's my first attempt at using CVS so I'm not sure I've done it right, but the file is there when I browse through the web-based CVS access, so at least now others can get to it if they need it. The rest of the CVS tree seems to be still intact, so I can't have done anything *that* destructive. : ) Julian, Thanks. Your addition to our doc tree was accomplished without incident. Could you have a look to see if I've done anything really stupid? 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/ The CVS version numbers are for CVS, and have little or nothing to do with release version numbers. Tags are used to indicate release versions. My day job workload has increased a fair bit over the last few weeks, so unfortunately I haven't had time to get an xml to PDF/HTML/etc converter running as I'd hoped. Sorry everyone! No problem. I'm glad you had the time to create the DocBook XML source. Maybe someone else will have the time to attend to the creation of the other formats. -- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
On Thu, 2002-08-29 at 21:59, Charles Steinkuehler wrote: using sh-httpd. or a small server (boa, thttpd) It looks as if almost noone knows about mini_httpd (http://www.acme.com/). It's from the same authors as thttpd. It's a little slower than thttpd, but smaller (40k vs. 71k) and it can be built with ssl support! It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. IMHO, any web-administration utility should be fairly web-server neutral. Since sh-httpd is small, and presents what I believe is a standard CGI interface to back-end programs, it is a good candidate. It should be possible to use boa, thttpd, apache, or any other CGI-enabled web-server with little difficulty, however. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. snip I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. I haven't looked at sh-httpd recently, but some form of authentication may be a good idea if it's used for a configuration interface. I can also help with architure, debugging, and (hopefully) crafty solutions to difficult scripting problems, but I can't commit to writing a major chunk of code due to current time constraints (although this may change suddenly if the company I work for suddenly craters :-/ ). *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script CGI's, would there be any benifit to wrapping the whole thing into a unified structure? In other words, create a custom script-based CGI interface, rather than trying to match standard CGI...something like a shell-script version of PHP. It could probably be faster/smaller than sticking with a conventional web-server/CGI approach, but would be less portable to other web servers. Something to think about. *WACKY IDEA #2* I've been investigating forth, and will be working on a micro-controller based hygrometer project running forth on an Ateml AVR processor in the near future. I've been wanting access to a scripting language more powerful than shell-script on LEAF, and I think forth might fit the bill. It's possible to compile forth without *ANY* libc requirements, but with the ability to talk *DIRECTLY* to the kernel (so you could load libc and make calls to it, if you really wanted, and do pretty much anything you want...remember the irreplacable part of libc is essentially an interface between C programs and the kernel, the rest is just a bunch of standard routines to make programmer's lives a bit easier). That's a lot of power for an interpreter that would probably weigh in at 10K to 20K Bytes, with code that can potentially run at near optimized C speeds (ie *WAY* faster than shell-script)! I've wanted to code an initial bootstrap loader in forth for a while (something that would boot from CD/Floppy/whatever, and optionally swap out the kernel, allowing fancy boot-time configuration w/o having to re-burn a CD to set kernel options. The ability to make kernel calls from a script, w/o having any libc or /bin/sh dependencies is very cool for a boot-loader. I also think an available forth interpreter could potentially help the construction of a new packaging system as well as fancy CGI admin scripts. That sounds really cool. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... I'll have a look a forth first. I did come across a small forth interpreter here (eforth): http://www.lxhp.in-berlin.de/index-lx.shtml I just built it, and the static executable is 22k small. Compare that to ...oh, if you really want to get wacky, the web-server could be written in forth, too! There are more people with such ideas :-) http://www.jwdt.com/~paysan/httpd-en.html It seems to be included in the gforth distribution. Ewald Wasscher I'll be back --- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
On Fri, 2002-08-30 at 21:40, Charles Steinkuehler wrote: I'm well aware of mini_httpd, but it's 40K...sh-httpd is about 9K (including the conf file), and it's text so it compresses well in *.lrp packages! Agreed! There's also micro_httpd, but it won't do CGI... You can wrap most any inetd based webserver (including sh-httpd) to get ssl support, if you can afford the space. I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. I haven't looked at sh-httpd recently, but some form of authentication may be a good idea if it's used for a configuration interface. IMHO, this should probably happen outside the web-server. I could code basic authentication into sh-httpd, but that's never really going to be secure. I'd suggest either using an authenticating (and possibly encrypting) front-end like ssh, or off-loading authentication to the system (ie running su as part of the CGI scripts, and providing the root or an admin password) while encourgaing the use of encryption (ssh, zeebee, or similar) if accessing remotely to prevent clear-text passwords traversing the 'net. I'll have a look a forth first. I did come across a small forth interpreter here (eforth): http://www.lxhp.in-berlin.de/index-lx.shtml I just built it, and the static executable is 22k small. Compare that to Yep...apx 20K for a *POWERFUL* scripting language that allows you direct access to kernel system calls! The code isn't pretty to look at, and it's pretty cryptic if you're not passably familiar with the notation. I especially like the kernel level forth also at the site above...one of the current big Forth applications is Open Firmware, which is how Suns and several other systems (including most PPC systems, IIRC) boot...rather than native code, the firmware roms on various plug-in cards contain small forth routines, which both saves space, and allows CPU/OS independent boot-strap code (of course, native compiled optimized drivers are loaded once the system is boot-strapped). I can see something similar being useful for boot-strapping LEAF w/o having to have 100K shell and 500K of libc...not to write hardware drivers, but to build/extract the initial ramdisk, do the kernel-two-step switch-a-roo to allow booting a selectable kernel w/o custom CD imgaes, and other things that are difficult to do with plain shell-script. That sounds good too, but who is going to code such a thing for LEAF? Ewald Wasscher --- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webbased configuration
Hi folks Thanks for the hearty welcome I did a bit of a fly by on all the summaries presented lately on the Webbased config subject. I would like to make a few suggestions, not necessarily technical ones because I feel the matter has been well understood. - Could we keep this on leaf-devel, it makes it easier to concentrate if I don't have 2 lists to watch?. - Could we agree to a common subject line, my procmail mail sorter is a lot happier that way? I suggest to keep 'Webbased configuration' in the subject for mail recognition. - My current work is on a Java based Web application which was badly designed, we are not in a hurry, lets try to get a good pattern for the configurator. - I believe we should try to build this with the currently available tools in Dachstein/Bering, e.g. sh-httpd. Even if it eats a few cycles, it has a miraculously small footprint. - 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. - 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. Thanks for comments, improvements and critics. It's late east of Greenwich, good night. Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] Webbased configuration
Well put!
I know that I have not been vocal in the past month, I have been overloaded with a
rush project at work, and my Wife has taken to Zope, so between these, I have had
little time for LEAF. This does not mean that I am less interested. :-)
Your post is right on track. One thing I would sugest, just repeating a few
sugestions made by others a month or so ago, since we are realy talking about two
things, the sh-httpd and the Weblet/configuration piece, we need to keep
distinguishing between them. A good messege subject line might be Web Config -
Weblet/Configurator and Web Config - sh-httpd.
Richard Amerman
-Original Message-
From: Erich Titl [mailto:[EMAIL PROTECTED]]
Sent: Fri 8/30/2002 2:12 PM
To: [EMAIL PROTECTED]
Cc:
Subject: [leaf-devel] Webbased configuration
Hi folks
Thanks for the hearty welcome
I did a bit of a fly by on all the summaries presented lately on the
Webbased config subject. I would like to make a few suggestions, not
necessarily technical ones because I feel the matter has been well understood.
- Could we keep this on leaf-devel, it makes it easier to concentrate if I
don't have 2 lists to watch?.
- Could we agree to a common subject line, my procmail mail sorter is a lot
happier that way? I suggest to keep 'Webbased configuration' in the
subject for mail recognition.
- My current work is on a Java based Web application which was badly
designed, we are not in a hurry, lets try to get a good pattern for the
configurator.
- I believe we should try to build this with the currently available tools
in Dachstein/Bering, e.g. sh-httpd. Even if it eats a few cycles, it has a
miraculously small footprint.
- 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.
- 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.
Thanks for comments, improvements and critics.
It's late east of Greenwich, good night.
Erich
THINK
Püntenstrasse 39
8143 Stallikon
mailto:[EMAIL PROTECTED]
PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16
---
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=urceforge1refcode1=3390
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
áË ë^¨¥Ë)¢{(ç[Èä58«yÚ ¶±©¢W\zYiÞëZì!z·¢±QHm¶?ÿ
0za¢xr¿«)®Ê.Ç¢¸ Ö·r^Öû7ßÝ y§Ýz÷¥¨¥x%ËKy§Ýz÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþW}ׯz
[Leaf-devel] Re: Webbased configuration
Better sense tells me I should probably keep quiet, but ... Back when this discussion came up previously (Dec 2001/Jan 2002?) I was able to get micro_httpd working with an embedded lua interpreter. It allows one to write html code with inline lua scripting, like php. To add some real numbers to this dicussion: micro_httpd - dynamically linked against libc9404 bytes lua_micro_httpd dynamic libc, static lualib 75972 bytes Compressing with upx gets it to 39K, which is still big for a diskette-based configuration engine. If FORTH can really get us an embedded language in 10K, that sounds great. I'll check the site Charles mentioned tomorrow; any other pointers anyone can give - please share! (I'm not a coder - but don't mind getting my fingers burned either...) --- FWIW, my wish-list is something like this: Must haves: +small size +URI (GET) or POST method variables exposed to the script language +rfc-2388 mulipart/form-data compliance (must be able to upload a ipsec cert/crl via the web browser) +inline scripting (like php) +enough of a framework (.css / examples / docs) to make it easy for someone else to use +master script (index.html?) that will take over the job of lrcfg Cool features, but not necessary +logging +http 1.1 compliance, especially keepalive +cookie support +std graphics building library (like fly or gd tools) Not desired +stand-alone server +high-performance +ssl +locked down security (need to be root to configure anyway!) -- I'm sure others have a different wish-list. Charles' wacky ideas got me to thinking If you check out nullwebmail, its an executable that runs as a cgi under a web server - but any will do: thttpd, boa, mini_httpd (I don't know about sh-httpd). Unlike most web-mail solutions, all you need is the single program - no complicated install process - just compile, put the program in the www directory and you have basic web-based mail. Do you think that's a better way to attack this problem? Rather than extend a web server, just build a really smart cgi? I don't know the answer - just wondering if anyone else does. --- 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=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
