04-26-2003, 11:46 PM #1New Member
- Join Date
- Mar 2003
- Helena, MT
Cpanel (and others?) 511 error, shared secure certificate, etc. I have a solution.
The ability to specify http://ip-address/~username/ to allow a new customer to access thier account before the dns propagates is an essential part of our business. Also many of us offer shared secure certificates via something like https://secure.domain.com/~username/.
Unfortunately, having the ability to do this leaves you open to http://www.customer-domain.com/~othe...omer-username. This allows the OTHER customer to leech the bandwidth of another customer. This is obviously unacceptable.
There is the bwprotect module for apache that prevents /~user to a user through a domain that isn't owned by that user. I am not sure if this is tied to cpanel or looks at permissions, either way its moot.
The option to disable the ability to /~user is not acceptable to us, yet with bwprotect we cannot offer services we wish to offer.
I have developed a solution to both problems, but it requires direct editing of your httpd.conf (For now until cpanel and others pick up on this.)
** end background**
**the follow I initially posted in the cpanel support forum.**
I've developed a work around for the now infamous "511 access not allowed from this domain" error. This isnít going to leave you open for leeching, or deny you the ability to do a shared secure certificate or provide access before propagation occurs.
As we know, the culprit for this problem is the bwprotect module. So letís get rid of that.
Find these two lines in your httpd.conf (most likely found in /etc/httpd/conf)
LoadModule bwprotect_module libexec/mod_bwprotect.so
Comment them out by placing a # in front of them. (I know, itís rudimentary.)
Okay now that we have bwprotect turned off, we have a problem, people can leech bandwidth again from other accounts.
So now we need to turn off the ability to /~user completely.
Find the following section in the server config part of httpd.conf:
and change it to
Oh dear. Now we are back where we have always been, and now /~user doesnít work at all. No more shared secure certificate, no more access before propagation. What are we to do?
Read the apache documentation, notice that the UserDir directive can fit within the scope of a VirtualHost!
So lets find a suitable virtualhost section, say the one you use for your shared certificate.
Add the following:
Well that solves the problem, now shared certificates work, and Iím sure you can figure out how to apply this to an IP based VirtualHost (or any VirtualHost for that matter!) to allow users access before propagation, or for a customer to leech between his own accounts.
But I have ANOTHER treat for you all! We can control what usernames are allowed to be accessed!
Instead of the above in a VirtualHost section do the following:
UserDir enabled username1 username2 username3Ö
This expressly allows only certain users. Optionally:
UserDir disabled username1 username2 username3Ö
And this would expressly deny certain users to be accessed.
Obviously restart apache for the changes to take effect!
With all of the above everybody ought to be able to protect their users bandwidth, while maintaining the ability to have a shared certificate or provide access prior to propagation.
Additionally, you now have control over specifically WHICH users may be accessed this way! This means you can prevent that 5GB a day site from leeching bandwidth through the shared secure certificate (and increasing CPU load because of encryption), or prevent people from abusing the courtesy of providing access before propagation.
I hope everybody has found this fun and informative, as well as very useful. I would like to point out I have already submitted a feature request built around this system. I am sure that we will see a nice way of doing this through WHM in the future as this is obviously a cure for something that has caused a lot of headaches for people.
http://httpd.apache.org/docs/mod/mod_userdir.html is the official documentation for apache that covers this specific topic. Iím quite surprised I was unable to find this same solution posted already.
Cody Frisch, InterSurge LLC.