-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Developer Guide
Developing is not that hard, as our tool is written in shell script. It uses Bourne shell (not to be confused with Bourne again shell, or BASH). The benefit is that it is available to all UNIX based systems, and a common language to every system administrator. No deep programming language is needed to be able to contribute.
The first part when developing, is understanding the structure of the project.
The most important files, like the Lynis script can be found in the root of the directory, together with the man page and documentation.
The directory is named "include", as more intelligence is included (or sourced) by the main script. It includes important functions, initializes variables, and shows the report. Also the individual tests are stored in this directory. So 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.
- Identitation is done with 4 spaces (no tabs)
- Variables are capitalized, optional with an underscore to "split" words
If you use Git already, simply clone the project to your local system. Otherwise work with a local copy. At the GitHub page you can download the master.zip file, containing the latest master release.
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.
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.