Re: [Nms-cgi-devel] Re: Configuration (was Re: Constants (was Re: [Nms-cgi-devel] Various Stuff);)

[Olivier D. <dr...@sh...>]

On Wed, Jan 30, 2002 at 06:08:48PM -0500, Joseph F. Ryan wrote:
> 1.) Store the Config inline in the file

We already doing that, and so is MWS and seeing as his scripts got very
popular that way I really wonder why this would be bad, on a user
friendliness point of view. I think, to a certain extent, we're maybe
underestimating the capabilities of users to change the configuration.
Which brings me to my second point below.

> 2.) Store the Config in an outside file

I doubt this is really as confusing as people may think. If we say where
to edit the configuration in both the script and the README file, think
the users won't figure it out? We should probably make the config file
(if we are to do one) so we can write comments in it (# is probably good
for that).

I personnally like the config file idea.

> Well, how about both?
> What if we have defaults inline in the file, and then have an outside 
> config file the user can change?  The defaults would be the fail safe if 
> the user screws up the config, while the config will contain what is user 
> defined.  We can parse the config, and if that fails, the defaults are 
> loaded.

Config is *very* specific to each server (url, basedir, baseurl,
etc...). Having ``defaults'' per say is bad, unless these are generated
automatically, based on pwd(), and apache's httpd.conf. Only problem is
to find httpd.conf and hope the server doesn't have a different
webserver running or that their version of apache isn't too old ie. has
the config in 3-4 different files. Unless someone here knows how to
figure out the documentroot and the webserver's DNS otherwise... Maybe
this could be a feature that only works with apache (to save us trouble)
since most users should fill out the config anyways.

> I was also thinking that we really couldn't have a program create the 
> config for us.  There is a problem with each of the options:
> 1.) A cgi-script to create the config would be a HUGE security hole

I see how it could be *hard* to generate config automatically but how is
this a security hole if 1.) it doesn't take CGI input 2.) it's run only
once and creates a config file used thereafter? I guess it could become
a security hole if it's done incorrectly and we end up with wrong config
data.

> 2.) A compiled C script would not be cross-platform
> 3.) Not all users have shell access

Agreed. And even if they have access to a shell most of them don't know
what to do with a shell anyway. I mean half the people won't have
touched a shell and the other half will only know DOS. Those that don't
probably won't have any trouble configuring the script.

The idea of a config file sounds very appealing to me. I think to a
certain extent it might be easier to modify than inline config as the
user will never see the code (unless they want to). Having a
dumb user filling the config inline won't be any better than one filling
the config in a separate file. I think the only issues is having
two files and do admins let people put config files in the /cgi-bin/? If
not, this idea isn't worth much. But I've never been an admin and I
don't know any admins either so I don't know what the general practices
are.

-Oli

-- 
+----------------------------------------------+
| Olivier Dragon        dr...@sh... |
| Software Engineering II, McMaster University |
+----------------------------------------------+