Revo manager doesn't like virtual server

Quote from: AMDbuilder at May 16, 2012, 07:43 PM

Hello,

Sorry, I missed the earlier responses! I think Jason is on the right train of thought in that the way your hosting is configured, the files aren't all owned by you which creates issues.

Could you ask you host how php is configured to run on the server? (cgi, fcgi, dso, suphp, etc?) Typically shared servers use suphp which avoids the ownership problem, with other configurations being used depending on server load/demands.

You're talking Greek to me, but I did pass this along to my hosting provider. Is it an ownership issue in core/cache session files? My hosting provider said, "The problem is that modx is creating those particular folders as httpd instead of your ftp username. That's not a normal occurrence with any other pieces of software on the servers." But he later said, "I'm looking into this further to see if I can't find some more information about what they need us to do."

His statement puzzles me however, because he had said that when they moved my site to the new environment "nothing changed." So if MODx creates the folders (core/cache) on the new server as httpd they should also have been created as such on the old server. I don't know about the old server - I never had reason to check.
[ed. note: kirkhuyser last edited this post 14 years, 4 months ago.]

Note that when you delete the files in the core/cache directory, MODX re-creates many of them on the next MODX request. That's normal and you've still cleared the cache, since the obsolete versions of the files are gone.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Quote from: BobRay at May 16, 2012, 11:26 PM

Note that when you delete the files in the core/cache directory, MODX re-creates many of them on the next MODX request. That's normal and you've still cleared the cache, since the obsolete versions of the files are gone.

Well, I can't delete them because I'm not "httpd." But I had my hosting provider delete them before running Setup. My problem is still not solved. So I was going to proceed to your next troubleshooting suggestion:

Make sure the config.inc.php file is writable
Back up the config.inc.php file
Load the file in a text editor
Delete the contents and save it empty
Delete all files in the core/cache directory
Clear your browser cache and cookies
Run Setup
Check the file to see if it's filled in

If this step jeopardizes the operation of the web site then I don't want to do it right now. Would it? Or does it just affect Manager operation?

Again, if sessions are stored in the database why am I fighting this persistence issue between Manager sessions? My database is in it's original location - only the web site moved.

It shouldn't hurt anything as long as the config.inc.php file is writable, but if anything goes wrong, you'd have the backup version and could just copy it back (assuming that's possible at your host).

You might want to back up the config.core.php files too, just in case. If you're nervous, you could always back up the DB and all site files, but it really shouldn't be necessary. The fact is that if you can't use the Manager, you're not going to be very happy anyway.

Before trying this step, though, I'd probably wait to see if the host comes up with anything on the ownership issue.



------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Thanks for that. As I mentioned earlier, my hosting provider is blaming httpd ownership on MODx, but at least he later said he would look into this further.

Hello,

It sounds like your host is using one of the configurations: cgi/fcgi/dso (without suexec enabled for them)

In this configuration any files/folders created by the server would be owned by nobody, instead of your user, thus causing the problems. Your host would need to alter the configuration, or if they are still unable to sort the issue out consider a different hosting provider.

I know for fact using the DSO configuration will cause issues with any script uploading files, so that's an unlikely (/very unwise) configuration for a shared server. CGI has performance/security issues so it's also unwise leaving fcgi, which is better if configured properly, but without suexec enabled will also have problems. Granted I am going for the abbreviated version of all the configuration gibberish

It sounds like your host is using one of the configurations: cgi/fcgi/dso (without suexec enabled for them)

In this configuration any files/folders created by the server would be owned by nobody, instead of your user, thus causing the problems. Your host would need to alter the configuration, or if they are still unable to sort the issue out consider a different hosting provider

But the files and folders are owned by httpd and are in the core/cache folder. By "your user" do you mean web users or mgr users?

This whole thing about who owns the files/folders in core/cache is just an inconvenience for me to follow Bob's Troubleshooting Guide. It's also a diversion away from the real problem - after logging in to Manager my login status does not persist.

As I had mentioned earlier, I'm totally confused about what gets stored in core/cache, what get's stored in the session path specified in .htaccess, and the so-called sessions that get stored in the database.

My login to Manager is stored somewhere and apparently as I move about in Manager it needs to keep checking my login status. Apparently my status gets lost and resources get grayed out, pages go blank, or I can't get to System Settings. I think this is what's termed "persistence," or lack thereof, from all my research on the Internet.

Hello,

I suspect the issues are related. Your server is configured in a non standard way (not the onapp/xen part), and as such you are having problems using MODX properly. I suspect fixing the ownership issues will resolve your login issues, granted they could just be the sign of additional server configuration problems.

In regards to all the user stuff... Typically there is a "nobody" and a "user" (at least for apache), in most situations you want the server to interact with php files as the "user" instead of "nobody", as you can't change/delete files you don't own.

In the current configuration it sounds like as I noted earlier, your host hasn't configured the server properly, and as such when apache interacts with php, it's doing so as the "nobody" user instead of your username. The user being your login (ex: cpanel/ftp login). In the earlier noted configurations, suexec should correct this problem (except with dso), to a degree. It doesn't prevent you from assigning incorrect permissions (aka too much permission), so you can still get in trouble. This is part of the reason most shared hosting providers use suphp, it forces php to run as your user, and if you give too much permission it causes 500 errors to help protect you.

I think in short, your server is misconfigured, and thus causing your problems. If you want I can set you up with a trial account on one of our servers to eliminate the hosting from the problem.

I hope that helps clear things up some.

@AMDBuilder -- Great explanation and a generous offer.

I agree that it's unlikely that the stuff in my troubleshooting guide will solve this.

------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

@AMDBuilder

My hosting provider said they use suphp.
At any rate, I've been fighting this problem three weeks tomorrow. I'll be in touch with you shortly.
Thx