Welcome and Introduction

Welcome to the Syslogd2 Wiki.

My initial thoughts for this wiki are to describe and discuss various components and features of Syslogd2. I'm still struggling with how to describe Syslogd2. The phrase "a syslog logging daemon" is (in my opinion) woefully inadequate. [Syslogd2 CAP_-abilities] Syslogd2 is a backgrounding daemon that CAN be used to replace the default logging daemon in Linux systems [Configuring Syslogd2]. It can ALSO be deployed as a backgrounding application -- one which avoids conflict with an existing syslog daemon but can (if necessary) supplement the default syslog daemon as desired. Syslogd2 can front-end existing syslog log servers or can be deployed generically throughout a corporate network as a means of controlling and managing syslog traffic flow for network devices or host systems / Linux desktops. Syslogd2 is also being designed to interoperate with 2 additional projects I already have in development [Syslogd2 Related Projects and Tools].

Please bear with me as I fumble my way through my first open-source code release. I first concieved the need and initial parameters for Syslogd2 almost 20 years ago and have been using it as both a hobby and a learning tool since. I now want to release this code as open-source because in the last 20 years, I've seen nothing that compares to SyslogD2's capabilities as a syslog data collector / concentrator and I feel there is a growing need for the capabilities Syslogd2 provides.

The fields of Linux Administration and Network Administration have mutually reinforcing needs and skill sets. Linux is a stable, (free) OS that runs on the cheapest hardware currently available so it can be economically deployed in numbers without incurring either license costs (as in MS code) or excessive hardware costs as with larger (old-school) Unix platforms. Linux-based tools are the most versatile, flexible, stable and powerful tools I've had the pleasure to use during my entire career in IT. I attribute this to the open-source nature of Linux and the thousands of deveopler eyeballs that are constantly looking for and fixing bugs in open-source code as well as the administrator/developers that are constantly improving the open-source tools they use on a daily basis. With Syslogd2, I wish to contribute something back to that body of excellence.

Over time, the Syslogd2 code has grown in size and features to the point that I have had to re-design not only the core data structures, but re-design code and algorithsm to enable features I wanted to add. I have just finished yet another of these rewrites where I threw out and replaced much of my existing parsing code in favor of a newly-designed library that I can use in other projects as well.

Syslogd2 (as it is currently designed) is a less of a one-size-fits-all application than it is a code-base where features and functioanlity can be selected at compile-time and compiled into one or more binaries that are tailored for deployment to meet the needs of hosts with vastly different requirements for collection and disposition of syslog data. Configuration of Syslogd2 can be as simple as using a traditional UNIX syslog configuration file with traditional syntax and enabling IP support with a "-r" command-line option. Syslogd2 default anctions are designed to mirror those of UNIX-style syslog daemons. Even when using the extended Syslogd2 features, the additional options can be hidden from more traditional syslog daemons providing the ability to create configuration files that can be used with both rocket syslog and Syslogd2 at will.

To fully understand the design goals and the extent of Syslogd2's abilities requires discussions on a variety of topics. I hope to address these topics in the pages of this wiki.

The short version is that Syslogd2 aspires to the following goals and principles:
1. Syslogd2 should be flexible in what it accepts, forgiving of user configuration errors to the maximum extent possible while producing strictly predictable output and robust & consistent performance.
2. Syslogd2 should default all features and settings to match the characteristics and options of traditional syslog daemons. This lowers the 'learning curve' of system administrators that don't care to learn the intricacies of syslogd2.
3. All new Syslogd2 features and options should have an 'off switch'. They should either require a run-time setting to enable them or have some way to be disabled at run-time.
4. All options and sub-options should have clearly recognizable relationships between the name and the function (I'm still struggling with this one -- discussiosn on option-names are welcomed and solicited in the dicussion forum).
5. When possible, advanced features should be entirely removable (both code and data structures) from the binary to reduce the footprint and processing requirements. Syslog supports 20 (at current count) such features - each with a name starting with 'CAP' and each enabling a major design or feature capability. These "CAP'-abilities must be selected prior to compilation for a given syslogd2 binary. [Syslogd2 CAP_-abilities]
6. Syslogd2 should do as few things as possible, but do them as well as possible. For Syslogd2, this means that custom output formats, and customized inputs are not envisioned to become part of the core daemon. Instead, Syslogd2 supports the creation of user-definable sockets where 3rd-party (preferably open-source) applications can write to syslogd2 inputs or read from syslogd2 outputs, functioning as customizable pre-processors or post-processors as necessary and desired.

Overall, Syslogd2 remains a work-in-progress [Syslogd2 Future Features] and [Syslogd2 Known Warts and Shortcomings]. I'd love to see Syslogd2 become the start of a new way to think about large-scale network-and-host management and about application and hardware administration. for large quantities of systems.

I welcome interested developers, end-users and administrators to this effort. Please contact me if you are interested in in participating as a developer, a tester, or if you wish to help with documentation (a weak spot for me), or with international translations.

Any developers willing to release their end-projects as open-source are welcome to utilize the Syslogd2 libraries and code-base (including the pOpen simplified code files). You incur no obligation to me by utilizing the Syslogd2 file-structrue for your code as long as you don't modify the common library modules. You would still retain copyright ownership and are welcome to utilize the Syslogd2 tools directory and all Syslogd2 libraries (or I'll create a new subdirectory & Makefile for your project). Any developer, translator or documentation guru interested in working on Syslogd2 directly are invited to join me in further developing the code and documentation.

Thank you for visiting the Syslogd2 project. Please check back regularly for updates. I will be uploading my initial file-set as soon as I resolve a few more outstanding issues (likely just a few days). In the meantime, please explore this wiki to get a feel for how Syslogd2 might be used in your networks and Linux deployments.

I welcome all feedback, bug reports (I hope to get a ticketing system up and running soon), and look forward to the discussions and feature requests that I hope will be forthcoming.

Ed Freesmeyer
Original architect and author of Syslogd2

Project Members:

• Ed Freesmeyer (admin)