Move control sockets out of /tmp

Along with the move, please update the default configuration for /etc/kea/kea-ctrl-agent.conf to refer to the appropriate location

Hm, this may pose a problem.

These sockets are created by each daemon, and their path is specified
in the respective configuration files:

kea-dhcp-ddns-server: /etc/kea/kea-dhcp-ddns.conf
kea-dhcp4-server: /etc/kea/kea-dhcp4.conf
kea-dhcp6-server: /etc/kea/kea-dhcp6.conf

At first I thought I just update the shipped config, user may get a
dpkg conf prompt, decides to apply it or not, things keep working
either way.

But there is another server, a control agent:
kea-ctrl-agent: /etc/kea/kea-ctrl-agent.conf

This guy doesn't create unix sockets, but it needs to know where the
unix sockets for the 3 other services are. This is specified in its
own configuration file.

In other words, the 4 config files need to agree about where the sockets are.

Example of a broken upgrade:
It's very likely that the dhcp server config file, be it ipv4 or ipv6,
will be changed by the admin to specify networks, pools, etc. So when
he gets a prompt, he will, for example, refuse the new file. So the
socket stays in /tmp.
But then kea-ctrl-agent.conf comes along, and that file was not
changed by the admin. pkg then installs the new copy, which will have
the new socket location. When kea-ctrl-agent starts, it won't find the
dhcp4 socket in the new location, and fail.

I can try to add smarts to postinst, but I'm asking around first to see if that's even allowed, as config files would be changed by postinst.

I reported this upstream (see linked bug), and it got triaged and added to the kea2.3.0 milestone [1].

I'm committed to fix this in Debian before the Bookworm freeze, but I'd like to follow / cherry-pick what upstream does, so for the moment I'll leave things as they are and follow the upstream issue.

[1] https://gitlab.isc.org/isc-projects/kea/-/milestones/59#tab-issues

I don't think this has been really fixed upstream. I reopened the upstream issue.

> I reported this upstream (see linked bug), and it got triaged and added to the kea2.3.0 milestone [1].

I can't find it in that page, do you have a direct link to the issue perhaps?

Ah, found it: https://gitlab.isc.org/isc-projects/kea/-/issues/2495

In Progress: https://salsa.debian.org/debian/isc-kea/-/merge_requests/15

This bug was fixed in the package isc-kea - 2.2.0-2

---------------
isc-kea (2.2.0-2) unstable; urgency=medium

  [ Athos Ribeiro ]
  * d/tests: add simple DEP8 smoke tests
  * Set default control sockets location to /run/kea (Closes: #1014929)
    (LP: #1863100)

  [ Paride Legovini ]
  * d/control: drop dependency on lsb-base (obsolete)
  * d/salsa-ci.yml: enable the autopkgtest job
  * d/kea-common.*:
    - Do not install keactrl. The keactrl script is not systemd-aware and not
      installed by the upstream .deb packages. Remove it from the Debian
      packaging
    - Leave handling of /var/*/kea directories to systemd. No need to create
      them in packaging as the systemd units will automatically create them
      with the right ownership and permissions
  * d/*.service:
    - Do not set KEA_LOGGER_DESTINATION. The variable is meant to tell the
      daemons where to log *before* their config files are loaded. If unset
      the default is stdout, which works well with systemd
    - Do not set KEA_PIDFILE_DIR. What we set it to corresponds to the
      defaults. The documentation says that KEA_PIDFILE_DIR "is intended
      primarily for testing"
  * d/rules: use the systemd journal for logging (Closes: #1016747)
    (LP: #2006522)
  * d/kea-doc.README.Debian: document how logging is done by default
  * d/tests/smoke-tests: check location of PID and lock files

 -- Athos Ribeiro <email address hidden> Tue, 14 Feb 2023 11:24:58 -0300