[Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337

--- Comment #10 from Cy Schubert <cy at FreeBSD.org> ---
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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.