You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bloodhound.apache.org by Jared Duncan <j...@jdunk.com> on 2013/09/17 10:25:41 UTC
Running Bloodhound via apache: 404
Hi list. I was successfully able to install and run bloodhound via tracd
just fine, but I'm getting a strange 404 situation when I try to access it
via apache instead.
I'm using the same VirtualHost block that was suggested by the installation
doc only with added directives for logging, and a ServerName and port 80
instead of 8000.
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer
My VirtualHost:
<VirtualHost *:80>
ServerName bh.mydomain.com
LogLevel warn
ErrorLog /var/log/apache2/bh.mydomain.com-error.log
CustomLog /var/log/apache2/bh.mydomain.com-access.log combined
WSGIDaemonProcess bh_tracker user=bloodhound
python-path=/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages
WSGIScriptAlias /bloodhound
/usr/local/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
<Directory /usr/local/bloodhound/installer/bloodhound/site/cgi-bin>
WSGIProcessGroup bh_tracker
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
<LocationMatch "/bloodhound/[^/]+/login">
AuthType Digest
AuthName "Bloodhound"
AuthDigestDomain /bloodhound
AuthUserFile
/usr/local/bloodhound/installer/bloodhound/environments/main/bloodhound.htdigest
Require valid-user
</LocationMatch>
</VirtualHost>
===
I ran trac-admin deploy and restarted apache of course. What happens,
though, is any attempt to access that VirtualHost at any URI for that
subdomain it's configured for yields a 404, and the error log says this:
File does not exist: /etc/apache2/htdocs
I know that it's matching the VirtualHost block because the above error
gets written to the very file I uniquely specified in the ErrorLog
directive within that block. (The unique access log gets hit also.)
So... anyone have an idea why it would be looking for an "htdocs" directory
within /etc/apache2/ instead of
/usr/local/bloodhound/installer/bloodhound/site/ ?
In case it's of any help, mod_wsgi emits the following "info" messages when
apache is started:
[info] mod_wsgi (pid=15156): Attach interpreter ''.
[info] mod_wsgi (pid=15156): Adding
'/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages' to
path.
===
Another thing: the Bloodhound installation doc says:
The user referred to in the WSGIDaemonProcess should be the user that you
> wish bloodhound to be run as and so that user must have the appropriate set
> of permissions to access the Bloodhound installation. Running with any
> special system level privileges should not be required and is not
> recommended.
>
...but it says nothing whatsoever about which permissions are needed on
which files/directories, so we are left to completely guess, and doing
something like
sudo chown -R bloodhound.www-data /usr/local/bloodhound; sudo chmod -R
ug+rwx /usr/local/bloodhound
...is ugly, inconvenient, and overly-permissive at best, and breaks things
at worst. Is there a better way?
Re: Running Bloodhound via apache: 404
Posted by Jared Duncan <j...@jdunk.com>.
Update: I *was* able to access the UI via apache once I tried the URL:
http://bh.mydomain.com/bloodhound
instead of just
http://bh.mydomain.com/
I was then able to get it to work with the latter URL by changing
"/bloodhound" to just "/" in the WSGIScriptAlias and AuthDigestDomain
directives,
and the LocationMatch block. I swear I did this earlier on a different
machine and it completely broke things (I saw a regular trac UI instead of
Bloodhound); sorry for any time wasted. If this list is googleable,
hopefully this will help someone in the future.
The question about the "bloodhound" user's permissions remains, however.
On Tue, Sep 17, 2013 at 1:25 AM, Jared Duncan <j...@jdunk.com> wrote:
> Hi list. I was successfully able to install and run bloodhound via tracd
> just fine, but I'm getting a strange 404 situation when I try to access it
> via apache instead.
>
> I'm using the same VirtualHost block that was suggested by the
> installation doc only with added directives for logging, and a ServerName
> and port 80 instead of 8000.
>
> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer
>
> My VirtualHost:
>
> <VirtualHost *:80>
> ServerName bh.mydomain.com
>
> LogLevel warn
> ErrorLog /var/log/apache2/bh.mydomain.com-error.log
> CustomLog /var/log/apache2/bh.mydomain.com-access.log combined
>
> WSGIDaemonProcess bh_tracker user=bloodhound
> python-path=/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages
> WSGIScriptAlias /bloodhound
> /usr/local/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
> <Directory /usr/local/bloodhound/installer/bloodhound/site/cgi-bin>
> WSGIProcessGroup bh_tracker
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
> </Directory>
> <LocationMatch "/bloodhound/[^/]+/login">
> AuthType Digest
> AuthName "Bloodhound"
> AuthDigestDomain /bloodhound
> AuthUserFile
> /usr/local/bloodhound/installer/bloodhound/environments/main/bloodhound.htdigest
> Require valid-user
> </LocationMatch>
> </VirtualHost>
>
> ===
>
> I ran trac-admin deploy and restarted apache of course. What happens,
> though, is any attempt to access that VirtualHost at any URI for that
> subdomain it's configured for yields a 404, and the error log says this:
>
> File does not exist: /etc/apache2/htdocs
>
> I know that it's matching the VirtualHost block because the above error
> gets written to the very file I uniquely specified in the ErrorLog
> directive within that block. (The unique access log gets hit also.)
>
> So... anyone have an idea why it would be looking for an "htdocs"
> directory within /etc/apache2/ instead of
> /usr/local/bloodhound/installer/bloodhound/site/ ?
>
> In case it's of any help, mod_wsgi emits the following "info" messages
> when apache is started:
>
> [info] mod_wsgi (pid=15156): Attach interpreter ''.
> [info] mod_wsgi (pid=15156): Adding
> '/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages' to
> path.
>
> ===
>
> Another thing: the Bloodhound installation doc says:
>
> The user referred to in the WSGIDaemonProcess should be the user that you
>> wish bloodhound to be run as and so that user must have the appropriate set
>> of permissions to access the Bloodhound installation. Running with any
>> special system level privileges should not be required and is not
>> recommended.
>>
>
> ...but it says nothing whatsoever about which permissions are needed on
> which files/directories, so we are left to completely guess, and doing
> something like
>
> sudo chown -R bloodhound.www-data /usr/local/bloodhound; sudo chmod -R
> ug+rwx /usr/local/bloodhound
>
> ...is ugly, inconvenient, and overly-permissive at best, and breaks things
> at worst. Is there a better way?
>
Re: Running Bloodhound via apache: 404
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Sep 17, 2013 at 9:48 PM, Jared Duncan <j...@jdunk.com> wrote:
> Allright, I was able to do it just as you described and everything seems
> to be working perfectly. It ran fine via tracd and apache, and in both
> modes I tested modifying a wiki article and ticket. While running via
> apache, I was able to upload a file attachment to a ticket, view it, and
> delete it. Zero problems. :)
>
> Here is the list of commands I used, which might be helpful in updating
> the docs:
>
> ===
>
> mkdir /var/www/bh.mysite.com/
> cd !$
> tar zxvf /usr/local/src/apache-bloodhound-0.7.tar.gz
> mv apache-bloodhound-0.7/ src
> cd src/installer/
> virtualenv --system-site-packages ../../python-virtualenv
> . !$/bin/activate
> pip install -r requirements.txt
> python bloodhound_setup.py --environments_directory=../../env -d sqlite
> --project=<env name> --default-product-prefix=<prefix> --admin-user=<admin
> username>
> tracd --port=8000 /var/www/bh.mysite.com/env/<env name>
> ^C
> trac-admin ../../env/<env name>/ # modify components, versions, milestones
> ^D
> trac-admin /var/www/bh.mysite.com/env/<env name>/ deploy /var/www/
> bh.mysite.com/www
> # and now, to run via apache...
> sudo useradd bloodhound
> cd /var/www/bh.mysite.com/
> sudo chown -R bloodhound.www-data env www python-virtualenv
> sudo chmod -R ug+r env www python-virtualenv
> sudo chmod -R ug+w env
> vi /etc/apache2/sites-available/bh.mysite.com
> sudo a2ensite bh.mysite.com
> sudo apache2ctl graceful
>
> ===
>
> ...and the contents of my /etc/apache2/sites-available/bh.mysite.com file:
>
> ===
>
> <VirtualHost *:80>
> ServerName bh.mysite.com
>
> LogLevel warn
> ErrorLog /var/log/apache2/bh.mysite.com-error.log
> CustomLog /var/log/apache2/bh.mysite.com-access.log combined
>
> WSGIDaemonProcess bh_tracker user=bloodhound python-path=/var/www/
> bh.mysite.com/python-virtualenv/lib/python2.7/site-packages
> WSGIScriptAlias / /var/www/bh.mysite.com/www/cgi-bin/trac.wsgi
> <Directory /var/www/bh.mysite.com/www/cgi-bin>
> WSGIProcessGroup bh_tracker
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
> </Directory>
> <LocationMatch "/[^/]+/login">
> AuthType Digest
> AuthName "Bloodhound"
> AuthDigestDomain /
> AuthUserFile /var/www/bh.mysite.com/env/<env
> name>/bloodhound.htdigest
> Require valid-user
> </LocationMatch>
> </VirtualHost>
>
> ===
>
> Cheers!
> Jared
>
Thanks Jared, your feedback is very helpful. I'll run through it and draft
an update to the wiki within the next few days.
Re: Running Bloodhound via apache: 404
Posted by Jared Duncan <j...@jdunk.com>.
Allright, I was able to do it just as you described and everything seems to
be working perfectly. It ran fine via tracd and apache, and in both modes
I tested modifying a wiki article and ticket. While running via apache, I
was able to upload a file attachment to a ticket, view it, and delete it.
Zero problems. :)
Here is the list of commands I used, which might be helpful in updating the
docs:
===
mkdir /var/www/bh.mysite.com/
cd !$
tar zxvf /usr/local/src/apache-bloodhound-0.7.tar.gz
mv apache-bloodhound-0.7/ src
cd src/installer/
virtualenv --system-site-packages ../../python-virtualenv
. !$/bin/activate
pip install -r requirements.txt
python bloodhound_setup.py --environments_directory=../../env -d sqlite
--project=<env name> --default-product-prefix=<prefix> --admin-user=<admin
username>
tracd --port=8000 /var/www/bh.mysite.com/env/<env name>
^C
trac-admin ../../env/<env name>/ # modify components, versions, milestones
^D
trac-admin /var/www/bh.mysite.com/env/<env name>/ deploy /var/www/
bh.mysite.com/www
# and now, to run via apache...
sudo useradd bloodhound
cd /var/www/bh.mysite.com/
sudo chown -R bloodhound.www-data env www python-virtualenv
sudo chmod -R ug+r env www python-virtualenv
sudo chmod -R ug+w env
vi /etc/apache2/sites-available/bh.mysite.com
sudo a2ensite bh.mysite.com
sudo apache2ctl graceful
===
...and the contents of my /etc/apache2/sites-available/bh.mysite.com file:
===
<VirtualHost *:80>
ServerName bh.mysite.com
LogLevel warn
ErrorLog /var/log/apache2/bh.mysite.com-error.log
CustomLog /var/log/apache2/bh.mysite.com-access.log combined
WSGIDaemonProcess bh_tracker user=bloodhound python-path=/var/www/
bh.mysite.com/python-virtualenv/lib/python2.7/site-packages
WSGIScriptAlias / /var/www/bh.mysite.com/www/cgi-bin/trac.wsgi
<Directory /var/www/bh.mysite.com/www/cgi-bin>
WSGIProcessGroup bh_tracker
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
<LocationMatch "/[^/]+/login">
AuthType Digest
AuthName "Bloodhound"
AuthDigestDomain /
AuthUserFile /var/www/bh.mysite.com/env/<env
name>/bloodhound.htdigest
Require valid-user
</LocationMatch>
</VirtualHost>
===
Cheers!
Jared
On Tue, Sep 17, 2013 at 2:36 PM, Ryan Ollos <ry...@wandisco.com> wrote:
> On Tue, Sep 17, 2013 at 2:31 PM, Jared Duncan <j...@jdunk.com> wrote:
>
>> Thanks so much for that Ryan; very elucidating.
>>
>> Yeah, I wasn't sure where that line was exactly between the source/setup
>> files and the files needed in the end once installation is complete, let
>> alone that there are actually a good 4 separable components here as you've
>> pointed out. I did at first try moving the
>> bloodhound/installer/bloodhound/ and/or
>> bloodhound/installer/bloodhound/site/ dirs to a higher level elsewhere
>> and that resulted in something very much broken. I probably needed to pass
>> the dir path as an argument to one of the install steps instead of moving
>> it after the fact. It's unclear in the installation steps that in a few
>> cases, "bloodhound" refers to an actual directory name/path that is then
>> created, and not an argument/flag to differentiate it from vanilla trac,
>> for example.
>>
>> Then, bloodhound-src can be deleted after install, and a newer version
>>> can be extracted to that location when upgrading. Static resources are
>>> deployed to www, and we can document the necessary permissions for each of
>>> these directories in a simple way. I'll have to try it out to be sure, but
>>> I think the webserver user will only need r-access to python-virtualenv and
>>> www, and will need w-access to bloodhound-env.
>>>
>>
>> This! That would be so much clearer and, imo, would be a better way to
>> instruct installation not only because of the permission and updateabilty
>> reasons you mentioned but also to significantly reduce the learning curve
>> and confusion for new users / improve adoption. Although I'm not yet
>> familiar with what params to which commands drive to output to one
>> directory or another, I'm going to go ahead and try to arrive at exactly
>> this setup right now and I'll test it out and let you know. :)
>>
>> To be clear, the /srv/site-name/www directory would be the one created by
>> "trac-admin deploy", i.e. the command would then be:
>>
>> trac-admin /srv/site-name/bloodhound-env/main/ deploy /srv/site-name/www
>>
>> , correct?
>>
>
> Yeah, that is correct. Thanks for experimenting and reporting your
> feedback. I'll do some experimenting in parallel and it would be great if
> we can improve the docs as a result over the next few days.
>
Re: Running Bloodhound via apache: 404
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Sep 17, 2013 at 2:31 PM, Jared Duncan <j...@jdunk.com> wrote:
> Thanks so much for that Ryan; very elucidating.
>
> Yeah, I wasn't sure where that line was exactly between the source/setup
> files and the files needed in the end once installation is complete, let
> alone that there are actually a good 4 separable components here as you've
> pointed out. I did at first try moving the
> bloodhound/installer/bloodhound/ and/or
> bloodhound/installer/bloodhound/site/ dirs to a higher level elsewhere
> and that resulted in something very much broken. I probably needed to pass
> the dir path as an argument to one of the install steps instead of moving
> it after the fact. It's unclear in the installation steps that in a few
> cases, "bloodhound" refers to an actual directory name/path that is then
> created, and not an argument/flag to differentiate it from vanilla trac,
> for example.
>
> Then, bloodhound-src can be deleted after install, and a newer version can
>> be extracted to that location when upgrading. Static resources are deployed
>> to www, and we can document the necessary permissions for each of these
>> directories in a simple way. I'll have to try it out to be sure, but I
>> think the webserver user will only need r-access to python-virtualenv and
>> www, and will need w-access to bloodhound-env.
>>
>
> This! That would be so much clearer and, imo, would be a better way to
> instruct installation not only because of the permission and updateabilty
> reasons you mentioned but also to significantly reduce the learning curve
> and confusion for new users / improve adoption. Although I'm not yet
> familiar with what params to which commands drive to output to one
> directory or another, I'm going to go ahead and try to arrive at exactly
> this setup right now and I'll test it out and let you know. :)
>
> To be clear, the /srv/site-name/www directory would be the one created by
> "trac-admin deploy", i.e. the command would then be:
>
> trac-admin /srv/site-name/bloodhound-env/main/ deploy /srv/site-name/www
>
> , correct?
>
Yeah, that is correct. Thanks for experimenting and reporting your
feedback. I'll do some experimenting in parallel and it would be great if
we can improve the docs as a result over the next few days.
Re: Running Bloodhound via apache: 404
Posted by Jared Duncan <j...@jdunk.com>.
Thanks so much for that Ryan; very elucidating.
Yeah, I wasn't sure where that line was exactly between the source/setup
files and the files needed in the end once installation is complete, let
alone that there are actually a good 4 separable components here as you've
pointed out. I did at first try moving the
bloodhound/installer/bloodhound/and/or
bloodhound/installer/bloodhound/site/ dirs to a higher level elsewhere and
that resulted in something very much broken. I probably needed to pass the
dir path as an argument to one of the install steps instead of moving it
after the fact. It's unclear in the installation steps that in a few
cases, "bloodhound" refers to an actual directory name/path that is then
created, and not an argument/flag to differentiate it from vanilla trac,
for example.
Then, bloodhound-src can be deleted after install, and a newer version can
> be extracted to that location when upgrading. Static resources are deployed
> to www, and we can document the necessary permissions for each of these
> directories in a simple way. I'll have to try it out to be sure, but I
> think the webserver user will only need r-access to python-virtualenv and
> www, and will need w-access to bloodhound-env.
>
This! That would be so much clearer and, imo, would be a better way to
instruct installation not only because of the permission and updateabilty
reasons you mentioned but also to significantly reduce the learning curve
and confusion for new users / improve adoption. Although I'm not yet
familiar with what params to which commands drive to output to one
directory or another, I'm going to go ahead and try to arrive at exactly
this setup right now and I'll test it out and let you know. :)
To be clear, the /srv/site-name/www directory would be the one created by
"trac-admin deploy", i.e. the command would then be:
trac-admin /srv/site-name/bloodhound-env/main/ deploy /srv/site-name/www
, correct?
On Tue, Sep 17, 2013 at 1:08 PM, Ryan Ollos <ry...@wandisco.com> wrote:
>
>
>
> On Tue, Sep 17, 2013 at 12:24 PM, Jared Duncan <j...@jdunk.com> wrote:
>
>> Thanks Ryan, that input is helpful. I'd be pretty shocked if it actually
>> needed write permission in particular to most files/dirs (many of them libs
>> and docs) from the highest root "bloodhound" level (parent of "installer")
>> and down, though, so wondering if perhaps someone who has worked on the
>> daemon might know.
>>
>
> At least for the environment directory, the user that the webserver runs
> under must have write permission. See:
>
> https://issues.apache.org/bloodhound/wiki/TracInstall#CreatingaProjectEnvironment
>
> This make sense for `conf` because Trac/BH needs to write to `conf/trac.in`,
> for `db` because Trac/BH needs to write to `db/bloodhound.db`, for `log`
> ....
>
> You might be able to have `templates` and `htdocs` as read-only by the
> webserver, and same for `plugins` provided that you won't be uploading eggs
> through the Plugins Admin panel.
>
> You are probably right that Trac/Bloodhound doesn't need write permission
> to the python environment directories. On my Linux distro, if you were
> running with the Python interpreter installed in /usr/local, the webserver
> would only have read access to those files.
>
> Someone what related, it was raised by at least one user on IRC some
> months back that the Python virtual environment and Trac/Bloodhound
> environment should probably not be installed inside of the source tree, and
> the steps we have documented tell the user to put the environments inside
> of the extracted source directory:
> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#Installation
>
> Alternatively, a structure that seems to be fairly common is:
>
> /srv/site-name/python-virtualenv
> /srv/site-name/bloodhound-env
> /srv/site-name/bloodhound-src
> /srv/site-name/www
>
> Then, bloodhound-src can be deleted after install, and a newer version can
> be extracted to that location when upgrading. Static resources are deployed
> to www, and we can document the necessary permissions for each of these
> directories in a simple way. I'll have to try it out to be sure, but I
> think the webserver user will only need r-access to python-virtualenv and
> www, and will need w-access to bloodhound-env.
>
>
Re: Running Bloodhound via apache: 404
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Sep 17, 2013 at 12:24 PM, Jared Duncan <j...@jdunk.com> wrote:
> Thanks Ryan, that input is helpful. I'd be pretty shocked if it actually
> needed write permission in particular to most files/dirs (many of them libs
> and docs) from the highest root "bloodhound" level (parent of "installer")
> and down, though, so wondering if perhaps someone who has worked on the
> daemon might know.
>
At least for the environment directory, the user that the webserver runs
under must have write permission. See:
https://issues.apache.org/bloodhound/wiki/TracInstall#CreatingaProjectEnvironment
This make sense for `conf` because Trac/BH needs to write to `conf/trac.in`,
for `db` because Trac/BH needs to write to `db/bloodhound.db`, for `log`
....
You might be able to have `templates` and `htdocs` as read-only by the
webserver, and same for `plugins` provided that you won't be uploading eggs
through the Plugins Admin panel.
You are probably right that Trac/Bloodhound doesn't need write permission
to the python environment directories. On my Linux distro, if you were
running with the Python interpreter installed in /usr/local, the webserver
would only have read access to those files.
Someone what related, it was raised by at least one user on IRC some months
back that the Python virtual environment and Trac/Bloodhound environment
should probably not be installed inside of the source tree, and the steps
we have documented tell the user to put the environments inside of the
extracted source directory:
https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#Installation
Alternatively, a structure that seems to be fairly common is:
/srv/site-name/python-virtualenv
/srv/site-name/bloodhound-env
/srv/site-name/bloodhound-src
/srv/site-name/www
Then, bloodhound-src can be deleted after install, and a newer version can
be extracted to that location when upgrading. Static resources are deployed
to www, and we can document the necessary permissions for each of these
directories in a simple way. I'll have to try it out to be sure, but I
think the webserver user will only need r-access to python-virtualenv and
www, and will need w-access to bloodhound-env.
Re: Running Bloodhound via apache: 404
Posted by Jared Duncan <j...@jdunk.com>.
Thanks Ryan, that input is helpful. I'd be pretty shocked if it actually
needed write permission in particular to most files/dirs (many of them libs
and docs) from the highest root "bloodhound" level (parent of "installer")
and down, though, so wondering if perhaps someone who has worked on the
daemon might know.
On Tue, Sep 17, 2013 at 11:04 AM, Ryan Ollos <ry...@wandisco.com>wrote:
> On Tue, Sep 17, 2013 at 1:25 AM, Jared Duncan <j...@jdunk.com> wrote:
>
>> Hi list. I was successfully able to install and run bloodhound via tracd
>> just fine, but I'm getting a strange 404 situation when I try to access it
>> via apache instead.
>>
>> I'm using the same VirtualHost block that was suggested by the
>> installation doc only with added directives for logging, and a ServerName
>> and port 80 instead of 8000.
>>
>> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer
>>
>> My VirtualHost:
>>
>> <VirtualHost *:80>
>> ServerName bh.mydomain.com
>>
>> LogLevel warn
>> ErrorLog /var/log/apache2/bh.mydomain.com-error.log
>> CustomLog /var/log/apache2/bh.mydomain.com-access.log combined
>>
>> WSGIDaemonProcess bh_tracker user=bloodhound
>> python-path=/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages
>> WSGIScriptAlias /bloodhound
>> /usr/local/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
>> <Directory /usr/local/bloodhound/installer/bloodhound/site/cgi-bin>
>> WSGIProcessGroup bh_tracker
>> WSGIApplicationGroup %{GLOBAL}
>> Order deny,allow
>> Allow from all
>> </Directory>
>> <LocationMatch "/bloodhound/[^/]+/login">
>> AuthType Digest
>> AuthName "Bloodhound"
>> AuthDigestDomain /bloodhound
>> AuthUserFile
>> /usr/local/bloodhound/installer/bloodhound/environments/main/bloodhound.htdigest
>> Require valid-user
>> </LocationMatch>
>> </VirtualHost>
>>
>> ===
>>
>> I ran trac-admin deploy and restarted apache of course. What happens,
>> though, is any attempt to access that VirtualHost at any URI for that
>> subdomain it's configured for yields a 404, and the error log says this:
>>
>> File does not exist: /etc/apache2/htdocs
>>
>> I know that it's matching the VirtualHost block because the above error
>> gets written to the very file I uniquely specified in the ErrorLog
>> directive within that block. (The unique access log gets hit also.)
>>
>> So... anyone have an idea why it would be looking for an "htdocs"
>> directory within /etc/apache2/ instead of
>> /usr/local/bloodhound/installer/bloodhound/site/ ?
>>
>> In case it's of any help, mod_wsgi emits the following "info" messages
>> when apache is started:
>>
>> [info] mod_wsgi (pid=15156): Attach interpreter ''.
>> [info] mod_wsgi (pid=15156): Adding
>> '/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages' to
>> path.
>>
>> ===
>>
>> Another thing: the Bloodhound installation doc says:
>>
>> The user referred to in the WSGIDaemonProcess should be the user that you
>>> wish bloodhound to be run as and so that user must have the appropriate set
>>> of permissions to access the Bloodhound installation. Running with any
>>> special system level privileges should not be required and is not
>>> recommended.
>>>
>>
>> ...but it says nothing whatsoever about which permissions are needed on
>> which files/directories, so we are left to completely guess, and doing
>> something like
>>
>> sudo chown -R bloodhound.www-data /usr/local/bloodhound; sudo chmod -R
>> ug+rwx /usr/local/bloodhound
>>
>> ...is ugly, inconvenient, and overly-permissive at best, and breaks
>> things at worst. Is there a better way?
>>
>
>
> I've always changed the owner like you've done (setting the group as well)
> and just left the permissions at the defaults, 775 for directories and 664
> for files. However, I couldn't say whether a more restrictive set of
> permissions would be advisable.
>
Re: Running Bloodhound via apache: 404
Posted by Ryan Ollos <ry...@wandisco.com>.
On Tue, Sep 17, 2013 at 1:25 AM, Jared Duncan <j...@jdunk.com> wrote:
> Hi list. I was successfully able to install and run bloodhound via tracd
> just fine, but I'm getting a strange 404 situation when I try to access it
> via apache instead.
>
> I'm using the same VirtualHost block that was suggested by the
> installation doc only with added directives for logging, and a ServerName
> and port 80 instead of 8000.
>
> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer
>
> My VirtualHost:
>
> <VirtualHost *:80>
> ServerName bh.mydomain.com
>
> LogLevel warn
> ErrorLog /var/log/apache2/bh.mydomain.com-error.log
> CustomLog /var/log/apache2/bh.mydomain.com-access.log combined
>
> WSGIDaemonProcess bh_tracker user=bloodhound
> python-path=/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages
> WSGIScriptAlias /bloodhound
> /usr/local/bloodhound/installer/bloodhound/site/cgi-bin/trac.wsgi
> <Directory /usr/local/bloodhound/installer/bloodhound/site/cgi-bin>
> WSGIProcessGroup bh_tracker
> WSGIApplicationGroup %{GLOBAL}
> Order deny,allow
> Allow from all
> </Directory>
> <LocationMatch "/bloodhound/[^/]+/login">
> AuthType Digest
> AuthName "Bloodhound"
> AuthDigestDomain /bloodhound
> AuthUserFile
> /usr/local/bloodhound/installer/bloodhound/environments/main/bloodhound.htdigest
> Require valid-user
> </LocationMatch>
> </VirtualHost>
>
> ===
>
> I ran trac-admin deploy and restarted apache of course. What happens,
> though, is any attempt to access that VirtualHost at any URI for that
> subdomain it's configured for yields a 404, and the error log says this:
>
> File does not exist: /etc/apache2/htdocs
>
> I know that it's matching the VirtualHost block because the above error
> gets written to the very file I uniquely specified in the ErrorLog
> directive within that block. (The unique access log gets hit also.)
>
> So... anyone have an idea why it would be looking for an "htdocs"
> directory within /etc/apache2/ instead of
> /usr/local/bloodhound/installer/bloodhound/site/ ?
>
> In case it's of any help, mod_wsgi emits the following "info" messages
> when apache is started:
>
> [info] mod_wsgi (pid=15156): Attach interpreter ''.
> [info] mod_wsgi (pid=15156): Adding
> '/usr/local/bloodhound/installer/bloodhound/lib/python2.7/site-packages' to
> path.
>
> ===
>
> Another thing: the Bloodhound installation doc says:
>
> The user referred to in the WSGIDaemonProcess should be the user that you
>> wish bloodhound to be run as and so that user must have the appropriate set
>> of permissions to access the Bloodhound installation. Running with any
>> special system level privileges should not be required and is not
>> recommended.
>>
>
> ...but it says nothing whatsoever about which permissions are needed on
> which files/directories, so we are left to completely guess, and doing
> something like
>
> sudo chown -R bloodhound.www-data /usr/local/bloodhound; sudo chmod -R
> ug+rwx /usr/local/bloodhound
>
> ...is ugly, inconvenient, and overly-permissive at best, and breaks things
> at worst. Is there a better way?
>
I've always changed the owner like you've done (setting the group as well)
and just left the permissions at the defaults, 775 for directories and 664
for files. However, I couldn't say whether a more restrictive set of
permissions would be advisable.