Menu
▾
▴
phpwiki-talk
|
From: Jeff D. <da...@da...> - 2002-09-14 19:10:46
|
Hey, I'd like to move the configuration data out of index.php (again).
(The little auto-decide if we really wanted to fire up main or not
code at the bottom of the current index.php is problematic...)
Having the config information in index.php was clever when we
only had one script using the info, but now it's just a pain,
and causing uneeded complexity...
My current thinking is that index.php should look like:
<?php
include('config/config.php')
include('lib/main.php')
main();
?>
(Also, I think we should ensure that including lib files doesn't
actually _do_ anything beyond defining things (i.e. classes, defines,
functions, or variables). One should have to call a function before
anything happens.)
Any objections or other comments?
|
|
From: Martin G. <gim...@gi...> - 2002-09-14 20:22:22
|
Jeff Dairiki <da...@da...> writes:
> Hey, I'd like to move the configuration data out of index.php
> (again). (The little auto-decide if we really wanted to fire up main
> or not code at the bottom of the current index.php is
> problematic...) Having the config information in index.php was
> clever when we only had one script using the info, but now it's just
> a pain, and causing uneeded complexity...
How about placing the configuration in two files: one file with a
default configuration and one file with the users customizations. The
default configuration should always be included, but the users
customization is only included if the right file exists. Somethings
like this:
include('config/config-dist.php');
if(file_exists('config/config-user.php')) {
include('config/config-user.php');
}
The config-user.php file should then be ignored by CVS: I've seen
conflicts when I've done 'cvs update' due to my changes in index.php.
This config-user.php file should then be generated by some tool - I
was very happy when I saw, that you've used the configurator.php
script from PHP Weather 1.x as a basis for such a tool.
Perhaps you'll like the new config tool I've made for PHP Weather 2.0.
It does nice things like generating JavaScript code to check
selections at the client before they're submitted and have a general
system for defining dependencies between the various options which
should prevent the user from making a wrong config file.
You can try it out here:
http://phpweather.sourceforge.net/phpweather/config/make_config.php
And the source can be found here:
http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpweather/phpweather/config/
--
Martin Geisler My GnuPG Key: 0xF7F6B57B
See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell => A telnet-connection (almost :-) in a PHP page.
|
|
From: Jeff D. <da...@da...> - 2002-09-15 00:48:41
|
> How about placing the configuration in two files: one file with a
> default configuration and one file with the users customizations.
Yes. The current system sort of started out that way with
the 'user-config' in index.php and the 'dist-config' in
lib/config.php. I.e. most of the settings in index.php
were commented out be default, and then lib/config.php
filled in the defaults...
(Note that due to our use of define()s (which can't be
re-defined) the dist-defaults need to be filled in _after_
the user customizations, like so:
if (!defined('FOO'))
define('FOO', 'default value');
)
Over time, as people have added options to index.php, I see
the defaults have been stuck in there too...
I think it would be real slick if the config script got all its
info from (specially formatted) comments (and code) in the
dist-config file. (Maybe it already works that way?)
Then problems with keeping the configurator in sync with the
config options go away....
|
|
From: Reini U. <ru...@x-...> - 2002-09-15 11:50:15
|
Jeff Dairiki schrieb: >>How about placing the configuration in two files: one file with a >>default configuration and one file with the users customizations. > > Yes. The current system sort of started out that way with > the 'user-config' in index.php and the 'dist-config' in > lib/config.php. I.e. most of the settings in index.php > were commented out be default, and then lib/config.php > filled in the defaults... > > I think it would be real slick if the config script got all its > info from (specially formatted) comments (and code) in the > dist-config file. (Maybe it already works that way?) > Then problems with keeping the configurator in sync with the > config options go away.... Maybe an INI style lib/config.ini lib/config.php parses this then and fills in the defaults. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Jeff D. <da...@da...> - 2002-09-15 14:23:23
|
On Sun, 15 Sep 2002 12:50:11 +0100 Reini Urban <ru...@x-...> wrote: > Maybe an INI style lib/config.ini > lib/config.php parses this then and fills in the defaults. I'm not sure I see the advantage of an INI style config file over an user-config.php. Brainstorming... Maybe, since we have a configuration script, the configuration script should do all the figuring of the defaults and autodetected values. (I.e. everything that's now down in lib/config.php.) Then it can generate a single config file with all required settings as constants. Faster to load at run time --- though I doubt that's our main speed bottleneck :-) |
|
From: Reini U. <ru...@x-...> - 2002-09-15 14:54:21
|
Jeff Dairiki schrieb: > On Sun, 15 Sep 2002 12:50:11 +0100 > Reini Urban <ru...@x-...> wrote: > >>Maybe an INI style lib/config.ini >>lib/config.php parses this then and fills in the defaults. > > I'm not sure I see the advantage of an INI style config file > over an user-config.php. Readability. > Brainstorming... > > Maybe, since we have a configuration script, the configuration script > should do all the figuring of the defaults and autodetected values. > (I.e. everything that's now down in lib/config.php.) > Then it can generate a single config file with all required settings > as constants. Faster to load at run time --- though I doubt that's > our main speed bottleneck :-) Yes. Configurator.php should be called when no lib/config-user.php exists, the virgin setup. Then we can ensure that e.g. the admin password is encrypted, the include path and many more paths can be guessed automatically and good suggestions for VIRTUAL_PATH configurations can be choosen from. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Reini U. <ru...@x-...> - 2002-09-16 13:19:53
|
Reini Urban schrieb: > Jeff Dairiki schrieb: >> Maybe, since we have a configuration script, the configuration script >> should do all the figuring of the defaults and autodetected values. >> (I.e. everything that's now down in lib/config.php.) >> Then it can generate a single config file with all required settings >> as constants. Faster to load at run time --- though I doubt that's >> our main speed bottleneck :-) > > Yes. > Configurator.php should be called when no lib/config-user.php exists, > the virgin setup. I added that in the current cvs configurator. > Then we can ensure that e.g. the admin password is encrypted, the > include path and many more paths can be guessed automatically and good > suggestions for VIRTUAL_PATH configurations can be choosen from. This will need some apache/conf/httpd.conf parsing and changing. This way we could check file-permissions and provide a good .htaccess solution. But not quite easy. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Martin G. <gim...@gi...> - 2002-09-16 17:41:09
|
Jeff Dairiki <da...@da...> writes:
> I think it would be real slick if the config script got all its info
> from (specially formatted) comments (and code) in the dist-config
> file. (Maybe it already works that way?)
No, it doesn't work that way. The configurator knows nothing about the
config-dist.php file at the moment.
But I agree that it would be cool to have the configurator get it's
data from a config-dist.php file which should be a fully functional
file itself.
Perhaps something we could extend the JavaDoc like comments:
<?php
/*#
* Select driver for X.
*
* If you want to do X, then you have to select the right
* driver.
*
* #type select
* #choices foo bar baz
* #depends Y
*/
if (!defined('X')) define('X', 'foo');
/*#
* The greeting
*
* Please specify a greeting.
*
* #type text
* #default Hello World
*/
if (!defined('Y')) define('Y', 'Hello World');
?>
I just don't know how this scheme could be made general enough to work
with all cases. For PhpWeather I have a system with dependencies and
validators which gives me a lot of flexibility. I think it will be
hard to turn that into a system with enhanced comments.
Unless, of course we simply hide the relevant PHP code in a comment
and then have the configurator execute it:
<?php
/* ## Begin configurator code
*
* $port_validator = new pw_validator_range("Sorry, '%s' is not a valid port-number " .
* "because is't outside the range 1-65536",
* 1, 65536);
*
* $proxy_dep = new pw_dependency('use_proxy', 'true');
*
* $options['proxy_port'] =
* new pw_option_integer('proxy_port',
* "This is the port number of the proxy server. The " .
* "default is what is used by the Squid proxy server. " .
* "Another common port number is '8080'",
* array($proxy_dep), $port_validator, 3128);
*
* ## End configurator code
*/
The configurator script could find the right comment, strip the
leading ' * ' from each line and run it through exec(). But isn't this
getting kind of silly now? :-)
> Then problems with keeping the configurator in sync with the config
> options go away....
--
Martin Geisler My GnuPG Key: 0xF7F6B57B
See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell => A telnet-connection (almost :-) in a PHP page.
|
|
From: Jeff D. <da...@da...> - 2002-09-16 18:09:05
|
> No, it doesn't work that way. The configurator knows nothing about the
> config-dist.php file at the moment.
>
> But I agree that it would be cool to have the configurator get it's
> data from a config-dist.php file which should be a fully functional
> file itself.
Yes, or we just treat the configurator.php as the ultimate authority
and generate the default config file using configurator.php.
Then the problem of keeping the two in sync goes away.
Of course, if Joby wants to write a perl configurator as well, then
the problem comes back.... oh well Personally, I'm not sure we need
a standalone (non web based) configurator script. It think Reini has
already suggested this but here's a possible UserStory:
(First: configurator.php should not be the entry point, the entry
should be through the main wiki script --- this allows configurator.php
to properly autodect things like VIRTUAL_PATH...)
1. The Configurator is fired up by browsing the main wiki script, either
with a query_arg of action=configurator, or if the wiki is a virgin,
unconfigured wiki, it fires up the configurator automatically...
Note that configurator.php should not be the entry point, the entry
should be through the main wiki script --- this allows the configurator
to properly autodect things like VIRTUAL_PATH.
2. The configurator reads in the current configuration file (if it
exists),
merges in defaults and autodetected values, then presents the user
with the configurator form.
Specially formatted comments in the
config file could be used to indicate the default/autodetected values
of each setting --- this would allow the configurator script to
determine
whether a setting has been customized, and would also allow give the
human reader useful information. E.g.:
/* VIRTUAL_PATH
*
* VIRTUAL_PATH is the ... blah blah...
*
* Example:
* define('VIRTUAL_PATH', '/SomeWiki')
*
* Default Value:
* define('VIRTUAL_PATH', '/foowiki')
*/
define('VIRTUAL_PATH', '/foowiki');
When merging the current configuration with default/autodetected
values the configurator would pick the current config values only
if they had been changed from their default values (at the time
the current config script was produced).
3. When the user has changed whatever settings he wanted to change, he
hits the "Download new configuration" button, and a new config file
gets downloaded (to the client computer, not the server).
4. Then the new configuration file must then be manually installed on the
server in the appropriate place (via FTP, rcp, scp, etc...)
|
|
From: Joby W. <joby@u.washington.edu> - 2002-09-16 19:18:42
|
Jeff Dairiki wrote: > Of course, if Joby wants to write a perl configurator as well, then > the problem comes back.... oh well Personally, I'm not sure we need > a standalone (non web based) configurator script. It think Reini has > already suggested this but here's a possible UserStory: > First it would be in PHP, I hate writing Perl. My main motivation is to avoid exposing my database settings over the web. Do you want it potentially available on the web that your data is in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs into that database as 'wikiuser' with the password of 'securepasswd'? jbw |
|
From: Jeff D. <da...@da...> - 2002-09-16 19:45:59
|
> First it would be in PHP, I hate writing Perl. My current first choice would be python :-) More seriously, many people may not have the CGI/standalone version of PHP installed (properly) which makes running standalone PHP scripts a bit problematic. The standalone PHP does not seem to be available in the RedHat 7.1 distribution, for example (though it is included in the 7.2 RPMs --- dunno about 7.3.) > My main motivation is to avoid exposing my database settings over the > web. Do you want it potentially available on the web that your data is > in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs > into that database as 'wikiuser' with the password of 'securepasswd'? I see your point. Perhaps the configurator script could be made so that it doesn't reveal the current values of sensitive settings --- it would still, of course, give you the option to change the setting to something else. You'd see something like: MySQL database name: <has been set, not shown for security reasons> Change to: _______________________ (Or if a database name hasn't yet been set) MySQL database name: _________________________ An alternative would be to make it so that the configurator never reads the installed config file. Instead give the user an opportunity to POST a config file from which settings would be pulled. |
|
From: Joby W. <joby@u.washington.edu> - 2002-09-16 20:35:23
|
Jeff Dairiki wrote: >>First it would be in PHP, I hate writing Perl. > My current first choice would be python :-) Python is pretty cool, but I am a language bigot. I prefer C-like syntax languages. > > More seriously, many people may not have the CGI/standalone version of > PHP installed (properly) which makes running standalone PHP scripts > a bit problematic. The standalone PHP does not seem to be available > in the RedHat 7.1 distribution, for example (though it is included > in the 7.2 RPMs --- dunno about 7.3.) > Oh I agree that not all would use it, but if we can provide configuration application independance by having settings be determined by the default config settings file (config-dist.php), then maintaining different configuration applications is trivial. Although devising the commented code and parsing it seems non-trivial. > >>My main motivation is to avoid exposing my database settings over the >>web. Do you want it potentially available on the web that your data is >>in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs >>into that database as 'wikiuser' with the password of 'securepasswd'? > > > I see your point. > > Perhaps the configurator script could be made so that it doesn't > reveal the current values of sensitive settings --- it would still, > of course, give you the option to change the setting to something else. > You'd see something like: > > MySQL database name: <has been set, not shown for security reasons> > Change to: _______________________ > > (Or if a database name hasn't yet been set) > > MySQL database name: _________________________ > This would only work because the configurator exports the config-user.php file to be used. If the file it exports has the current settings (assuming no changes) then we have the same problem. If it doesn't include the settings then the end user will have to: 1) add the info each time, 2) manually merge the current (old) with the exported (new), 3) we would have to provide a tool to merge the data. Another work around for the above senario would be to split the config-user.php file into multiple files -- non ideal. > An alternative would be to make it so that the configurator never reads > the installed config file. Instead give the user an opportunity > to POST a config file from which settings would be pulled. This is more secure, but it does involve many extra steps: 1) download current config-user.php 2) Access action=configurator 3) upload current config-user.php 4) Edit 5) download new config-user.php 6) upload new config-user.php This does also expose the database settings to man-in-the-middle attacks. I understand that I am being extra paranoid (part of my job), so I don't want to veto ideas because they don't meet my needs even though they might be sufficient for the vast majority of other users. Having the config settigs be accessable only by an administrator and using https should be sufficient for most users. But from my paranoid perspective, I would like to provide a very secure route for configuration -- which is command line. jbw |
|
From: Joby W. <joby@u.washington.edu> - 2002-09-17 19:18:01
|
A proposal:
My solution is a bit more complicated (because there are four elements),
but it would involve a lot less parsing and allow for multiple methods
of configuration.
The current proposal is for three parts:
1) config-dist.php -> Default distribution config settings
2) config-user.php -> Implimentation's config settings
3) Configurator.php -> elements to configure via wiki
The current debate is whether to put the validation elements in
config-dist.php (as notes in the comments) or Configurator.php (would
just be code). Since the validation of settings is really a seperate
function, I would just make it a fourth file, thus:
Config elements:
1) config-dist.php -> Default distribution config settings
2) config-user.php -> Implimentation's config settings
3) config-valid.php -> defines what is a valid data for a setting
(authoritative source).
Config applications:
1) Configurator.php -> elements to configure via wiki
2) cli-config.php -> config via command line
n) more options, such as a plugin to a web management app (webmin), a
GUI app (Gnome or KDE), or perhaps a ncurses app.
config-dist.php and config-user.php would just be the define()s and
variables set.
config-valid.php would contain classes to validate configuration data
and the authoritative settings, such as:
-------------------------------------
class valid_bool{
valid_bool($variable){}
get_default(){}
get_current(){}
get_description(){}
is_valid($new){
if(is_bool($new)){
$this->new = $new;
return true;
}
}
get_new(){
if(isset($new)){
return $new;
} else {
return $current;
}
}
}
$reverseDNS = array(
'type' => 'boolean',
'define' => true, // true if use define, else variable
'name' => 'ENABLE_REVERSE_DNS',
'description' => "If set, we will perform...");
$valid_reverseDNS = new valid_bool($reverseDNS);
-----------------------------------------------
The above is really rough and just for the idea. In this situation,
when someone starts a virginwiki and the Configurator.php file is called
the config-dist.php file would be generated from this config.valid file
-- thus config-valid.php would be the authoritative source.
Configurator.php and cli-config.php would just know how to use the tools
presented by config-valid.php and generate an interface.
jbw
|
|
From: Aredridel <rs...@nb...> - 2002-09-17 19:50:48
|
Having defaults (loaded first) and a user-override file makes a lot of sense -- it's easy to parse, and easy to write a configurator for. That'd be my preference for sure. If one uses a configurator, the defaults could be coded into a load-configuration routine, leaving the option typing and structure in code, where it's most flexible and doesn't involve writing any parser. Having a configurator spit out a file to upload isn't too bad, and I like the idea of a CLI configurator. Downsides: If done this way, a configurator would either have to parse PHP or be written in PHP -- not an issue I think, since this /is/ PHPWiki, and there's no sense in using something else since this is a prerequisite for the rest of the project anyway. Simplicity is a good thing, as is a central place for configuration in the code. In my own projects, I use defines if not defined in my libraries, and to override, just define before require. Documenting settings is easy, really, and a configurator could serve as documentation rather easily. The system is scalable, and defines are a plus since they're inherently superglobal even in PHP3, so no version messes to deal with. Code optimizers deal with them efficiently, and the parse time on my several thousand lines of code is milliseconds. Ari |
|
From: Jeff D. <da...@da...> - 2002-09-17 20:25:50
|
> A proposal:
It sounds like a decent one.
A few not particularly germaine comments:
> Config applications:
> n) more options, such as a plugin to a web management app (webmin), a
> GUI app (Gnome or KDE), or perhaps a ncurses app.
Just in case you're seriously considering writing something like that:
keep in mind that (I think) the way to go is to use a scripting-type
language (e.g. python or perl) with GUI (or curses) bindings. Development
is
much easier (IMHO), and the result is (or can be) much more portable
(easily). (A fair amount of our user base seems to be Windows based...)
(Or one could use Java... which makes it, in theory (haha), automatically
portable...)
> class valid_bool{
...
> is_valid($new){
> if(is_bool($new)){
> $this->new = $new;
> return true;
> }
> }
Since it changes the state of the valid_bool object,
is_valid is a BAD, BAD method name. (Should be,
maybe, set_new(), or set_new_checked() or something
like that.)
> ... thus config-valid.php would be the authoritative source.
>
> Configurator.php and cli-config.php would just know how to use the tools
>
> presented by config-valid.php and generate an interface.
Seems good. "One authoritative source" is a good goal.
And if it's in PHP (rather than something we have to parse)
life will be easier. (Until you want to write the fancy GUI
C/perl code...)
|
|
From: Joby W. <joby@u.washington.edu> - 2002-09-17 21:26:02
|
Thanks for the comments Jeff. I wasn't actually proposing that we (or
I, as if I had the skill...) write the bindings for Webmin or a
Gnome/KDE plugin, just that this model would make it a bit easier to do
so if desired in the future.
I just want to propose a more atomic structure for the configuration
files. We have the following goals for our config file structure:
1) Seperation between user settings and defaults
2) No parsing to get user or default settings (this is ok for a daemon,
but for a script that has to reparse for each pageview, it is just more
overhead).
3) One authoritative source for config variables and the potential
values for those variables.
4) Clean interfaces which increase flexability and will decrease
breakage over time.
Seperate config-user.php and config-dist.php files does (1). Having the
config-user and config-dist files be in php does (2). (3) can be done in
a variety of ways, but in my proposal config-valid.php's only purpose is
to be authoritiative. By putting validation and only validation in one
file we can design a clean interface so that the validation tools can be
used by a variety of interfaces and those interfaces should not need
significant management to maintain compatability over time.
>
>>class valid_bool{
>
> ...
>
>> is_valid($new){
>> if(is_bool($new)){
>> $this->new = $new;
>> return true;
>> }
>> }
>
>
> Since it changes the state of the valid_bool object,
> is_valid is a BAD, BAD method name. (Should be,
> maybe, set_new(), or set_new_checked() or something
> like that.)
>
Yeah I saw that just before I sent it, but since this was more for the
idea rather than the actual code, I left it. Should have split
is_valid() into is_valid() and set_new() and have set_new() call is_valid().
jbw
|
|
From: Martin G. <gim...@gi...> - 2002-09-16 17:21:35
|
Jeff Dairiki <da...@da...> writes: > Maybe, since we have a configuration script, the configuration > script should do all the figuring of the defaults and autodetected > values. (I.e. everything that's now down in lib/config.php.) > > Then it can generate a single config file with all required settings > as constants. Are you sure it's a good idea to have the script write a file with the settings? This was how my first attempt at a configuration tool worked, but I've now moved away from the idea. The problem is that it rarely works... It only works if the webserver has write permission to the installation directory of PhpWiki. At my server PHP runs as the user 'nobody' whereas the files are owned by user 'gimpster'. The configuration tool also has to be protected so that others cannot change the configuration. This is not a problem, but it has to be considered. The current configurator lets you create a configuration that you can /download/ and then later upload using FTP or whatever mechanism you use for this. Just a couple of thoughts... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
|
From: Joby W. <joby@u.washington.edu> - 2002-09-16 17:27:41
|
I agree with Martin that we need to provide some additional options, which I would be happy to help with. Another option would be a command line php script, much like Squirrelmail's perl configuration script. jbw Martin Geisler wrote: > Jeff Dairiki <da...@da...> writes: > > >>Maybe, since we have a configuration script, the configuration >>script should do all the figuring of the defaults and autodetected >>values. (I.e. everything that's now down in lib/config.php.) >> >>Then it can generate a single config file with all required settings >>as constants. > > > Are you sure it's a good idea to have the script write a file with the > settings? This was how my first attempt at a configuration tool > worked, but I've now moved away from the idea. > > The problem is that it rarely works... It only works if the webserver > has write permission to the installation directory of PhpWiki. > > At my server PHP runs as the user 'nobody' whereas the files are owned > by user 'gimpster'. > > The configuration tool also has to be protected so that others cannot > change the configuration. This is not a problem, but it has to be > considered. > > The current configurator lets you create a configuration that you can > /download/ and then later upload using FTP or whatever mechanism you > use for this. > > Just a couple of thoughts... > |
|
From: Jeff D. <da...@da...> - 2002-09-16 17:40:01
|
> The current configurator lets you create a configuration that you can > /download/ and then later upload using FTP or whatever mechanism you > use for this. Oh yes, I agree. I think that's definitely the way it ought to work. (If I said something else, I didn't mean it...) What I was trying to suggest was that the generated config file should contain the values for those config settings which are being defaulted (or auto-detected) as well as those modified by the user. I.e. all the defaulting and auto-detecting should happen in configurator.php, rather than (as it is currently done) in lib/config.php. This saves the run-time overhead of computing the defaults on every invocation of PhpWiki, and allows the user to easily override the defaults via configurator.php (or by manually editing the resulting config file.) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X