This was topic #7 from the proposed list and since this is going to become a hot topic soon, in linux-system-administration circles, we thought of introducing our community to the basic principles.
If you read up what module means, where the term comes from, where is it utilized, you may end up more confused than you were before you encountered the term. If you are French or speak French well, since the term appears more native in this language than others, and since it has more applications you are familiar with, the concept may be easier to digest. There is also a mathematical operationalization of the term, which is a very specific concept in mathematics that is, that makes the term more understandable, but if you are not into theoretical mathematics don’t even touch that subject. Don’t go there!
Let’s say for simplicity that Lego parts are modular, or lego sets are modules of a greater system, a Lego city or a Lego-land. A blue 2x2x4 lego can be the torso of a Lego man wearing a blue shirt, it can be a brick in a blue wall, or part of the engine hood of a blue truck. In one respect one single thing can have different uses, and also modules can be compatible with each other, as building blocks. This means that a shopping center in lego land is not smaller than a dog house, the same dog seems proportional to the center as to the dog’s house. Now project this logic into system services or bundles of services. Those are the modules we will speak about. The main difference with lego is that legos have three dimensions and also have colors and qualities of each bit, so let’s say 4 dimensions. Here the dimensions are really endless.
It is hard to speak of service modules, or service bundle modules, without speaking specifically of Obarun, since we don’t know of a single example elsewhere. 66 is software native to Obarun, Eric Vidal is the father of both, 66 is also in the standard Void repositories.
“Is a service module something new that Obarun will introduce?”
Not exactly. If you have booted or installed obarun you may have seen on the list of services instead of a tty1 something called tty@tty1. That is a module. Has anyone taken advantage of this quality? tty@-66serv is a package with a standard tty service file. If tty1 was a copy of tty2 and tty3 and so on, those three would behave exactly the same. tty@tty4 may be configured differently than other ttys. It is a modular service. Just because nobody has tried doesn’t mean it can’t be done. tty@tty2 and tty@tty3 can coexist in the system and have different configurations.
TTYs are simple services, let’s apply the similar logic to something like dhcpcd. We configure dhcpcd and we let the service supervisor monitor its running, stopping, restarting, logging, etc. This is fine for most who use one network interface for all connectivity. What if there was a 2nd physical interface, or what if we created more virtual interfaces and each needed a separate configuration of dhcpcd. If you were to start dhcpcd, then change its configuration and start a second instance, how do you tell them apart. And what if one instance runs into a problem, is stopped, and restarted, it has adopted a different configuration. What if dhcpcd@eth0, dhcpcd@eth1, dhcpcd@wlan0, and dhcpcd@vmeth4, needed different configurations? You need a service supervision that can handle such complexities. Without users really knowing it 66 partially had this ability since its early days. Not s6, s6 will do the supervision of whatever you through at it, even the deletion of its own system can be thrown at it and it will delete itself being an obedient slave. 66 takes advantage of the abilities of s6 and makes it do things its inventor never thought possible or necessary.
I can hear Cynwulf, reading this, roaring, huffing and puffing, repeating himself, what does the average user need with all this? This is too complex and unnecessary. Why do people buy convertible cars or motorcycles in Finland or Alaska? Why does a boater in the Caribbean need a heater?
It is free! It doesn’t cost extra to have, it doesn’t burden the system to have this ability. It is not as if the code of s6 was tripled in order to do this, s6 never changed. While a running system is setup and runs 66 is absent. 66 materializes only when you want to alter something in the system, it carries out the change (rearranges what s6 does), then signs off and lets s6 doing its thing. Better than any other system we know, BY FAR!!
Ask Laurent Bercot, the author of s6, to implement this change in the system, instead of having tty1 and tty2 running, to have tty@tty1 and tty@tty2, each running a different keyboard language, font, rate, … or whatever else you can make a tty do. With 66 you issue:
# 66-disable -S tty1 tty2 # 66-enable -S tty@tty1 tty@tty2
Assuming you had already altered the tty@tty1 tty@tty2 configurations and it is easy to have two different configurations in the same system for the same service.
dhcpcd@eth0 and dhcpcd@wlan0 can not be confused while running, their logs are separate and can be debugged by them, they don’t affect each other, now think of the possibilities! Think of all other services you have available in the system and what you can make them do with converting them to modules. While everyone is trying to provide one shoe that fits all feet, with 66 you have lego shoes, you can buy a pair of modules and custom make shoes for all kinds of different feet, even two left ones …. some don’t even like “right” feet.
But wait, don’t go away, we are not done yet. What about service bundles, like ….. boot? Something tells us that the entire idea came FROM BOOT and didn’t start with tty@ and ended with boot@.
With up to version 0.1.2.2.1 boot-66serv was a service bundle whose possible sys-admin/user configuration extended to a file called /etc/66/boot.conf. There was a set number and type of services, some one-shots, some continuous-classic like udev, some more or less dynamic, like mounting and checking different kinds of file systems. boot-66serv had a set list of all those things and while s6 was starting it would run through the entire list. Imagine this list was used in every linux system we could get our hands on and worked, as well as various machines, with various C libraries, and worked everywhere. In that boot.conf you can alter parameters, hostname, time/date/region, different types of file systems, raid setups, zfs, encrypted, btrfs, swap, … etc. But booting went through the list and read whether each was enabled or disabled, and if enabled it was pointed to a specific configuration. So we all run the same boot bundle of services with minor alterations of things being on/off. One shoe for every foot. What is good for all other linux/unix systems wasn’t good enough. What if the same machine was used as a home desktop, you took to work and became a backup server, synced arrays of volumes and systems, upgraded clients, or was a file server, or was an email server? How long would it take to adopt the machine for each one of those roles, and have it boot all pre-configured to undertake the role and tasks?
# 66-disable -t boot boot@desktop # 66-enable -t boot boot@net-server # reboot
Booting doesn’t go through the same pre-set list, it skips all the parts that are disabled, and boots doing exactly the steps necessary to undertake this role. Configuration must be done in advance and then you are done. It doesn’t matter what name in what language you give the module, as long as it has the format xxx@yyy, if you want to call the boot bundle a, you specify on init.conf to boot “a”, and if desktop use is configuration 1, you enable boot tree a bundle a@1 and it does it.
What if on top of an already running boot configuration you decide to add additional services without rebooting, can you do so? Yes, most can be added while on the fly. We have had some exposure to the run after variable of services depending on others running before they start, like a file server running only after there is networking. We have modular trees of services running only if another tree is running. So if you are using the machine as a personal desktop file server or ssh servers and so on don’t need to run. If your file serving setup, as a module, is running after boot@fileserv runs, it is enabled and knows when to begin running. If you boot on boot@pcandgames, that tree although enabled, it doesn’t see boot@fileserv running so it doesn’t run. It is asleep. And those are just simplistic examples I thought about and the possibilities are endless.
For many people this is too much information, too many abilities that they would never utilize or want or have to learn to utilize, and things will remain as they were. Possibly they may have to edit a single boot configuration module once and finish with it. (with a simple command of 66-env this can be done once and done with). It will never change. From that point onward no update/upgrade will need their attention, any future changes will be compatible with whatever they had. The transition of sportscar to space-shuttle is finished (runit is a bicycle and sysvinit is a door rolling on timber). Beginning with 66 0.5 and service files 0.2 and above, the user/sysadmin has nothing to worry about. They don’t have to see an ugly terminal or console ever again. It is as if the child grew up and reached its final development form. The details will keep changing and will affect those who want to utilize the additional capacities, and for them this is a new beginning. Like a kid taken from the sand pit with a bucket and shovel and into LegoLand to play.
The rest of us will seat quietly in a modular artificial virtual sand pit and play with sand not realizing we are just locked in a room created by legos.
And this is just a beginning!
Forest Gump: But systemd can do this too!
Go run a few thousand miles back in your century and let the rest of us move into 21st century and enjoy the capabilities of our machine without the burden of chocking it by useless binaries. Anything users install that can be daemonized in a systemd system, will begin running and stay running till you learn how to stop it, and its configuration stays as the distro sent it, and even if you manage to change something an upgrade will come and overwrite it, and the resources used by such a system are double or triple what they are with runit, s6, 66, etc. So don’t waste your time comparing corporate crap (same guys that sell 5digit-cost servers to corporations like they are pencils) with s6 and 66. When it comes to enterprise use we are talking of fractions of a cost and a fraction of heat and “consultants with redHats” that IBM/DELL/HP/Siemens … etc. will send to “maintain” the systems they advised an enterprise to purchase. They never liked runit, never acknowledged the existence of s6, and god forbid anyone mentioning 66.
Got to go, the phone is ringing, I can see mr.Smith coming!