At the moment, this project is still very much a WIP. Most of the data are there for testing and demonstration purposes.
Both tool, template and other scripts in this repository are still far from being completely ready for practical usage. Data formats and available APIs may change at any time.
If you are interested in Yunorock, the operating system, check this.
This tool is designed to be a common configuration interface for dæmons or applications that depend on each other. Its intended goal is to make administrating a server easier for non-power-users, even for servers that serve multiple domains and applications.
Services are configured as a tree of producers and consumers of services. A service will produce a tag that will be consumed by another. For example: mariadb provides a tag "sql" that will be consumed by every program that needs to perform SQL operations.
Here the different steps to get the job done:
- install the configuration tool and its dependencies (described below)
- install the programs you need, and their configuration templates (ex: mariadb-yunorock)
- create a configuration file that describes the interaction between services on your computer
- generate configuration files for all your services with it
- start your services
- ...
- profit!
With it, services are configured as a tree of producers and consumers of services.
luarocks install moonscript
luarocks install etlua
luarocks install loadkit
luarocks install argparse
luarocks install luafilesystem
luarocks install lua-term
luarocks install serpent
The configuration file (config.cfg
) is written in Moonscript syntax.
This file describes a tree of services and domains, each of which must be named.
root {
service "nginx", {
-- ...
}
service "ssh", {
-- ...
}
domain "test.example", {
-- ...
}
domain "othertest.example", {
-- ...
}
}
Domains and services can (and probably should) be declared within other domains.
root {
service "nginx", {}
domain "test.example", {
domain "subtest", {
-- subtest.test.example configuration here.
}
}
}
Most services will depend on another service in one way or another.
services print
will indicate the missing requirements.
To configure them, just add a field that has the name of the requirement in the service definition.
root {
service nginx, {}
domain "test.example", {
service "some-php-app", {
php: "/nginx"
}
}
}
The syntax that describes other services is the following: domain/service
.
If the service is configured at the root of the tree (and therefor not in any domain), the domain
part can simply be left blank.
Service files are files that describe… a service.
They mostly define what tokens they provide or depend on and the code to run in order to generate the service’s configuration.
service "nginx", {
-- Generated tokens.
provides "http", {}
provides "php", {}
-- Required tokens.
depends "http", {
-- Not configuring a source may not be an issue if “optional”.
optional: true
-- What ports to request if the token is not provided.
-- Typically, public services will use ports if not “piped” through
-- another dæmon.
publicPorts: {80, 443}
}
-- Configuration generation comes here.
-- You may import any Lua libraries you wish, but you’ll get errors
-- and crashes if they are missing.
configure: =>
os.execute "mkdir -p /etc/nginx"
-- First parameter is the template to load. Second one is the file
-- that will be generated using that template.
-- Templates are .ept files (plain etlua files), usually stored next
-- to the service files.
@\writeTemplate "nginx", "/etc/nginx/#{@\getDomain! or "@"}-config"
}
A print
command is available from the tool’s CLI.
This command prints the tree of domains and services, as well as their status and possible reason for failing.
moon yunoconfig.moon print
Because each service requirement can be misconfigured for a different reason, they are all printed with their respective status as well.
The generate
command (from the tool’s CLI) will generate the configuration.
moon yunoconfig.moon generate