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: Closed Not Accepted
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: 2020-04-19 21:44 UTC (History)
4 users (show)

See Also:

Diffs to form MIT kadmind /usr/local/etc/rc.d/ script (1.10 KB, patch)
2020-03-28 23:05 UTC, Stephen E. Halpin
no flags Details | Diff
Diffs to form MIT kdc /usr/local/etc/rc.d/ script (1014 bytes, patch)
2020-03-28 23:05 UTC, Stephen E. Halpin
no flags Details | Diff
Final version to be committed (2.25 KB, patch)
2020-04-18 03:12 UTC, Cy Schubert
no flags Details | Diff

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.
Comment 14 Stephen E. Halpin 2020-03-28 23:05:09 UTC
Created attachment 212814 [details]
Diffs to form MIT kadmind /usr/local/etc/rc.d/ script
Comment 15 Stephen E. Halpin 2020-03-28 23:05:49 UTC
Created attachment 212815 [details]
Diffs to form MIT kdc /usr/local/etc/rc.d/ script
Comment 16 Stephen E. Halpin 2020-03-28 23:09:06 UTC
This was still a problem with FreeBSD 12.1 and the krb5-117-1.17.1
package as of the end of December 2019 and is an issue with both the
actual scripting and the handbook.  The problem is the default Heimdal
code doesn't detach by default and the MIT code does and the MIT package
attempts to share the /etc/rc.d/ scripts which can't drive both unchanged.

The following is an "it seems to work" workaround.  There are many (likely
better!) ways to solve this but hopefully if people run into this problem
and find this bug report it might get them off the ground while a better
solution is developed.

On the master I use the following configuration:



On the replicas I use the following configuration:



The MIT package brings in a unique kpropd so that gets used as is.
The other two service scripts are derived from the original scripts
in /etc/rc.d with the attached patches and placed in:

Comment 17 Cy Schubert freebsd_committer 2020-03-29 00:20:53 UTC
Post the following output, please.

slippy$ grep kdc /etc/rc.conf
kdc_enable="YES"		# Run a kerberos 5 KDC (or NO).
kdc_program="/usr/local/sbin/kdc"	# path to kerberos 5 KDC
kdc_flags=""			# Additional flags to the kerberos 5 KDC

kdc_progran should be /usr/local/sbin/kdc, not krb5kdc.

Also, if secirity/krb5* ports are supposed to provide anrc script, why not security/hiemdal too?
Comment 18 Stephen E. Halpin 2020-03-31 17:01:22 UTC
>Post the following output, please.
>slippy$ grep kdc /etc/rc.conf
>kdc_enable="YES"		# Run a kerberos 5 KDC (or NO).
>kdc_program="/usr/local/sbin/kdc"	# path to kerberos 5 KDC
>kdc_flags=""			# Additional flags to the kerberos 5 KDC
>kdc_progran should be /usr/local/sbin/kdc, not krb5kdc.
>Also, if secirity/krb5* ports are supposed to provide anrc script, why not security/hiemdal too?

- MIT ports people have been using for at least five years don't currently provide rc scripts
- Both MIT and Heimdal ports/packages should install their own unique non-conflicting rc scripts
- The FreeBSD Handbook needs updating

Since I'm the only person who has written here in nearly two years I'm blindly assuming this request was directed to me.

My *workaround* is just to provide rc scripts to make the MIT package run as it doesn't have its own rc scripts.  The FreeBSD Handbook (https://www.freebsd.org/doc/handbook/kerberos5.html) section 13.5.4 claims MIT Kerberos (krb5-117-1.17.1 is the package I'm using on FreeBSD 12.1) can be made to use the base system rc scripts in /etc/rc.d/ with:


The problem is the base system Heimdal servers don't (background|detach|run_as_daemon|similar_terms) and require the scripts to add to the command line to make this happen.  Unfortunately the MIT code does automatically run as daemons and the flags hard-coded into the base system /etc/rc.d/ scripts aren't compatible with the MIT code.  Comment 1 implies they built a system without the base scripts but the MIT distribution wouldn't work even if the base system's scripts were there.

One option is to have unique scripts for base Heimdal, port/package Heimdal and port/package MIT.  Simple rc.conf changes allow quick changing from one to another and each port is self contained.  Trying to use one set of scripts  in the base system for all three means unexpected port changes may require base system changes which is unneeded coupling.

Either way the Handbook still needs to be updated.

Note the rc environment variable names in the Handbook seem really off from a base r12.1 install with no additional ports/packages:

$ egrep '(kdc|krb|kadmin)' /etc/defaults/rc.conf

kdc_enable="NO"                 # Run a kerberos 5 KDC (or NO).
kdc_program="/usr/libexec/kdc"  # path to kerberos 5 KDC
kdc_flags=""                    # Additional flags to the kerberos 5 KDC
kadmind_enable="NO"             # Run kadmind (or NO)
kadmind_program="/usr/libexec/kadmind"  # path to kadmind
ipropd_master_keytab="/etc/krb5.keytab" # keytab for ipropd-master.
ipropd_slave_keytab="/etc/krb5.keytab"  # keytab for ipropd-slave.
Comment 19 Cy Schubert freebsd_committer 2020-03-31 17:36:30 UTC
The handbook should be updated. I'll work with a doc committer to facilitate that.

As to each port providing its own rc script, I'll submit a review to install the base rc scripts regardless. That should satisfy all requirements.
Comment 20 Stephen E. Halpin 2020-04-01 17:28:14 UTC
>...That should satisfy all requirements.

I'm assuming Comment 1 started this with the fact that the MIT distributions didn't have rc scripts.  Since the MIT distributions were incompatible with the base scripts it seems this bug should be forwarded to the port/package owner as whatever solution they {,will} have has to be in place before the MIT part of the Handbook can be updated with working rc.conf bits.
Comment 21 Cy Schubert freebsd_committer 2020-04-01 17:35:58 UTC
I am the port/package owner and am one of the people responsible for kerberos in base.

I will make sure the documentation is updated. The documentation isn't even relevant for the base kerberos.

The ${LOCALBASE}/sbin/kdc script was created to allow krb5kdc to be started with the base rc scripts. It was the least intrusive method to solve the problem.

Regarding installing the rc scripts in base when kerberos is excluded from base, that too will be addressed.

To have multiple scripts, one for each package and one for base can result in people attempting to start multiple copies of the kdc, all but one failing, resulting in even more PRs. The goal is to provide one approach to starting all flavours of kerberos.

I should be able to get around to this next week sometime.
Comment 22 Cy Schubert freebsd_committer 2020-04-01 19:10:23 UTC
Two reviews to address this:


rc sripts:
Comment 23 Cy Schubert freebsd_committer 2020-04-02 02:03:40 UTC
Can you list uname -a please.
Comment 24 Stephen E. Halpin 2020-04-02 18:17:47 UTC
My apologies for missing the fact that there is a shell script in /usr/local/sbin/ called kdc which removes the --detach flag.  I've updated my rc.conf to use the edits from the Handbook you submitted and it invoked this script and worked fine so that's an already solved problem.

The "uname -a" (minus hostnames) for my kerberos servers are:


Thanks for your work on this!
Comment 25 Cy Schubert freebsd_committer 2020-04-02 18:35:04 UTC
The shell script was the least intrusive way to resolve the problem. Otherwise I would need to implement getopt_long() and if doing so would need to support all the Heimdal kdc options in getopt_long(). MIT krb5kdc uses only getopt().
Comment 26 Cy Schubert freebsd_committer 2020-04-18 03:12:38 UTC
Created attachment 213516 [details]
Final version to be committed

Final version to be committed. Apply it to /usr/src, buildworld, installworld, then mergemaster or etcupdate.
Comment 27 commit-hook freebsd_committer 2020-04-19 17:01:33 UTC
A commit references this bug:

Author: cy
Date: Sun Apr 19 17:01:17 UTC 2020
New revision: 54063
URL: https://svnweb.freebsd.org/changeset/doc/54063

  Properly document invoking MIT Kerberos daemons through rc.conf.
  This commit chases r270782 in base which renamed the kerberos5_*
  varibales to their current form.

  PR:		197337
  Reported by:	Adam McDougall <ebay at looksharp.net>
  Reviewed by:	delphij, bcr
  Approved by:	delphij, bcr
  Differential Revision:	https://reviews.freebsd.org/D24253

Comment 28 commit-hook freebsd_committer 2020-04-19 17:01:36 UTC
A commit references this bug:

Author: cy
Date: Sun Apr 19 17:01:22 UTC 2020
New revision: 360102
URL: https://svnweb.freebsd.org/changeset/base/360102

  Conditionally install Kerberos rc files based on MK_KERBEROS_SCRIPTS
  instead of MK_KERBEROS. The reason for this change is some users
  prefer to build FreeBSD WITHOUT_KERBEROS, wanting to retain the
  Kerberos rc scripts to start/stop MIT Kerberos or Heimdal from ports.

  PR:		197337
  Reported by:	Adam McDougall <ebay at looksharp.net>
  Reviewed by:	imp
  Differential Revision:	https://reviews.freebsd.org/D24252

Comment 29 Cy Schubert freebsd_committer 2020-04-19 21:44:34 UTC
Reverted due to popular demand. Port patches are welcome. The patches attached to this PR are incomplete and thus rejected.