bloodhound-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Bloodhond Instalation and Configuration CentOS 6.4
Date Mon, 29 Jul 2013 16:33:47 GMT
All things being equal - that running through tracd, it should only be a 
problem with the system installed packages at this point.

I've not managed to get a working CentOS 6.4 to try to replicate yet. If 
problems continue then this may be quite difficult to sort it out 
without more information. Is this an error that you are not getting when 
you are running without the webserver?

If so, can you turn on logging by going to the admin interface and click 
"Logging" on the left-hand menu. On the assumption that Type is set to 
None, change it to "File" and apply the changes.

That page should also show the path to the log file so you can correct 
the next commands..

Now you can either

    tail -f

or just examine the file after you replicate the error.


On 29/07/13 12:58, Pedro Estrela wrote:
> 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 < 
> <>>
>     Good morning Gary,
>     I followed your instrutions but, when add the WSGIPythonHometo 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 <
>     <>>
>         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 <
>         <>>
>             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
>                 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

View raw message