Sorry for the confustion...
I think I may have muddied my own waters here. I don't want to configure every script on a server for every user, all in one go. Well I could but that's another question...
I can do it with one file per script, that's how STAMP et al do it now. The problem is, that it's not designed for multiple users, so it wont scale properly. Lots of other scripts are designed the same way, in fact until I started to think about multiple domains on the same box, all of mine were built this way.
Using multiple files allows individual users to to control their own space. Problem is that it seems messy. You get files all over the place, but you know that user X can't touch user Y's settings.
Imagine three domains, A, B and C each which usess three scripts 1.pl, 2.pl and 3.pl. Unless I write all three scripts, each script will have it's own legacy configuration system, which may need changing, so that each script does differnet things per different virtual-server.
I started with STAMP as it's a decent formmail replacement, now if I want to configure it differently for each domain, I have to either force it's configuration system, or create a file per virtual-server - which was my own initial solution.
My approach is to use one file that the script will default to if nothing else is found, and one file per virtual-host that it tries first. This will be duplicated per script.
Next I try another script, and this uses it's own different configuration system, which again may need changes to make it multi-host aware. Now things are starting to get scary....
Doing it this way I'll end up with one config file per script per virtual host plus a default per script, 12 in the example above.
Is there a better way of doiong this? Given that some of the scripts will be new and some will be legacy? What is the best way of tackling the problem.
- I like the one file approach, (not nessisarily for every script), but I'd have to write a way of controling it, as it's unsafe as it stands.
- The multiple config files is simpler, and works with largacy code better, but could get messy.
Much thanks for the suggestions so far, I do appreciate input, it's very helpful. If I have still confused anyone I can take this off line if you prefer.
|