Difference between revisions of "Configs"

From Dreamwidth Notes
Jump to: navigation, search
m (once again i fail at wiki)
m (removed link to Bugzilla)
 
(One intermediate revision by one other user not shown)
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 <a href="http://bugs.dwscoalition.org/show_bug.cgi?id=518">bug 518</a>):
+
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 [info]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.