Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server

by perrin (Chancellor)
on Oct 02, 2001 at 18:54 UTC ( [id://116144]=note: print w/replies, xml ) Need Help??


in reply to Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server

Well, now I'm confused. You seemed to be asking how to avoid having a separate config file for each virtual host. Masem suggested a way to do that and you replied that you don't want to share it for security reasons, which means you have to have separate config files. So what are you trying to do?
  • Comment on Re: Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server

Replies are listed 'Best First'.
Re: Re: Running Perl scripts from a single CGI-BIN, on a multiple-virtual hosting server
by ajt (Prior) on Oct 02, 2001 at 19:33 UTC
    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.

      Let's boil down your requirements:
      • For every script, be able to vary its configuration for each virtual host.
      • Manage as few files as possible.
      • Prevent users of different virtual hosts from changing each other's files.
      With that set of requirements, you seem to have the best solution: a default config for each script, with the ability to override it for each virtual host. The only thing I could add is that you may want to make the overriding more fine-grained. You could do this by converting the scripts to use a config system that supports option overriding, like AppConfig, or you could generate the config files from simpler templates, so that the user managing a particular virtual host just fills out a form or something and your program generates the approriate script-specific configs.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://116144]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (1)
As of 2024-04-16 15:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found