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.

Section template-apache-frontend was not updated in buildout.hash.cfg

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.

Changes:

 * traffic_cop was removed, so use traffic_manager directly
 * logging.config was changed to logging.yaml
 * made records.config and storage.config similar to original files
 * proxy.config.admin.synthetic_port option was removed
 * proxy.config.process_manager.mgmt_port option was removed
 * test: ignore traffic.out in logs
 * test: update ATS version
 * pqsn field was removed and replaced with shn, so follow upstream:
   https://github.com/apache/trafficserver/commit/b0969c91ebc52b37f4c3195ec17d4d0c1c18650c
 * add a test to prove squid.log working, as upgrade resulted with not
   created file

As there might be some reasons why the instance is not found explain what to
in each case.

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 regular expressions, matching exact host names up to the optional
port and putting wildcard matches in the end, the Haproxy acl rules will allow
to direct request to correct backend.

Because of escaping of slapos.cookbook:wrapper kedifa is never reloaded, so
use instead jinja2 with template_wrapper for it.

Also adapt to kill from dash (-HUP).

By copy paste mistake wrong log files were configured for log rotation,
resulting with damaging logrotate for the whole partition.

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.

done with:

     npm install
     git ls-files | grep -v '\/unstable\/' | xargs ./node_modules/.bin/eclint fix
     git ls-files | grep buildout.hash.cfg | xargs ./update-hash

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.

haproxy by itself provides good information, so there is no need to add
information from rsyslogd itself.

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

There is no reason to drop connection to the backend and then reinitate it on
each request. It's better to keep connected and avoid additional work,
especially in SSL handshake.

Note: This was kept as the file has been copied from other place (haproxy
      on a backend), and slipped MR review, where MR author wanted to drop it
      anyway.

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.

Caddy's proxy stanza for defined path with spaces sometimes is working when
it's done like this:

  proxy /path with_spaces ip:port

It happens, that few first requests after starting Caddy it's working, but
then it fails with error message like:

  dial tcp: lookup with_spaces on ip: no such host

So to stabilise situation now paths are generated like:

  proxy "/path with_spaces" ip:port

ssl_proxy_ca_crt can be just empty value, and that's not acceptable.

On backend side headers are asserted in tests:

 * X-Forwarded-For
 * X-Forwarded-Proto
 * X-Forwarded-Port
 * Host

In order to pass cleanly X-Forwarded-For from the frontend to the backend,
it's passed as X-Forwarded-For-Real in case of cached slaves.

Noted problem with IPv6 endpoint was used, as in this case 6tunnel IP would
be used.

QUIC is not used at all, and became superseded by HTTP/3

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