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.
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.
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. Thoughts?
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? kdc_enable="base" -> enables /etc/rc.d/kdc and ignores /usr/local/etc/rc.d/kdc kdc_enable="pkg" -> ignores /etc/rc.d/kdc and enables /usr/local/etc/rc.d/kdc kdc_enable="YES" -> enables both
That seems a bit complex. How about this? Keep the variable names the same for base, e.g., kdc="YES" MIT krb5 ports use, mit_kdc="YES" mit_kadmind="YES" -- 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, heimdal_kdc="YES" 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.)
(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?
Sendnail uses mailer.conf.
(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.
Then we must use a single rc script in /etc/rc.d/. /etc/rc.d/dhclient might be a template. dhclient_enable="YES" dhclient_program="/sbin/dhclient" # Path to dhcp client program. # or dhclient_program="/usr/local/sbin/dhclient" # isc-dhclient dhclient_flags="" etcetera.... 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.
Ping.
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.)
"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 kerberos5_server_flags="" Because /etc/rc.d/kerberos contained: kerberos5_flags="${kerberos5_server_flags}" 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: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197339 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!
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: 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.
I'll take this and discuss with folks at freebsd.org.
Created attachment 212814 [details] Diffs to form MIT kadmind /usr/local/etc/rc.d/ script
Created attachment 212815 [details] Diffs to form MIT kdc /usr/local/etc/rc.d/ script
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: mitkdc_enable="YES" mitkdc_program="/usr/local/sbin/krb5kdc" mitkdc_flags="" mitkadmind_enable="YES" mitkadmind_program="/usr/local/sbin/kadmind" On the replicas I use the following configuration: mitkdc_enable="YES" mitkdc_program="/usr/local/sbin/krb5kdc" mitkdc_flags="" kpropd_enable="YES" 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: /usr/local/etc/rc.d/mitkadmind /usr/local/etc/rc.d/mitkdc
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 slippy$ 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?
>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 >slippy$ > >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? **tl;dr:** - 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: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_flags="" kerberos5_server_enable="YES" kadmind5_server_enable="YES" 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.
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.
>...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.
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.
Two reviews to address this: Handbook: https://reviews.freebsd.org/D24253 rc sripts: https://reviews.freebsd.org/D24252
Can you list uname -a please.
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: FreeBSD [HOSTNAME] 12.1-RELEASE FreeBSD 12.1-RELEASE GENERIC amd64 Thanks for your work on this!
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().
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.
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 Log: 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 Changes: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
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 Log: 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 Changes: head/libexec/rc/rc.d/Makefile head/share/mk/bsd.opts.mk head/share/mk/src.opts.mk head/tools/build/mk/OptionalObsoleteFiles.inc
Reverted due to popular demand. Port patches are welcome. The patches attached to this PR are incomplete and thus rejected.
Created attachment 242534 [details] make rc.d/kdc more compatible with non-base Kerberos There's an issue with the /usr/local/sbin/kdc wrapper approach when using MIT Kerberos from ports - it leaves the "service kdc status" command unable to check whether the kdc is running or not. In our puppet environment this causes every run of the puppet agent to start another instance of krb5kdc. I tried to resolve this using kdc_procname or by adding PID flags to kdc_flags, but with no success: 1. /etc/rc.conf can't be used to set the non-service-prefixed globals $procname or $pidfile 2. base kdc doesn't support PID fies. My proposed fix to /etc/rc.d/kdc is to explicitly set the default kdc executable to /usr/libexec/kdc and only add the --detach flag if this remains unchanged. With this in place there's no need for the wrapper and kdc_program can be pointed directly at /usr/local/sbin/krb5kdc
p.s. although the original bug report is for 10.1, the patch was generated on a 12.4 system and applies cleanly on 13.1
apologies - there's a missing space before the `]` in the `if` command that wasn't picked up in my testing.