system() source does not work on DragonFlyBSD

[czanik]

DragonFlyBSD is using FreeBSD ports with minor modifications for external packages, including the syslog-ng package.

dragon# /usr/local/etc/rc.d/syslog-ng forcestart
Starting syslog_ng.
[2021-02-17T08:59:13.598727] system(): Error detecting platform, unable to define the system() source. Please send your system information to the developers!; sysname='DragonFly', release='5.8-RELEASE'
Error parsing config, syntax error, unexpected LL_ERROR, expecting '}' in /usr/local/etc/syslog-ng.conf:19:14-19:20:
14      options { chain_hostnames(off); flush_lines(0); threaded(yes); };
15      
16      #
17      # sources
18      #
19----> source src { system();
19---->              ^^^^^^
20      	     udp(); internal(); };
21      
22      #
23      # destinations
24      #


syslog-ng documentation: https://www.syslog-ng.com/technical-documents/list/syslog-ng-open-source-edition
contact: https://lists.balabit.hu/mailman/listinfo/syslog-ng

While system() source works on FreeBSD, where this configuration was prepared, it does not work on DragonFlyBSD.

     unix-dgram("/var/run/log");
     unix-dgram("/var/run/logpriv" perm(0600));
     file("/dev/klog" follow-freq(0) program-override("kernel"));

This is based on the earlier FreeBSD configuration and seems to work.

[alltilla]

Supported platforms are listed in this function:

syslog-ng/modules/system-source/system-source.c

Line 265 in 2d594f6

system_generate_system_transports(GString *sysblock, CfgArgs *args)

"Linux"
"SunOS"
"FreeBSD"
"GNU/kFreeBSD"
"HP-UX"
"AIX"
"OSF1"
"CYGWIN"
"OpenBSD"

We are getting the info from uname.

Maybe we can make this configurable with an execution flag, like --sysname, so one can "fake" its platform, in situations like this.
Alternatively we can add DragonFlyBSD, but I think we shouldn't just list all platforms, and let them decide what they categorize themselves, when starting syslog-ng. In this case FreeBSD seems viable.

[czanik]

DragonFlyBSD is similar to FreeBSD, but did not switch to RFC5424 yet.

[Kokan]

The main purpose of system() source that syslog-ng does the right thing, without specifying it. (categorizing themself)
I do not think we should ask the user to specify which OS/distro they are close to based on what system() source does.
That should be tested, and specified for each platform.

The sysname would be nice for testing, but I fear users are going to use the way you described, and in the and make it not to work and conclude system source is not good. (testing can be achieved other ways, not exposing such an cli)

If somebody wants to override what system() source expands into, they can without changing the code. Simple use the placeholder in scl: https://github.com/syslog-ng/syslog-ng/blob/master/scl/system/plugin.conf

Of course on long term, they should contact us with a request, so that can be incorporated into the system source as well.

[alltilla]

@czanik
Is is possible for DragonFlyBSD to change scl/system/plugin.conf, or should we start working on integrating them into the system source in our C code?

[czanik]

I'd prefer to get it done in C code. Adding local modifications to DragonFlyBSD ports does not seem to be easy and straightforward, and having it in the C code makes it available even if someone compiles syslog-ng outside of ports.

On the other hand it is not urgent and most likely not that difficult either. It could be a testing task for GSoC students.

[dch]

freebsd ports committer here, I'm happy to add a patch (we are the "upstream" for ports for dfly). I'm in the usual places on IRC for questions.

[bazsi]

I think if a patch is prepared we can merge that to syslog-ng. It's just an extra if in the system source driver and a config snippet that works to instate when running on dflybsd.

…

On Tue, Feb 23, 2021, 17:50 Dave Cottlehuber ***@***.***> wrote: freebsd ports committer here, I'm happy to add a patch (we are the "upstream" for ports for dfly). I'm in the usual places on IRC for questions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOK5Q3UQXBLEZUO6RPOU3TAPMERANCNFSM4XYCN7YA> .