Rename OutputRegisterFlowLogger to SCOutputRegisterFlowLogger and
document in the header file.
Mark other functions in the header file as part of the internal API.
Ticket: #7227
Rename OutputRegisterPacketLogger to SCOutputRegisterPacketLogger as
its part of the public API and document its parameters.
Comment on the other functions in the header that they are part of the
internal API.
Ticket: #7227
Expose LoadYamlConfig as SCLoadYamlConfig and remove it from
SuricataInit. This is required to allow the library user the ability
customize the loading of the configuration, for example doing some
programmatic configuration then loading a configuration file.
Move the contents of SuricataMain into the `main()` function found in
main.c. This forces the Suricata application to bootstrap and run
Suricata through the same interfaces as a library user might do.
Required exposing StartInternalRunMode as SCStartInternalRunmode. Its
arguable whether those "actions" belong in the library or just the
application, but I think that is separation we can look at later.
For now the lib example and Suricata's own main are the same, however
the example will probably extend more into programmatically
configuring Suricata or dynamically registering a runmode, which
doesn't really belong the main Suricata application.
Expose the functions FinalizeRunMode and ParseCommandLine to library
users, renaming with the `SC` prefix in the process.
This involves moving "application" level details from SuricataInit
into SuricataMain, as parsing command line options should be opt-in
for a library user.
In 7.0 if EVE was non-threaded, the ThreadInit for the filetype was
not called meaning that the filetype author had to handle the threaded
and non-threaded cases.
To simplify this, if non-threaded, still call ThreadInit (and
ThreadDeinit) once with a thread_id of 0. This should simplify
authoring EVE filetype plugins.
Remove EVE filetypes from plugin context as they are not only used
from plugins. Plugins allow user code to register filetypes, but we
also have internal file types that use this api including the null
output and syslog. Additionally library users can use this API to
register filetypes, and they are not plugins.
Ideally this code would go in "output-json.[ch]" as the "primary" eve
API, however there are currently some include circular include issues
there, so start new cleaned up EVE API in "output-eve.[ch]" which is
"clean" with respect to includes, and as we cleanup existing EVE API for
"public" use, it can be moved here.
Ticket: #6838
Create a mininal capture plugin that injects one packet. While it can
also be a template, we should be able to run this in CI to test the
loading and registration of the capture plugin mechanisms.
The simple example Makefile.am was unconditionally including
$(HTP_LDADD) which might be empty resulting in "../.." ending up in the
Makefile causing the build to fail.
Instead, also make HTP_LDADD a conditional, so we can only include it
when actually set, and its only set when libhtp is bundled.
The reason this Makefile needs to include the path components "../.."
is because the HTP_LDADD value is relative to the top level "src/"
directory.
Provide an example of an extremely simple application that links
against Suricata. This provides a Makefile integrated with the
Suricata build system for in-tree building, as well as an example
Makefile for building out of tree.
Currently this application just wraps SuricataMain and does nothing
else.
Simplify the Makefile by avoiding automake and providing our own
Makefile.in that is suitable for in-tree builds of the plugin and can
also serve as an example for standalone plugins.
But the bigger benefit of this is to allow building the example plugin
even with --disable-shared provided to configure, as this is just a
phony limitation imposed by automake/libtool.
This is an example of what adding plugin examples to the Suricata repo
could look like.
This plugin is an example plugin for an EVE filetype. It could be
extended to support outputs like Redis, syslog, etc.
There is one issue with adding plugins like this to an autotools
project, the project can't be built with --disable-shared, which is
more of an autotools limitation, and not really a Suricata issue.
Suricata built with --disable-shared will load plugins just fine.
Note that the examples directory was added as DIST_SUBDIRS as we don't
want normal builds to recurse into it and attempt to build the plugin,
its just an example, but we still need to keep distcheck happy.
Jason Ish
Philippe Antoine
Jeff Lucovsky