View Full Version : CGI program permissions

01-26-2005, 11:20 AM
Hi All,

Just moved a first domain to WH to test the water, vds, plus a little host domain to test that too.
There seems to be permission problem running some perl script (for the vds domain in the main cgi-bin), it builds html pages to the root (var/www/html) from mysql records. It runs, but doesn't actually make the pages.

Simultaneously, moved another first domain to a close competitor of WH to test the water there too, same problem. Their documentation is a bit better, clearly the problem is that "nobody" is the owner and the only workaround is to use cgiwrap (new to me, and annoying). Trouble is I'm getting nowhere since hardly anyone there knows how to work with it.

So I'm stuck and starting to think of whether reverse gear was top left or bottom right :-), and would be real pleased if someone knows how to cope.

With my previous provider (and I haven't changed DNS yet) this problem never came up, It was also easier for me to understand since the whole structure was straight Apache (usr/local/etc/httpd/htdocs as the root and so on) of which I had installed a local version on my PC, so I was accustomed to configuring that. The program in question ran without a problem for the server domain and several hosts as well.

Any ideas anyone?

01-26-2005, 12:48 PM
Hard to tell for sure what the problem is without knowing what is in your script. Can you give any more details? What Apps do you have installed via your Site Manager? Is it possible that you may not have something installed under Database or Development that you would need?

I wonder if it may have to do with not haveing changed the DNS yet. I know that when folks are first setting up an account that some scripts do not work that may refrence a url instead of an IP. Folks have problems with like PhpMyAdmin since it redirects to a http://domain.com/address and have had to go in and modify the script to have it look redirect to http://ipnumber/address... does that make sense?

I am just kind or grasping here but thought I would offer my input. :)

01-26-2005, 01:36 PM
Normally the server permissions on the server root (which is '/var/www/html') are set to rwx for owner, r-x for group and others.
Using PHP I have no trouble writing to the html directories, even with those permissions, as I understand it that Apache runs as 'User domainname' and 'Group vuser' (which is the owner and group of the server root directory).

There should not be a problem and you shouldn't need to do anything. But you could try setting the permissions on /var/www/html to allow reading and writing by anyone, just to test the script. If the script still doesn't work, then you will know that the problem lies elsewhere.

Let us know what you do to get it to work.

01-27-2005, 04:08 AM
Thanks for your reactions!
Just what I needed to find the solution!

Wildjokerdesign, yes, I had noticed phpadmin and some other things don't work until I change DNS.
I am calling the program using the IP adress, so I know that cannot be the cause.

Jalal, very encouraging to hear you write html using php without any specific intervention, that helps enormously to limit the problem causes. Add to that your information that Apache runs as User domainname and Group vuser, there is food for inspirational thought.

On the other new provider (vps on a shared server), if I changed the permission (chmod 777 -rwxrwxrwx) on the directory or file the program was writing to, it worked. Trouble is I cannot possibly manually chmod each and every one of them (and chmod 777 at root level is not enough, there is no inheritance). I tried chmod -R 777 at least the directories but that is not accepted in FTP. The conclusion to be drawn, was that the program did not have owner level authority to write, that was the key, and since I discovered that owner was "Nobody" and Group was all the users on this shared server, the only workaround was "cgiwrap".

From the experience at the other new provider, when it didn't work here at WH, I assumed similar causes, and frustration set in. Jalal's info that Apache runs with Owner domainname (same as my old provider) was the eye-opener, and meant the problem was totally unrelated to the other new provider scenario I described.

The only embarassing conclusion could be, I had a configuration mistake related to the program, when I installed at WH. So that was it, and it works now.

I might point out at this stage that the special VPS technology (each domain operating in its own environment) that WH boasts is what makes the difference for my issue. I should have realized that too, as an afterthought.

thanks to Wildjokerdesign and Jalal for taking the effort to help out!