CurrentStatus

Return to Home page

Syslogd2 will eventually run on both Linux and Mac and anywhere else I or others can port it to.

I am at the point of looking for people willing to give me feedback on Syslogd2, to help with development, or to help with documentation or help-files or testing or ....

----------- Nov 10 2022 ------------

Syslogd2 is finally released for Linux. Lots of additions since July of last year means that I now need to go back and verify / fix any porting issues with OSX. The last-minute release frenzy included adding explicit copyright notices on all files (they were legally copyrighted already, but I added explicit statements, contact info and specific license information).

The changes also mean that much of the documentation in this wiki is either outdated or (in the worst case) flat out incorrect. One of the things I've found out is that updating a wiki for documentation is just way too time-consuming which is why I've changed to the concept of using multiple OpenDocument files (written in OpenOffice.org) that can be updated individually and that cover limited, individual features. This allows the documentation to better reflect the code -- and you only need to read the parts that pertain to your needs.

There are still relatively large pieces of functionality I want to add to Syslogd2, but those pieces can come later in the form of patch-updates:
-- A 'burst' mode for stream sockets where collected data is spooled for a while, then all collected data is 'bursted' over a temporary stream-connection before the connection is shut down for more data-spooling. This is intended to provide reliable (even network-aware) connections even when the fan-in for stream connections to Syslogd2 reaches into the thousands (such as for large desktop deployments) or for laptop deployments.
-- An initial 'critical mass' for the CheckNet library (the library Syslogd2 uses to determine network-state. 'Critical Mass' refers to an initial capability to define the identifying characteristics of a network in sufficient detail that 'most' networks can be distinguished, making many of the 'network-aware' claims in Syslogd2 more useful and obvious as to their meanings. This will also increase the value-added of Syslogd2 for laptops.

There is also more documentation that I need to add, but that documentation is less critical than what is currently posted that has taken me so long to write:
-- A full description of my concept of 'network-awareness'.
-- Additions (with more examples) of filters, more Syslogd2 demonstrations, list of log-messages and priorities, etc.

I need to take a break from Syslogd2 documentation for a while to focus on DBD2 development and documentation -- DBD2 is a multi-threaded database-insertion tool for syslog and user-command-line data. Once DBD2 is stable and on-line, I have yet more projects in mind, but they will have to wait for now since Syslogd2 and DBD2 fixes and periodic updates are higher priority activities.

----------- Jul 31 2021 ------------

Syslogd2 release has been delayed as I've decided to add an '--includeconfig' option to allow distributions (or admins) to recursively include "configuration snippets" into the primary configuration file, allowing for packages to add "log files" as they are installed or to allow admins to apply standardized logging only where applicable packages are installed.

Because of the extensive nature of the involved changes (in error generation and reporting, and configuration display as well as in internal algorithms and structures, this is more of an extensive change than it appears on the surface.

Additionally, I've decided to re-write the algorithms that 'build' the operational structures from the parsed structures. This re-write is expected to result in more reliable and predictable (as well as more efficient and more correct) code, but is somewhat time-consuming to get absolutely correct.

Because the changes above are essential to operation of Syslogd2 and affect core code components in major ways, I cannot release any updates until they are complete and I'm sure they appear to work properly under all conceivable (realistic) configurations.

----------- Jun 22 2021 ------------

Syslogd2 is now functional on Linuxr. It is undergoing unit testing and testing of various configurations. This documentation wiki is also being updated with new feature entries and pages being added/revised to describe and illustrate usage.
Using Ubuntu as one of my development platforms, I've been forced to deal with the apparent 'new direction' of Linux (systemd).

The way systemd has 'taken over' the OS and all resource access to the kernel and devices is very reminiscient of Microsoft's early years when they were still attempting to gain control and dominance over the nascent PC (personal computing) industry by putting their 'windows' between DOS apps and the kernel and devices. (All done in the name of "user-convenience" of course with a concurrent disregard for any code or requirements 'not invented here' or that did not comply to Microsoft's way of 'doing business' until Microsoft could control the applicable technology themselves.)

As a Red Hat initiative, systemd may (or may not) be a bid to gain increasing control (via systemd 'rquirements') over a dominant set of development projects which could then lead to charging license fees for the use of systemd (and it's 'services') -- fees that would need to be passed on to users, effectively making Linux a "payware" OS with Red Hat then competing with Microsoft for 'sales'. Dominating system/kernel interfaces and access to the OS and devices also has a chilling effect on creativity and independent development of individual services which has long been a primary defining characteristic of Linux apps.

For the above reasons and others (including portability), Syslod2 will remain non-dependent on systemd and its multitude of 'wrappers' that foster dependency on systemd's (host-limited) 'environment'. One big argument for Syslogd2's independence from systemd (in addition to porability) is avoidance of any filtering or modification of raw log data between application and input to Syslogd2 as well as performance degredation due to handling the same data multiple times or throughput limits imposed by systemd's middle-of-the-road ('good enough') design philosophy. Because Syslogd2 is primarily network-oriented and focuses on performance as well as communications and generic data collection instead of on host-logging, compliance with systemd's limitations would restrict (rather than 'enhance') Syslogd2's scope, capabilities and its entire reason for being.

The attitude that one man's opion of what 'most people' want is sufficient reason to restrict the capability of 'all people' can have runs counter to the basic premises of Syslogd2 and it's design to be mroe than just a 'host logger'. Syslogd2 will address systemd issues by adding options and insructions to allow operation on systemd-based distributions while continuing to enjoy the 'unwrappered' performance gains of NOT running within the 'contraints' mandated by systemd. Instructions will be provided on how to configure Syslogd2 to integrate with systemd as a 'free process' operating outside the confines and limits of systemd on a systemd-based distribution.

----------- Jun 10 2021 ------------

The newest features (include-files, kernel-threads and the 'ignore=' input option) are still being fully integrated into the code and unit-tested (they need some more work on configuration display) and even when completed and tested still have immediate upgrade plans to their functional capabilities.

Now that my Linux box has been replaced, I can work to insure that all Linux features also work in Apple-Mac (with exception of the kernel-threads of course).

----------- May 25 2021 ------------

Syslogd2 is mostly functional on Linux, but has only just been ported back to Linux and has brand-new kernel-threads and modified primary routines that have not been thoroughly tested or verified for correct operation in several change iterations.

----------- Initial Status Posting ------------

I'm willing to be flexible on licensing for any reasonable requests. I have initially selected the Affero GPL license in an attempt to prevent this code from getting co-opted by commercial charlatans selling CLOSED "silver-bullet" black boxes as "network management" or "data-collection" systems. My desire is to have Syslogd2 become a tool for SERVICE-vendors or in-house IT personnel to use to customize network-management solutions (hopefully using open-source tools) for network customers.


Ed Freesmeyer