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 Wed, 18 Sep 2013 04:48:52 GMT
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 <ryan.ollos@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.
>

Mime
View raw message