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
Re: [Leaf-devel] Re: Webbased configuration
On Sunday 01 September 2002 09:58, Nathan Angelacos wrote: > Hey Lynn, thanks for your comments. > > I guess we are approaching this from slightly different starting > assumptions. My assumption is that the webbased configuration engine > is just a pretty face on lrcfg. > > The model I'm thinking of is "you buy a linksys router, you plug it > in to your LAN, look at the sticker on the router, and it says that > if you point your web browser at 192.168.0.254, you'll get the > configuration web page." No passwords - you're in as admininstrator, > configuring the router for first use. All it is doing is editing the > equivalent of /etc/interfaces; /etc/network.conf or whatever, and > then bringing up the interface. Right? > > 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. I agree with the rest of what your saying... I was taking several steps further than you intended to in the application itself. Thx for clarifying! -- ~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
RE: [Leaf-devel] Re: Webbased configuration
I must say your description of Fourth sounds great. I have to agree with all your desires in a language for these purposes. As to the Lego M's, though mine have been on the shelf for at least a year, you are always a kid if you choose to be! Mine were a gift from my wife! :-) I have played with the C like language on it, but not Fourth Richard -Original Message- From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]] Sent: Sat 8/31/2002 9:55 AM To: Nathan Angelacos; [EMAIL PROTECTED] Cc: Subject: Re: [Leaf-devel] Re: Webbased configuration > Better sense tells me I should probably keep quiet, but ... Nah...speak up. We won't even flame you here! > 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...) I like LUA (haven't programmed anything real in it, but I've gone over the docs pretty well, and compiled the stand-alone LUA interpreter). I think it's excellent at its targeted application (a scripting language for complex programs), but is not particularly well suited to being added to the core of a LEAF distribution for a few reasons: Size - While fairly small for a scripting language (vs perl, python, etc), LUA is still pretty large. Requires libc - Not a show-stopper...almost all parts of LEAF require libc, but I'd like to have a light-weight scripting language that could boot w/o libc to enable some potentially complex booting scenarios that have been discussed previously, like run-time selection of libc version, mixed libc environments (ie a base system running off ulibc, with optional add-ons using gnu libc), and similar. We already have sh - While more powerful than ash in several respects (especially with handling numbers), I don't think LUA provides dramatically more functionality than is available with standard shell-scripts...especially if a light-weight numeric processing tool was provided to extend ash's native abilities in this regard. Untyped - I especially don't like the fact that LUA is untyped (strong integer & floating point math capability is one of the key things I miss when programming in shell-script). I may be missing something with LUA since I don't have much experience with it, but as an example, I'd like to know how well a numeric processing program (like rrdtool or MRTG) would code in LUA. This is one of the things I'd like to code in a small script for LEAF, but have not attempted due to the limited numeric processing available in sh. LUA is definately better with math than sh, I just don't think it goes far enough. No linux syscalls - There is no inherent capabilitiy to directly make linux syscalls, and given LUA's untyped data structures, grafting on this ability would likely be difficult. With the ability to directly make linux syscalls, not only is the requirement for libc drastically reduced (or eliminated), but ti becomes possible to script things like a full-fledged web-server, e-mail sending program, or other network based program, and it also becomes possible to script core utilities (like su, chroot, etc) if desired. Forth: Tiny - about 1/4 the size of LUA No libc required - works on any system, even at bootstrap with an initrd in the 10's of K, rather than 500K+ low-level-power - While still considered a scripting language, Forth has the ability (and was initially designed) to do low-level machine controllike "c", you get the ability to talk directly to the machine...unlike "
Re: [Leaf-devel] Re: Webbased configuration
> Better sense tells me I should probably keep quiet, but ... Nah...speak up. We won't even flame you here! > 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...) I like LUA (haven't programmed anything real in it, but I've gone over the docs pretty well, and compiled the stand-alone LUA interpreter). I think it's excellent at its targeted application (a scripting language for complex programs), but is not particularly well suited to being added to the core of a LEAF distribution for a few reasons: Size - While fairly small for a scripting language (vs perl, python, etc), LUA is still pretty large. Requires libc - Not a show-stopper...almost all parts of LEAF require libc, but I'd like to have a light-weight scripting language that could boot w/o libc to enable some potentially complex booting scenarios that have been discussed previously, like run-time selection of libc version, mixed libc environments (ie a base system running off ulibc, with optional add-ons using gnu libc), and similar. We already have sh - While more powerful than ash in several respects (especially with handling numbers), I don't think LUA provides dramatically more functionality than is available with standard shell-scripts...especially if a light-weight numeric processing tool was provided to extend ash's native abilities in this regard. Untyped - I especially don't like the fact that LUA is untyped (strong integer & floating point math capability is one of the key things I miss when programming in shell-script). I may be missing something with LUA since I don't have much experience with it, but as an example, I'd like to know how well a numeric processing program (like rrdtool or MRTG) would code in LUA. This is one of the things I'd like to code in a small script for LEAF, but have not attempted due to the limited numeric processing available in sh. LUA is definately better with math than sh, I just don't think it goes far enough. No linux syscalls - There is no inherent capabilitiy to directly make linux syscalls, and given LUA's untyped data structures, grafting on this ability would likely be difficult. With the ability to directly make linux syscalls, not only is the requirement for libc drastically reduced (or eliminated), but ti becomes possible to script things like a full-fledged web-server, e-mail sending program, or other network based program, and it also becomes possible to script core utilities (like su, chroot, etc) if desired. Forth: Tiny - about 1/4 the size of LUA No libc required - works on any system, even at bootstrap with an initrd in the 10's of K, rather than 500K+ low-level-power - While still considered a scripting language, Forth has the ability (and was initially designed) to do low-level machine controllike "c", you get the ability to talk directly to the machine...unlike "c", you have small programs, no compile required, and no libc required (at the expense of somewhat slower execution and coding your own library routines). Talking directly to the machine means you can execute linux syscalls, load/call external libraries (including libc) if required, and pretty much do anything possible in a "real" compiled programming language. For math, you get everything from bit-level twiddling to whatever you want to write for a math library (single/double precision floating point, arbitrary precision calculations, whatever)...of course for standard things like floating point, there are off-the-shelf GPL/public-domain "libraries" (actually, word-sets in forth) availble from a variety of places. Drawbacks - Forth is considered by many to be a wierd, arcane, and obscure language. Of course, I don't think LUA is going to be replacing C or Java anytime soon, either, and I actually consider LEAF a bit obscure, although probably not wierd or arcane :) There is actually a pretty large group of folks continuing to write Forth (and commercial vendors providing supported toolchains), but it's all in the "hidden" world of micro-controllers...the tiny CPU's controlling your dishwasher, oscilloscope, etc...several folks are even running forth on their Lego MindStorms RCX controllers (why didn't they have these when I was a kid!?!). Drop by comp.lang.forth sometime, and you'll see a pretty active user community.
[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=sourceforge1&refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
