Future Features

Return to Home page
This is the list of potential features that might be added to syslogd2 in the future if requested or if a need arises (kind of a 'ToDo" list):

Kernel Threads

Full implementation of kernel threads will support the 'procfs' input sub-option to specify the use of the kernel klogctl call that directly reads the kernel's ring-buffer even if the /proc file system is not mounted. This will provide support on systems where the admins may not want to mount /proc for security reasons.

Implement Inotify

This impelementation will utilize the ability of the Linux fielssytem to nofy syslogd2 when a 'watched' filesystem changes to both speed up the response to tail-file updates, but to also merge tailfile and socket input and even kernel input into the same input threadpool if desired. (Remove the current need for separate threadpools).

Integrate CheckNet

Integrate the project library for detection and configuration of changes among multiple network environments. The goal is to provide a tool that can be used by shell scripts and Syslogd2 to control laptop configurations (mounting corporate resources and disabling connections to corporate hosts) as they move around and join different networks.

Authenticated Streaming Connections

his is a big "MAYBE" because I'm not convinced of the demand. This idea is an extension to the --network and CAP_STREAMIN / CAP_STREAMOUT functionality.
When Linux is running on a work-laptop, it can be expected (by virtue of the laptop hardware) to move from work to other networks. If that laptop is configured to forward syslog (or other) data to a remote host via UDP, there is no way to prevent it from transmitting that UDP syslog data to any non-corporate host with the same address (or to nobody at all since UDP does not verify that transmitted data is ever receieved).
Syslogd2's `--network` option takes a step in this direction by attempting to detect what network it is running on and (potentially) disabling the connection if not on a correct 'corporate' network. (Though this step is currently incomplete in that it does not recognize networks other than the generic "other"). One way forward would be to "beef up" the *CheckNet* project above so admins could specify an interface valid only when on a corporate network (as determined by distinct detectable criteria).
The possible `authenticated streaming connections` feature (possibly in conjunction with the `--network` option) would provide a challenge-authentication when a streaming connection is first established (streaming connections only since this won't work with datagrams). The client passes a challenge to to the host. If the host does not respond with a pass-phrase, the connection is aborted and the client resumes spooling as if the connection could not be made. If the host responds correctly, the connection is establishd and any spool-file gets flushed. Both the challenge and pass-phrase would be configured as sub-options to output and input connections respectively in the Syslogd2 configuration file.
If an incoming streaming connection is established and the first packet is not a challenge, the host would accept the connection as normal, so challenging clients can intermix with other streaming input connections and (when at work) would appear to be performing normally.
This feature may gain in popularity with so many people working from home or possibly if Syslogd2 starts being used in a 'salesman' mode where off-line (application-logged) data is to be stored for later transmission to a corporate host (and ONLY to a corporate host).

Intermittant Connectivity

his is also a big "MAYBE" because I have no confidence there is any demand for this ability. The basic idea is that a Syslogd2 host using a streaming connection with defined spoolfile would peridically connect to a remote host, dump the spoolfile, then intentionally disconnect for a period. Some of the questions that needs to be answered are:
What should be used to trigger the connection ? disconnection ? (1) Elapsed time ? (2) Time-of-day ? (3) spoolfile-size ? (4) Other ?
This feature might have use for a remote site periodically dumping accumulated logfiles to a 'parent' (primary) site when time sensitivity is not an issue (like if the remote site has its own alerting system and the primary site wants the data for long-term trend reporting only).
This feature could allow a larger "fan-in" of stream connections if each connection is relatively short rather than permanently-connected, but the data would likely have to be non-time-sensitive. Return to top

Return to Home page