Suricata

This really seems to be a packaging issue. I've just done an uninstall, manual cleaning, install and the python module as well as the script are correctly installed.

Peter: Can you provide me the debian directory used to build the package ?

I was not using a package.

Clean VM machine ->

wget http://www.openinfosecfoundation.org/download/suricata-1.4.3.tar.gz
tar -zxf suricata-1.4.3.tar.gz 
cd suricata-1.4.3/
./configure  --enable-unix-socket --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/ --enable-non-bundled-htp  --enable-geoip --with-libnss-libraries=/usr/lib --with-libnss-includes=/usr/include/nss/ --with-libnspr-libraries=/usr/lib --with-libnspr-includes=/usr/include/nspr

Then when I tried to start it I got the issue.

Eric Leblond wrote:

Furthermore, if we don't use the --prefix=/usr flag in configure, suricatasc is working fine. As prefixing to /usr is not the way to do a compilation, I stay on my position and the one that need to be fixed is python setup.

Whats wrong with passing --prefix=/usr? I use it all the time. Also, we suggest it to the user at the end of configure:

"To install Suricata into /usr/bin/suricata, have the config /etc/suricata and use /var/log/suricata as log dir, use: ./configure --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/"

The point is that it can conflict with package. Manually compiled software should be installed under /usr/local.

Extract from Filesystem Hierarchy Standard (http://www.pathname.com/fhs/)

4.8.2. /usr/local : Local hierarchy
4.8.2.1. Purpose
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to
be safe from being overwritten when the system software is updated. It may be used for programs and data that
are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
replace or upgrade software in /usr.

...rather than /usr unless it is being installed to
replace or upgrade software in /usr.

Which is exactly the case with Ubuntu PPA.

....It needs to
be safe from being overwritten when the system software is updated.

Which again is exactly the case with our Ubuntu PPA - where we need to specify /usr prefix, where the users would be able to just do

apt-get update && apt-get upgrade

to easily upgrade to another version of Suricata.

Then

...Furthermore, if we don't use the --prefix=/usr flag in configure, suricatasc is working fine.

It does not seem correct to me, to tell a user - don't use --prefix=/usr flag in order to use unix-socket, otherwise it won't work.

I don't entirely agree with your position Eric.

Plus if this is the case I think (Python path update) - it should be included in the wiki.

What do you want me to do there ? I'm ok this is an issue if the use has to set PYTHONPATH and it should at least be included in the wiki. But it is not to us to fix this in the code. I'm using standard python-distutils to install the module. And if it don't work then it is not my fault.

For ubuntu PPA, you need to look at how project that are using a embedded python module are doing to have it inside their package. I know NuFW has the same thing inside so you could have a look at how they (read pollux) have fixed this.

PYTHONPATH=/usr/lib/python3.7/site-packages suricatasc

So is it safe to use Python 2.7 as well or only Python 3.x should be used ?

When you run the PYTHONPATH command , does unix-socket still work with prefix=/usr/ or one should just avoid using prefix=/usr/ in order to use unix-socket functionality?