Bug 1508816

Summary:	Re-enable libprelude support
Product:	[Fedora] Fedora EPEL	Reporter:	Thomas Andrejak <thomas.andrejak>
Component:	suricata	Assignee:	Steve Grubb <sgrubb>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	athmanem, jmlich83, jtfas90, sgrubb
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-01-26 00:59:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Andrejak 2017-11-02 09:47:56 UTC

Description of problem:
When installing suricata, libprelude support is not available. It has been droped in 2013 without reason but at this time, libprelude was not really uptodate so I understand. Now that libprelude is OK, it's time to make it back.


How reproducible:
Install suricata and try to use prelude support

Steps to Reproduce:
1. Install suricata
2. Enable prelude in suricata conf file
3. Start Suricata

Actual results:
Not trying to connect to Prelude


Expected results:
Try to connect to Prelude


Additional info:
It was enabled before (2013) and it is simple to re-enable.

Comment 1 Steve Grubb 2017-11-02 10:21:36 UTC

Its not a case of libprelude support being dropped without a reason. It was dropped because upstream was dead and libgrypt was upgraded to a new version which caused libprelude not to compile. With upstream dead and not compiling...support had to be dropped for this reason.

I don't know if I trust upstream is healthy or won't disappear again.

Comment 2 Thomas Andrejak 2017-11-02 10:35:49 UTC

The re-take of libprelude was hard arround 2010 to 2014 but since, it is OK.
All distribution are now OK (not just EPEL), we contribute on probes: suricata, clamav, kismet for most recents commits, prelude websites are back (prelude-siem.org and prelude-siem.com), twitter is back too.
Also, since 1.2 version, we do two released by years. The 4.0 was released this year and the 4.1 will be released by the end of this year.

I know that getting the community back is hard but we hope you will help us :)

Comment 3 Jason Taylor 2017-12-08 14:39:51 UTC

Hi Thomas,

After some testing and research it appears that the current suricata support implementation for libprelude is broken.

According to a ticket with upstream:

https://redmine.openinfosecfoundation.org/issues/1480

It appears it is a known issue but also in talking with upstream prelude support is not officially supported so it can break essentially at time.

At this point in time enabling prelude isn't something we can do safely in the suricata packages.

We will be happy to revisit enabling if the integration status changes.

JT

Comment 4 Thomas Andrejak 2017-12-10 23:52:27 UTC

I tested my self with koji ( https://koji.fedoraproject.org/koji/taskinfo?taskID=23632244 ) and the Prelude support is fully working.

Can you tell me what are your issues ?

For the suricata ticket you pointed out, the initial user talk about Prelude 1.0.1 (released before 2010). The actual version is 4.0 (released this year) in f27, f28 and epel so I think it is not relevant for adding the prelude support.

I packaged Suricata for myself for two years with your .spec and the --enable-prelude and the dependencies and it works perfectly.

An other example is Debian, the suricata package enabled the prelude support for a long time.

If you still disagree to enable the prelude support, can you tell me what you want me to do to let this happens ?

Thanks and regards

Comment 5 Jason Taylor 2017-12-11 00:37:55 UTC

Hi Thomas,

Yes, the bug link was against version 1.x albeit that is not the current version in fedora (as you noted 4.x is) the information in the ticket was the same as I was experiencing in my build tests so it appeared that there has been trouble compiling against prelude in the past.

In reviewing your build, you included an additional BuildRequires of pkgconfig(gnutls). I was unaware of that dependency and when I tested with that addition the build completes successfully. So thank you for that.

As far as packaging the default support with prelude, given that prelude is not officially supported I would still hesitate to enable it in the default package.

I have added a request for additional information from Steve to get his take on things.

I would be more than happy to work with you to maintain a copr version that includes prelude support in the interim.

Comment 6 Steve Grubb 2017-12-11 20:04:37 UTC

If its just a dependency issue, then we can re-enable it.

Comment 7 Jason Taylor 2017-12-11 20:48:27 UTC

Steve,

Yes, slightly embarrassed about that but it was just a missing dependency it would appear.

Do you want me to unpush the updates and repush with prelude enabled?

JT

Comment 8 Steve Grubb 2017-12-11 21:05:07 UTC

Sure. I think we're just enabling it on the new 4.0.3 package? 3.2 is now end of life.

Comment 9 Jason Taylor 2017-12-11 21:15:40 UTC

Yes, 4.0.3.

JT

Comment 10 Thomas Andrejak 2017-12-11 22:51:17 UTC

Thanks a lot :)

In the future, if you have issues with libprelude, ask me, it will be my pleasure.

Regards