If you turn on winbind offline logon and try to login with cached credentials it will always fail with: [2012/10/19 18:39:08.297101, 0] ../source3/winbindd/winbindd_cache.c:335(centry_hash16) centry corruption? hash len (126) != 16
Created attachment 8103 [details] v4-0-test patch Jeremy, please sign-off the patch and push it to master if you're fine with it.
Wouldn't it be better to restore the 3.6 behavior?
(In reply to comment #2) > Wouldn't it be better to restore the 3.6 behavior? Hmm, in the 3.6 branch, the time is also only read but the read value is not used later on. So the question is whether it makes sense to restore that behaviour. It would make sense in order to not change the disk format of the winbindd cache, so as to easily survive upgrades whith "offline logons = true".
(In reply to comment #3) > (In reply to comment #2) > > Wouldn't it be better to restore the 3.6 behavior? > > Hmm, in the 3.6 branch, the time is also only read but > the read value is not used later on. > > So the question is whether it makes sense to restore that > behaviour. It would make sense in order to not change > the disk format of the winbindd cache, so as to easily > survive upgrades whith "offline logons = true". That's what I mean. We should not change on disk format for no reason.
Created attachment 8126 [details] Alternative fix that does not change the cache's disk format. Fix without changing disk format. If appropriate, please ACK and also send to master.
Comment on attachment 8126 [details] Alternative fix that does not change the cache's disk format. I think we should use (void)centry_time(centry); to avoid the compiler warning jeremy removed in 21528da9cd12a4f5c
Created attachment 8127 [details] improved alternative fix according to Metze's remark improved fix
Comment on attachment 8127 [details] improved alternative fix according to Metze's remark looks good for master and 4.0
(In reply to comment #8) > Comment on attachment 8127 [details] > improved alternative fix according to Metze's remark > > looks good for master and 4.0 OK. it's on its way to master. Will give the bug to Karolin once we have the hash from master to cherry-pick.
(In reply to comment #9) > (In reply to comment #8) > > Comment on attachment 8127 [details] [details] > > improved alternative fix according to Metze's remark > > > > looks good for master and 4.0 > > OK. it's on its way to master. > Will give the bug to Karolin once we have the hash from master to cherry-pick. The attached patch went into master as commit: f853c1792967332c4aff52c0fb35f653f614f86d It applies cleanly to v4-0-test. Karolin would you do "git cherry-pick -x f853c1792967332c4aff52c0fb35f653f614f86d" to import it into v4-0-test with correct reference or do you need a new attachment here? Thanks - Michael
Sorry about the break of the cache read :-( - I completely missed that in the unused variable clean-up. I should have added a comment instead. Jeremy.
(In reply to comment #10) > It applies cleanly to v4-0-test. > > Karolin would you do "git cherry-pick -x > f853c1792967332c4aff52c0fb35f653f614f86d" to import it into v4-0-test with > correct reference or do you need a new attachment here? Pushed to autobuild-v4-0-test.
Has been pushed to v4-0-test. Closing out bug report. Thanks!