It is impossible to accomodate for all possible combinations of hardware, software implementing the same mechanism, user preferences and use cases of a computer. For this reason, goetia comes in the form of building blocks. The following text and all the other documentation on this website try to make it clear how to assemble these building blocks.
goetia is aimed at power users and distribution maintainers. It makes it particularly simple to ship a finished configuration to end users in form of a finished configuration directory (see configuration below).
goetia consists of a couple of modular packages, to allow it to support multiple use cases, Kernels and init systems.
Be sure to read up on installation directories. The installation of below packages will create such directories, one for each installed package. From the installation directories, certain subdirectories will be copied or symlinked during the configuration part that will be explained later.
Choose and install the appropriate packages.
On a Linux based system, one might want to install:
All that follows assumes that the default settings were used
during ./configure.
Create the following if they do not already exist:
logger for the
automatically generated loggers.
/run for the
runtime directory.
/dev/null
must exist.
It can be created by mknod -m 666 /dev/null c 1 3.
Warning: this has to be done without the devtmpfs mounted.
/etc/goetia/system
├── env
├── run-image
│ └── service
└── src
for the
configuration directory.
Following are the steps to take to get a minimal booting system. Thus only the setup of the mandatory system supervision tree is covered here. For more advanced configurations, like user supervision trees, see the tutorials.
The main purpose of goetia is to provide "ready to use" service and source directories. They can be either symlinked or copied from the installation directories to the configuration directory. Symlinking has the advantage (or disadvantage) that updates of the goetia packages (which changes the installation directory) are reflected in the configuration directory. Copying the service and source directories allows the modification of them. This makes it possible to change dependencies or change the script starting the daemon to customize it.
The actual configuration of goetia happens in configuration directories. In this case, the configuration directory of the system supervision tree will be populated.
Read up on configuration directories.
Initially, a couple of service directories
need to be added to the
run-image/service/ subdirectory of the
system configuration directory.
Symlink or copy them from the
installation directories.
For example,
s6-svscan-log
should appear as
run-image/service/s6-svscan-log.
Unconditionally required are:
s6-svscan-log!
.s6-svscan!
goetia-shutdown.
goetia-rescue.
This service is never stopped during shutdown and can be used
to add a rescue interface.
Of course, many more service directories might be symlinked, copied or manually created if desired.
A minimal goetia setup on Linux with default install time settings could look as follows:
/etc/goetia/system/run-image/service ├── .s6-svscan -> /usr/lib/goetia-base/service/system/.s6-svscan ├── goetia-rescue -> /usr/lib/goetia-linux/service/system/getty-12 ├── goetia-shutdown -> /usr/lib/goetia-linux-init/service/system/goetia-shutdown └── s6-svscan-log -> /usr/lib/goetia-base/service/system/s6-svscan-log
Make the Kernel boot a goetia init as described in the init tutorial.
At this point, the most minimal goetia based system would be ready to boot. This system has no drives mounted, the root filesystem is read-only and the only interface is the rescue console described above.
Most realistic scenarios require some kind of dependency management, as well as services that do run only for a short duration - so called "oneshots".
To allow for this, s6-rc is used as an abstraction that dynamically creates and removes service directories like those manually added above. Additionally it allows to dynamically start and stop services, considering depencencies. Finally it allows to define "oneshots", services that do something and then exit, without being restarted by a supervisor.
For this reason, all further services are defined/configured using source directories, the format that is used by s6-rc. Note that those are slightly different from service directories.
Much like the service directories above,
Source directories
can be symlinked, copied and manually created
inside the src/*/ subdirectories of the
configuration directory.
Ready to use source directories can be found inside of the
installation directories
installed earlier during this guide.
Whenever a longrun source directory is added, removed or changed, system-db needs to be run to automatically generate the corresponding logger (see log directory). Whenever any source directory is added, removed or changed, the system-db command has to be run to recalculate the dependencies and update the service directories managed by s6-rc. Check the programs listed at the goetia-base page, to get an overview of the tools at your hands to manage the services.
At this point, the needs for different machines and scenarios strongly diverge. Thus, this step by step guide has to end here. Some of the most basic and universal source directories one might want to set up on most machines are covered in dedicated tutorials:
Finally, service and source directories may of course be manually created at
run-image/service/ and src/*/.
Be sure to follow the
service format
and
source format.