Incremental Propagation and kpropd

[Jeremy Hunt]

Hi there vs_krb,

It appears that incremental propagation before version 1.11 will not be 
able to do a fulll propagation when kpropd is configured to run from 
inetd. From the code, it looks like 1.11 may have solved this problem, 
but I am looking to test this to confirm it in a couple of days. (I am 
not a developer from MIT by the way).

In any case for an incremental propagation installation I would 
recommend running kpropd standalone on the slaves and not configuring 
inetd to answer the propagation port. The propagation port is krb5_prop 
which is 754 generally, the value on your system is defined in your 
/etc/services file.

In incremental propagation mode the propagation logs are always circular 
logs and are rolled after a number of entries has been reached. This 
number is configurable, see the next paragraph. Incremental propagation 
works by comparing the version numbers of the propagation logs of the 
master and the slaves, any updates on the master are propagated to the 
slaves on a different port which you can configure in your kdc.conf (in 
ours iprop_port = 2107). The slaves update their version of the 
propagation log when these updates have been applied. If the number of 
entries in the propagation log on the master to be copied to the slave 
are greater than the rollover amount, a full propagation is initated by 
the master. The master then talks directly to the kpropd on the slave 
via the krb5_prop port. This works fine if inetd is not configured to 
listen on the krb5_prop port.

The number of entries in the master's propagation log is 1000 by 
default, you can increase this or decrease it by setting the parameter 
"iprop_master_ulogsize" in kdc.conf. The maximum size you can configure 
is 2500 entries.

iprop_logfile is the tool used to interrogate the state of your 
incremental logfile.

You might want to read this for other configurable options.
http://web.mit.edu/kerberos/krb5-current/doc/admin/database.html

If you have doubts about the timing of full and incremental propagation, 
set up a test bed appropriately sized  for your implementation. Set up 
shell scripts generating roughly the expected rate of updates you expect 
or know about your system and force a full update every now and then. 
You could force a full update at the highest and lowest expected rate of 
updates to see how your systems would cope.

You can force a full update in incremental propagation mode by deleting 
the incremetal logfile on the master or the slave. Ours is called 
"principal.ulog.", but you can change the name of your file with the 
iprop_logfile entry in the kdc.conf file.

You can write a shell script to execute kadmin.local -q 'cpw -pw 
<anyPassword> anyPrincipal' for a number of principals with the 
appropriate timing to generate the background incremental updates.

I hope this helps you,

Jeremy

vs_krb at aol.com wrote:
> Hi There
>
> I am trying to setup our kerberos to work with incremental propagation. Currently its turned off and we push updates from master to slaves. I am able to get iprop to work but it looks like we need to change the kpropd  slave setup. We at present run it out of inetd but it looks like we need to take it out of inetd and  run kpropd on the slaves in a standalone daemon mode. If this sounds not right, please let me know.
>
> >From the MIT documentation for iprop i see "The normal kprop mechanism is disabled by the incremental propagationsupport.  However, if the slave has been unable to fetch changes fromthe master KDC for too long (network problems, perhaps), the log onthe master may wrap around and overwrite some of the updates that theslave has not yet retrieved.  In this case, the slave will instructthe master KDC to dump the current database out to a file and invoke aone-time kprop propagation, with special options to also convey thepoint in the update log at which the slave should resume fetchingincremental updates.  Thus, all the keytab and ACL setup previouslydescribed for kprop propagation is still needed"
>
> So this raises few questions for me.
>
> 1) With incremental propagation I believe, I can turn off kpropd on master and run only on slave in standalone mode. So as stated above in case of issues, will the slave be requesting a full propagation and pulling the full copy or does it have to be initiated by the master via kprop. If the master has to initiate a kprop, the kpropd on the slave is not going to be listening on the same port, i think this would be a problem.
> 2)  How can we manage the size of iproplog specified using iprop_logfile, what is the best way to rotate it?
> 3)  Is the update log same as the one specified with iprop_logfile, it seems that way from the documentation.
>
> Any other info on best practices for switching to iprop pull configuration would be appreciated.
>
> Thanks,
>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos