User Tools

Site Tools


modules

What is a module?

A module, if one looks up the general definition of the term, can be a very complex subject, especially in theoretical mathematics, for us to explain here. Let us just consider an example, like an electrical drill. Its primary use is to have a drill bit attached to the choke to open holes. Different drill bits can be used for concrete, wood, metal, etc. But there are modules that can also be attached to it alter its use. It can have a sanding wheel, a wire brush, or even a pump. So we can consider it as a “modular” tool, that can do more than its “default” purpose. The user of the drill can configure it in various ways and the same single tool can have many modules.

How does a 66 module work?

Back to 66 service management and Obarun in specific, we have seen how different services can be one-shots, meaning they execute once and the task is complete, or have a form of a daemon, a constantly running service that in the rare occasion that something fails they can safely be restarted without disrupting other work, while logging the problem specific to the service (supervision). If you have used Obarun for a while you may have noticed some “services” ending with a @, for example we have ntpd-66serv (not a module), and we also have tty@-66serv, or boot-user@-66mod. Not all of services notated with a “@” are modules, they can also be instantiated services. The difference is that a module can be configured as a service or group of services working together, while an instantiated service can have “its environment” configured. boot-user@-66mod (replaced now by boot-user@-66serv) is a module, tty@tty3 is an instantiated service. The best example to understand the difference is boot@-66serv which is a group (bundle) of services that can selectively be utilized or disabled to work together as a “module”. (see more specific the document on boot@)

In the past tty12 on boot-66serv was fixed by the distribution to have specific settings. (Note: from boot@-66serv 0.2.xx and beyond the tty services are incorporated into the boot module and renamed tty-rc@ while tty12 becomes tty@tty12 with a specific default behavior. Not restrictive or mandated, but recommended, tty configuration should be incorporated into the boot module.

Example:

Let us take another example, ntpd. ntpd-66serv is currently a service, not a module, but can be converted into a module type of service. Imagine if you are a high profile executive flying to different cities during the week to conduct business, or you are a flight attendant, and you change time zones often, or a mariner. You would have to manually go and modify the /etc/ntpd.conf for the timezone and locality to make it work every time you land in a different time zone. With a module it is easier, you may have ntpd@baltimore, ntpd@dublin, ntpd@cairo, ntpd@new-delhi. The environment settings should point each to a different ntpd.conf with localized time servers. Disabling one module and enabling another, with 66, is all it takes to make the adjustment between the cities you frequently visit. For the specific example the boot module must also be reconfigured for the change of timezone.

Examine each and every service and you may discover more uses of modules (modular services or module type of service).

For every daemon or service you can think of there are specific practical uses for converting to modular type. Not necessarily, and other service management/supervision systems do not have this luxury, but an existing complexity and ability doesn't act as a burden to those that do not utilize it. To utilize this complexity/luxury you have to read a little more about its employment in 66 [66 documentation]. It is probably advantageous to everyone using 66 to learn at least how the new boot bundle works as a module. Go to this specific document to see what boot@-66serv does that boot-66serv didn't.

“More specific 66 handling and structure of module setup (documents boot@, boot-user@, user-trees)”

modules.txt · Last modified: 2020/10/26 09:16 by wikiman