GSoC2015 Proposal: Syslog ng as a command line tool (battila7)
Syslog-ng is a highly configurable log management tool designed to work with various sources and destinations. The goal of this project is to extend the functionality of syslog-ng by implementing the standard input (as a source plugin) and the standard output (as a destination plugin) and making it possible to use syslog-ng as a command line tool without losing any of its notable features.
Syslog-ng is a highly configurable log management tool designed to work with various sources and destinations. These include files, TCP and UDP connections and database systems (just to name a few of the several options) making syslog-ng a perfect choice when dealing with a large amount of data. The program currently runs as a daemon process which is the best approach when handling the sources and destinations mentioned above. The goal of this project is to extend the functionality of syslog-ng by implementing the standard input (as a source plugin) and the standard output (as a destination plugin) and making it possible to use syslog-ng as a command line tool without losing any of its notable features.
In most cases, the syslog-ng performs very well as a daemon process, but it is not hard to imagine a use case when a simple command line tool with the same functionality would be more suited to the specific problem.
The program has a “syntax-only” mode, when it checks if the configuration file(s) meet(s) the syntactical requirements. But what if it is syntactically correct, yet semantically wrong (e.g.: it does not produce the output required)? If the program gathered input from stdin and put the processed output to stdout these kind of problems would be easy to detect. Going even further, the correct or a new behavior can be tested with an external configuration provided through the command line instead of modifying the current one.
Those who are familiar with the command line interface, probably have used redirection and piping before. After implementing the new source and destination, syslog-ng could be used as part of these expressions enabling users to feed syslog-ng particular files and even use the output produced instantly as other applications’ input. It should not be forgotten, that a similar functionality can be achieved now, but not through the well-known command line. This way the powerful filtering and parsing capabilities of syslog-ng could be inserted into a toolchain.
The development of the project includes the following tasks:
- Implementing the stdin source and the stdout destination
- Widening the range of command line arguments accepted by syslog-ng
- Defining the point when syslog-ng should be terminated
The first two tasks are pretty straightforward, but the third one requires some explanation. As discussed in the Introduction, syslog-ng works in a continuous fashion, receiving, processing and storing/transmitting data. But in this case we want it to work with resources present as the program is started and do not require a daemon process. Of course, large structural modifications cannot be involved in the project, therefore a point must be defined when the process can be terminated. The termination must be done gently, taking care of cleaning up after ourselves. For example syslog-ng saves its internal state between executions in order to make it possible to continue file reading from the position where the execution stopped. That functionality is definitely something we should take care of.
- From 27 April To 25 May
- Diving into the syslog-ng codebase
- Reading the documentation
- Sharing and exchanging ideas with my mentor
- From 25 May To 8 June
- Designing the basic structure of the new source and destination plugin
- Solving the questions on how the source and destination can be integrated
- From 8 June To 22 June
- Implementing and integrating the new plugins
- From 22 June To 13 July
- Solving the when-to-stop syslog-ng problem
- Implementing and testing the solution given
- From 13 July To 20 July
- Testing the new behavior together with other functionality
- Improvements and changes based on the test results
- From 20 July To 3 August
- Adding and implementing new necessary command line parameters
- From 3 August To 17 August
- Final changes and tests
- Writing detailed documentation
- From 17 August To 24 August
- Last changes and revisions if necessary
- Finalizing for the final evaluation
My name is Attila Bagossy. I’m studying Computer Science at the University of Debrecen in Hungary. I expect to graduate in 2017. I have been writing programs since elementary school and I have always been interested in this field, so I never hesitated when asked what I wanted to do when I grow up. When it comes to programming, I consider myself as a perfectionist. The first programming language I have learnt was Pascal but I quickly moved forward to C, C++ and then C#. In the past years I have gained some experience in JavaScript and web-oriented technologies but there is no doubt that developing desktop applications is my favorite field, primarily utilizing C++ or C#. In addition to these skills I am also familiar with git and Linux. I think of this project as a huge opportunity to extend my programming skills and to join the development of a well-known open source application.
Email addresses:
- bagossyattila@outlook.com
- bagossyattila@mailbox.unideb.hu (school issued)