Re: Fixing the "kdc" startup file.

> On Apr 5, 2023, at 7:09 AM, Cy Schubert <Cy.Schubert@cschubert.com> wrote:
> 
> In message <48fa4fc5-76c0-3cd1-eda6-bc71dbcd4db3@prime.gushi.org>, "Dan 
> Mahoney
> (Gushi)" writes:
>> Hey there all,
>> 
>> I'm hitting the issue where we use MIT krb5kdc at work, but the port 
>> doesn't provide its own startup file
>> 
>> Previously, I'd been told (I think by the maintainer) to just set 
>> kdc_program and the like in rc.conf, but that really doesn't solve things: 
>> the one in base is sorely lacking (find_proc doesn't work with it, it 
>> doesn't restart cleanly, it doesn't give you a way to have krb5kdc specify 
>> a pid file).
>> 
>> Setting things like:
>> 
>> kdc_pidfile=/var/run/krb5kdc.pid
>> kdc_args="-P /var/run/krb5kdc.pid"
>> 
>> in rc.conf do nothing because the existing rc.d script doesn't provide a 
>> way to override them.
>> 
>> For starters: Heimdal has no pidfile support, bit it could get one if 
>> launched under daemon(1) -- heimdal doesn't even detach by default -- the 
>> rc.d file sets --detach.  MIT only creates one if you specify -P, and 
>> there's no corresponding kdc.conf knob.
>> 
>> While we're at it,
>> 
>> ====
>> 
>> There's this very old bug that references this, last touched in 2020, 
>> closed unsuccessful.  I want to fix it.
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197337
> 
> IIRC this bug the resolution was to install the rc files.
> 
> Plans are in the works to replace Heimdal in base with MIT (through a 
> staged approach). Any new rc scripts will serve to further confuse an 
> already confusing (for users) situation.
> 
> A possible interim measure might be new port/package which simply provides 
> generic rc scripts for MIT, which could be extended when MIT replaces 
> heimdal in base.
> 
>> 
>> ====
>> 
>> I've written a number of startup files for our own services at work (we 
>> use puppet, so it relies on the built-in BSD framework to start, stop, and 
>> refresh services cleanly).
>> 
>> If I supplied startup files for mitkdc, mitkadmin, mitkpropd, would they 
>> be useful?
> 
> We already have one.
> 
> Historically kpropd has been run from inetd.  There is a daemon mode but 
> IMO running it through inetd takes fewer resources.
> 
> There is also a kdc shell script to be used as a drop-in replacement for 
> heimdal's kdc, accepting the same arguments.
> 
>> 
>> I'll note, this is not an "urgent" thing.  I'm planning to be at BSDCan. 
>> If others want to meet me there and hack on this, I'm a chunky guy with 
>> blue hair and am hard to miss.
> 
> I have no plans to go to BSDCan this year. Maybe next year.
> 
>> 
>> -Dan
>> 
>> -- 
>> 
>> --------Dan Mahoney--------
>> Techie,  Sysadmin,  WebGeek
>> Gushi on efnet/undernet IRC
>> FB:  fb.com/DanielMahoneyIV
>> LI:   linkedin.com/in/gushi
>> Site:  http://www.gushi.org
>> ---------------------------
> 
> Can you post the relevant lines in your rc.conf, please.

The standard ones:

kdc_enable="YES"
kdc_program="/usr/local/sbin/kdc"

## these don't do anything useful
kdc_pidfile=/var/run/krb5kdc.pid
kdc_args="-P /var/run/krb5kdc.pid"
kdc_procname="krb5kdc"

root@k1:/etc/rc.d # service kdc status
kdc is not running.
root@k1:/etc/rc.d # ps auxwww|grep kdc
root   60106   0.0  0.1 17960 8484  -  Is   14:06      0:00.08 /usr/local/sbin/krb5kdc
root   60214   0.0  0.0 11288 2596  0  S+   14:14      0:00.00 grep kdc

Note that, even without pid file support, adding this to rc.d/kdc at least gives you a useful “status” command:

procname=${kdc_procname:-/usr/local/sbin/krb5kdc}
root@k1:/etc/rc.d # service kdc status
kdc is running as pid 60106.

Which, when we need puppet runs to be idempotent, matters.

-Dan


> 
> 
> -- 
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
> NTP:           <cy@nwtime.org>    Web:  https://nwtime.org
> 
> 			e^(i*pi)+1=0
> 
> 
> €€€€€€€€נ