mod_security2 limiting file upload

[m.petersen68]

I've recently installed mod_security (with a third party ruleset) to fix an issue with great success. However, my joomla sites "PHP Info" pages now tell me that max_file_upload is back down at 2M (despite being set by me at 100M in the PHP config in WHM).

I can only guess that mod_security is throttling this back.

I've seen a couple of other posts about using the htaccess file to modify the limit, but I believe these posts refer to modsecurity1, as adding them to my htaccess gives a server error.

Can anyone help me with the appropriate course of action/rule syntax in modsecurity2 that will increase my file upload capability to the desired limit?

MP

[Infopro]

If it was modsecurity, you should be able to find the ruleset being tripped in the log and make a change as needed. I'm not sure though what rule would do this. That said, there's a nice tool for modifying rulesets per domain as needed which you might find handy in this case if it is indeed one of your rules.
ConfigServer ModSecurity Control

[m.petersen68]

thanks for that tip, I installed that script successfully, but alas it looks like the ruleset that I'm using doesn't have unique ID's as nothing appears in the mod_security Rule ID list. The other functions are working though.

You make an interesting point though about "which rule is tripping mod_security". The way I'm finding out about the restricted upload size is from my PHP summary page within Joomla, NOT by attempting to upload a file and being denied. In other words, would mod_security rules be invoked when simply running a PHP info?? I would think not.

Which begs the question: is there something ELSE that is limiting the upload_max_filesize and post_max_size??

On my previous (shared) hosting provider, I solved this with entries in root-level PHP.ini, but now on this dedicated server, these entries have no effect.

any advice appreciated!

MP

[Infopro]

You did restart Apache, correct?

[m.petersen68]

yes indeed.

as an aside (i've been searching this all morning), I have just read somewhere that in latter versions of PHP (I'm on 5.2.9) these values CANNOT be edited globally.

http://forum.siteground.com/showthread.php?t=6993

There are a couple of suggestions on how to change them on a site-per-site basis, including editing the HTACCESS file. when I added the recommended entries in my site .htaccess :

php_value post_max_size 100M
php_value upload_max_filesize 100M

I simply get a server error 500.

I am flumoxed!!! Ideas people???

MP

[Infopro]

What rules are you using? I don't need the actual file names but where you got them at. I'm just curious about this.

(I'm on 5.2.9)

Any specific reason you're on this older version?
What version of cPanel are you using?

[m.petersen68]

I really only have a set of popular rules from gotroot, plus the various rules that come as "standard" on c-panel/WHM.

I wondered about the PHP version as I considered it was possible I was experiencing a small bug. So tonight I took it up to the latest version.... with unfortunate results!! My sites operated but were without their content. So I wound it back to 5.2.9 and most is back to normal (though I think I separated from normal some days ago!!).

I'd be interested to hear your view on how an admin "knows" what versions of MySQL and PHP go with "what" version of WHM/C-Panel. I have all my automatic updates turned on so I assumed this would look after itself!

MP

[Infopro]

From an earlier post by you:

thanks for that tip, I installed that script successfully, but alas it looks like the ruleset that I'm using doesn't have unique ID's as nothing appears in the mod_security Rule ID list. The other functions are working though.

...

Do you mean in the CMC (configserver modsecurity control) page you see no IDs in that second area from the top, box? If yes, that's correct, you wont. Not until you add one there. If you add an ID here, it is bypassed globally for the entire server. Just below that area, is the area I mentioned previously that you could add an ID for one user account, instead of using the global bypass.

I really only have a set of popular rules from gotroot, plus the various rules that come as "standard" on c-panel/WHM.

All of gotroots rulesets have IDs, as do the default rules provided by cPanel.

I wondered about the PHP version as I considered it was possible I was experiencing a small bug. So tonight I took it up to the latest version.... with unfortunate results!! My sites operated but were without their content. So I wound it back to 5.2.9 and most is back to normal (though I think I separated from normal some days ago!!).

I'd be interested to hear your view on how an admin "knows" what versions of MySQL and PHP go with "what" version of WHM/C-Panel. I have all my automatic updates turned on so I assumed this would look after itself!

MP

cPanel does not auto update Apache nor PHP. This is done by the Server Administrator. Neither are really dependent on the cPanel version.

I follow the cPanel - The Leading Control Panel - Change Log as I would think most do for updates to cPanel, Easy Apache. When I see a post like this (from the changelog, sorted by Easy Apache from top drop menu)

Easyapache 5156
2010-07-23 16:01:50 Add PHP 5.2.14, remove PHP 5.2.13

I can assume it's time to update and I do. cPanel's QA team makes sure the version bundled with EA is good to go before it makes it to this list.

In your WHM top right corner you'll see the cPanel version listed. What does it tell you there? CURRENT, STABLE, or RELEASE?

Personally, I"m running CURRENT and EDGE on my servers, but most I think will stick with the most STABLE version to leave the problems that may be present in these to others to deal with.

I'm not sure why your update didn't go so well, but you could put in a ticket if you think something has gone wrong and you're unsure of the reason for it.

cPanel's tech support team are great at what they do and can help you sort things out if needed. You can get to the ticket system from within your WHM or, click the support link, top of any page on these forums.

[m.petersen68]

I did indeed lodge a ticket with c-Panel and the technician not only explained my issue very clearly to me, but also traced the root cause very quickly, and it was something that I would NEVER have found unassisted.

Basically, after accidentally editing PHP.ini in WordPad, the file had some bad CR's in it which was causing parsing errors. Despite the valued being correctly read by WHM's configurator, the actual values were not in force.

He also took the time to explain the very important difference as to how PHP.ini is treated, depending on whether you're running PHP in CGI or DSO mode.

anyway, "SOLVED", thanks to c-panel support...

MP

[Infopro]

Great news then. cPanel support are the best.