need to serve files from a common location

I need help with serving .pl files from a common location like "/usr/share/dir" to all domains on the same server machine.

The .pl files should execute/work on/in user's directory.

my purpose is to avoid copying the same file under each user's dir.

Status: 
Closed (fixed)

Comments

So do you want to map a URL path like /dir in all domains to a directory like /usr/share/dir ?

If so, you could do this with an Apache alias in the default virtual host - just go to Webmin -> Servers -> Apache Webserver -> Default Server -> Aliases and Redirects, and add an entry in the Document directory aliases table.

bislinks's picture
Submitted by bislinks on Wed, 04/14/2010 - 10:25 Pro Licensee

oh. i did not realize that i have already done that in the past.

But when i call a url mapped to /usr/share/dir from a domain; instead of executing, it gives option to save the .pl file from that domain.

Is there a permission problem? if so, who should own and what group should files in /usr/share/dir belong to ?

Oh, so those are .pl CGI scripts that you want to run?

This could get a little more tricky ... do you want them to run as the owner of each domain, or as single user?

bislinks's picture
Submitted by bislinks on Wed, 04/14/2010 - 14:34 Pro Licensee

i want them to run as owner of each domain

Joe's picture
Submitted by Joe on Wed, 04/14/2010 - 14:45 Pro Licensee

That's not possible. suexec decides who to run something as by the owner of the files, and decides whether it can be run securely based on permissions, so it will refuse to run things that can't be run securely, and the files can't be made to be owned by everybody. Also, suexec won't run anything outside of the docroot, which is /home on a Virtualmin system.

So, you'll need to figure out a way to make it secure while running as the Apache user. Since the files are going to be owned by apache and domain owners can't modify it, you can do that.

If you need the scripts to behave in some specific way based on the domain, you'll need to make it aware of domain and behave accordingly.

bislinks's picture
Submitted by bislinks on Wed, 04/14/2010 - 15:45 Pro Licensee

I CHOOSE THIS: "files are going to be owned by apache and domain owners can't modify it"

OK. I will run them as apache.

Please let me know how do i configure. Should I just change the ownership to apache? Are there more configuration to be done?

Due to the way suexec works, you won't be able to use an alias to run CGI scripts that are owned by some common user unless you disable suexec for the whole domain (which would break PHP scripts run as the domain owner, and other CGIs).

Perhaps a better solution is to create a new virtual server that will just run your scripts (like yourscript.yourdomain.com), and setup a proxy from /dir to http://yourscript.yourdomain.com/dir . The put all the .pl files in the /home/yourscript/public_html/dir directory.

bislinks's picture
Submitted by bislinks on Wed, 04/14/2010 - 16:51 Pro Licensee

ok. I have created the vs software.bislinks.com

how/where do i create proxy?

You can do this for each domain at Server Configuration -> Proxy Paths.

bislinks's picture
Submitted by bislinks on Wed, 04/14/2010 - 17:37 Pro Licensee

i did set up proxy for preachword.com/tools

yet the browser is trying to download the .pl file.

html files are doing ok through the proxy.

Can you move just the .pl files to the cgi-bin directory instead? By default, only files in that directory will be executed - those elsewhere will just be returned as text.

Alternately, you can go to Services -> Configure Website -> /home/whatever/public_html -> Edit Directives, and add the line :

AddHandler cgi-script .pl

Then click Save, and then Apply Configuration.

bislinks's picture
Submitted by bislinks on Thu, 04/15/2010 - 08:42 Pro Licensee

I had "AddHandler cgi-script .cgi"; hence, it was failing.

I changed .cgi to .pl and now it is working.

Thank you very much.

Glad to hear it is working now!

I'd suggest keeping the AddHandler cgi-script .cgi line as well, so that regular CGI scripts still work.

Automatically closed -- issue fixed for 2 weeks with no activity.