fatalerrors/init.sh
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

bump to version 0.99.18

Browse Source
This commit is contained in:
fatalerrors
2022-06-24 17:52:17 +02:00
parent e8c6f46572
commit da37fd3bae
52 changed files with 1268 additions and 435 deletions
Download Patch File Download Diff File Expand all files Collapse all files

176
README.md
View File

@@ -1,8 +1,8 @@
# 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.
**init.sh** is an automated configuratinon software 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)
@@ -33,26 +33,27 @@ Short answer: why not?
Long answer: Even if I value tools like Puppet or Ansible, I always thought that
such great and complex systems are very nice for big infrastructures. But, on a
much smaller scale like small business, or if you need something fast to deploy
and easy to adapt to your needs, such great tools are somehow overkill.
much smaller scale like small business, or if you require something fast to
deploy and easy to adapt to your needs, such great tools are somehow
overkilling.
I wanted something simple and as universal as possible to manage many different
unique servers in my small local foundations. I started with a lot of long
hardcoded monolitic scripts where I had to rewritte many things on every new
I wanted something simple and as universal as possible to manage many unique
servers in my small local foundations. I started with a lot of long hard-coded
monolithic scripts where I had to rewrite many things on every new
infrastructures I wanted to manage. As it was a fastidious job, I started to
rewritte and redesign everything with a common architecture and code, modular
and easily adaptative. As I don't know any tools in that market scale, I decided
to publish and share that work, in the hope it can be usefull.
and easily adaptive. As I don't know any tools in that market scale, I decided
to publish and share that work, in the hope it can be useful.
## 3. Design
**init.sh** relies on three different elements to work:
- the ```init.sh``` script and libraries, which provide a simple framework to do
- The ```init.sh``` script and libraries, which provide a simple framework to do
simple tasks and embed system dependent tools 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.
- 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 using the provided cron mode with the benefits of ```init.sh```
@@ -75,7 +76,7 @@ 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
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
@@ -85,14 +86,14 @@ results.
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
- **-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.
- **--chroot \<path\>**: Allows you to apply init.sh test or modification on a non
running system, mounted in the given path.
- **--chroot \<path\>**: Allows you to apply init.sh test or modification on a
non-running system, mounted in the given path.
- **--cron**: execute init.sh in cron mode. Check [cron subsystem
documentation](./doc/cron.md)
for more details.
@@ -103,7 +104,7 @@ be customized using the ```LOGFILE``` environment variable.
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```.
example, you cannot write ```-rR```, you have to write ```-r -R```.
### 3.2. Loading order and process
@@ -111,40 +112,38 @@ 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.
and catch errors that could occur while loading other library files.
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
After that, a basic command line parameter treatment will be 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.
```--no-root-check``` option was 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 files exist in two distinct categories. First system dependent
configuration will be loaded automatically depending on your platform, then
your own configuration. At this point a deeper analysis of command line option
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.
After that all the configured modules with the ```$MODULE_LIST``` variable are
loaded to be availble for execution. Note that even function that might not be
used will be loaded. At this point everything that will be necessary for checks
and modification will be available in the scripts execution environment. If the
```--shell``` command line option is given, the subshell is loaded just after
After that, all the configured modules with the ```$MODULE_LIST``` variable are
loaded to be available for execution. Note that even function that might not be
used will be loaded. At this point, everything that will be necessary for checks
and modification will be available in the scripts' execution environment. If the
```--shell``` command line option was given, the sub-shell is loaded just after
this point.
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
configuration file). A module dependency check is made prior to the module specific
checks unless the ```--no-deps``` option was given or if a manual module list
was transmitted. 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.
execution, even if the ```--keep-going``` option was provided.
### 3.3. Configuration files
#### 3.3.1. Main configuration file
@@ -162,21 +161,21 @@ 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.
appear, 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
so you can declare something in your organization configuration file and
supersede it in your host configuration file. The only limit will be Bash
capabilities in terms of variable manipulation.
#### 3.3.2. Automatically loaded configuration files
Those file are basically the system dependent part that assure compatibility
Those files 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:
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 | Description |
|:------------|:---------------|:----------------------------------------------|
@@ -185,14 +184,14 @@ of OS detection:
| **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.x kernel branch). |
| **codename**| ```SYS_CODE``` | If your distribution provide a version codename, it will be set with it, elsewhere it will remain unset. |
The configuration files are loaded if exists in the following order:
The configuration files loads 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 (only if ```$SYS_CODE``` is defined)
5. distro-codename.conf.sh (only if ```$SYS_CODE``` defined)
6. distro-version-arch.conf.sh
7. distro-codename-arch.conf.sh (only if ```$SYS_CODE``` is defined)
7. distro-codename-arch.conf.sh (only 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.
@@ -203,10 +202,10 @@ 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.
can't be used as a leading character or worse the full name 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
@@ -236,30 +235,30 @@ sed -e "s/@template@/module_name/g" -e "/^# .*/d" -e "s/^##/# /" template > \
Versioning modules is up to you, but the recommended behavior follows some
standard rules, not artificially increasing version numbers in a stupid fight of
who will have the biggest like Google or Firefox. Considering a numbering as
who will have the biggest, like Google or Firefox. 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 and jeoppardy compatibility;
- y might be incremented in case of simple functionality addition or basic
- x might increment in case of major change, rewriting or different approach on
the way to have the job done, the used variable could massively change and
jeopardy compatibility;
- y might increment 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
- z might increment 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.
Unless only configuration files has 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>
# <License header compatible with BSD-3 license, you want to use>
# ------------------------------------------------------------------------------
# Variable list:
# * <VARNAME>: role explaination
# * <VARNAME>: role explanation
# ------------------------------------------------------------------------------
# Module version
@@ -280,13 +279,13 @@ precheck_@template@()
: # Code
}
# Optionnaly, cron mode code
# Optionnally, cron mode code
cron_@template@()
{
: # Code
}
# Any public fonction have to be exported
# Any public function have to be exported
export -f @template@
export -f precheck_@template@
@@ -294,17 +293,17 @@ export -f precheck_@template@
export -f cron_@template@
```
Unexported template function will work but won't be available in the integrated
debugging shell (see ```--shell``` option), so it's not encouraged.
Unexported template function will not work as any module execute in a sub-shell
in order to protect ```init.sh``` script environment.
The optionnal ```cron_@template@``` function allows you to define code that will
The optional ```cron_@template@``` function allows you to define code that will
be executed in cron mode. Check [cron documentation](./doc/cron.md) for more
details.
## 4. Error code table
The following table is giving a list of error code with explanation:
The following table is giving a list of error codes with explanation:
| Code | Meaning |
|:----------|:------------------------------------------------------------|
@@ -344,55 +343,56 @@ how to solve problems.
## 5. Contact and more information
### 5.1. New users
As this project is very new and as I have no idea of who will use it, if you do
so, I'll be very happy if you simply mail me to let me know, especially if you
don't plan to contribute.
This project is very new in terms of publication, and I have no idea of who will
use it, if any does. If you use (or plan to use) ```init.sh```, I'll be very
happy if you simply mail me to let me know, especially if you don't plan to
contribute. If you plan to contribute, I'll be twice happier for sure!
### 5.2. Bugs
**init.sh** have no bug tracker yet. For now, if you find a bug, please submit a
bug report to the maintenor mentionned at the end of that document. A bug report
bug report to the maintainer mentioned at the end of that document. A bug report
may contain the command line parameters where the bug happens, OS details,
the module that trigger it if any, and the log file containing the error.
the module that trigger it, if any, and the log file containing the error.
Please check the to do list before sending any report as the problem might
Please check the to-do list before sending any report, as the problem might
already be known.
### 5.3. How to contribute?
You are free to improve and contribute as you wish. If you have no idea what to
do or want some direction, you can check the [to do list](./doc/todo.md),
do or want some direction, you can check the [to-do list](./doc/todo.md),
containing desired future improvements. Make sure you always have the latest
development version before starting your work.
It's heavily recommended to use git to obtain latest copy of init.sh tree. Make
sure your git is configured for contribution. Please contact me to obtain push
authorisations, or, if you want to submit a patch, you can send it by mail to
the maintainor of init.sh.
It's heavily recommended to use git to obtain the latest copy of init.sh tree.
Make sure your git configuration is correct in order to contribute. Please
contact me to obtain push authorizations, or, if you want to submit a patch, you
can send it by mail to the maintainer of init.sh.
You can improve anything you want, but keep in mind init.sh have to stay small
and simple. If your idea cannot be written using Bash scripting, maybe that
means you're going to far in the improvement.
means you're going too far in the improvement.
Code written in Python or Perl might be accepted as long as it's not mobilizing
a lot of dependencies (forget big framework). Anything that need installing
packages not provided in minimal Debian installation will be rejected. Anyway,
core scripts will remain in Bash whatever the evolutions of ```init.sh``` will
be.
a lot of dependencies (forget big framework). Anything that need the
installation of packages not provided in minimal Debian installation will be
rejected in the libraries. For module, the KISS philosophy is the one promoted.
Anyway, core scripts will remain in Bash whatever the evolutions of
```init.sh``` will be.
If you want to make a financial contribution, please contact me by mail.
### 5.4. License, website and maintainor
### 5.4. License, website, and maintainer
Everything except configuration files is licensed under BSD-3 license. Please
check license file allong this one.
Please check [https://www.geoffray-levasseur.org/init](https://www.geoffray-levasseur.org/init).
Please note that this website is still under construction and needs some more
care.
Note that this website is still under construction and needs some more care.
You can mail author to fatalerrors \<at\> geoffray-levasseur \<dot\> org.
-----------------------------------------------------------------------------
Documentation (c) 2019-2021 Geoffray Levasseur.
Documentation (c) 2019-2022 Geoffray Levasseur.
This file is distributed under3-clause BSD license. The complete license
agreement can be obtained at: https://opensource.org/licenses/BSD-3-Clause