combined reply to several posts and some ideas (at the bottom): On Thursday 29 August 2002 14:59, Charles Steinkuehler wrote: > > 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.
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. > 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" :-/ ). I understand, I have a little more time once I finish roofing my house (within the weekend, I hope). I can distribute what testing code I have presently, but the architecture will definately need the be the first thing on the todo list. I have compiled the "su-wrapper" binary that will solve the write permissions problems as well. I'm presently working with SF on fixing my CVS access, as SF has blocked all SSH connections from my Desktop the last couple of days. :-((( BTW, I hope everything is still maintaning for you on the work end! > *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. I hate to break any portability, but it would be a serious consideration being that Weblet would essentially be integrated and only LEAF style OS's would likely use it. It would also be a space saver on the floppy end. Good idea! > *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)! Good idea, but I don't know if any of us except Charles and David D are familiar with Forth. I think I wrote a "hello world!" program in Forth around 15 years ago, but I haven't retained any more about the language since then. It was a low-level language similar to machine language if I remember right. :-) > 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. Maybe a few of us should spend some time and learn forth. C is about as cryptic of a language as I've learned to interpret, but it sounds as if LEAF could gain a lot by using it. On Thursday 29 August 2002 15:44, Eric Wolzak wrote: > I would propose to get something like webmin does. > some routines for individual packages > reading in variables combining them with package specific items > and then into the engine throwing out a webpage /form > after posting the option file is written out in standard > option.textfile This is what I had in mind. Adding backup would be rather simple as well. The largest sticky point I see at this time is reading and over-writing the existing configuration files. An example would be setting the internal interface network information.... many packages need this information. It would simplify things to enter the information in it's own file, then source the information to the relevent file needing it. On Thursday 29 August 2002 16:47, Erich Titl wrote: > Hi Eric, Lynn, Charles > > Asking for permission to come aboard. Welcome aboard!!! On Thursday 29 August 2002 18:11, Peter Robinson wrote: > Hi there > I have written a web based admin tool for LEAF based loosly on > MOSQUITO. > > It is written in /bin/sh. > > I dont believe you need perl for this task That is interesting! I've gone through the Mosquito code and found that it covers many of the bases. However, there were several disadvantages to using any of it....like lack of CLI configuration options. The use of Jscript for a PHP-type atmosphere is interesting. It would be nice if you could elaborate on what you have done. Which LEAF version did you use? What modifications to the existing configuration files have you made to make it work? 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'? ************************* *New thoughts* Through my personal testing, though rather minimal, I've ideally got an environment that includes: *sh-httpd- can use GET or POST form methods. Either works fine, but GET has a 255 character line limit, POST doesn't and save a couple of lines of code to interpret the form information. James S.'s POST patch has worked in my testing. This is the smallest webserver that effectively works in my testing. *su-wrapper- to overwrite any file owned by 'root' and safely run sh-httpd as a non-priviledged user a suid binary must run. This small binary can be configured for many files and under set binaries and conditions...very easy to configure and I've compiled it w/o any glibc restrictions. *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. *Variant Independence- How do we propose to write the code in a way that will not cater to a specific LEAf variant? This answer could possibly lead to variant developers porting their configuration files and packages to using our framework. The other option would be to start a new LEAF variant to accomadate this development and encourage other variants to use it if they choose. *Language for Executable code- Jscript, C, Forth and other languages could reduce the overall size of the operational configuration. Due to my proposed framework, the actual CGI size wouldn't benefit from using Jscript, but writing executables in compiled code could make a large difference. Who is available to write in any of these languages? I've written a little C/C++, but most of my experience has been modifying existing code to work for my environment rather than writing it from scratch. *Package framework- Should there be a "base.lrp", a "www.lrp" and a "cli.lrp" to account for different installation preferences. How would we institute adding modules to the package.... porting lrpkg or apkg would be ideal and user-friendly. ****************** These questions pose the largest problems we're likely to run into with this project and *should* be answered before they become a problem. I believe the member resources are available to do this in a short period of time, but a solid framework and direction will make or break the project. All opinions, ideas, and suggestions are welcome and encouraged! Thx again, ~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: 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
