Difference between revisions of "Configs"
m (more wikifail) |
m (removed link to Bugzilla) |
||
Line 3: | Line 3: | ||
==What config variables go where?== | ==What config variables go where?== | ||
− | There are three config files that live in /etc: config.pl, config-local.pl, and config-private.pl. When adding a new config option, figuring out where it goes should roughly follow these rules (from <dwuser>mark</dwuser> in comments to | + | There are three config files that live in /etc: config.pl, config-local.pl, and config-private.pl. When adding a new config option, figuring out where it goes should roughly follow these rules (from <dwuser>mark</dwuser> in comments to a discussion on Bugzilla bug 518): |
Latest revision as of 11:57, 1 August 2014
What config variables go where?
There are three config files that live in /etc: config.pl, config-local.pl, and config-private.pl. When adding a new config option, figuring out where it goes should roughly follow these rules (from mark in comments to a discussion on Bugzilla bug 518):
If the setting is globally useful to everybody who runs the DW code, even if
they're just running dw-free on IJ, without being modified, then it belongs in
config.pl.
Example: $HTDOCS = "$HOME/htdocs";
Given that our files are in the htdocs directory, that's just how the code is, nobody is going to want to change this option. Unless they really, really know what they're doing.
If the setting is useful to everybody running Dreamwidth.org code, and developing for the Dreamwidth.org site (i.e., using dw-nonfree to develop for our site), but is not useful to everybody in the world, then that's config-local.pl.
Example: $SITENAME = "Dreamwidth Studios";
This is true for everybody developing dw-nonfree/Dreamwidth.org code. But it won't apply to Squeaky over at IJ, so it doesn't belong in config.pl.
If the setting is even more intimate: it contains a password, IP address, cluster name/number, URL, etc, then it's config-private.pl.
Example: $CONCAT_RES = 1;
[...]
- I think I was following you until I got to the example. Why is CONCAT_RES in
- config-private, and not config-local? Or is it just that many people running
- test installations likely won't have Perlbal set up?
Yep, since that's an implementation detail, it's a private option. Now, if we switch to *requiring* Perlbal for dw-nonfree test installations, then I could see an argument for moving that option up to -local. But for now, as Perlbal is entirely optional, -private is appropriate.