Configure Suexec and PHP

Background: I’ve transferred several sites from one host to another. Since I store ALL passwords to everything in a my own FIleMaker database, all I have to do is set up the database in phpmyadmin in the new host, import the SQL file, FTP the files and I’m done. Period. Everything works like a dream. No issues, no errors of anykind. None. Sweet. Except I’m an idiot at times:

Yesterday I woke really early and thought I would explore the WHM panel and came across the Configure Suexec and PHP. I made a change but I don’t remember what it was. See? I’m an idiot. All of the sites work but I cannot login to the manager. I get nothing but includes paths errors.

I searched here and came across the vhost.httpf.conf as being the likely culprit? So I suggested that to support, who in turn said that it looked like the old host had re-written the includes path. They kinda resolved it: the sites did display without the includes warning. But now I can’t login the manager. It displays the login, but when I click on login, the browser displays a dropdown message (attached) referring to the login.processor.php file.

The websites I FTPed to the new host: I can’t login. The websites I start from scratch (everything is MODx except one Joomla site which has no issues whatsoever).

PHP 5.25 | MySQL 5.0.51a-community | Zend Optimizer 3.3.3 | Apache 2.0.63 | MODx 9.6.1p2

If you can still ssh into your server or otherwise get access to MySQL database, you should be able to track down the settings that you changed. I hope I’m understanding you here correctly... do you mean you changed a setting in MODx and then everything broke? If so, the setting is stored in the database... if you can log into the database you can revert your change.

If you have shell access to the server, you can fix the permissions errors (if that’s what’s causing the error you’re experiencing).

Did you turn on Suexec, or change your include path, or...? You forgot to attach the error you’re seeing, so we don’t know what it is. Suexec generally requires you to use different permissions for PHP files than the standard PHP-as-a-shared-service setup (there is documentation explaining this in the MODx wiki).

Actually, now I’m starting to have problems with suexec. I’m working on a new Cent OS Linux box, and the @!%!^!# thing won’t let me change the permissions on the /assets/ directory to anything but 777. In other words, I’m leaving my assets folder vulnerable.

I installed suexec (with a lot of help), and it is now running as an apache module, but no good. What exactly does MODx require? Why is this such a pain? Why are some of my scripts not working with suexec?

Thanks!

I run suexec on my servers and dont have any problem. suexec is supposed to not let you run anything with 777 permission. Are you on a dedicated server where the admin folks can switch it back?

Yes, it’s a dedicated server... I guess now it’s running as an apache module, but for whatever reason it’s not actually handling scripts. I had this thought that maybe since some of my Snippets "broke out" of MODx by using a "include(’../lib/some_other_file.php’);" type of line, that maybe that caused some problems.

What should I ask the server admins?

Thanks for the help. I’ve read a lot of the docs on suexec and it still doesn’t entirely make sense to me when I see how our server is behaving.

What you said earlier doesn’t seem right to me :-

"
Actually, now I’m starting to have problems with suexec. I’m working on a new Cent OS Linux box, and the @!%!^!# thing won’t let me change the permissions on the /assets/ directory to anything but 777. In other words, I’m leaving my assets folder vulnerable.
"

I run on Centos all the time, my assets folder has the following perms ’drwxr-xr-x 16 apache apache’ however you should be able to set this to what you want it to be, I also have several external php scripts included from snippets that use my user name, not apache, as I check these out of a subversion repository. Your external php scripts should only ever be r--r--r--, you dont need to write to these

If you have your perms set correctly you shouldnt need suexec.

I’d see your admin’s about perms on /assets first.