bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Duncan...@jdunk.com>
Subject Re: Running Bloodhound via apache: 404
Date Tue, 17 Sep 2013 21:31:49 GMT
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 <ryan.ollos@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.
>
>

Mime
View raw message