Hi VS, Thank you for a very comprehensive update.
That is an interesting coding issue (bug) where the propagation log is kept in memory. I did stop and start the kpropd daemon after removing the file, so I missed what you observed. I didn't try to edit the propagation log, but did observe the behaviour you described with an empty file, eg: 'touch principal.ulog'. It looks like you are well on your way to being a happy incremental propagator Good Luck, Jeremy vs_krb wrote: > 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 > fullytest 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 thatthe 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 fullpropagation. Once the slave > requests full propagation, the master initiates kprop on port 754 and syncs > the db. A! > fter 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 presentstruck > with 1.8 in prod. > > I will try to test few other scenarios before I attempt a change in oursystem. > > 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 standalonedaemon >>> 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 toalso >>> >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. Ifthe >>> master has to initiate a kprop, the kpropd on the slave is not goingto 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 [email protected] >>> https://mailman.mit.edu/mailman/listinfo/kerberos > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
