Project

General

Profile

Actions

Optimization #3337

open

Python is assumed to be installed in the same --prefix as suricata

Added by Shawn Michael almost 3 years ago. Updated almost 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

The installation assumes that the prefix where you are installing suricata is the same as the prefix for the python you are using. The attached patch changes the python installation from using it's use of --prefix to the use of --root which allows python to pick it's location on where to install the site-packages files.


Files

python-root.patch (1.94 KB) python-root.patch Don't require python and suricata to share a --prefix Shawn Michael, 11/15/2019 05:59 PM
Actions #1

Updated by Jason Ish almost 3 years ago

What problem does this patch solve?

Actions #2

Updated by Shawn Michael almost 3 years ago

The way setup.py --prefix is used it forces the site-packages directory to be installed in a location that is potentially different than where python's default site-packages directory is.

For instance if you compile suricata with --prefix of /opt/suricata then the site packages will be /opt/suricata/lib/python3.7/site-packages instead of the expected /usr/local/lib/python3.7/site-packages that python is expecting. Without the path you will need to do more work to set the python environment up in order to use suricata-update or any of the other python utilities.

My patch uses setup.py --root instead which will put the python libraries within the "correct" site-packages location while still allowing the executable scripts to be installed in the --prefix for suricata.

Actions #3

Updated by Jason Ish almost 3 years ago

The way we do it now is on purpose.

With this patch what happens if I install 4.1.5 with --prefix=/opt/suricata-4.1.5 and 5.0.0 with --prefix=/opt/suricata-5.0.0? Will one not overwrite the others Python support files?

Suricata-Update and the other python tools that ship with Suricata should handle this case just fine. If they don't, the specific tool should be fixed up to pickup its associated Python modules.

Actions #4

Updated by Shawn Michael almost 3 years ago

I should have probably prefaced this with the information that I am a package builder. In my situation there can only be one instance installed at a time. I acknowledge that my situation is directly at odds with hand builds that developers do.

Actions #5

Updated by Jason Ish almost 3 years ago

Shawn Michael wrote:

I should have probably prefaced this with the information that I am a package builder. In my situation there can only be one instance installed at a time. I acknowledge that my situation is directly at odds with hand builds that developers do.

What are you building packages for? Fedora seems to use us as-is. I think Debian doesn't use the bundled suricata-update, but builds it from its own release which could be used.

Actions #6

Updated by Shawn Michael almost 3 years ago

In house corporate package maintainer. We have a CentOS base, but have a few items upgraded that would conflict with CentOS packages if we placed them in the "correct" location with respect to the distribution. Python 3.7 is one of those upgraded packages (we have an independent requirement for it to be available as "python" not "python37"). So it's PATH manipulation for us to get the right thing called in the right situation. Luckily for us yum uses #!/usr/bin/python and not #!/usr/bin/env python so it just happens to work in our situation.

Both Fedora and Debian will be using the "system" python and both will use their standard package location prefix (/usr). So normal distribution packagers just happen to work with what you choices. I'm in the "value added" space and build upon others work, which results in some doing some work arounds some classes of problems. This is one.

To me this is a bug in my narrow view of the world. To upstream distribution maintainers what you have likely works just fine (the prefixes are the same). For suricata developers and multi-version evaluation on a single box, my patch is directly at odds with ease of use in those narrow situations. I proposed the patch as a fix for my world view, you enlightened me on your needs as developer which conflicts on the ease of use in my situation.

I acknowledge that my world view may be an extreme minority type situation. Ease of use for developers may trump how I think things should be. I am independently maintaining this patch for our in house use. In my case submitting to upstream is a possible selfish way for less work for me in the long term if what I provided is useful.

Actions #7

Updated by Andreas Herz almost 3 years ago

  • Tracker changed from Bug to Optimization
  • Assignee set to Shawn Michael
  • Target version set to Packaging/PPA
Actions #8

Updated by Victor Julien almost 3 years ago

  • Status changed from New to Feedback
  • Assignee changed from Shawn Michael to Jason Ish
  • Target version changed from Packaging/PPA to TBD
  • Effort deleted (low)
Actions

Also available in: Atom PDF