mod_ruid2 - Still developing?
Hello,
I am running DSO with mod_ruid2 with great performance results.
I was wondering if development was still active on mod_ruid2?
Will there be solutions for incompatibilities with ModSecurity and UserDir?
Thanks much.
-
Hello :) Yes, there is still ongoing development to resolve known issues with Mod_Ruid2 and Mod_Security. There is a thread on this at: Mod Ruid2 + mod security conflicts on cPanel Thank you. 0 -
Hi Michael, That's great to hear. But it seems that EasyApache 3.24 won't be released for a year or more (guessing)? Why so long to get this conflict resolved? Any idea on whether the conflict with UserDir will be resolved? Thanks 0 -
The issue with modsec and ruid2 is quite complex, I'll just say that. It's definitely a lot of work. userdir (IMO) is obsolete and shouldn't be used. It violates PCI compliance (which you may not be worried about). Much better to test sites by modifying your local 'hosts' file to bypass DNS lookups. 0 -
[quote="quizknows, post: 1530621">The issue with modsec and ruid2 is quite complex, I'll just say that. It's definitely a lot of work. userdir (IMO) is obsolete and shouldn't be used. It violates PCI compliance (which you may not be worried about). Much better to test sites by modifying your local 'hosts' file to bypass DNS lookups.
Yes, I image modsec and ruid2 are complex. I't just good to know that ruid2 is moving forward with improvements, as it is awesome. + :) Yes, I agree, modifying local hosts file is the best route vs userdir. Thanks much for your reply, and I am setting my sites on EasyApache 3.24 :)0 -
We were on the brink of releasing 3.24, but found some last minute issues with respect to updating, particularly for users that expected Apache 1.3 and 2.0 to be there. Also, we've internally resolved the Mod Ruid2 and Mod Security incompatibility (Case 76493) for the 3.24 update. The fix you can look forward to involved a small code and configuration change. The core of the incompatibility between these two modules is that Mod Security, by default, uses a file-based lock. This lock is needed because the default behavior of Mod Security, is to write all events into a single log file; /usr/local/apache/logs/modsec_audit.log. Since Mod Ruid2 changes the process ownership, this naturally causes complications when two different users try to acquire a lock on the same file they don't own. 0
Please sign in to leave a comment.
Comments
5 comments