bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Estrela <p.estr...@campus.fct.unl.pt>
Subject Re: Bloodhond Instalation and Configuration CentOS 6.4
Date Mon, 29 Jul 2013 10:37:34 GMT
Good morning Gary,

I followed your instrutions but, when add the WSGIPythonHome to my
VirtualHost configurations i get this error:

"WSGIPythonHome cannot occur within <VirtualHost> section"

then when i change to Directory or LocationMatch sections i get this one:

"WSGIPythonHome not allowed here"




2013/7/25 Pedro Estrela <p.estrela@campus.fct.unl.pt>

> Thanks for your help Gary!
>
> I can'l on this until Monday. But i will folow your advices.
> Once again thank you!
>
> Pedro
>
>
> 2013/7/25 Gary Martin <gary.martin@wandisco.com>
>
>> 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<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