Developer Guide
Doing developing on Lynis is easy. Our tool is written in shell script. It uses the Bourne shell, usually /bin/sh on your system. Don't confuse it with BASH though (Bourne Again SHell). By adhering to the Bourne shell, the tool remains portable, and allows it to run on Linux, *BSD, Mac OS X, and others.
Understanding the structure of the project is an important starting point
In the tarball and on GitHub, you will see just a few directories.
The most important files, like the Lynis script itself, can be found in the root of the directory. It will include other things like the man page, documentation and changelog.
The directory is named "include", as more intelligence is included (or sourced) by the main script. This way it can import functions, initialize variables, and show the report. Also the individual tests are stored in this directory. They are grouped by category. This directory is definitely where most of the magic happens.
Supporting documents and scripts are stored here.
Like any programming language, there are different ways to keep a project structured. It ranges from variable names, up to spacing. So we provide some guidelines to keep the structure and flexible enough for further expansion.
- Indentation is done with 4 spaces (no tabs)
- Variables are capitalized, optional with an underscore to "split" words
First step to contributing via GitHub, is by forking the project. This creates a local version for you to experiment.
- Fork it ( https://github.com/CISOfy/lynis/fork )
- Create your feature branch (git checkout -b adding-my-new-feature)
Next step is making your local changes and test them.
Tip: To simplify testing, you don't have Lynis to perform all tests. Use --tests-category or --tests to specifically decide what tests to run.
After you are done, commit the changes: (git commit -am 'Adding some feature or improvement')
To improve the quality of your changes, tests should limit the amount of screen output. Important details should be logged to the log file, using the logtext function.
Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch.
- Push to the branch (git push origin adding-my-new-feature)
- Create a new Pull Request