On 8/28/06, up@xxxx <up@xxxx> wrote:
Hi:
After running Apache 1.3.x with SuExec for many years, I just upgraded to
2.2.3. I installed it from FreeBSD ports with SuExec enabled, but without
specifying much else, figuring I could change that runtime.
After making the neccessary changes in my virtual host users' conf file
(changing User and Group to SuExecUserGroup), I am getting a:
cannot get docroot information (/usr/local/www/data)
Error. Well that isn't the server's doc root, so I tried a simlink to it
from the real one (default FreeBSD ports selected), then the error changed
to this:
command not in docroot (/home/servers/vhost.com/cgi-bin/someform.cgi)
I checked the Apache docs on SuExec and found this:
"--with-suexec-docroot=DIR
Define as the DocumentRoot set for Apache. This will be the only
hierarchy (aside from UserDirs) that can be used for suEXEC behavior. The
default directory is the --datadir value with the suffix "/htdocs", e.g.
if you configure with "--datadir=/home/apache" the directory
"/home/apache/htdocs" is used as document root for the suEXEC wrapper."
I'm not sure I understand this. This is intended for the user of virtual
hosting customers, and their websites are under:
/home/servers/somecustomer.com/pages (their doc root)
/home/servers/somecustomer.com/cgi-bin (their cgi-bin)
If I understand the instructions correctly, Apache is going to append
"htdocs" onto whatever I use?
No. The docs are not all that clear here. The suexec docroot is distinct from the apache httpd DocumentRoot. It simply specifies a parent directory under which ALL the script that suexec exectures (with the expection of those mapped through mod_userdir) must live. So in your case, if all your sites are under /home/servers/... you should set the suexec docroot to /home/servers/. Joshua. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|