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 11:58:01 GMT
I already solve this problem, it was a miss configuration on httpd.conf.

The problem now is that i have:

"Internal Server Error"   :(


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

> 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