fatalerrors/init.sh
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
2859cbfc676847db1618718e3229283c1e714c3e
init.sh/README.md
levasseur 33da21dfe2 updated documentation
2021-10-08 17:35:39 +02:00

295 lines
14 KiB
Markdown
Raw Blame History

# init.sh
**init.sh** is an automated configurator for system administrators. It's fully
written using Bash scripting and aims to be platform independent. Nevertheless,
its requirements turn it naturally to Linux systems. It has long been tested
using Debian GNU/Linux, Devuan and different flavors of Ubuntu.
## Table of content
- [init.sh](#initsh)
- [1. Getting started](#1-getting-started)
- [2. Design](#2-design)
- [2.1. Command line](#21-command-line)
- [2.2. Loading order and process](#22-loading-order-and-process)
- [2.3. Configuration files](#23-configuration-files)
- [2.3.1. Main configuration file](#231-main-configuration-file)
- [2.3.2. Automatically loaded configuration files](#232-automatically-loaded-configuration-files)
- [2.4. Naming conventions](#24-naming-conventions)
- [2.5. Basic module structure](#25-basic-module-structure)
- [3. Error code table](#3-error-code-table)
- [4. Contact and more information](#4-contact-and-more-information)
## 1. Getting started
You should consider reading that document entirely before use. If you need
to create additional modules to meet your needs, consider reading the
[Developer's guide](./doc/dev.md).
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.
## 2. Design
**init.sh** relies on three different elements to work:
- the init.sh script, which provide a simple framework and libraries to do
simple tasks and embed system dependent functions to provide system independent
function calls.
- modules that actually do the job, as possible on a system independent way
through the use of the framework and consisting of very small and simple tasks.
- multilevel configuration files, being simply Bash variables declaration.
Additionally, some module might be run regularly, so it could be integrated in a
cron-like service.
### 2.1. Command line
The **init.sh** script allows some command line parameters and some environment
variables to change its behavior.
The parameters are:
- **-f \<file\>, --file \<file\>**: Allows specifying which configuration file
to load manually. That option can be repeated to allow the loading of multiple
configuration file, the last overloading the previously defined ones in case of
identical variable name.
- **-m \<list\>, --module \<list\>**: Allows to manually give a module list and
override 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 successful checks (e.g. after using the
\--check-only option).
- **-k, --keep-going**: The scripts will try to continue even if errors occurs.
Thus, some unrecoverable errors might stop the script anyway if it's not
allowing it to work. Please use with care as it might lead to unexpected
results.
- **-r, --resume**: Restart an interrupted process with the last executed module
that failed.
- **-R, --no-root-check**: Disable checks on root rights (or the 0 UID).
- **-D, --no-deps**: Disable module dependencies checks.
- **-P, --no-proxy**: Do not hot apply proxy setting to the running system even
if system proxy is set in configuration files.
- **-h, --help**: Display information on command line usage.
- **-s, --shell**: Launch a shell with entire script's environment for
debugging purpose. No action or modification is made to the system unless you
launch commands manually doing some.
- **-l, --logfile**: Specify a custom name for the log file. Standard log file
is named init-hostname-date-time.log in the log subdirectory. That file can also
be customized using the LOGFILE environment variable.
- **-v, --version**: Display version information, including available module
list and their version.
The options cannot be concatenated like most of Unix binaries allows. For
example you cannot write "*-rR*", you have to write "*-r -R*".
### 2.2. Loading order and process
The first thing the script do is loading its libraries contained in the "*lib*"
directory. Any file situated in that directory ending with the .sh extension
will be loaded in alphabetical order. For that reason, error management
functions are placed in a file called aaa_error.sh, so it can be loaded first
and catch errors that could occur while loading other library files. In the
opposite the zzz_main_fct.sh file have to be loaded last, because it's widely
using previously declared libraries.
After that, a basic command line parameter treatment is done. That allows the
use of *--version* and *--help* options in user space. Those options display
information and don't require any superuser rights and exit at that point of
execution. Everything after that will require administrator rights and the
script will exit with error at that point if not superuser, unless the
*--no-root-check* option have been given.
Next will be the log file creation and the loading of configuration files.
Configuration files exists in two distinct categories. First system dependant
configuration will be loaded automatically depending on your platform, then
your own configuration. At this point a deeper analysis of command line option
will be done, triggering errors in case of inconsistency or incompatible
options.
Finally, checking processes are launched in their declaration order (cf.
configuration file). A module depency check is made prior to the module specific
checks unless the *--no-deps* option is given or if a manual module list have
been transmited. If no error occurs and after a confirmation prompt, final
treatment processes, those that actually makes changes, are launched.
Without the *--keep-going* option, any error will immediately stop execution.
Some errors that could make the script impossible to execute will stop
execution, even if the *--keep-going* option is provided.
### 2.3. Configuration files
#### 2.3.1. Main configuration file
The main configuration file can be two different files. Either it's completely
generic and will be named **init.conf.sh** in the "conf" directory, either it
will be named after the current hostname of the computer in that same "conf"
directory. Please remember that the actual name will be used until the end of
the execution of init.sh. If one of your module change the hostname, the new
name can only be taken into account after a new execution of init.sh.
Most of the variable you can declare to configure your host depends on the
module you will use. Please refer to module header to see what's available for
your use case.
After a module version upgrade, you should check again headers as variable name
or structure might change. A variable can also be deleted, new variables could
appears, and so on.
It is heavily recommended to use includes technique to shorten your
configuration file and make a file for your organization and another one
for the Linux distribution you use. Remember that the declaration order matters,
so you can declare something on your organization configuration file and
supersede it in your host configuration file. The only limit will be Bash
capabilities in terms of variable manipulation.
#### 2.3.2. Automatically loaded configuration files
Those file are basically the system dependent part that assure compatibility
with different Linux distributions. Some of those files are shipped with
init.sh but you can add what you want to improve possibilities or to add support
for a new distribution. init.sh understand the following possibilities in terms
of OS detection:
| Name | Variable | |
|:------------|:---------|:----------------------------------------------------|
| **arch** | SYS_ARCH | This is the system architecture, like x86_64, i386, arm64, etc. |
| **dist** | SYS_DIST | The name of the Linux distribution as reported by */etc/os-release*. |
| **version** | SYS_VER | Version of the distribution. If you run a rolling release and no version is provided by your */etc/os-release* file, the main version of the Linux kernel will be used (e.g. 5.4 for any version of 5.4. kernel branch). |
| **codename**| SYS_CODE | If your distribution profide a version codename, it will be set with it. |
The configuration files are loaded if exists in the following order:
1. arch.conf.sh
2. distro.conf.sh
3. distro-arch.conf.sh
4. distro-version.conf.sh
5. distro-codename.conf.sh (if *$SYS_CODE* defined)
6. distro-version-arch.conf.sh
7. distro-codename-arch.conf.sh (if *$SYS_CODE* defined)
The loading of those files, if one exists, cannot be avoided. They all must be
located in the *conf/auto* directory of the init.sh tree.
### 2.4. Naming conventions
Because of internal mechanics, the dash character is forbidden in module names.
Thus, Bash language also forbid that character in variable name.
Another 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.
### 2.5. 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. Additionally, it will be possible to create system dependent modules using
naming convention in the style module_name.debian.x86_64.sh (awaited for version
2 of init.sh).
In the following example, @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:
```shell
sed -e "s/@template@/module_name/g" -e "/^# .*/d" -e "s/^##/# /" template > \
module_name.sh
```
Versioning modules is up to you, but the recommended behavior follows some
standard rules. Considering a numbering as x.y.z:
- x might be incremented in case of major change, rewriting or different
approach on the way to have the job done, the used variable could massively
change;
- y might be incremented in case of simple functionality addition or basic
improvements, existing variable might not change, but new ones could appear;
- z might be incremented only when correcting problems and/or bugs (+n fix ⇒ +n
to increment), variable should not change unless this is the only way to fix a
problem.
Unless only configuration files have been changed, any change in the code
implies an increment of a version number in the code **and** a git commit.
```shell
# ------------------------------------------------------------------------------
# Description @template@ module
# Copyright (c) Year Your Name <your.mail@host.tld>
# ------------------------------------------------------------------------------
# <Licence header compatible with BSD-3 licence, you want to use>
# ------------------------------------------------------------------------------
# Variable list:
# * <VARNAME>: role explaination
# ------------------------------------------------------------------------------
# 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@
```
Unexported template function will work but won't be available in the integrated
debugging shell (see --shell option).
## 3. Error code table
The following table is giving a list of error code with explanation:
| Code | Meaning |
|:----------|:------------------------------------|
| 0 | No error |
| 1 | Command line syntax error |
| 2 | Misuse of Bash built-in |
| 3 | Missing library file or function |
| 4 | No root rights |
| 5 | Malformed module list |
| 6 | Unable to find configuration |
| 7 | Misuse of script internal function |
| 8 | Can't determine OS version |
| 9 | Unsatisfied dependency |
| 11 | Bad function call |
| 12 | Error copying files |
| 13 | Bad target file system |
| 50..100 | Error in module execution |
| 126 | Command exists but not executable |
| 127 | Command not found |
| 128 | Abortion due to external cause |
| 150..200 | Error in module checks |
| 255 | Exit status out of range |
Additionally to exit codes, the script will try to produce a call stack to help
you in the debugging process. If you find a bug outside modules or in the basic
provided module, please contact the author. Of course, if you also have a patch,
your mail will be even more welcomed!
## 4. Contact and more information
Everything except configuration files are licensed under BSD-3 license. Please
check license file.
Please check [https://www.geoffray-levasseur.org/init](https://www.geoffray-levasseur.org/init)
You can mail author to fatalerrors \<at\> geoffray-levasseur \<dot\> org
Reference in New Issue View Git Blame Copy Permalink