Resent-To: rt-comment@krbdev.MIT.EDU
Resent-From: Tom Yu <tlyu@MIT.EDU>
Resent-Date: Tue, 27 Aug 2013 12:19:04 -0400
Resent-Message-ID: <ldvvc2r85tz.fsf@cathode-dark-space.mit.edu>
Date: Mon, 26 Aug 2013 22:12:10 -0400
From: Richard Basch <basch@alum.MIT.EDU>
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
In-Reply-To: <045301cea10e$750307b0$5f091710$@mit.edu>
To: "'Richard Basch'" <basch@alum.MIT.EDU>, krbdev@mit.edu
CC: richard.basch@gs.com
Message-ID: <059c01cea2ca$d6813ad0$8383b070$@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Language: en-us
Content-Transfer-Encoding: 7BIT
Thread-Index: Ac6cYhyM71adIhhoSuehsJ/d2YadNQEq7cowAG8bI8A=
References: <rt-7695@krbdev.mit.edu> <rt-7695-38935.16.4884902896994@krbdev.mit.edu> <045301cea10e$750307b0$5f091710$@mit.edu>
RT-Send-Cc: 
Content-Length: 3156

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@alum.mit.edu] 
Sent: Saturday, August 24, 2013 5:11 PM
To: krbdev@mit.edu
Cc: richard.basch@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/rbasch/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@krbdev.mit.edu] 
Sent: Sunday, August 18, 2013 6:26 PM
To: basch@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