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 <ryan.ol...@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. >
