Is anyone running PhpGedView- what settings?

[midwestm]

I'm trying to install phpgedview on one of my own, personal accounts which I have set up on my VPS. I cannot access the install script. I get a 500 internal server error. The logs reveal nothing except for the fact that I got a 500 page.

Does anyone else have phpgedview running on one of their VPS's? Was there a specific change you had to make to deviate from the Jag default settings? I have made only moderate changes to the default (ie, changing the max php upload from 2M to 10M) and as far as I know nothing that would affect this situation.

My server is hosting lots of other php/mysql programs without a problem. However, I do think that there IS an error or configuration issue somewhere (soon to be a new thread) so I am open to ideas.

[JPC-Jawad]

I'm trying to install phpgedview on one of my own, personal accounts which I have set up on my VPS. I cannot access the install script. I get a 500 internal server error. The logs reveal nothing except for the fact that I got a 500 page.

Does anyone else have phpgedview running on one of their VPS's? Was there a specific change you had to make to deviate from the Jag default settings? I have made only moderate changes to the default (ie, changing the max php upload from 2M to 10M) and as far as I know nothing that would affect this situation.

My server is hosting lots of other php/mysql programs without a problem. However, I do think that there IS an error or configuration issue somewhere (soon to be a new thread) so I am open to ideas.

Are you trying to access the install script via browser. An internal server error is most probably due to an apache misconfiguration like a file permission error or some incorrect .htaccess rules. You can find the exact error by logging in via shell and checking the error logs. Here is how to do it.

1- tail -f /path/to/apache/error_log

2- Enter the script path in the browser and keep pressing ctrl + F5 key which will refresh the page creating several entries in the logs for your IP. Immediately revert back to shell and press ctrl + c to end the tail and check the error. An indicator is that the IP against the error will be your local IP (confirm by visiting myipaddress.com, this IP should appear in the logs).

You can also open a support ticket and provide us your VPS logins as well as steps to reproduce the problem so that we can assist you.

[JPC-Jawad]

For a cPanel server, the error log path is /usr/local/apache/logs/error_log and for Plesk its usually /etc/httpd/logs/error_log

[midwestm]

I had kind of hoped to avoid troubling the support people but as I already have in this thread perhaps I'll just open a ticket after all.

Actually, I think I will open two tickets. I've been having trouble with my VPS (and have an open ticket regarding the matter) for awhile now related to some php error and I observe that the errorlog is some 200mb large with the suphplog and suexeclog being just as big. (I'm pretty sure that Jag has looked at these before, I'm just thinking that if I have almost 1 gig in error logs its worth checking into again.)

[Gwaihir]

So, you are using suphp? Have you perhaps tried to make php settings via .htaccess anyway? Many installation instructions for php applications tell you to make them there, but that is only true when PHP is installed as mod_php. In JagPCs standard suphp setup (as used on shared servers), it will get you a 500 internal server error. Put your php settings in a php.ini instead. (For how that works, see notes in the kb and elswhere on these boards.)

[Vin DSL]

Yep! In particular, make sure you don't have:

php_flag display_errors off
php_flag register_globals off

...in your .htaccess file(s). Those are common killers!

Sorry, for being rudimentary, but you never know...

[midwestm]

It ended up being even more rudimentary than that. I had uploaded to the domain using root ftp access and for some reason, since the files were 'owned' by root instead of by the domain username, the program wouldn't install. Jag changed the ownership of the files and viola, it was up.

[Vin DSL]

~Cool

Tech Support rawks!!!

[jason]

It ended up being even more rudimentary than that. I had uploaded to the domain using root ftp access and for some reason, since the files were 'owned' by root instead of by the domain username, the program wouldn't install. Jag changed the ownership of the files and viola, it was up.

That's the nature of suPHP. Not only does it allow PHP scripts to be run as the UID of the site owner it also prevents scripts from running if they aren't owned by the site owner. Together these features greatly limit the amount of damage an attacker can do if he gets access to the system.

Root is your administrator account and should only be used for administrative tasks. Root is all-powerful--whatever you try you can do with root, even if it is wrong. To avoid accidently hosing your VPS, use individual user accounts for your sites and only use root when you absolutely need to.

--Jason