79 lines
2.6 KiB
Markdown
79 lines
2.6 KiB
Markdown
# 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 Beginners guide. If you need to create
|
|
additional modules to meet your needs, consider reading the Developers 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.
|
|
|
|
### 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 introduice any platform dependent
|
|
code.
|
|
|
|
In the following exemple @template@ have to be replaced par le nom de votre
|
|
module qui doit être nomé @template@.sh. Vous pouvez automatiquement créer votre
|
|
nouveau module avec la commande suivante :
|
|
|
|
```shell
|
|
sed -e "s/@template@/nom_module/g" -e "/^# .*/d" -e "s/^##/# /" template > \
|
|
nom_module.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.
|
|
|
|
```shell
|
|
# Description @template@ module
|
|
|
|
# Modiule 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@
|
|
```
|
|
|