[syslog-ng] is there support for multi-line messages in a syslog-ng OSE release?

[Balazs Scheidler]

On Thu, 2011-09-01 at 17:57 -0400, mike at lague.org wrote:
> I'm  using syslog-ng 3.0.5 (OSE). 
> 
> I've noticed that if a multi-line message is sent by an application to
> syslog-ng  via a unix-stream source, the first line is logged to the
> right destination, and the next line goes to a default destination.
> E.g., if a message like 
> "Test message line 1\nTest message line 2\n" 
> is sent,
> "Test message line 1"
> appears in the expected destination file, while
> "Error processing log message: Test message line 2"
> appears in the default destination.
> 
> This limitation (which does not exist with unix-dgram sources) seems
> to have been reported a number of times on various lists.
> 
> The feature comparison table at
> http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/features/comparison
> indicates that there is no support for multi-line messages in OSE 3.2,
> but there is such support in PE 4.0
> 
> Yet I thought a saw a message which indicated that there might be
> support for multi-line messages in an OSE release? Can someone confirm
> this? Also, is there any way around this limitation in earlier OSE
> releases?

Hi,

The code by the PE team is available on git.balabit.hu, but I still had
no time to integrate all changes. This is one of those bits, which is
not yet in OSE, even though the code is available.

The issue is that the patches in the PE tree are quite interleaved and
picking out features is quite difficult. Also, I wouldn't want to merge
the tree as a whole, since I'd be the one to support that version, and
when I'm not 100% sure that I understand how things work, I don't
integrate.

But anyway, this is something that is important to do, and I'd like to
do that, but as always it happens as time permits.

You, or anyone else can help me in this regard: creating a concise patch
series that contains a single functionality alone.

Then, quite probably some review cycles are going to be needed, in cases
when something is implemented in a way that is not fit for the OSE
purposes. I do know about a couple of things that are so PE specific
that I wouldn't want to put it in the OSE tree, those bits will have to
be maintained by the PE crew. Such an example is the code supporting the
license validation, which certainly doesn't make sense in the OSE
context.

So with coding skills, anyone can contribute by helping me to integrate
that stuff.

PS: and this is now possible, because of the latest change in licensing
and because of the fact that the PE crew actually publishes the git tree
that they integrate into the PE product.

-- 
Bazsi