Bug 197337 - rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
Summary: rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 10.1-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: Cy Schubert
Depends on:
Reported: 2015-02-04 23:58 UTC by Adam McDougall
Modified: 2019-10-24 18:31 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adam McDougall 2015-02-04 23:58:29 UTC
I use WITHOUT_KERBEROS on my systems but I still use Kerberos from ports.  We also run some Kerberos servers, but Kerberos from ports (at least security/krb5) does not provide startup scripts.  The ports depend on the rc.d scripts from the system, such as /etc/rc.d/kdc since you can redefine the daemon path.  Fortunately 'make delete-old' does not delete /etc/rc.d/kdc.

I think the head/etc/rc.d/Makefile changes in r273285 (head) and r273286 (stable/10) should be reverted as a fix.
Comment 1 Dmitry Marakasov freebsd_committer 2015-02-05 01:14:08 UTC
The solution you propose doesn't seem to be correct - base system and ports should not be dependent on each other this way. Instead, kerberos port should likely be fixed to take care of its rc.d file. CC krb5 and haimdal port maintainers.
Comment 2 Cy Schubert freebsd_committer 2015-02-05 02:14:32 UTC
The question is, should /etc/rc.d/kdc be the correct file or should the krb5 ports use their own file? I could argue it both ways but we should look at existing and prior precedents such as,

- named (when it was still in base), bind9X ports
- sendmail (in base), sendmail (in ports), postfix, exim, etc...
- ntp (in base), ntp (in ports), and ntp-devel
- there are probably others that don't come to mind right now.

I'd like to keep the approach consistent across all classes of software.

Having said that, I can argue for ${LOCALBASE}/etc/rc.d/kdc if all other ports do the same or if that is our direction. I think a bigger discussion is needed to set the standard.

Comment 3 Hiroki Sato freebsd_committer 2015-02-05 03:32:51 UTC
I also think they should be independent from each other.  A port is responsible for installing rc.d scripts if needed.

As you noticed, the problem is that collision of the script file name can happen.  To solve this, we need a way to select one.  I come up with something like the following, but any ideas else?

 -> enables /etc/rc.d/kdc and ignores /usr/local/etc/rc.d/kdc 
 -> ignores /etc/rc.d/kdc and enables /usr/local/etc/rc.d/kdc 
 -> enables both
Comment 4 Cy Schubert freebsd_committer 2015-02-05 03:57:49 UTC
That seems a bit complex. How about this?

Keep the variable names the same for base, e.g.,


MIT krb5 ports use,

-- adds an entry to crontab for kpropd if mit_kadmind is yes (we assume master runs kadmind thus it also runs kpropd).

Heimdal krb5 uses variables prefixed by heimdal_ instead of mit_, for example,


There may be a reason to run both simultaneously, but on different ports. (It is possible, with a little work, to have both ports and base heimdal installed on the same system.)
Comment 5 Hiroki Sato freebsd_committer 2015-02-05 04:57:22 UTC
(In reply to Cy Schubert from comment #4)

Do you mean all of the rc.d scripts installed by ports should have their own prefixes to avoid filename collision in a consistent manner?  It works for different names such as MIT and Heimdal, but what prefixes are expected for sendmail, for example?
Comment 6 Cy Schubert freebsd_committer 2015-02-05 05:15:20 UTC
Sendnail uses mailer.conf.
Comment 7 Hiroki Sato freebsd_committer 2015-02-05 05:34:04 UTC
(In reply to Cy Schubert from comment #6)

We are discussing a consistent way to support cases of possible file name collision at this moment and in the future, don't we?  I do not think prefixed variables work well for ones like sendmail, ntp, and etc.
Comment 8 Cy Schubert freebsd_committer 2015-02-05 07:08:02 UTC
Then we must use a single rc script in /etc/rc.d/. /etc/rc.d/dhclient might be a template.

dhclient_program="/sbin/dhclient"       # Path to dhcp client program.
# or
dhclient_program="/usr/local/sbin/dhclient"   # isc-dhclient


Following this example, our /etc/rc.d/kdc would need to be installed regardless of WITHOUT_KERBEROS as the submitter suggests. To have each port install its own rc.d file in /usr/local/etc/rc.d/ tying into some kind of kdc_enable rules is complex and fragile given multiple ports and base need to adhere to a single set of rules. Putting control and a single set of rules into one rc script (in /etc/rc.d/) will reduce complexity that multiple ports and base will need to adhere to.
Comment 9 Cy Schubert freebsd_committer 2015-02-06 07:37:56 UTC
Comment 10 Cy Schubert freebsd_committer 2015-02-06 08:38:58 UTC
Now that I have the time, thinking about this further, default arguments passed to heimdal kdc and MIT krb5kdc are different (the Heimdal --detach). There is no elegant solution to having MIT KRB5 and Heimdal KRB5 (in base or ports) to simply share the same startup scripts without a hack (detection of whether --detach should be used or not). I think it's best to leave the r273285 (head) and r273286 (stable/10) as is and implement port specific rc scripts in ${LOCALBASE}/etc/rc.d.

Regarding name collision, the MIT kdc is called krb5kdc and an rc script name of the same would mitigate that issue. MIT KRB5 has no kfd or kpasswdd, so no collision there either. Kadmind is the only collision. Naming tile ${LOCALBASE}/etc/rc.d/mit_kadmind might be one solution. The other is to start kadmind in the krb5kdc script but only on the master (not slave) KDC. This could be handled though a krb5kdc_master="YES" variable. One would also want to run kprop on the master through cron if one has slave KDCs to propagate to and kpropd on the slaves. The MIT kpropd is initiated through inetd.

As to how we might want to handle this in security/heimdal, The package could detect if files exist in /etc/rc.d using a post-install script and install them as necessary. This would necessitate a post-deinstall script to remove the files if necessary. Similarly, the Heimdal master kdc machine would need to periodically run hprop while the slaves run hpropd via inetd. (BTW, the base scripts don't take this into account.) The only problem I see is that if the files were not created by a post-install script and were installed by another port or by hand, summarily deleting the files at post-install would be a POLA violation but this should be an easy problem to address.

For the end-user sysadmin, providing a simple set of scripts, as we do in base, facilitates running a simple KDC but should anyone want a slave or slaves the setup becomes non-trivial. (Having done this with a master [FreeBSD] and three slaves [two FreeBSD and one Solaris] in one city and another slave [FreeBSD] in another city.)
Comment 11 Adam McDougall 2015-02-06 13:57:11 UTC
"There is no elegant solution to having MIT KRB5 and Heimdal KRB5 (in base or ports) to simply share the same startup scripts without a hack (detection of whether --detach should be used or not)."  <- There was, and it was removed by 10.1.

To be fair, I don't use kadmind now but I suspect I had it running in the past from rc scripts.

Up to and including 10.0-RELEASE /etc/defaults/rc.conf contained:
kerberos5_server_flags="--detach" # Additional flags to the kerberos 5 server

I could override it in /etc/rc.conf using:
# MIT Kerberos does not support --detach in default flags, override with empty

Because /etc/rc.d/kerberos contained:

This usage case was supported up until 10.1 where there was a regression because support for reading flags from rc.conf was removed.  It did feel slightly odd to use an empty string to avoid default arguments, but it only required editing standard configuration files so I didn't consider it a hack.

I forgot about reporting the --detach issue because it was a lesser issue compared to the script not existing, but someone else recently reported it:

I don't have integration problems with the rest of MIT Kerberos such as propagation, I setup a cron job and inetd for that.

I'm in favor of an improved solution and I'm delighted it is being discussed, but just pointing out these two issues are regressions from 10.0-RELEASE in a stable branch.  I hope it can be solved by ports changes or at least the regressions corrected before the next FreeBSD release.  Thank you all for being involved!
Comment 12 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:39 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 13 Cy Schubert freebsd_committer 2018-05-28 19:54:36 UTC
I'll take this and discuss with folks at freebsd.org.