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?