Incremental Propagation and kpropd

[vs_krb]

Hi Jeremy

Thanks for your prompt reply, appreciate your in depth reply clearly explaining all the concepts. I did setup a test bed and still need to fully test the scenarios you mentioned but did test triggering full and incremental updates. I took kpropd from inetd and created a separate daemon process.  It worked as you described. The incremental updates happen on the port defined by iprop_port. I deleted the prop log and interestingly observed incremental updates still happening. I believe kpropd is probably loading the file into memory and still writing to memory without caring much for the file on disk(sync command did not help, probably the buffer would be flushed after reaching a certain size). kproplog does complain that the log does not exist but the updates still happened. I had to restart kpropd and then it knows file is missing and starts requesting for a full propagation. Once the slave requests full propagation, the master initiates kprop on port 754 and syncs the db.  After that it goes back to requesting incrementals.

The other thing I observed is, when I just truncated the prop log and restarted kpropd it went mad and quit. I thought it would trigger a full restore but was surprised to find that it just died. 
I hope to test the newer version some time soon since we are at present struck with 1.8 in prod.

I will try to test few other scenarios before I attempt a change in our system.

Thanks again,
VS.

On Wednesday, February 20, 2013 7:49:03 PM UTC-5, Jeremy Hunt wrote:
> 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
> 
> 
> 
> 
> > 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