For the past couple of months, Yash Mathne has been working on testing syslog-ng on MacOS as a GSoC (Google Summer of Code) student. He worked both on x86 and on the freshly released ARM hardware. And we have some good news here to share: while there is still room for improvement, most of syslog-ng works perfectly well on MacOS.
Why is it an important topic?
To understand this, we have to look back on the history of syslog-ng. When syslog-ng was born 23 years ago, there were many competing platforms. Commercial UNIX variants were still strong, while Linux and BSDs were becoming more and more important. So, one of the major aims of syslog-ng was to ensure easy portability among multiple operating systems and architectures.
Over the years, many architectures and operating systems completely disappeared. From the business point of view, only Linux on x86_64 stayed relevant, so, that is where all new development is carried out. Still, easy portability is the main value of syslog-ng. Just think about how ARM is taking over not just Apple computers, but also many datacenters. POWER is also having a comeback and we have a new rising star: RiscV. Testing syslog-ng on MacOS ARM kills two birds with one stone: testing is carried out on a different OS and on a different architecture.
While syslog-ng is built and tested on MacOS x86 before each pull request is merged to syslog-ng, we did not have a clear picture what does not work on MacOS and why. As a result of this GSoC project, we learned what the problem areas are. Some of them cannot be fixed by the syslog-ng project and the actual problems are in external dependencies, while others can be fixed or have a workaround.
What is next?
You can read the project report below. It was written by Yash and gives you a good overview of what he was working on and the methodology he used. A second part of this blog will cover the technical details: how syslog-ng can be installed on MacOS, what the problems are and some of the possible workarounds.
The GSoC report written by Yash is copied here from https://yash6866.gitbook.io/syslog-macos-testing/gsoc-project-report without modification.
You can reach Yash on LinkedIn.
Project
MacOS, as of 2021, is not officially supported by syslog-ng. Currently, only the building and the corresponding unit tests are guaranteed on MacOS (x86 architecture) with some minor changes to the config file. However, what makes syslog-ng a better alternative is the abundance of sources/destinations and the rich filtering capabilities.
These, unfortunately, don't have any guarantee of working, as extensive testing is still pending. Moreover, Apple has also introduced their in-house Apple Silicon laptops with ARM architecture, and no tests have been done on this system whatsoever.
This project aims to test and document the current status of syslog-ng on MacOS and, if possible, provides fixes for the same. This project seeks to extensively test multiple modules with their various plugins on both macOS architectures. For all the plugins tested, reproducible tests and documentation will be maintained, and a root cause analysis provided if a plugin fails to function.
Work done
The work done in this project is being tracked on the Testing Status page. As of the GSOC final submission, over 35 drivers have been tested, from writing the tests to documenting the results and the errors faced.
Apart from this, I have also worked with my Mentor to discuss various solutions to the problems we faced with drivers that didn't function as expected. One example can be the system() source driver which did not support macOS. We discussed the possible solutions, researched the options and consequently I pushed a pull request for the same.
Highlights
GSOC has given me a plethora of different experiences, from learning how to interact with a dev team to building professional connections online. I’ve had contributed to open source before however, my favourite part of participating in GSOC this year is most definitely my interactions with the team at syslog-ng, in particular, my mentor. Never before have I met a team that is so friendly and helpful, oftentimes going beyond what is expected of the devs when it comes to troubleshooting.
My mentor, Mr Attila Szakacs, in particular, has been immensely helpful throughout the process. From helping perfect my proposal during the contribution phase to oftentimes being online and troubleshooting a problem with me instead of simply pointing me somewhere else. Since the problem I am covering is a broad one, he has also given me the freedom to explore in any direction, whilst also keeping a constant check, which is very comforting.
Challenges
This project was very broad in its scope. Testing a driver required me to learn about the dependencies of that driver, so that I could write a test code for it. This meant that throughout the project I have had to learn various technologies, such as Elasticsearch, Riemann, Redis, etc. When a particular driver or process did not work, the root cause analysis often pointed to a chain of issues and getting to the root of it all wasn't always easy. We also extensively discussed the solution space for such drivers, which often required a lot of research.