Module service creation

A module can be considered as an instantiated service. It works the same way as a service frontend file but allows the user/admin to configure a set of different kind of services before executing the enable process. Also, the set of services can be configured with the conjunction of a script called configure which can be made in any language.

This allows one to pre-configure a set of parameters or other services for special tasks without knowing the exact target of the module. The best example is the module for booting a machine. Each machine is different and the set of services need to be adaptable as much as possible for different kinds of machines during boot; e.g booting a container.

A module is defined with two elements:

an instantiated frontend service file at /usr/share/66/service
a directory at .

The name of the frontend and the name of the directory must be the same. For example if the frontend is named /usr/share/66/service/foo@, the directory of the module must be /foo@.

Frontend file

The instantiated frontend service is written as any other instantiated service with its own specification—see the section [regex].

Module directory

The module directory can contain three sub-direcotories:

configure : This directory can contain an executable file script named configure. For example, /foo@/configure/configure. The sub-directory must be named configure and the file script must be named configure. This file is not mandatory. The 66-enable process will detect if the file exists and it runs it if it’s the case. It’s up to you to write the configure script file with the language of your choice as long as you define a correct shebang.

Also, this directory can contain any files or directories that you need to configure your module. It’s the responsability of the module creator to properly use or dispatch files or directories found inside the configure directory with the help of the configure script or during the module installation phase. 66-enable will not handle any other file than the configure script for you.

Note : The configure script is launched after the parsing of the frontend file, meaning all regex operations on directories and files are already made.
service : This directory can contain any frontend files for any kind of service except instantiated frontend service files. Also, this directory can contain sub-directories containing another frontend service files. This can be done recursively.
service@ : This directory can contain any instantiated frontend service files and only instantiated frontend service files. Also, this directory can contain sub-directories containing other instantiated frontend service files. This can be done recursively.

Any services that you need must be present inside the service or service@ directory. 66-enable only deals with these directories. If a service fooA has fooB as dependency, fooA and fooB must exist in the /<module_name>/service directory.

A word about the [regex] section `@addservices` field

You may need an existing frontend service file from your system to configure your module. Instead of redefining this frontend file, use this field. The 66-enable process will verbatim copy the frontend service file inside /usr/share/66/service/<module_name>/service or /usr/share/66/service/<module_name>/service@ module directory, depending on the type of service. This copying is made after all regex operations, and does not modify the frontend file at all.

A word about the [main] section with the module type

The valid fields in section [main] are:

@type
@description
@name
@version
@user
@depends
@optsdepends
@extdepends
@hiercopy

All other fields from [main] section are not allowed.

66-enable module process creation

The name foo@ will be used in this explanation as a module name.

When you do 66-enable foo@system:

It searches for the corresponding /usr/share/66/service/foo@ frontend service file.
It reads, parses, and replaces @I character by system as any intantiated service.
It searches for the corresponding /foo@ directory.
It checks if the /foo@/configure, /foo@/service and /foo@/service@ directories exist and create it if it is not the case.
It verbatim copies the /foo@ directory to /usr/share/66/service/foo@system. If the frontend file was found at /etc/66/service/foo@ the module, it is copied to /etc/66/service/foo@system, and if the frontend file was found at $HOME/.66/service/foo@, the module is copied to $HOME/.66/service/foo@system.

Note : if the module already exists and the -F was not passed to 66-enable, the configuration of the modules is skipped. If The -F was passed to 66-enable the corresponding /usr/share/66/service/foo@system directory is erased and the verbatim copy is made.
It reads all frontend file found at /usr/share/66/service/foo@system/service and /usr/share/66/service/foo@system/service@ and applies the regex defined with @infiles field.
It reads all frontend file found at /usr/share/66/service/foo@system/service and /usr/share/66/service/foo@system/service@ and applies the regex defined with @directories field.
It reads all frontend file found at /usr/share/66/service/foo@system/service and /usr/share/66/service/foo@system/service@ and applies the regex defined with @files field.
It runs the /usr/share/66/service/foo@system/configure script if it exists.
It adds the frontend service file set at @addservices, if any exist.
It reads and parses all frontend service files found at /usr/share/66/service/foo@system/service and /usr/share/66/service/foo@system/service@, as any 66-enable <service> service process.
It disables the service foo@system if it already exists, and finally finishes the enabling process, like any other service.

Environment variable passed to the script `configure`

At launch of the script configure, 66-enable passes the following variables to the environment:

MOD_NAME: name of the module.
MOD_BASE: /var/lib/66/system for root, $HOME/.66/system for regular user.
MOD_LIVE: /run/66.
MOD_TREE: /var/lib/66/system/<treename> for root, $HOME/.66/system/<treename> for regular user.
MOD_SCANDIR: /run/66/scandir/0 for root, /run/66/scandir/<owner_uid> for regular user.
MOD_TREENAME: name of the tree.
MOD_OWNER: numerical UID value of the owner of the process.
MOD_VERBOSITY: verbosity level passed to 66-enable.
MOD_COLOR: color state passed to 66-enable. MOD_COLOR=0 means color disabled where MOD_COLOR=1 means color enabled.
MOD_MODULE_DIR: /<module_name> or /<module_name> or $HOME//<module_name> depending of the owner of the process and the location of the service frontend file.
MOD_SKEL_DIR: /etc/66
MOD_SERVICE_SYSDIR: /usr/share/66/service
MOD_SERVICE_ADMDIR: /etc/66/service
MOD_SERVICE_ADMCONFDIR: /etc/66/conf
MOD_MODULE_SYSDIR:
MOD_MODULE_ADMDIR:
MOD_SCRIPT_SYSDIR: /usr/share/66/script
MOD_USER_DIR: .66
MOD_SERVICE_USERDIR: .66/service
MOD_SERVICE_USERCONFDIR: .66/conf
MOD_MODULE_USERDIR:
MOD_SCRIPT_USERDIR: .66/script