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] 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] 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-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [leaf-user] Webbased configuration
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. 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 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. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... ...oh, if you really want to get wacky, the web-server could be written in forth, too! ...signing off before I convince everyone I'm clinically insane! :-) Charles Steinkuehler [EMAIL PROTECTED] --- 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
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
Hello Charles, Lynn , list 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. 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. I agree with this. I like the sh-httpd, although I have some problems with persisiting /tmp files. The webconfiguration interface will not get lots of page views at one time, ( at least I hope so ;) ). But depending on what you are doing repeatedly viewing from one page. 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 would like to commit. ( time is also sparse :( ) 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 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. That would be great. 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 don't hope so ( for you and the company that is) *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. that sounds good to me. fast and small is something we could need for the doorstop computers still running . *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)! sounds good, but sounds also like a lot of work I am not that kind of a coder. ;) 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. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... ...oh, if you really want to get wacky, the web-server could be written in forth, too! ...signing off before I convince everyone I'm clinically insane! :-) That would make two of us ;) Eric Wolzak --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
Hi Eric, Lynn, Charles Asking for permission to come aboard. regards 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[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. I'm not a programmer nor can I write good programs. I can test and document though. I volunteer for this part. Mohan -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
[Leaf-devel] Re: [leaf-user] Webbased configuration
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.
