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

updated README.md, added to do list, fixed separator length, version info swith to english

Browse Source
This commit is contained in:
levasseur
2021-11-26 17:30:18 +01:00
parent 6db50b3d69
commit c978eb1ef8
4 changed files with 87 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
README.md
View File

@@ -15,8 +15,9 @@ using Debian GNU/Linux, Devuan and different flavors of Ubuntu.
- [3.5. Basic module structure](#35-basic-module-structure)
- [4. Error code table](#4-error-code-table)
- [5. Contact and more information](#5-contact-and-more-information)
- [5.1. How to contribute?](#51-how-to-contribute)
- [5.2. Website and maintainor](#52-website-and-maintainor)
- [5.1. New users](#51-new-users)
- [5.2. How to contribute?](#51-how-to-contribute)
- [5.3. Website and maintainor](#52-website-and-maintainor)
## 1. Getting started
You should consider reading that document entirely before use. If you need
@@ -29,10 +30,10 @@ it would be a good idea to submit your module to init.sh source base.
## 2. Why init.sh?
Short answer: why not?
Long answer: Even if I vallue 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, or if you need something fast to deploy and adapt to
your needs, such big tools are somehow overkill.
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.
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
@@ -40,12 +41,12 @@ hardcoded monolitic scripts where I had to rewritte 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.
to publish and share that work, in the hope I can be usefull.
## 3. Design
**init.sh** relies on three different elements to work:
- the ```init.sh``` script, which provide a simple framework and libraries to do
- the ```init.sh``` script and libraries, which provide a simple framework 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
@@ -127,6 +128,13 @@ 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 esecution environment. If the
```--shell``` command line option is given, the subshell 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
@@ -174,7 +182,7 @@ of OS detection:
| **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.x kernel branch). |
| **codename**| ```SYS_CODE``` | If your distribution profide a version codename, it will be set with it. |
| **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:
1. arch.conf.sh
@@ -205,16 +213,16 @@ 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.
case (except local variables) with the same underscore as word separator.
### 3.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).
recommended to use automatic configurations files to introduce any platform
dependent code and variables. 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
@@ -226,11 +234,13 @@ 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. Considering a numbering as x.y.z:
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
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;
change and jeoppardy compatibility;
- 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
@@ -254,27 +264,39 @@ implies an increment of a version number in the code **and** a git commit.
# Module version
export VER_@template@="0.0.1"
# Module dependencies (contains other module names if dependencies exists)
export DEPS_@template@=""
# Module main code
@template@()
{
# Code
: # Code
}
# Pre-run checks code
precheck_@template@()
{
# Code
: # Code
}
# Optionnaly, cron mode code
cron_@template@()
{
: # Code
}
# Any public fonction have to be exported
export -f @template@
export -f precheck_@template@
# If cron_@template@ exists :
export -f cron_@template@
```
Unexported template function will work but won't be available in the integrated
debugging shell (see ```--shell``` option).
debugging shell (see ```--shell``` option), so it's not encouraged.
An optionnal ```cron_@template@``` function allows you to define code that will
The optionnal ```cron_@template@``` function allows you to define code that will
be executed in cron mode. Check [cron documentation](./doc/cron.md) for more
details.
@@ -315,23 +337,35 @@ provided module, please contact the author. Of course, if you also have a patch,
your mail will be even more welcomed!
## 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.
### 5.1. How to contribute?
If you want to contribute, the best is to use git and push your changes in a
branch you made for that purpose. If you want to submit a patch, you can send it
by mail to the maintainor of init.sh.
### 5.2. 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),
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.
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.
Code written in Python or Perl might be accepted as long as it's not mobilizing
a lot of dependencies (forget big framework). Core script will remain in Bash
whatever the evolutions of init.sh will be.
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.
### 5.2. Website and maintainor
Everything except configuration files are licensed under BSD-3 license. Please
check license file.
### 5.3. License, website and maintainor
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