init.sh

init.sh is an automated configurator for system administrator. It's fully written using Bash scripting and aims to be platform independent. Nevertheless, it's requirements turns it naturally to Linux systems. It have long been tested using Debian GNU/Linux, Devuan and different flavor of Ubuntu.

Getting started

You should consider reading the Beginner's guide. If you need to create additional modules to meet your needs, consider reading the Developer's guide.

Please also consider that your needs might meet the needs of someone else, thus it would be a good idea to submit your module to init.sh source base.

Design

init.sh relies on three different elements to work:

the init.sh script, which provide a simple framework and libraries to do simple taks and embed system dependent functions to provide system independent function calls.
modules that actually do the job on a system independant way through the use of the framework and consisting on very small and simple task.
multilevel configuration files, being simply Bash variables declaration.

Additionally some module might be ran regularly so it could be integrated in a cron-like service.

Main configuration file

Writing in progress.

Naming conventions

Because of internal mechanics the dash character is forbidden in module names. Thus Bash language also forbid that character in variable name.

An other limit is, even if digits are allowed in module names and variable, they can't be used as a leading character or worse the full name being only made of digits. You can use as many digits you want in names but with at least a leading alphabetical (or underscore) character, whatever the case of that character will be.

You can use upper case and lower case as you wish, with underscore character, even as leading character. Any other special character than alphanumerical or underscore is completely forbidden.

Any submitted module to the central repository will have module name in lower case with underscore to separate words and ease reading, and variable name upper case with the same underscore as word separator.

Basic module structure

Please note that modules are not supposed to contain any specific code for a platform or a distribution even if nothing block you doing so. It is highly recommended to use configurations files to introduce any platform dependent code.

In the following exemple @template@ have to be replaced with the name of your module with the filename @template@.sh. You can automatically create your new module with the following command:

sed -e "s/@template@/module_name/g" -e "/^# .*/d" -e "s/^##/# /" template > \
    module_name.sh

Versionning modules is up to you but the recommended behavior follows somme standard rules. Considering a numbering as x.y.z:

x might be incremented in case of major change, rewriting or deferent approach on the way to have the job done
y might be incremented in case simple finctionnality addition or basic improvements
z might be incremented only when correcting problems and/or bugs (+n fix => +n increment)

Unless only configuration files have been changed, any change in the code implies any increment of a version number in the code and a git commit.

# Description @template@ module

# Module version
export VER_@template@="0.0.1"

# Module main code
@template@()
{
    # Code
}

# Pre-run checks code
precheck_@template@()
{
    # Code
}

# Any public fonction have to be exported
export -f @template@
export -f precheck_@template@

Command line

The init.sh script allows some command line parameters and some environement variables to change it's behaviour.

The parameters are:

-m <list>, --module=<list>: Allows to manually give a module list and overide the MODULE_LIST variable declaration. The list is a comma separated module name. If that option is provided, the module list is mandatory.
-c, --check-only: Do not launch any actions, only the checks are launched. In that situation, no change should be done to the system.
-j, --jump: Jump the checks and goes directly to system transformation. That option should only be run after successfull checks (eg. after using the --checkonly option).
-k, --keep-going: The scripts will continue even if errors occurs. Thus some unrecoverable errors might stop the script anyway if it not allowing it to work.

4.4 KiB Raw Blame History