Bug 237909 - net/kea: new rc script
Summary: net/kea: new rc script
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Hiroki Sato
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-15 10:40 UTC by Martin Pietsch
Modified: 2019-11-07 15:33 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (hrs)


Attachments
compressed archive of the modified net/kea port (6.16 KB, application/x-xz)
2019-05-15 10:40 UTC, Martin Pietsch
no flags Details
patch for Kea's rc file without nojail keyword (2.38 KB, patch)
2019-11-07 09:42 UTC, Martin Pietsch
no flags Details | Diff
Makefile patch of Kea's port to provide a new rc file (752 bytes, patch)
2019-11-07 09:45 UTC, Martin Pietsch
no flags Details | Diff
patch for Kea's rc file without nojail keyword (302 bytes, patch)
2019-11-07 09:51 UTC, Martin Pietsch
no flags Details | Diff
pkg-plist patch of Kea's port to provide a new rc file (279 bytes, patch)
2019-11-07 09:52 UTC, Martin Pietsch
no flags Details | Diff
new rc file for Kea (2.38 KB, application/x-shellscript)
2019-11-07 09:53 UTC, Martin Pietsch
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Pietsch 2019-05-15 10:40:01 UTC
Created attachment 204390 [details]
compressed archive of the modified net/kea port

To whom it may concern,

I have a question concerning the Kea DHCP Server package of the FreeBSD repository. But at first I want to describe what I want to do, what problems I have and how I have solved them.

I want to provide the Kea DHCP service within a jail container. Furthermore, I want to manage this service with Ansible. During the installation and configuration of that service, I noticed two problems with the rc script of Kea.

The first problem relates to the use of Kea within a jail container. The usage of Kea within a jail container is easily possible and it is also described in the Kea Documentation since Kea version 1.4 (https://ftp.isc.org/isc/Kea/cur/doc/Kea-guide.pdf, page 39). The problem is now that the keyword "nojail" in Kea's rc script prevents the service from starting automatically when the jail container starts.

The second problem has to do with the invocation of rc script. This current script uses the keactrl tool to start one or more of the services that are provided by the Kea suite and all information on which services have to be started can be found in the keactrl.conf file. The problem is that the returncode of keactrl is usually 0. The same is true if you want to check the state of a single service of this suite. Normally, the service(8) command returns a 0 if a service is running and 1 if the service is not running. In the case of the Kea's rc script the keactrl displays a conclusion of all services states on stdout and returns always 0. Especially configuration management systems, in my case Ansible, and other programs or scripts use the returncode of the service(8) command to determinate the state of a service. For example Ansible checks the state of a service before it starts or stops this. So it is not possible to start a Kea service as usual.

To solve these problems, I developed a new rc script for the Kea suite which can be used within a jail container and controls each service separately. The control is done by using the name of the invoked rc script, so that all Kea services only have to be a soft link to this new rc script.
A compressed archive of the modified net/kea port can be found in the attachment.

And now back to my question. Is it possible to replace the current Kea rc script in the port source with the rc script I developed or add it to the port source?

I thank you in advance for your answer.

Best regards
Martin
Comment 1 Jose Luis Duran 2019-10-28 20:13:28 UTC
(In reply to Martin Pietsch from comment #0)

1. Regarding the first issue, if you just remove the 'nojail' keyword, are you able to run Kea successfully inside a jail? I am interested in using this approach as well.

2. I do not think this is a future-proof solution. I would suggest fixing keactrl's '-s' switch upstream (I don't think it's working at the moment), altogether with its exit code.

As a side note, could you submit your suggestions as a patch (uncompressed)?

Thank you!
Comment 2 Martin Pietsch 2019-11-07 09:42:41 UTC
Created attachment 208936 [details]
patch for Kea's rc file without nojail keyword
Comment 3 Martin Pietsch 2019-11-07 09:45:10 UTC
Created attachment 208937 [details]
Makefile patch of Kea's port to provide a new rc file
Comment 4 Martin Pietsch 2019-11-07 09:49:05 UTC
Comment on attachment 208936 [details]
patch for Kea's rc file without nojail keyword

--- kea.orig/files/kea.in	2019-11-05 13:39:02.428216863 +0100
+++ kea/files/kea.in	2019-11-05 13:53:53.760854516 +0100
@@ -3,7 +3,7 @@
 #
 # PROVIDE: kea
 # REQUIRE: netif routing
-# KEYWORD: nojail shutdown
+# KEYWORD: shutdown
 
 #
 # Add the following to /etc/rc.conf[.local] to enable this service
Comment 5 Martin Pietsch 2019-11-07 09:49:55 UTC
Comment on attachment 208936 [details]
patch for Kea's rc file without nojail keyword

--- kea.orig/files/kea.in	2019-11-05 13:39:02.428216863 +0100
+++ kea/files/kea.in	2019-11-05 13:53:53.760854516 +0100
@@ -3,7 +3,7 @@
 #
 # PROVIDE: kea
 # REQUIRE: netif routing
-# KEYWORD: nojail shutdown
+# KEYWORD: shutdown
 
 #
 # Add the following to /etc/rc.conf[.local] to enable this service
Comment 6 Martin Pietsch 2019-11-07 09:51:37 UTC
Created attachment 208938 [details]
patch for Kea's rc file without nojail keyword
Comment 7 Martin Pietsch 2019-11-07 09:52:46 UTC
Created attachment 208939 [details]
pkg-plist patch of Kea's port to provide a new rc file
Comment 8 Martin Pietsch 2019-11-07 09:53:40 UTC
Created attachment 208940 [details]
new rc file for Kea
Comment 9 Martin Pietsch 2019-11-07 09:55:53 UTC
I'm sorry the answer took so long.

Here are my answers now:

Yes, Kea runs very well inside a jail. There is even the possibility to run a HA-cluster with primary, secondary and backup (jail)nodes. My current configuration consists of a primary and secondary node on two machines.
But you have to pay attention, if you want run a Kea jail with a virtual network interface that is connected with the real network via NAT and port forwarding. In this case "bootp" requests will not reach the server inside the jail. In order to ensure that "bootp" requests can also be processed by the server, it is necessary to "unhide" the bpf-devices of the jail host for the Kea jail. This is done with the devfs rules.

The keyword "nojail" prevents the automatic start of a rc file inside a jail. This is also described in the man page of rc(8) in point 5 of the section "Operation of rc". A service marked with this keywork is not automatically executed when the jail starts. But that is not what I want. So I removed it and everything was well. The patch file "patch-files-kea.in" contains this change.

The patch files "patch-Makefile" and "patch-pkg-plist" and the file kea_dhcp4.in are used for my suggestion of a new rc file for Kea. I hope that is right. 

The patch files "patch-Makefile" and "patch-pkg-plist" and the file kea_dhcp4.in are used for my suggestion of a new rc file for Kea. By linking the rc file kea_dhcp4 to kea_dhcp6, kea_ctrl_agent etc it is possible to start each server individually and to get the correct exit code of them. I hope this is the right way to provide such patches.
Comment 10 Jose Luis Duran 2019-11-07 15:33:08 UTC
(In reply to Martin Pietsch from comment #9)

Thank you for your explanation. I'll test Kea contained in a jail, that one should be an easy fix.

Regarding the other suggestion, splitting the services into individual services (and rc scripts) instead of using keactrl, I still think it's better to fix it upstream.  Right now, issuing `keactrl status -s dhcp6`, for example, does not work, as can be seen in the current implementation of keactrl:

https://gitlab.isc.org/isc-projects/kea/blob/628d764179824329a5c654d69a9934f174d23e4a/src/bin/keactrl/keactrl.in#L395

The `-s|--server` flag is essentially a NOP.  Once this is working, you should be able to control individual servers using this flag regardless of the platform you are running Kea on, and have the appropriate exit code.  So I still think you should pursue your suggestion (2) upstream.  However, this decision is up to the maintainer.