It's a dict, and in SlapOS usage of Jinja2 it's good to see the type of
a variable immediately.

That's true, that those are templates, but the important information which
shall be in the name of the parameter is its purpose - a profile.

Each node allows for global statistic access for full backend-haproxy, which
is exposed using special frontend, and then transferred back to the master
partition, so that the administrator can access it.

Thanks to using check_execute_command with logrotate -d one can assure, that
logrotate is for sure correctly configured.

By disabling delaycompress filenames are going to be stable, on delaying the
compression is not needed.

By using nginx it's possible to set it up to expose logs nicely with the
real frontend.

furl is used to rewrite URL from the frontend to add proper username and
password information.

Backend logs are exposed as usual access and error logs.

By using rsyslogd templates and regex filtering, the rsyslogd reacts itself
and creates needed files per each slave which accesses it. Thanks to this, it's
configuration is static from point of view of SlapOS profiles, and can be
generated once.

As the rsyslogd configuration became fully special to backend-haproxy, the
rsyslogd template filename and its references has been correctly renamed.

Logs are critical for caddy-frontend, so let's configure rotate-num locally,
as changes in the stack can come unattended, and can result with loosing logs.

We moved out from local logrotate configuration long time ago, it was just
leftover.

The logrotate folder also serves as an publication folder for logs, so be sure
that logs are linked there.

By default do not offer authentication certificate, the switch
authenticate-to-backend can be used on cluster or slave level to control
this feature.

rsyslogd is used, as haproxy does not support writing log files by its own.

This is needed in order to provide future support for client certificates
to the backend.

Also it means that haproxy is used in all cases, with or without cache, and as
a result the "cached" version of caddy is dropped.

Let haproxy setup maxconn by itself, as it's wise enough.

Also trust that it'll detect and use proper limits, instead enforcing them in
the shell with ulimit trick (ulimit -n $(ulimit -Hn)).

As empty server alias can impact the configuration, add proper test for
checking it.

Instead of passing various kedifa information to the profile generating
configuration use section kedifa-configuration and access later such grouped
values.

In context of frontend node reuse passed directory section to slave
configuration to improve readability and simplify future enhancements.

Customized configuration support is not used since introduction of
Caddy software, so there is no need to support it anymore.

We were using caddy-log-access-header to make sure we have at least one
file to include, but this was implemented in a way that the config file
was overwritten.
Reimplement this by using caddy-log-access-empty to create an empty file
when there are no slaves, caddy-log-access otherwise.

The same caddy-log-access section was defined more than once, keep only
one implementation.
Remove some trailing spaces.

Prevent creating 2 wrapper for the same service if hash changed. Here, one service is exited because port is used by the firt to service to start:

    slappart6:runner-sshd-4248650e36a9a26a6481df1baffd9f58-on-watch                RUNNING   pid 27835, uptime 0:03:45
    slappart6:runner-sshd-b3b68f4278ceb84691ec27521ea229eb-on-watch                EXITED    Mar 06 04:52 PM

To achieve that, update slapos.cookbook and use hash-existing-files option of wrapper recipe

hash-existing-files list all the files used for hash that are not
handled by buildout. For those files, the hash is calculated as soon as
the __init__ function so that if there is a change in those files,
buildout will remove the existing wrapper (it will uninstall the
section) and replace it with the new wrapper.

/reviewed-on nexedi/slapos!525

Sorting will make dumped data "canonical", so it will limit amount of order
based changes.

It defaults to 600s, which is good reasonable chosen before.

Added part for logrotation into part_list, resulting with installing it.

/reviewed-on nexedi/slapos!606

/reviewed-on nexedi/slapos!597

In some cases domain can come from "outside" of the profile, and be filled
with "garbage", so if custom_domain is set, do not overwrite it.

/reviewed-on nexedi/slapos!575

Kedifa partition was missing monitoring at all, so add it and monitor kedifa
and exposer ip and port.

Partition running caddy was missing monitoring for exposer, so add it.

Use unreal address to avoid any tries for network connectivity.

Kedifa requires some time to process new slave, and during that time the key
download URL is not available, but as it is required for proper mapping file,
use some url to mimic it.

During buildout run no network communication is required in order to prepare
fallback certificates, so call kedifa-updater with --prepare-only

Each time new slave appears the kedifa-updater has to be run immediately, in
order for certificates to be properly setup.

Otherwise caddy can be left in non-runnable state until next kedifa-updater
would run again.