MonitorWare Knowledge Base

Hi

I'd like to write a rsyslog output plugin, but I don't find any documentation about how to integrate it in the rsyslog build system.
I tried modifying several build files, but the only result so far is a weird list of error messages at compile time :
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -D_PATH_MODDIR=\"/tmp/rsyslog/lib/rsyslog/\" -I.. -pthread -g -O2 -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g -MT librsyslog_la-rsyslog.lo -MD -MP -MF .deps/librsyslog_la-rsyslog.Tpo -c -o librsyslog_la-rsyslog.lo `test -f 'rsyslog.c' || echo './'`rsyslog.c
../libtool: line 818: X--tag=CC: command not found
../libtool: line 851: libtool: ignoring unknown tag : command not found

Is there any documentation available about how to do that ?

Thanks

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

There is unfortunately very limited documentation. One thing is to look at imtemplate, which is a template for an input module. Most things are the same for output modules.

To get started, I'd probably duplicate an existing module, e.g. ommail. Make sure you dulicate its sub-directory and also check the main configure.ac /Makefile.am for all occurences of ommail. That should get you going.

Rainer

Hi

Thanks for your answer. Now it's compiling. But I'm facing another issue.
I was planning to write this output module because I was expecting a much better control and a complete access to the message structure.
And it looks like the module API doesn't give access to this structure.

Is there any way to access this structure from an output module instead of the string generated from the template ?

Thanks

Simple answer: no It was a design goal that the internal structure is not exposed to the output module. This enables us (at a later time) to provide code that fully lets us de-couple the output module from the engine itself (if desired).

I don't really see the problem with sending the output module a pointer to a structure that is well defined and done for that use.
Such a design decision is good to keep the internal cleans, sure, except that it has its own set of problems. For instance having the SQL query generated from the core for the ommysql/ompgsql modules is imho worse than sending the output module a nice pointer to a structure.
I don't think that not exposing the output module internal structures is incompatible with exposing the output module an easy to use and manipulate structure for the messages instead of a raw char*.

sure, you can argue this way or the other. The fact, still, is that it is "the other" Changing that requires changing the output module interface. If you submit a patch that is compatible to "the other" type of outputs, I would appreciate that and will almost for sure integrate it