dev.md: updated documentation
This commit is contained in:
464
doc/dev.md
464
doc/dev.md
@@ -1,73 +1,80 @@
|
||||
# init.sh developer's reference
|
||||
|
||||
## Table of content
|
||||
- [1. Getting started](#1-getting-started)
|
||||
- [2. The aaa_error.sh file](#2-the-aaa_errorsh-file)
|
||||
- [2.1. Functions](#21-functions)
|
||||
- [2.1.1. ```check_root```](#211-check_root)
|
||||
- [2.1.2. ```die <exitcode> [--force]```](#212-die-exitcode---force)
|
||||
- [2.1.3. ```noerror [--noout] <command>```](#213-noerror---noout-command)
|
||||
- [2.2. Other functionalities](#22-other-functionalities)
|
||||
- [3. The display.sh file](#3-the-displaysh-file)
|
||||
- [3.1. Functions](#31-functions)
|
||||
- [3.1.1. ```prnt [-n] [I|W|E|m] <message>```](#311-prnt--n-iwem-message)
|
||||
- [3.1.2. ```separator```](#312-separator)
|
||||
- [3.1.3. ```dsleep <miliseconds> [char]```](#313-dsleep-miliseconds-char)
|
||||
- [3.1.4. ```dump_key_buffer```](#314-dump_key_buffer)
|
||||
- [3.2. Other functionalities](#32-other-functionalities)
|
||||
- [4. The filefct.sh file](#4-the-filefctsh-file)
|
||||
- [4.1. Common behavior](#41-common-behavior)
|
||||
- [4.2. Functions](#42-functions)
|
||||
- [4.2.1. ```backupdist <list_of_files_or_dirs>```](#421-backupdist-list_of_files_or_dirs)
|
||||
- [4.2.2. ```installfile <sources> <destination>```](#422-installfile-sources-destination)
|
||||
- [4.2.3. ```appendfile <source> <destination>```](#423-appendfile-source-destination)
|
||||
- [4.2.4. ```isdirempty <directory>```](#424-isdirempty-directory)
|
||||
- [4.2.5. ```patch_file <source> <destination> [VAR1 [VAR2 ...]]```](#425-patch_file-source-destination-var1-var2-)
|
||||
- [4.2.6. ```tagfile <list_of_files>```](#426-tagfile-list_of_files)
|
||||
- [4.2.7. ```file_exists <list_of_files>```](#427-file_exists-list_of_files)
|
||||
- [4.3. Other functionnalities](#43-other-functionnalities)
|
||||
- [5. The pkgman.sh file](#5-the-pkgmansh-file)
|
||||
- [5.1. Global dependencies](#51-global-dependencies)
|
||||
- [5.2. Functions](#52-functions)
|
||||
- [5.2.1. ```pkgupdt```](#521-pkgupdt)
|
||||
- [5.2.2. ```pkginst <package_list>```](#522-pkginst-package_list)
|
||||
- [5.2.3. ```pkgupgd```](#523-pkgupgd)
|
||||
- [5.2.4. ```pkgrm <package_list>```](#524-pkgrm-package_list)
|
||||
- [5.2.5. ```pkgautorm```](#525-pkgautorm)
|
||||
- [5.3. Other functionnalities](#53-other-functionnalities)
|
||||
- [6. The services.sh file](#6-the-servicessh-file)
|
||||
- [6.1. Global dependencies](#61-global-dependencies)
|
||||
- [6.2. Functions](#62-functions)
|
||||
- [6.2.1. ```exec_serv <service> <command>```](#621-exec_serv-service-command)
|
||||
- [6.2.2. ```svc_start <service1> [service2 ... serviceN]```](#622-svc_start-service1-service2--servicen)
|
||||
- [6.2.3. ```svc_reload <service1> [service2 ... serviceN]```](#623-svc_reload-service1-service2--servicen)
|
||||
- [6.2.2. ```svc_restart <service1> [service2 ... serviceN]```](#622-svc_restart-service1-service2--servicen)
|
||||
- [6.2.3. ```svc_stop <service1> [service2 ... serviceN]```](#623-svc_stop-service1-service2--servicen)
|
||||
- [7. The support.sh file](#7-the-supportsh-file)
|
||||
- [7.1. Global behaviour](#71-global-behaviour)
|
||||
- [7.2. Functions](#72-functions)
|
||||
- [7.2.1. ```disp_help```](#721-disp_help)
|
||||
- [7.2.2. ```show_version```](#722-show_version)
|
||||
- [7.3. Other functionnalities](#73-other-functionnalities)
|
||||
- [8. The utils.sh file](#8-the-utilssh-file)
|
||||
- [8.1. Functions](#81-functions)
|
||||
- [8.1.1. ```stdtime```](#811-stdtime)
|
||||
- [8.1.2. ```function_exists <function_name>```](#812-function_exists-function_name)
|
||||
- [8.1.3. ```get_mod_name <module_file>```](#813-get_mod_name-module_file)
|
||||
- [8.1.4. ```set_system_proxy```](#814-set_system_proxy)
|
||||
- [8.2. Other functionnalities](#82-other-functionnalities)
|
||||
- [9. The version.sh file](#9-the-versionsh-file)
|
||||
- [9.1. Functions](#91-functions)
|
||||
- [9.1.1. ```get_os_version```](#911-get_os_version)
|
||||
- [9.1.2. ```set_sys_var <arch> <dist> <version> <codename>```](#912-set_sys_var-arch-dist-version-codename)
|
||||
- [10. The zzz_main_fct file](#10-the-zzz_main_fct-file)
|
||||
- [10.1. Functions](#101-functions)
|
||||
- [10.1.1. ```read_commandline```](#1011-read_commandline)
|
||||
- [10.1.2. ```chroot_bootstrap```](#1012-chroot_bootstrap)
|
||||
- [10.1.3. ```load_autoconf```](#1013-load_autoconf)
|
||||
- [10.1.4. ```load_configuration```](#1014-load_configuration)
|
||||
- [10.1.5. ```process_commandline_and_vars```](#1015-process_commandline_and_vars)
|
||||
|
||||
- [1. Getting started](#1-getting-started)
|
||||
- [2. The aaa_error.sh file](#2-the-aaa_errorsh-file)
|
||||
- [2.1. Functions](#21-functions)
|
||||
- [2.1.1. ```check_root```](#211-check_root)
|
||||
- [2.1.2. ```die <exitcode> [--force]```](#212-die-exitcode---force)
|
||||
- [2.1.3. ```noerror [--noout] <command>```](#213-noerror---noout-command)
|
||||
- [2.2. Other functionalities](#22-other-functionalities)
|
||||
- [3. The chroot.sh file](#3-the-chrootsh-file)
|
||||
- [3.1. Functions](#31-functions)
|
||||
- [3.1.1. ```chroot_bootstrap```](#311-chroot_bootstrap)
|
||||
- [3.2. Other functionnalities](#32-other-functionnalities)
|
||||
- [4. The diskman.sh file](#4-the-diskmansh-file)
|
||||
- [4.1. Function](#41-function)
|
||||
- [4.2. Other functionnalities](#42-other-functionnalities)
|
||||
- [5. The command_line.sh file](#5-the-command_linesh-file)
|
||||
- [5.1. Functions](#51-functions)
|
||||
- [5.1.1. ```read_commandline```](#511-read_commandline)
|
||||
- [5.1.5. ```process_commandline_and_vars```](#515-process_commandline_and_vars)
|
||||
- [6. The display.sh file](#6-the-displaysh-file)
|
||||
- [6.1. Functions](#61-functions)
|
||||
- [6.1.1. ```prnt [-n] [I|W|E|m] <message>```](#611-prnt--n-iwem-message)
|
||||
- [6.1.2. ```separator```](#612-separator)
|
||||
- [6.1.3. ```dsleep <miliseconds> [char]```](#613-dsleep-miliseconds-char)
|
||||
- [6.1.4. ```dump_key_buffer```](#614-dump_key_buffer)
|
||||
- [6.2. Other functionalities](#62-other-functionalities)
|
||||
- [7. The filefct.sh file](#7-the-filefctsh-file)
|
||||
- [7.1. Common behavior](#71-common-behavior)
|
||||
- [7.2. Functions](#72-functions)
|
||||
- [7.2.1. ```backup_dist <file_or_dir1> [file_or_dir2 [... file_or_dirN]] ```](#721-backup_dist-file_or_dir1-file_or_dir2--file_or_dirn-)
|
||||
- [7.2.2. ```select_file <filename>```](#722-select_file-filename)
|
||||
- [7.2.2. ```install_file <source1> [source2 [... sourceN]] <destination>```](#722-install_file-source1-source2--sourcen-destination)
|
||||
- [7.2.3. ```append_file <source> <destination>```](#723-append_file-source-destination)
|
||||
- [7.2.4. ```is_dir_empty <directory>```](#724-is_dir_empty-directory)
|
||||
- [7.2.5. ```patch_file <source> <destination> [VAR1 [VAR2 [... VARN]]]```](#725-patch_file-source-destination-var1-var2--varn)
|
||||
- [7.2.6. ```tag_file <file1> [file2 [... fileN]]```](#726-tag_file-file1-file2--filen)
|
||||
- [7.2.7. ```file_exists <file1> [file2 [... fileN]]```](#727-file_exists-file1-file2--filen)
|
||||
- [7.2.8. ```file_must_exists <file1> [file2 [... fileN]]```](#728-file_must_exists-file1-file2--filen)
|
||||
- [7.2.9. ```directory_exists <directory1> [directory2 [... directoryN]]```](#729-directory_exists-directory1-directory2--directoryn)
|
||||
- [7.2.10. ```directory_must_exists <directory1> [directory2 [... directoryN]]```](#7210-directory_must_exists-directory1-directory2--directoryn)
|
||||
- [7.3. Other functionnalities](#73-other-functionnalities)
|
||||
- [8. The loaders.sh file](#8-the-loaderssh-file)
|
||||
- [8.1. Functions](#81-functions)
|
||||
- [8.1.3. ```load_autoconf```](#813-load_autoconf)
|
||||
- [8.1.4. ```load_configuration```](#814-load_configuration)
|
||||
- [8.2. Other functionnalities](#82-other-functionnalities)
|
||||
- [9. The pkgman.sh file](#9-the-pkgmansh-file)
|
||||
- [9.1. Global dependencies](#91-global-dependencies)
|
||||
- [9.2. Functions](#92-functions)
|
||||
- [9.2.1. ```pkgupdt```](#921-pkgupdt)
|
||||
- [9.2.2. ```pkginst <package1> [package2 [... packageN]]```](#922-pkginst-package1-package2--packagen)
|
||||
- [9.2.3. ```pkgupgd```](#923-pkgupgd)
|
||||
- [9.2.4. ```pkgrm <package1> [package2 [... packageN]]```](#924-pkgrm-package1-package2--packagen)
|
||||
- [9.2.5. ```pkgautorm```](#925-pkgautorm)
|
||||
- [9.3. Other functionnalities](#93-other-functionnalities)
|
||||
- [10. The services.sh file](#9-the-servicessh-file)
|
||||
- [10.1. Global dependencies](#101-global-dependencies)
|
||||
- [10.2. Functions](#102-functions)
|
||||
- [10.2.1. ```exec_serv <service> <command>```](#1021-exec_serv-service-command)
|
||||
- [10.2.2. ```svc_start <service1> [service2 ... serviceN]```](#1022-svc_start-service1-service2--servicen)
|
||||
- [10.2.3. ```svc_reload <service1> [service2 ... serviceN]```](#1023-svc_reload-service1-service2--servicen)
|
||||
- [10.2.2. ```svc_restart <service1> [service2 ... serviceN]```](#1022-svc_restart-service1-service2--servicen)
|
||||
- [10.2.3. ```svc_stop <service1> [service2 ... serviceN]```](#1023-svc_stop-service1-service2--servicen)
|
||||
- [11. The support.sh file](#11-the-supportsh-file)
|
||||
- [11.1. Global behaviour](#111-global-behaviour)
|
||||
- [11.2. Functions](#112-functions)
|
||||
- [11.2.1. ```disp_help```](#1121-disp_help)
|
||||
- [11.2.2. ```show_version```](#1122-show_version)
|
||||
- [11.3. Other functionnalities](#113-other-functionnalities)
|
||||
- [12. The utils.sh file](#12-the-utilssh-file)
|
||||
- [12.1. Functions](#121-functions)
|
||||
- [12.1.1. ```stdtime```](#1211-stdtime)
|
||||
- [12.1.2. ```function_exists <function_name>```](#1212-function_exists-function_name)
|
||||
- [12.1.3. ```get_mod_name <module_file>```](#1213-get_mod_name-module_file)
|
||||
- [12.1.4. ```set_system_proxy```](#1214-set_system_proxy)
|
||||
|
||||
## 1. Getting started
|
||||
This is a developer's reference. It's not intended to be a manual, but a
|
||||
@@ -130,9 +137,96 @@ The script will exit after cleanup when that signal is trapped.
|
||||
the bash process running the script. The kill signal can come from the kernel or
|
||||
through the use of a *kill* command. The script will exit after cleanup.
|
||||
|
||||
## 3. The display.sh file
|
||||
## 3. The chroot.sh file
|
||||
### 3.1. Functions
|
||||
#### 3.1.1. ```prnt [-n] [I|W|E|m] <message>```
|
||||
#### 3.1.1. ```chroot_bootstrap```
|
||||
That function is called if a chroot option have been given. It's in charge of
|
||||
performing the chroot, copying a full working directory structure of init.sh
|
||||
tree. After that copy a chroot command is runned launching that new copy of
|
||||
init.sh.
|
||||
|
||||
If the child init.sh end with error, the stage file is gathered in parent
|
||||
directory tree to allow launching again the chrooted init.sh with the resume
|
||||
option.
|
||||
|
||||
At the end the function will clean up removing the second copy of init.sh.
|
||||
|
||||
### 3.2. Other functionnalities
|
||||
So far, only one function is provided in this file.
|
||||
|
||||
## 4. The diskman.sh file
|
||||
### 4.1. Global warning
|
||||
The goal of that unit is to provide disk manipulation function, like
|
||||
partitionning, blanking or formative. All those functions are potentially very
|
||||
destructive. Please use with extra care and do not hesitate to highly protect
|
||||
your code when using those. By defaults the functions try to be as conservative
|
||||
as they can, triguering errors on the smallest doubt.
|
||||
|
||||
### 4.2. Function
|
||||
#### 4.2.1. ```blank_disk <bloc_device>```
|
||||
Blank a block device using two different method to be sure it's all clear. First
|
||||
we use the *wipefs* method specialized in reseting all possible flags on the
|
||||
drive and it's partitions. It will also blank the partition table. A second pass
|
||||
will fill the first 512 MB with zeroes to also blank MBR and other parts of the
|
||||
drive wipefs would have ignored.
|
||||
|
||||
That function only take parameter which must be a bloc device.
|
||||
|
||||
#### 4.2.2. ```is_blank <bloc_device>```
|
||||
That function will try to detect if a drive is blank of not. It will return 0 if
|
||||
the drive is blank, and return 1 otherwise. Please consider that special drive
|
||||
configuration could be detected as blank while it's not. Only one parameter will
|
||||
be accepted, a bloc device. The bloc device you provide is suposed to be a whole
|
||||
drive, not a partition.
|
||||
|
||||
### 4.3. Other functionnalities
|
||||
That file don't profide any other things that the previously listed functions.
|
||||
|
||||
## 5. The command_line.sh file
|
||||
### 5.1. Functions
|
||||
#### 5.1.1. ```read_commandline```
|
||||
That function consist in a loop that analyse command line one parameter after
|
||||
the other. Most of command line parameters will result in the positionning of
|
||||
some global variables. The following table details the variable with their type
|
||||
associated to the corresponding parameter:
|
||||
| Parameter | Variable | Type | Descrition |
|
||||
|:--------------|:-------------------|:--------|:------------------------------|
|
||||
| --help | *none* | *n/a* | Trigger help display directly and exit |
|
||||
| --version | *none* | *n/a* | Trigger version display directly and exit |
|
||||
| --module | MANUAL_MODULE_LIST | string | The following parameter will set a list of module to use |
|
||||
| --check-only | CHECK_ONLY | boolean | Activate check only mode |
|
||||
| --jump | JUMP | boolean | Activate no checks mode |
|
||||
| --keep-going | KEEPGOING | boolean | Activate keep going option |
|
||||
| --resume | RESUME | boolean | Activate resume mode if stage file exists |
|
||||
| --no-root-check | NO_ROOT_CHECK | boolean | Activate option to not check if user is root |
|
||||
| --no-deps | NO_DEPS | boolean | Activate not checking module dependencies option |
|
||||
| --logfile | NEW_LOGFILE | string | The following parameter will be the log filename |
|
||||
| --file | CONFFILES | string | The following parameter will be a configuration filename |
|
||||
| --shell | RUN_SHELL | boolean | Activate the shell mode |
|
||||
| --chroot | CHROOT_PATH | string | The following parameter will be the path to chroot in |
|
||||
| --cron | CRON_MODE | boolean | Activate cron mode |
|
||||
|
||||
The function will do some basinc synthax checks. For exemple if you put an
|
||||
option just after one supposing a value declaration, an error will be trigered
|
||||
directly.
|
||||
|
||||
#### 5.1.5. ```process_commandline_and_vars```
|
||||
That function have the role to check the concistancy of command line parameters.
|
||||
It will triger errors if incompatible parameters have been given or if those
|
||||
parameters might lead to a non predictable situation.
|
||||
|
||||
When those checks are done, the definitive module list to load is created. With
|
||||
that list we then checks the modules are available and do not contain the dash
|
||||
character.
|
||||
|
||||
That function will also triger an error if the definitive module list is empty.
|
||||
|
||||
### 5.2. Other functionnalities
|
||||
That file don't profide any other things that the previously listed functions.
|
||||
|
||||
## 6. The display.sh file
|
||||
### 6.1. Functions
|
||||
#### 6.1.1. ```prnt [-n] [I|W|E|m] <message>```
|
||||
Print a message with timestamp and header. The header depends on a single
|
||||
character parameter, will be colored and have a fixed length, so the messages
|
||||
will always be aligned.
|
||||
@@ -156,14 +250,14 @@ Consequently that function can only contain code that cannot trigger errors or
|
||||
fail as it's also used to display errors. Thus it only contains echoes and some
|
||||
variables manipulation.
|
||||
|
||||
#### 3.1.2. ```separator```
|
||||
#### 6.1.2. ```separator```
|
||||
That function display a seprator made with dash, to fill the length of the
|
||||
screen minus one character if screen length is 80 character or less. If more
|
||||
than 80 the lenght of the separator will be 80 plus half of additionnal length.
|
||||
|
||||
It takes no parameters and return no value.
|
||||
|
||||
#### 3.1.3. ```dsleep <miliseconds> [char]```
|
||||
#### 6.1.3. ```dsleep <miliseconds> [char]```
|
||||
That function is an equivalent to *sleep* bash command but will display a
|
||||
countdown every second until it reaches zero. Optionnally a character (or a
|
||||
string) can be given as a second parameter to replace the countdown by that
|
||||
@@ -172,13 +266,13 @@ the wait is over.
|
||||
|
||||
The function returns nothing useful.
|
||||
|
||||
#### 3.1.4. ```dump_key_buffer```
|
||||
#### 6.1.4. ```dump_key_buffer```
|
||||
That function dumps keyboard's buffer. It's used to clear eventual key press
|
||||
before any critical keyboard action.
|
||||
|
||||
That function takes no parameter and returns no useful value.
|
||||
|
||||
### 3.2. Other functionalities
|
||||
### 6.2. Other functionalities
|
||||
Using that script will declare some easy to remember variables containing Bash
|
||||
color codes:
|
||||
|
||||
@@ -207,8 +301,8 @@ Remember to always terminate an *echo -e* using colors with the $DEFAULTCOL
|
||||
variable. If not, any new line might be filled with the last used color and line
|
||||
ending will be filled with background color.
|
||||
|
||||
## 4. The filefct.sh file
|
||||
### 4.1. Common behavior
|
||||
## 7. The filefct.sh file
|
||||
### 7.1. Common behavior
|
||||
In our terminology a source file can be of three different origins, selected
|
||||
automatically from highest to lowest priority:
|
||||
- **```repo/hosts/$HOSTNAME```**: this allows to provide system specific
|
||||
@@ -218,8 +312,8 @@ files. Use only relative path to access it.
|
||||
- **Any path**: You can give fully qualified path names to access resources
|
||||
from other locations.
|
||||
|
||||
### 4.2. Functions
|
||||
#### 4.2.1. ```backupdist <list_of_files_or_dirs>```
|
||||
### 7.2. Functions
|
||||
#### 7.2.1. ```backup_dist <file_or_dir1> [file_or_dir2 [... file_or_dirN]] ```
|
||||
That function will provide a backup of any given files or directories given in
|
||||
command line. The backup will be named name.dist-timestamp, where name is the
|
||||
original file or directory name and timestamp the date and time of the backup
|
||||
@@ -231,14 +325,14 @@ recursively until we backup the final target on its side.
|
||||
|
||||
The function don't take any other parameters than file and/or directory names.
|
||||
|
||||
#### 4.2.2. ```select_file <filename>```
|
||||
#### 7.2.2. ```select_file <filename>```
|
||||
Returns the best match in our priority system returning on ```stdout``` the
|
||||
resulting fully qualified path name as a result. The priorities applies on file
|
||||
existance.
|
||||
|
||||
Many functions manipullating files in ```init.sh``` depends on that function.
|
||||
|
||||
#### 4.2.2. ```installfile <sources> <destination>```
|
||||
#### 7.2.2. ```install_file <source1> [source2 [... sourceN]] <destination>```
|
||||
Install a list of source files to the given destination using our priority
|
||||
system.
|
||||
|
||||
@@ -248,15 +342,15 @@ use any. It's also not yet possible to give an entire directory as a source.
|
||||
The last parameter is always the destination. If the destination path does not
|
||||
exists, it will be created automatically.
|
||||
|
||||
#### 4.2.3. ```appendfile <source> <destination>```
|
||||
#### 7.2.3. ```append_file <source> <destination>```
|
||||
That function add the content of source file to destination file. The source
|
||||
file can have different origins, following the same path priority as the
|
||||
*installfile* function.
|
||||
*install_file* function.
|
||||
|
||||
The destination file must exist and be on the root filesystem. Only two
|
||||
parameters are accepted, the source and destination files.
|
||||
|
||||
#### 4.2.4. ```isdirempty <directory>```
|
||||
#### 7.2.4. ```is_dir_empty <directory>```
|
||||
That function take only one parameter, a path name and return 0 if the given
|
||||
path don't exists or is empty. It will return one if there's at least one file
|
||||
in the given directory.
|
||||
@@ -264,7 +358,7 @@ in the given directory.
|
||||
If the given parametter is a file (or a symlink to a file), it will terminate
|
||||
with an error.
|
||||
|
||||
#### 4.2.5. ```patch_file <source> <destination> [VAR1 [VAR2 ...]]```
|
||||
#### 7.2.5. ```patch_file <source> <destination> [VAR1 [VAR2 [... VARN]]]```
|
||||
That function will patch the given file using our priority system, patch it
|
||||
then place the result in the given destination. The patching will be done when
|
||||
any @VAR@ item in the source file will match an environment variable of the
|
||||
@@ -275,7 +369,7 @@ variables, in the context of the *init.sh* execution.
|
||||
Source file must exists and not be empty. The function returns nothing
|
||||
useful.
|
||||
|
||||
#### 4.2.6. ```tagfile <list_of_files>```
|
||||
#### 7.2.6. ```tag_file <file1> [file2 [... fileN]]```
|
||||
That function add a tag to the first line of the given files. If one file
|
||||
allready exists, the added line will be in the form:
|
||||
|
||||
@@ -289,17 +383,63 @@ It's not using the file selection system as our source file are not suposed to
|
||||
be modified directly. In consequence, you should always provide fully qualified
|
||||
path names to it.
|
||||
|
||||
#### 4.2.7. ```file_exists <list_of_files>```
|
||||
#### 7.2.7. ```file_exists <file1> [file2 [... fileN]]```
|
||||
That function check files existance within our file selection system. If one
|
||||
source file is missing it will return 1 and echo the first file name that have
|
||||
not been found in the list. If all the given files exists, it returns 0.
|
||||
|
||||
#### 7.2.8. ```file_must_exists <file1> [file2 [... fileN]]```
|
||||
That function check files existance within our file selection system. If one
|
||||
source file is missing it will return an error and stop execution. That function
|
||||
is logicaly massively used during check phase to verify all source files are in
|
||||
place.
|
||||
|
||||
### 4.3. Other functionnalities
|
||||
#### 7.2.9. ```directory_exists <directory1> [directory2 [... directoryN]]```
|
||||
That function check directories existance within our file selection system. If
|
||||
one source directory is missing it will return 1 and echo the first directory
|
||||
name that have not been found in the list. If all the given directories exists,
|
||||
it returns 0.
|
||||
|
||||
#### 7.2.10. ```directory_must_exists <directory1> [directory2 [... directoryN]]```
|
||||
That function check directories existance within our file selection system. If
|
||||
one source directory is missing it will return an error and stop execution. That
|
||||
function is logicaly massively used during check phase to verify all source
|
||||
directories are in place.
|
||||
|
||||
### 7.3. Other functionnalities
|
||||
That file don't profide any other things that the previously listed functions.
|
||||
|
||||
## 5. The pkgman.sh file
|
||||
### 5.1. Global dependencies
|
||||
## 8. The loaders.sh file
|
||||
### 8.1. Functions
|
||||
#### 8.1.3. ```load_autoconf```
|
||||
That function will automatically load system specific configuration if file
|
||||
exist in the following order:
|
||||
1) ```auto/arch.conf.sh```
|
||||
2) ```auto/distro.conf.sh```
|
||||
3) ```auto/distro-arch.conf.sh```
|
||||
4) ```auto/distro-version.conf.sh```
|
||||
5) ```auto/distro-codename.conf.sh``` (if ```SYS_CODE``` defined)
|
||||
6) ```auto/distro-version-arch.conf.sh```
|
||||
7) ```auto/distro-codename-arch.conf.sh``` (if ```SYS_CODE``` defined)
|
||||
|
||||
Plaese note that a situation where no such file exists would lead to error. Most
|
||||
of the time a basic package manager configuration will be required to make it
|
||||
work.
|
||||
|
||||
#### 8.1.4. ```load_configuration```
|
||||
That function loads configuration files. It will first check for configuration
|
||||
given as command line parameter. If no such parameter exists, it will try to
|
||||
load a file named ```conf/${HOSTNAME}.conf.sh```. If that file don't exists, the
|
||||
generic configuration will be loaded in the file ```conf/init.conf.sh```.
|
||||
|
||||
If no configuration file can be found the function will trigger an error and
|
||||
exit the script.
|
||||
|
||||
### 8.2. Other functionnalities
|
||||
That file don't profide any other things that the previously listed functions.
|
||||
|
||||
## 9. The pkgman.sh file
|
||||
### 9.1. Global dependencies
|
||||
Because it gives system independent function to the system dependent package
|
||||
manager, the entire file depends on ```PKG_MAN``` variable, defining the package
|
||||
manager executable to use. Other variables giving command line parameters to
|
||||
@@ -307,8 +447,8 @@ use for the different function will also be nedeed and detailed for every
|
||||
function. All those variable are defined in a system dependant configuration
|
||||
file automatically called on script startup.
|
||||
|
||||
### 5.2. Functions
|
||||
#### 5.2.1. ```pkgupdt```
|
||||
### 9.2. Functions
|
||||
#### 9.2.1. ```pkgupdt```
|
||||
That function calls the package manager to update package database.
|
||||
|
||||
It depends on the ```COM_UPDATE``` variable wich define the parameters to use to
|
||||
@@ -316,7 +456,7 @@ accomplish that function.
|
||||
|
||||
That function takes no parameters and any given parameters will be ignored.
|
||||
|
||||
#### 5.2.2. ```pkginst <package_list>```
|
||||
#### 9.2.2. ```pkginst <package1> [package2 [... packageN]]```
|
||||
That function installs using the package manager the packages given in
|
||||
parameters. The list of parameters are all considered as package names.
|
||||
|
||||
@@ -337,7 +477,7 @@ all the post installation scripts.
|
||||
The function depends on the ```COM_INSTALL``` variable wich define the parameter
|
||||
to use to accomplish that package manager function.
|
||||
|
||||
#### 5.2.3. ```pkgupgd```
|
||||
#### 9.2.3. ```pkgupgd```
|
||||
That function calls the package manager to upgrade system. If pre upgrade
|
||||
scripts exists, they will be executed if the corresponding package are being
|
||||
upgraded. After the upgrade, the same behaviour will trigger post upgrade
|
||||
@@ -351,7 +491,7 @@ to accomplish that function.
|
||||
|
||||
That function takes no parameters and any given parameters will be ignored.
|
||||
|
||||
#### 5.2.4. ```pkgrm <package_list>```
|
||||
#### 9.2.4. ```pkgrm <package1> [package2 [... packageN]]```
|
||||
That function uninstalls using the package manager the packages given in
|
||||
parameters. The list of parameters are all considered as package names.
|
||||
|
||||
@@ -372,7 +512,7 @@ script will be in the form ```postrm_<package_name>```.
|
||||
The function depends on the ```COM_REMOVE``` variable wich define the parameter
|
||||
to use to accomplish that function.
|
||||
|
||||
#### 5.2.5. ```pkgautorm```
|
||||
#### 9.2.5. ```pkgautorm```
|
||||
That function calls the package manager to remove no longer needed installed
|
||||
dependencies. Any package not manually installed is considered as a depndency.
|
||||
|
||||
@@ -385,7 +525,7 @@ to accomplish that function.
|
||||
|
||||
That function takes no parameters and any given parameters will be ignored.
|
||||
|
||||
### 5.3. Other functionnalities
|
||||
### 9.3. Other functionnalities
|
||||
Other functions are declared to call pre and post actions for the corresponding
|
||||
package manager events. It doesn't make sense those functions to be called
|
||||
outside of the integrated package manager mechanisms as their functionnalities
|
||||
@@ -403,8 +543,8 @@ The following table resume those function sorted with their respective caller:
|
||||
| ```exec_preautorm``` | ```pkgautorm``` | ```GET_AUTORMLIST``` | ```prerm_@pkgname@``` | ```GET_AUTORMLIST``` variable defines the command that allows us to obtain the list of package that will be automatically removed. |
|
||||
| ```exec_postautorm``` | ```pkgautorm``` | ```POSTRMLIST``` | ```postrm_@pkgname@``` | ```POSTRMLIST``` is generated by ```exec_preautorm``` and destroyed after ```exec_postautorm``` execution. |
|
||||
|
||||
## 6. The services.sh file
|
||||
### 6.1. Global dependencies
|
||||
## 10. The services.sh file
|
||||
### 10.1. Global dependencies
|
||||
That script relies on the ```INIT_COM``` variable, defining the program to use
|
||||
to manipulate services. It is defined in configuration file automatically called
|
||||
depending on your distribution. Nevertheless, even if it's system dependent,
|
||||
@@ -422,8 +562,8 @@ With the tested init systems, and considering ```%srv%``` the service name and
|
||||
* **```systemctl %com% %srv%```** for systems using SystemD
|
||||
* **```service %srv% %com%```** for upstart like scripts (but widely available)
|
||||
|
||||
### 6.2. Functions
|
||||
#### 6.2.1. ```exec_serv <service> <command>```
|
||||
### 10.2. Functions
|
||||
#### 10.2.1. ```exec_serv <service> <command>```
|
||||
That function execute the given action to the given service. The service have
|
||||
to be the first parameter and the action, the second parameter. No more
|
||||
parameter will be acceted and an error will be triggered if there's any more
|
||||
@@ -431,74 +571,77 @@ than two.
|
||||
|
||||
The function returns the exit code of the service command.
|
||||
|
||||
#### 6.2.2. ```svc_start <service1> [service2 ... serviceN]```
|
||||
#### 10.2.2. ```svc_start <service1> [service2 ... serviceN]```
|
||||
Start the services given in parmeters. You can give as many services you want.
|
||||
|
||||
That function relies on the previously documented exec_serv function.
|
||||
|
||||
#### 6.2.3. ```svc_reload <service1> [service2 ... serviceN]```
|
||||
#### 10.2.3. ```svc_reload <service1> [service2 ... serviceN]```
|
||||
Reload the configuration of the services given in parmeters. You can give as
|
||||
many services you want. Be careful using this as some services don't have that
|
||||
capability.
|
||||
|
||||
That function relies on the previously documented exec_serv function.
|
||||
|
||||
#### 6.2.2. ```svc_restart <service1> [service2 ... serviceN]```
|
||||
#### 10.2.2. ```svc_restart <service1> [service2 ... serviceN]```
|
||||
Restart the services given in parmeters. It consist generally in a stop
|
||||
immediately followed by a start. You can give as many services you want.
|
||||
|
||||
That function relies on the previously documented exec_serv function.
|
||||
|
||||
#### 6.2.3. ```svc_stop <service1> [service2 ... serviceN]```
|
||||
#### 10.2.3. ```svc_stop <service1> [service2 ... serviceN]```
|
||||
Stop the services given in parmeters. You can give as many services you want.
|
||||
|
||||
That function relies on the previously documented exec_serv function.
|
||||
|
||||
## 7. The support.sh file
|
||||
### 7.1. Global behaviour
|
||||
### 10.3. Other functionnalities
|
||||
That file don't profide any other thing that the previously listed functions.
|
||||
|
||||
## 11. The support.sh file
|
||||
### 11.1. Global behaviour
|
||||
That file is designed to just display information. It only contains code that
|
||||
don't requires any special writes, and do nothing to the system. The idea is to
|
||||
have the minimal sets of dependencies. As it's sometimes using colors to display
|
||||
results, it depends only on color code declaration in the ```display.sh``` file.
|
||||
|
||||
### 7.2. Functions
|
||||
#### 7.2.1. ```disp_help```
|
||||
### 11.2. Functions
|
||||
#### 11.2.1. ```disp_help```
|
||||
That function display the help screen, usually called using the *--help* switch.
|
||||
|
||||
It's not taking any parameter and return nothing but help text.
|
||||
|
||||
#### 7.2.2. ```show_version```
|
||||
#### 11.2.2. ```show_version```
|
||||
That function display the version of init.sh. It will also parse all the
|
||||
available modules to display a table with their respecting versions.
|
||||
|
||||
If user is not root an additionnal warning will be displayed to warn the fact
|
||||
the script requires root privileges to work properly.
|
||||
|
||||
### 7.3. Other functionnalities
|
||||
### 11.3. Other functionnalities
|
||||
That file don't profide any other thing that the previously listed functions.
|
||||
|
||||
## 8. The utils.sh file
|
||||
### 8.1. Functions
|
||||
#### 8.1.1. ```stdtime```
|
||||
## 12. The utils.sh file
|
||||
### 12.1. Functions
|
||||
#### 12.1.1. ```stdtime```
|
||||
Display date and time based on RFC 3339 standard but slightly modified so it can
|
||||
be used in filename. Thus spaces are replaced by dash, and comas between hours,
|
||||
minutes and seconds are removed.
|
||||
|
||||
That function takes no parameters and return its result on standard output.
|
||||
|
||||
#### 8.1.2. ```function_exists <function_name>```
|
||||
#### 12.1.2. ```function_exists <function_name>```
|
||||
That function checks if the given name is a defined function in the execution
|
||||
environment. It returns 0 if yes and an undefined non zero value if not.
|
||||
|
||||
That functions prints nothing.
|
||||
|
||||
#### 8.1.3. ```get_mod_name <module_file>```
|
||||
#### 12.1.3. ```get_mod_name <module_file>```
|
||||
That function return the name of the module file given in parameter. It takes
|
||||
only one parameter: the module file name.
|
||||
|
||||
Result is sent to ```stdout```.
|
||||
|
||||
#### 8.1.4. ```set_system_proxy```
|
||||
#### 12.1.4. ```set_system_proxy```
|
||||
That function applies proxy settings in the configuration files to the system
|
||||
proxy configuration, unless the ```--no-proxy``` parameters have been given
|
||||
command line.
|
||||
@@ -506,12 +649,12 @@ command line.
|
||||
That function takes no parameters and only change ```http_proxy``` and
|
||||
```https_proxy``` standard POSIX variables. No usefull result will be returned.
|
||||
|
||||
### 8.2. Other functionnalities
|
||||
### 12.2. Other functionnalities
|
||||
That file don't profide any other thing that the previously listed functions.
|
||||
|
||||
## 9. The version.sh file
|
||||
### 9.1. Functions
|
||||
#### 9.1.1. ```get_os_version```
|
||||
## 13. The version.sh file
|
||||
### 13.1. Functions
|
||||
#### 13.1.1. ```get_os_version```
|
||||
That function takes no parameters and will return three values in order:
|
||||
1. Distribution ID, in lowcase, usually equivalent to the distribution name.
|
||||
2. Distribution version, if available, elsewhere kernel version with it's major.
|
||||
@@ -525,7 +668,7 @@ the [official documentation](https://www.freedesktop.org/software/systemd/man/os
|
||||
In "*/etc/os-release*" the variables *ID*, *VERSION_ID* and *VERSION_CODENAME*
|
||||
will be the ones being analysed. Only the *ID* variable is mandatory.
|
||||
|
||||
#### 9.1.2. ```set_sys_var <arch> <dist> <version> <codename>```
|
||||
#### 13.1.2. ```set_sys_var <arch> <dist> <version> <codename>```
|
||||
That function sets important variable that will store the system architecture.
|
||||
It will allow the automatic loading of mandatory system dependent code and
|
||||
variables. For debugging purpose it will be possible to call it manually.
|
||||
@@ -552,85 +695,8 @@ The following global variables will be set at the end of the execution:
|
||||
|
||||
The ```SYS_CODE``` variable won't be set if your distribution provides no codename.
|
||||
|
||||
## 10. The zzz_main_fct file
|
||||
This file is used internally directly by the init.sh script. Its purpose is
|
||||
only to lighten the main program file and those function are not supposed to be
|
||||
used by any module or even more than once. Thus it's documented to help new
|
||||
developpers to contribute.
|
||||
|
||||
### 10.1. Functions
|
||||
#### 10.1.1. ```read_commandline```
|
||||
That function consist in a loop that analyse command line one parameter after
|
||||
the other. Most of command line parameters will result in the positionning of
|
||||
some global variables. The following table details the variable with their type
|
||||
associated to the corresponding parameter:
|
||||
| Parameter | Variable | Type | Descrition |
|
||||
|:--------------|:-------------------|:--------|:------------------------------|
|
||||
| --help | *none* | *n/a* | Trigger help display directly and exit |
|
||||
| --version | *none* | *n/a* | Trigger version display directly and exit |
|
||||
| --module | MANUAL_MODULE_LIST | string | The following parameter will set a list of module to use |
|
||||
| --check-only | CHECK_ONLY | boolean | Activate check only mode |
|
||||
| --jump | JUMP | boolean | Activate no checks mode |
|
||||
| --keep-going | KEEPGOING | boolean | Activate keep going option |
|
||||
| --resume | RESUME | boolean | Activate resume mode if stage file exists |
|
||||
| --no-root-check | NO_ROOT_CHECK | boolean | Activate option to not check if user is root |
|
||||
| --no-deps | NO_DEPS | boolean | Activate not checking module dependencies option |
|
||||
| --logfile | NEW_LOGFILE | string | The following parameter will be the log filename |
|
||||
| --file | CONFFILES | string | The following parameter will be a configuration filename |
|
||||
| --shell | RUN_SHELL | boolean | Activate the shell mode |
|
||||
| --chroot | CHROOT_PATH | string | The following parameter will be the path to chroot in |
|
||||
| --cron | CRON_MODE | boolean | Activate cron mode |
|
||||
|
||||
The function will do some basinc synthax checks. For exemple if you put an
|
||||
option just after one supposing a value declaration, an error will be trigered
|
||||
directly.
|
||||
|
||||
#### 10.1.2. ```chroot_bootstrap```
|
||||
That function is called if a chroot option have been given. It's in charge of
|
||||
performing the chroot, copying a full working directory structure of init.sh
|
||||
tree. After that copy a chroot command is runned launching that new copy of
|
||||
init.sh.
|
||||
|
||||
If the child init.sh end with error, the stage file is gathered in parent
|
||||
directory tree to allow launching again the chrooted init.sh with the resume
|
||||
option.
|
||||
|
||||
At the end the function will clean up removing the second copy of init.sh.
|
||||
|
||||
#### 10.1.3. ```load_autoconf```
|
||||
That function will automatically load system specific configuration if file
|
||||
exist in the following order:
|
||||
1) ```auto/arch.conf.sh```
|
||||
2) ```auto/distro.conf.sh```
|
||||
3) ```auto/distro-arch.conf.sh```
|
||||
4) ```auto/distro-version.conf.sh```
|
||||
5) ```auto/distro-codename.conf.sh``` (if ```SYS_CODE``` defined)
|
||||
6) ```auto/distro-version-arch.conf.sh```
|
||||
7) ```auto/distro-codename-arch.conf.sh``` (if ```SYS_CODE``` defined)
|
||||
|
||||
Plaese note that a situation where no such file exists would lead to error. Most
|
||||
of the time a basic package manager configuration will be required to make it
|
||||
work.
|
||||
|
||||
#### 10.1.4. ```load_configuration```
|
||||
That function loads configuration files. It will first check for configuration
|
||||
given as command line parameter. If no such parameter exists, it will try to
|
||||
load a file named ```conf/${HOSTNAME}.conf.sh```. If that file don't exists, the
|
||||
generic configuration will be loaded in the file ```conf/init.conf.sh```.
|
||||
|
||||
If no configuration file can be found the function will trigger an error and
|
||||
exit the script.
|
||||
|
||||
#### 10.1.5. ```process_commandline_and_vars```
|
||||
That function have the role to check the concistancy of command line parameters.
|
||||
It will triger errors if incompatible parameters have been given or if those
|
||||
parameters might lead to a non predictable situation.
|
||||
|
||||
When those checks are done, the definitive module list to load is created. With
|
||||
that list we then checks the modules are available and do not contain the dash
|
||||
character.
|
||||
|
||||
That function will also triger an error if the definitive module list is empty.
|
||||
### 13.2. Other functionnalities
|
||||
That file don't profide any other thing that the previously listed functions.
|
||||
|
||||
|
||||
-----------------------------------------------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user