bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Bloodhond Instalation and Configuration CentOS 6.4
Date Thu, 25 Jul 2013 19:02:37 GMT
On 25/07/13 17:58, Gary Martin wrote:
> I prefer to recommend installation as a user without admin privileges 
> which is partly the reason for using virtualenv - that and it means 
> that you can have python programs with conflicting package 
> requirements by doing this. Any accidental installation outside of an 
> activated virtualenv - and particularly as root or similar - will 
> install to the system instead.
>
> So, your choices here would be one of:
>
> 1. install all the packages as admin
> 2. use pip to uninstall the system packages that were introduced
> 3. don't worry too much about the system packages that were
>    accidentally installed but still try to make sure that the
>    virtualenv packages are used in preference to system packages
>
> Actually it is possible to combine options 2 and 3 - it would make 
> things a bit more robust against other accidental installation events.
>
> If you want to go down this route you will still need to work out 
> whether you have the right python-path. It seems likely that it would 
> be correct but you should confirm to yourself that 
> /var/www/bloodhound/installer/bloodhound/lib/python2.6/site-packages 
> does actually exist and it may be worth checking all the other paths 
> to various files are correct.
>
> Something else that springs to mind here is that the VirtualHost setup 
> that we suggest also sets user=bloodhound for the WSGIDaemonProcess. I 
> believe this user (or whatever user you have replaced it with) needs 
> to have appropriate access to the installed files. There are notes to 
> this effect in 
> https://issues.apache.org/bloodhound/wiki/BloodhoundInstall#WebServer
>
> I'll try to get some notes together unless someone beats me to it!
>
> Cheers,
>     Gary

OK, looks like I have worked out what the wsgi documentation is talking 
about, though I am actually struggling to replicate an aspect of the 
problem on my ubuntu server at the moment to see if it is doing what I 
expect. Perhaps someone else can verify this..

So, *IF* you believe that there are no other programs served through 
your webserver that this will mess up (that is any other mod_wsgi 
applications that are running correctly at the moment) then you can do 
something like the following:

    sudo mkdir -p /opt/local/apachepythonenv
    cd /opt/local/apachepythonenv
    sudo virtualenv --no-site-packages BASELINE

    sudo vi /etc/apache2/httpd.conf

and add the following to that file:

    WSGIPythonHome /opt/local/apachepythonenv/BASELINE

and restart apache with something like

    sudo apachectl graceful

Doing this should ensure that all wsgi applications will be using a 
clean python environment without any system installed files at the base 
so that all those system files that were installed should be completely 
ignored unless in turn you specify a python-path to the 
WSGIDaemonProcess option of your VirtualHost that happens to have 
included the system site packages (which of itself is not a problem if 
that happens to be what you need).

So, now if the VirtualHost definition is otherwise correct, everything 
should work (I say with my fingers crossed). The question at this point 
is whether the missing sqlparse error will reappear. If it does, at the 
moment I would still be suspecting a problem with the VirtualHost 
configuration.

As I say, my failure to replicate the issue does not fill me with 
confidence with this but I have seen similarly odd behaviour due to 
accidental sudo pip installs.

Cheers,
     Gary

Mime
View raw message