MODX Revolution 2.2.10-pl traditional
Apache/2.2.26 via WHM/Cpanel 11, Liquid Web VPS
128M memory allocated
PHP 5.4.22
Previous install went haywire, current upgrade with **zero errors**
All packages = successful updates.
Assumptions: I manage 12 modX installs, assume I know how to debug/setup mod_rewrite and that I have spent two days searching forums and documentation (which I have.) I have re-installed three times, re-installed packages twice, installing via various approaches including nuking the entire site and doing an unpack from Cpanel's file manager. Oddly enough, the FTP reinstalls were the only thing that seemed to make progress.
Current issue, short version: Unable to fix a previous install, I performed an upgrade to 2.2.26 via the documentation. Three issues: 1) All URL's and placeholder attributes in row template are empty (previously working.) 2) FURL's are not working, all redirects to main page. 3) Attempts to update any resource are returning 500's, the server error logs don't appear to be showing anything useful.
Modx error log: Only shows trivial errors from my updates, nothing is output with current page views via manager or web.
Best guess: I am presuming this is a permissions issue, but I've no idea where it may be or how to debug it. This is a live site and it's been down for two days . . . any assistance is appreciated.
Comprehensive modX permissions list? I can't locate one.
Supplementary/ longer story/ how this began/ might be helpful: As I've mentioned, I've worked with modx for over three years and manage 12 installs, and one of my most frequent complaints are that it arbitrarily breaks without server changes or user changes, I just get the calls/emails, my site is broken, please help. Last week on another install the entire manager menu went missing, after several frustrating hours I managed to save that one with another upgrade. The issue at hand is on a different server, but is a similar issue, but REALLY weird. It has a sister site, a duplicate copy (normally not indexed,) and out of nowhere this install began pointing to the outdated install.
In other words, on the same server we have two Cpanel accounts:
/home/site-one/public_html (live)
/home/site-two/public_html (outdated)
Site one was humming along fine then one day it was brought to my attention a bunch of landing pages went missing. Changes to every possible file, database entry, modx and manual cache clearing did nothing, it refused to show site-one in the manager (or anywhere else.) Hence the upgrade/re-install, and then the fun REALLY began . . . .
Please help. I've always supported modx but am beginning to fade.
Update:
P.S. test-config.php runs flawlessly.
I fixed #3 (resource updates) by doing a chmod 755 on the manager directory, recursed into directories/files. Still looking, and still appreciate help on #1 and #2.
Correction: **ALMOST** fixed #3. As I'm going down through the resources, I'm seeing that by updating each resource (a huge and tedious task in itself) the ones I can update are fixing #'s 1 and #2, but there are now two resources that are giving me 500's. (Gathering that from Firebug.)
I did a manual delete via command line of the cache directory items; getting "permission denied" via FTP and File Manager is useless - shows it as deleted, reload the directory, everything is still there (File Manager has always been impotent this way.)
I've looked at the database entries in site_content, don't see anything really different. This site has a parent/child set of resources, and wouldn't you know it, one of the 500's is a parent, and the other is a child (of a different parent.) I've checked the (global duplicate url?) setting on and off, as there ARE some urls in other children the same, but not for the second resource.
Can someone give me an idea of items to look at to figure out why only TWO resources are returning a 500 on save?
Okay . . logged in as root and checked the apache logs, might be onto something. It still doesn't explain why all the other resources update, these two won't.
[Thu Jan 16 14:30:16 2014] [error] [client 123.456.789.00] ModSecurity: Access denied with code 500 (phase 2). Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\\\(.*from)" at ARGS:content. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "371"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "www.example.com"] [uri "/connectors/resource/index.php"] [unique_id "UtgzSDIcWesAAAg@NNkAAAAF"]
[Thu Jan 16 14:33:50 2014] [error] [client 123.456.789.00] ModSecurity: Rule 4c55930 [id "2000149"][file "/usr/local/apache/conf/modsec2.user.conf"][line "402"] - Execution error - PCRE limits exceeded (-8): (null). [hostname "www.example.com"] [uri "/manager/min/index.php"] [unique_id "Utg0HjIcWesAAAjwL1oAAAAI"]
So disabling mod_security for this domain fixed the last issue. I did review the modX document about nit picking through the rules and whitelisting them, but then what's the odds another one might come up later?
The following questions may likely go unanswered, but adding them for future discussion, if any:
Without any apparent server or environment changes, what could cause modX to spontaneously break, in part or completely?
What kinds of issues would cause the original #1 and #2? These were not related to mod_security.
Is there a comprehensive list of modx permissions, even a brief one? Such as "everything in core executable (755) except for import, export, cache," .... etc.
Why is modx kicking mod_security rules in the first place? Specifically, exceeding PCRE limits, I know rules concerning user input is a hard one to answer. This server has a variety of sites with different CMS software running (including the infamous "W" sites) and we're not seeing these issues with any other sites - this includes the "sister site" in the older version of modx.
-
☆ A M B ☆
- 24,524 Posts
The necessary permissions depend entirely on the server configuration. For the most part, if PHP is an Apache module, any directories that MODX itself will write to (particularly the cache directories and the core/components, core/packages and in the case of some add-ons core/model/addon-name) need to be 777 and the files 666. If PHP is being run as CGI/FastCGI, or using some other form of suexec, suphp or something similar they usually need to be 755 for directories and 644 for files. I have had some installations give 500 errors if the config.inc.php wasn't set to 444. And I worked with one server that required 775 and 664, although in that case I suspect a badly configured server. It had other problems.
During setup the permissions MODX will try to use when creating directories and files can be specified; I'm not sure where this would be adjusted later.
As far as why it should suddenly fail, invariably (barring a hacker infiltration) this turns out to be some configuration adjustment, upgrade or backup-restore or some other server administration task done by the hosting administration without any warning or notification. I once had a panicked client who had lost half of their site, which turned out to be because the hosting provider had had a catastrophic failure and used a months-old backup to restore the entire server. There had been absolutely no communication of any kind, and it took several phone calls from the client to finally pry the truth out of the hosting provider.
Another problem is that some actions in MODX, particularly Revo as it has a larger footprint to begin with, take a considerable amount of memory. For example, a number of large images being processed through phpthumb can hit a memory limit very easily.
