Re: [Leaf-devel] Weblet Enhancements
Hi Charles
At 16:36 03.07.2002, you wrote:
> >>> My understanding is cgi scripts recieving data like the above
>example
> >>> via a GET or HEAD request are supposed to refer to the QUERY_STRING
> >>> variable, which should be properly exported by sh-httpd.
> >>
> >>- or maybe this explains it?
> >
> > I does indeed, one can use QUERY_STRING instead of $1
> >
> > I believe the easiest way (for the user) is to implement all the
>variables
> > in sh-hddpd so it will provide
> > your parameters as
> >
> > ${SelDAY}
> > ${SUNUP}
> > ...
> >
> > this is quite easy to do in sh-httpd, I will start with it as soon as
>I get
> > the patched version for POST.
>
>If this is how apache, and other web servers work, I have no problem
>with making sh-httpd follow suit. I think, however, that the behavior
>you describe is not part of the normal CGI interface, so any scripts
>depending on the above functionality will only work on sh-httpd, and
>would not work on something like thttpd, apache, boa, &c...
The CGI source http://hoohoo.ncsa.uiuc.edu/cgi/ you mentioned yesterday is
the actual reference. There is no other format defined but as you find in
the examples section there are libraries ready to provide access to the
parameters. Actually it's been quite a while since I coded CGI's in shell.
Perl for example has a multitude of CGI interfaces available which take the
burden out of decoding the CGI stream.
>NOTE: Parsing of the QUERY_STRING for form data can be easily done by a
>few shell routines in a cgi.include file (or similar)...it doesn't have
>to be done by the web-server for convinence.
Correct, but it would be a very central location and easy to maintain.
>Should we maybe troll the leaf-user list for someone with extensive
>web/cgi design experience? I don't have anything that indicates form
>data should be pre-processed by the web-server and provided as command
>line arguments, but I'm a cgi neophyte.
Sounds sensible
take care
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
No, I will not fix your computer.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet Enhancements
>>> My understanding is cgi scripts recieving data like the above
example
>>> via a GET or HEAD request are supposed to refer to the QUERY_STRING
>>> variable, which should be properly exported by sh-httpd.
>>
>>- or maybe this explains it?
>
> I does indeed, one can use QUERY_STRING instead of $1
>
> I believe the easiest way (for the user) is to implement all the
variables
> in sh-hddpd so it will provide
> your parameters as
>
> ${SelDAY}
> ${SUNUP}
> ...
>
> this is quite easy to do in sh-httpd, I will start with it as soon as
I get
> the patched version for POST.
If this is how apache, and other web servers work, I have no problem
with making sh-httpd follow suit. I think, however, that the behavior
you describe is not part of the normal CGI interface, so any scripts
depending on the above functionality will only work on sh-httpd, and
would not work on something like thttpd, apache, boa, &c...
NOTE: Parsing of the QUERY_STRING for form data can be easily done by a
few shell routines in a cgi.include file (or similar)...it doesn't have
to be done by the web-server for convinence.
Should we maybe troll the leaf-user list for someone with extensive
web/cgi design experience? I don't have anything that indicates form
data should be pre-processed by the web-server and provided as command
line arguments, but I'm a cgi neophyte.
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet Enhancements
At 10:04 03.07.2002, you wrote:
>Hi,
>
>I may be missing something in this, so do CMIIW, but;
>...
>This is on the weblet that comes with bering 1.0rc2. It's GET, plain and
>simple, it works nicely, and the sort of string that is passed to my
>script by weblet in $QUERY_STRING is:
>
>SelDAY=1&SUNUP=0630&SUNRISE=30&SUNDOWN=2230&SUNSET=1&ONOFF=1
>
>Just to be sure, I went and checked the script that parses this, and it
>does indeed look for the '='s (and the '?'s) in order to break it up.
>
>
>I just thought I should mention this, in case someone is about to go
>over sh-httpd, and passing multiple arguments in this fashion is a
>no-no...
>
> > My understanding is cgi scripts recieving data like the above example
> > via a GET or HEAD request are supposed to refer to the QUERY_STRING
> > variable, which should be properly exported by sh-httpd.
>
>- or maybe this explains it?
I does indeed, one can use QUERY_STRING instead of $1
I believe the easiest way (for the user) is to implement all the variables
in sh-hddpd so it will provide
your parameters as
${SelDAY}
${SUNUP}
...
this is quite easy to do in sh-httpd, I will start with it as soon as I get
the patched version for POST.
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
No, I will not fix your computer.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet Enhancements
Hi, I may be missing something in this, so do CMIIW, but; On Tue, Jul 02, 2002 at 09:18:31AM -0500, Charles Steinkuehler wrote: > > > there is a *=* case which resets the parameter list in sh-httpd, it > > > disables constructs like > > > > > > foo=bar&baz=foo > > > > > > I guess parameters without a value would pass fine > > > > Thanks for the detail...I'll see if I can remember why this was > > specifically added when reviewing the code (hopefully sometime in the > > near future). > > OK, I dug out my CGI references, and what I have indicates the command > line arguments should only be parsed and provided to scripts if the GET > or HEAD request does *NOT* contain an unencoded equals sign, which is > why the arguments are cleared if there's an equal sign present. Knowing nothing at all about any of these issues, I went ahead and built the form for setting times etc. on my blinder-thingie using how-to's and a couple of similar pages as template. This is on the weblet that comes with bering 1.0rc2. It's GET, plain and simple, it works nicely, and the sort of string that is passed to my script by weblet in $QUERY_STRING is: SelDAY=1&SUNUP=0630&SUNRISE=30&SUNDOWN=2230&SUNSET=1&ONOFF=1 Just to be sure, I went and checked the script that parses this, and it does indeed look for the '='s (and the '?'s) in order to break it up. I looked at sh-httpd, and I see the place in do-cgi() where it checks for '*=*', but either: There's something I don't understand, or It doesn't work as intended... (?) I just thought I should mention this, in case someone is about to go over sh-httpd, and passing multiple arguments in this fashion is a no-no... > My understanding is cgi scripts recieving data like the above example > via a GET or HEAD request are supposed to refer to the QUERY_STRING > variable, which should be properly exported by sh-httpd. - or maybe this explains it? In any case, FWIW I agree that authentication, however nice it would be, can't compete with tunneling through ssh... 0.02 Regards, Jon --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet Enhancements
> > there is a *=* case which resets the parameter list in sh-httpd, it > > disables constructs like > > > > foo=bar&baz=foo > > > > I guess parameters without a value would pass fine > > Thanks for the detail...I'll see if I can remember why this was > specifically added when reviewing the code (hopefully sometime in the > near future). OK, I dug out my CGI references, and what I have indicates the command line arguments should only be parsed and provided to scripts if the GET or HEAD request does *NOT* contain an unencoded equals sign, which is why the arguments are cleared if there's an equal sign present. My understanding is cgi scripts recieving data like the above example via a GET or HEAD request are supposed to refer to the QUERY_STRING variable, which should be properly exported by sh-httpd. If using the POST method, the cgi script will recieve the data on stdin (won't work with sh-httpd w/o the POST patch). See the NCSA section on handling form data with cgi scripts: http://hoohoo.ncsa.uiuc.edu/cgi/forms.html What cgi programs were you having problems with? Did they work properly under another web server (like apache or thttpd), or did you only test with sh-httpd? BTW: The references I'm using for CGI implementations are the NCSA: http://hoohoo.ncsa.uiuc.edu/cgi/ ...and the latest CGI 1.1 internet draft standard I could find: http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt Note there are several more CGI doucments available from the above site, but I think the 1.1 draft is the most applicable, even though it expired in Dec, 1999: http://cgi-spec.golux.com/ Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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] Weblet Enhancements
> Hi Charles > > there is a *=* case which resets the parameter list in sh-httpd, it > disables constructs like > > foo=bar&baz=foo > > I guess parameters without a value would pass fine Thanks for the detail...I'll see if I can remember why this was specifically added when reviewing the code (hopefully sometime in the near future). I do remember I was pretty aggressive on what was *NOT* allowed to be passed as a parameter, to prevent various exploits possible via shell-expansion of the cgi command and parameters (ie url's like http://www.weblet.firewall/cgi-bin/viewlogs&messages;rm+-rf+/ ) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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] Weblet Enhancements
Hi Charles there is a *=* case which resets the parameter list in sh-httpd, it disables constructs like foo=bar&baz=foo I guess parameters without a value would pass fine cheers 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
Re: [Leaf-devel] Weblet Enhancements
At the bottom of this message is a diff of the changes I made. It was to
the Users list as a response to "Weblet Abuse". It still hasn't been
thouroughly tested by me since I found a better method to handle my issue.
I'm not a registered developer so someone else will have to add the changes
to the distribution.
JamesS
At 10:36 AM 7/1/02 +0200, Erich Titl wrote:
>Lynn
>
>At 04:50 01.07.2002, you wrote:
>
>>James Sturdevant posted POST support in patch form to the list a while
>>back. I think this will work fine.
>
>I would be very interested in that patch. I changed sh-httpd to support a
>GET with multiple parameters to at least be able to use forms in a still
>very primitive state, but of course a fully fledged POST would be superior.
>
>
I have build a POST handler into sh-httpd but haven't had the time to
thoroughly test it. Here it is as a diff script:
JamesS
*** sh-httpdMon May 13 09:01:27 2002
--- sh-httpd.orgMon May 13 09:02:21 2002
***
*** 182,193
;;
esac
! if [ -f /tmp/sh-httpd$PID.input ] ; then
! $LOCALURL "$@" $OUTPUT &
! rm -f /tmp/sh-httpd$PID.input
! else
! $LOCALURL "$@" > $OUTPUT &
! fi
CGI_PID=$!
CNT=1
--- 182,188
;;
esac
! $LOCALURL "$@" > $OUTPUT &
CGI_PID=$!
CNT=1
***
*** 200,206
fi
done
! file_stats $OUTPUT
STATUS="200 OK"
case $FILE in
nph-*) if [ -n "${PROTOCOL}" ] ; then
--- 195,201
fi
done
! # file_stats $OUTPUT
STATUS="200 OK"
case $FILE in
nph-*) if [ -n "${PROTOCOL}" ] ; then
***
*** 349,377
local HEADER
local HEADERDATA
read COMMAND URI PROTOCOL
! COMMAND=${COMMAND%"${CR}"}
URI=${URI%"$CR"}
PROTOCOL=${PROTOCOL%"${CR}"}
REQUEST="$COMMAND $URI $PROTOCOL"
if [ -n "$PROTOCOL" ] ; then
IFS=' :'
while read -r HEADER HEADERDATA
! [ "x$HEADER" != "x$CR" ]
! do
HEADER=`toupper "$HEADER"`
! HEADERDATA="${HEADERDATA%${CR}}"
! setvar HTTP_$HEADER "$HEADERDATA"
export HTTP_$HEADER
done
! if [ "$HTTP_CONTENT_LENGTH" != "" ] ; then
! PID=$$
! export PID
! dd bs=$HTTP_CONTENT_LENGTH count=1
of=/tmp/sh-httpd$PID.input
! fi
IFS=$OIFS
! fi
REQ_DATE="`date -uR`"
case $COMMAND in
--- 344,395
local HEADER
local HEADERDATA
+ PID=$$
read COMMAND URI PROTOCOL
! echo "Processing $COMMAND $URI $PROTOCOL" >>/tmp/sh-http.log
! COMMAND=${COMMAND%"${CR}"}
URI=${URI%"$CR"}
PROTOCOL=${PROTOCOL%"${CR}"}
REQUEST="$COMMAND $URI $PROTOCOL"
+ export COMMAND URI PROTOCOL REQUEST
+
if [ -n "$PROTOCOL" ] ; then
IFS=' :'
while read -r HEADER HEADERDATA
! do
! HEADER="${HEADER%${CR}}"
! HEADERDATA="${HEADERDATA%${CR}}"
! if [ "x$HEADER" != "x" ] ; then
HEADER=`toupper "$HEADER"`
! eval HTTP_$HEADER=$HEADERDATA
export HTTP_$HEADER
+ echo "Header variable HTTP_$header = $HEADERDATA" >>/tmp/sh-http.log
+ else
+ PID=$$
+ export PID
+ dd bs=$HTTP_CONTENT_LENGTH count=1
of=/tmp/sh-httpd$PID.input
+ LINE=`cat /tmp/sh-httpd$PID.input`
+ rm -f /tmp/sh-httpd$PID.input
+ while [ "$LINE" != "" ] ; do
+ var=`echo "$LINE" | sed "s/\&.*//"`
+ if [ "$var" == "" ] ; then
+ var="$LINE"
+ LINE=""
+ else
+ LINE=`echo "$LINE" | sed "s/$var//" | sed
"s/^\&//"`
+ fi
+ eval $var
+ vname=`echo "$var" | sed "s/=.*//"`
+ export $vname
+ done
+ break 2
+ fi
done
!
IFS=$OIFS
! fi
REQ_DATE="`date -uR`"
case $COMMAND in
-
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lis
RE: [Leaf-devel] Weblet Enhancements
I have already made this modification (index.cgi) and will deploy it on the LEAF
Weblet Dev Demo by the end of the day. I have added a link at the botom of the
index.cgi page that will display the source for all the weblet cgi files. It should
also be working.
Richard Amerman
-Original Message-
From: Charles Steinkuehler [mailto:[EMAIL PROTECTED]]
Sent: Mon 7/1/2002 8:11 AM
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [Leaf-devel] Weblet Enhancements
> On Friday 28 June 2002 00:16, Richard Amerman wrote:
> > What if we modified the architecture of Weblet so that you can add
> > standard plugins (in the format of the standard LEAF pachage format,
> > LRP for now).
>
> Actually, with the packaging system the only hard part would be links
> from index.html.
It should be possible to do this cleanly with an index.cgi (instead of
index.html), and a clearly defined structure for add-ons (ie each weblet
add-on package would have it's own directory and maybe a descriptive
file for use in building menus on the main web page...similar to how
lrcfg works).
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
áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±òÞi÷^½éfj)b
b²ÒÞi÷^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?æuëÞ
Re: [Leaf-devel] Weblet Enhancements
> On Friday 28 June 2002 00:16, Richard Amerman wrote: > > What if we modified the architecture of Weblet so that you can add > > standard plugins (in the format of the standard LEAF pachage format, > > LRP for now). > > Actually, with the packaging system the only hard part would be links > from index.html. It should be possible to do this cleanly with an index.cgi (instead of index.html), and a clearly defined structure for add-ons (ie each weblet add-on package would have it's own directory and maybe a descriptive file for use in building menus on the main web page...similar to how lrcfg works). 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] Weblet Enhancements
> >James Sturdevant posted POST support in patch form to the list a while > >back. I think this will work fine. > > I would be very interested in that patch. I changed sh-httpd to support a > GET with multiple parameters to at least be able to use forms in a still > very primitive state, but of course a fully fledged POST would be superior. What was required to make GET work with multiple parameters? AFAIK, it should have worked already (and in fact, several of the existing cgi scripts are called with multiple parameters). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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] Weblet Enhancements
Lynn At 04:50 01.07.2002, you wrote: >James Sturdevant posted POST support in patch form to the list a while >back. I think this will work fine. I would be very interested in that patch. I changed sh-httpd to support a GET with multiple parameters to at least be able to use forms in a still very primitive state, but of course a fully fledged POST would be superior. > > Performance: The sh-httpd server is kind of slow when serving up CGI > > pages. This is due to the way the shell-script handles spawning the > > child CGI process, and checking to see if it's finished. I think > > this can be re-architected to perform much better...when I was > > working on sh-httpd, I didn't know I could open multiple file-handles > > in shell-script, which makes the above problem easier. > >I don't think much CGI would be required with the use of forms, ash >scripts, and limiting access to localhost. Agreed, performance is not that big an issue with configuration. >I agree 100% with that statement. >I am using forms (of course), which POST on individual lines. I think >sed and stock ash are fine w/o needing mawk. The forms would use >stock variables (ie... eth0_IP_ADDR) when the "option" sets a single >variable and a new variable to set several "stock" variables when >applicable (ethernet-dhcp, ppp-dhcp, etc...). The added scripting needed >to interpret the added variables would be put in network.conf. As far >as changes to the network.conf "standard", I propose modularizing >certain sections of declared variables into their own form/conf file, >then "sourcing" these new conf files into the "script-only" >network.conf file. Example of the break-up of network.conf would be >something along the lines of "base-config, advanced-net, qos, and dmz." >This will minimize the amount of needed CGI code run. This would also >allow for a CLI-config set of scripts so that you can edit all >configuration on the LEAF machine itself with the same ash/cgi scripts >that the web-based admin uses. Thoughts??? I would not necessarily break up network.conf. Neither is it necessary to have the functions implemented there, at least not for the development cycle. I would make it a separate package unless it fits nicely on a floppy. How far advanced are you? I would hate to replicate your work. 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
Re: [Leaf-devel] Weblet Enhancements
Sorry about my lateness in responding, but I was out of town for the last several days. This post will consolidate reply's from several posts in my absence. Comments are inline ;-) > Security: This is critical if external access is to be provided, but > not really an issue if the internal network is trusted. While SSL > would be ideal for encrpting external sessions, let's not forget > about ssh. If you already have ssh installed, it's possible to tunnel > through ssh to access an un-encrypted weblet running on an internal > private-IP port remotely. This requires ssh in addition to a > web-browser on the remote system, but is quite workable. NOTE: The > Cygwin ssh client from RedHat works just fine for this sort of thing > if you're running a windoze platform. ssh would be ideal, except on floppy images. Maybe zebedee is going to be the best option for remote floppy administration @61KB. See later section. > Funtionality: It would really be nice if the web server supported > the POST method. There is no fundamental reason why you can't do > this with shell-script, and I believe it's already been done. James Sturdevant posted POST support in patch form to the list a while back. I think this will work fine. > Performance: The sh-httpd server is kind of slow when serving up CGI > pages. This is due to the way the shell-script handles spawning the > child CGI process, and checking to see if it's finished. I think > this can be re-architected to perform much better...when I was > working on sh-httpd, I didn't know I could open multiple file-handles > in shell-script, which makes the above problem easier. I don't think much CGI would be required with the use of forms, ash scripts, and limiting access to localhost. > CGI Scripts: Since it's unlikely that LEAF systems will start > including perl, python, or anything similar in the near future > (mainly due to space constraints), I think shell-scripts are the best > choice for CGI's. If there's something that can't quite be done with > sed/grep/dd, I would probably suggest using mawk, which I already > have packaged (required by IPSec), and which weighs in at 45,956 > bytes (compressed). I agree 100% with that statement. I am using forms (of course), which POST on individual lines. I think sed and stock ash are fine w/o needing mawk. The forms would use stock variables (ie... eth0_IP_ADDR) when the "option" sets a single variable and a new variable to set several "stock" variables when applicable (ethernet-dhcp, ppp-dhcp, etc...). The added scripting needed to interpret the added variables would be put in network.conf. As far as changes to the network.conf "standard", I propose modularizing certain sections of declared variables into their own form/conf file, then "sourcing" these new conf files into the "script-only" network.conf file. Example of the break-up of network.conf would be something along the lines of "base-config, advanced-net, qos, and dmz." This will minimize the amount of needed CGI code run. This would also allow for a CLI-config set of scripts so that you can edit all configuration on the LEAF machine itself with the same ash/cgi scripts that the web-based admin uses. Thoughts??? > Modularity: Seems like a good thing! The more flexable the > architecture, the more likely it is to meet the various needs of the > pretty diverse user base we have for LEAF. This will likely be the only way to keep it on a floppy image. This would also help with portability between different versions of LEAF. It would allow for saving each "module" individually, so that small changes would use minimal resources and accidental errors would be less of an issue. We could also add a link to a "config-barf" CGI file that could auto-magically post comments+config information via a web-form to the mailing list. My use of starting with DF is simply that I am very familiar with the release and my lack of knowledge with Shorewall. Bering would likely be easier to work with, however most code should be relatively portable with variable & conf file name changes. I expect with the amount of people that are willing to work on this, that parallel development between releases will be no problem. Scott, I love your idea this would be beautiful in environments that would have a server available However, a huge amount of our users will not, so we are simply working around the requirment of hand editing configuration in a minimal amount of disk-space. I'm hoping something that is stand-alone on a floppy is possible. At 10:31 PM 6/26/02 +0200, Erich Titl wrote: >I am playing around with weblet to get some kind of a web based >configuration. Authentication is certainly an issue there and I am very >interested in anything that should come up in that aspect. Let's consider this. only a certain set of machines *should* be allowed access to configuration period. Weblet/sh-httpd allows for setting allowed hosts in the present configuration an
