Date: Fri, 06 Feb 2015 08:38:58 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 197337] rc.d/kdc missing with WITHOUT_KERBEROS, but Kerberos ports need it Message-ID: <bug-197337-8-O9s9rqG1rA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-197337-8@https.bugs.freebsd.org/bugzilla/> References: <bug-197337-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337 --- Comment #10 from Cy Schubert <cy@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-197337-8-O9s9rqG1rA>