[krbdev.mit.edu #7695] AutoReply: krb5-1.11.3/1.10.6 - full resync may fail and still result in ulog being updated

[Richard Basch via RT]

I believe these are final... They compile and I believe they will fix the
issues (I will be testing for a couple days, but "no news is good news").

1.10:
https://github.com/rbasch/krb5/commit/fc7aabea9bf0abb0712a8509c38d4382474361
c3

1.11:
https://github.com/rbasch/krb5/commit/f6237998bf7b20ea898d8b1ac2b30255caad89
d8
https://github.com/rbasch/krb5/commit/affc746f296869d25c49ee2eabc843c60470ac
df


-----Original Message-----
From: Richard Basch [mailto:basch at alum.mit.edu] 
Sent: Monday, August 26, 2013 10:12 PM
To: 'Richard Basch'; 'krbdev at mit.edu'
Cc: 'richard.basch at gs.com'
Subject: RE: [krbdev.mit.edu #7695] AutoReply: krb5-1.11.3/1.10.6 - full
resync may fail and still result in ulog being updated

There is a second bug... I don't believe the patch I provided is wrong, but
I believe to be effective in my test environment, a second fix is required,
specifically to the dump side of kdb5_util, where it might not properly
determine whether to create a new dump file (the quick serial number check
is flawed).

Stay tuned for another git reference (though this one should only apply to
1.11 since 1.10 doesn't use the same conditional dump optimization logic).


-----Original Message-----
From: Richard Basch [mailto:basch at alum.mit.edu] 
Sent: Saturday, August 24, 2013 5:11 PM
To: krbdev at mit.edu
Cc: richard.basch at gs.com; 'Richard Basch'
Subject: RE: [krbdev.mit.edu #7695] AutoReply: krb5-1.11.3/1.10.6 - full
resync may fail and still result in ulog being updated

Instead of the supplied patch, refer to the following patches instead:

1.11:
https://github.com/rbash/krb5/commit/affc746f296869d25c49ee2eabc843c60470ac
df

1.10:
https://github.com/rbasch/krb5/commit/fc7aabea9bf0abb0712a8509c38d4382474361
c3

I am relatively confident in the above since they move the ulog update to
after the db promotion, ensuring everything is ok first. This should avoid
all the issues which previously existed.

There is a remote chance something might prevent the ulog update from taking
place but the db might be updated. I am not quite sure what the right answer
is in this case, but certainly the other way round of updating the ulog
before the database matches is wrong. There are pros and cons to resetting
the ulog prior to the db load, but in either scenario, the final state
should not be set until after the db is loaded & promoted.


-----Original Message-----
From: krb5 [mailto:rt at krbdev.mit.edu] 
Sent: Sunday, August 18, 2013 6:26 PM
To: basch at alum.mit.edu
Subject: [krbdev.mit.edu #7695] AutoReply: krb5-1.11.3/1.10.6 - full resync
may fail and still result in ulog being updated 


Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
	"krb5-1.11.3/1.10.6 - full resync may fail and still result in ulog
being updated", 
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [krbdev.mit.edu #7695].

Please include the string:

         [krbdev.mit.edu #7695]

in the subject line of all future correspondence about this issue. To do so,

you may reply to this message.

                        Thank you,
                        

-------------------------------------------------------------------------
In my test environment, even with krb5-1.11.3, I noticed a database reload
(full resync) may still fail and result in the ulog being updated with the
new serial number, resulting in an inconsistent environment.

 

I have another patch available which seems to fix the condition.
Specifically, I have seen the condition occur with an accompanying log
message:

./kdb5_util returned a bad exit status (2)

 

krb5-1.11

https://github.com/rbasch/krb5/commit/83c34de8a740711961d05fde150cc8b16e68f9
e1

 

krb5-1.10

https://github.com/rbasch/krb5/commit/638b2e299157b1c2e637cb992bc07cf9f55985
94