afsocket: added error warning messages on so-rcvbuf/so-sndbuf failures

This patch checks if the setsockopt to change the socket buffer sizes
actually succeeds, and emits a warning if it doesn't. Otherwise it can be
difficult to detect udp drops due to receive buffer sizing issues, when
the kernel limits syslog-ng's attempt to increase the buffer.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afsocket: Implement tcp_keepalive_time(), intvl() and probes()

Three new options are introduced this patch to control various TCP
keepalive related parameters

  tcp-keepalive-time()   - equivalent to /proc/sys/net/ipv4/tcp_keepalive_time
  tcp-keepalive-probes() - equivalent to /proc/sys/net/ipv4/tcp_keepalive_probes
  tcp-keepalive-intvl()  - equivalent to /proc/sys/net/ipv4/tcp_keepalive_intvl
  tcp-keepalive()        - an alias to the earlier so-keepalive() option to match the keepalive related params

With these new options one can control on a per-source basis the parameters
governing TCP keepalives.

While these options can be specified for all socket related sources,
it only makes sense for TCP-based transports.

By default, it's value is 0, which means using the kernel default (2
hours).

These options only work on platforms which provide TCP_KEEPCNT,
TCP_KEEPIDLE and TCP_KEEPINTVL setsockopts, which is only Linux as
far as I know.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
tcp(): enable TCP keepalive by default

This patch enables SO_KEEPALIVE by default and changes the various
keepalive timers so that broken connections would be detected within
2minutes, 60 seconds idle time, 10 seconds between keepalive probes and
6 failed probe means that the connection got broken.

The keepalive parameter setup only works on Linux.

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
jsonparser: Clone the marker() setting when cloning the parser

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
afsmtp: Fix the module linkage

Use $(MODULE_DEPS_LIBS) and $(MODULE_LDFLAGS) instead of trying to
grab all the libs.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
jsonparser: Handle every kind of invalid input gracefully

Previously, we used json_tokener_parse_ex(), which always returned
NULL in case of an error. A while ago, we switched to
json_tokener_parse() instead, which never returns NULL, and instead,
modifies the returned object to be an integer casted to pointer in
case of an error.

This resulted in the json-parser segfaulting whenever it encountered
invalid input.

The best course of action is to switch back to
json_tokener_parse_ex(), because that way we can easily see when an
error happened, and we even have easy access to the error message.

In the long run, we should probably move back the tokener to the
LogJSONParser object, and protect it with a mutex, for a bit better
performance.

Reported-by: Eun Kyung <ekyung01@googlemail.com>
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
db-parser(): implement a MAC address parser

The MACADDR parser matches the standard format for printing MAC-48
addresses in human-friendly form, whis consists of is six groups of
two hexadecimal digits, separated colons (:)

Signed-off-by: Balint Kovacs <blint@balabit.hu>
.gitmodules: change repository PATH to algernon's repo

Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
afmongodb: Support connecting to unix sockets

The next version of libmongo-client (0.1.6) will support connecting
via unix sockets, and the mongodb destination driver should follow. To
achieve this, the internal copy was updated to a version that already
supports this, and the minimum required version was also bumped to
0.1.6.

With that in place, the path() option is introduced, which, when set,
will tell the driver to connect via the specified path to a unix
socket. It does this by setting port to MONGO_CONN_LOCAL, that's how a
path is recognised by libmongo-client.

However, setting path() conflicts with host(), port() and servers():
the first cannot be used when any of the other three was previously
set, nor the other way around. The configuration grammar was updated
to notice this case, and bail out with an error if such a scenario is
detected.

Based on the work of Conrad Hoffmann <ch@bitfehler.net>.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>
afmongodb: Fix a queue notify<->wakeup deadlock

As it turns out, there's a race condition between
afmongodb_dd_queue_notify() and the worker thread: one is trying to
lock queue_mutex to send a wakeup signal and clear the notification
callback, and the other is using g_cond_wait() with the same
queue_mutex locked around it.

There appears to be a race between the two threads, and it can happen
that both are trying to g_mutex_lock() the same mutex at the same
time.

To work around this problem, the patch below removes the queue_mutex
locking from dd_queue_notify(): it's not required anyway. But it also
moves the log_queue_reset_parallel_push() from the queue notify
function to the other thread, where we're already holding the mutex
after the g_cond_wait() anyway. (And do something similar in the
suspend wakeup case too, where locking queue_mutex is also safe).

This gets rid of the deadlock, and the code becomes easier to follow
aswell.

Reported-by: Eun Kyung <ekyung01@googlemail.com>
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
confgen: Implement a built-in system() generator

The system SCL plugin relies on a script (generate-system-source.sh)
to generate the block system() expands into. While this is flexible
and easy to modifiy, it has the disadvantage of running an external
script at startup, which is undesirable in many situations, including
when using a strict AppArmor profile.

However, a generated system() is useful in a lot of situations,
ranging from creating portable, system-agnostic configuration files to
supporting sysvinit and systemd with the same config.

For these reasons, this patch implements a built-in system()
generator, that does not rely on the generate-system-source.sh script
at all, but does everything itself, from C.

It should be used similarly to the existing generator:

 @module confgen context(source) name(system) system(yes)

This will result in the very same system() expansion as the script's
as of this patch. The downside is that if one of the generator gets
extended, the other must be updated too, to keep them in sync.

Signed-off-by: Gergely Nagy <algernon@balabit.hu>