On 06/05/2013 01:23 PM, Tomas Babej wrote: > On 06/04/2013 01:29 PM, Tomas Babej wrote: >> On 06/03/2013 02:58 PM, Martin Kosek wrote: >>> On 06/03/2013 02:43 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this patch fixes the installation problems on master on F19 with krb5 >>>> packages >>>>> = 1.11.2-6 >>>> https://fedorahosted.org/freeipa/ticket/3666 >>>> >>>> Tomas >>> 1) Leaving cache_desc open: >>> >>> + (cache_desc, cache_path) = tempfile.mkstemp(prefix='krbcc') >>> + os.environ['KRB5CCNAME'] = cache_path >>> >>> Why do we keep the descriptor open and close it at the and of the >>> installation? >>> Can we close it right after tempfile.mkstemp? I think we do it this way in >>> other places in installation. >>> >>> 2) What about other installers where we handle Kerberos auth, like >>> ipa-{replica,dns,ca}-install? >>> >>> A common function, other shared means, of handling KRB5CCNAME may be >>> appropriate to avoid duplicating code too much. >>> >>> Martin >> I moved the code responsible to PrivateCCache class, both for readability and >> conciseness. >> >> Private ccache now used in replica,dns and ca the installers. I managed to >> reproduce the error only with >> dns-install though(fails on adding the service principal), but having a >> private ccache for the installer should not hurt. >> >> Ipa-adtrust-install requires the admin ticket, so there shouldn't be an >> issue. > > My reasoning was flawed here, ipa-adtrust-install attempts to re-kinit admin > ticket, so it needs the private ccache as well. > > Sending one-liner fix. > > Tomas
As also discussed with Alexander on IRC, we do not want to have private ccache for ipa-adtrust-install as we deliberately re-kinit admin user to add new MS-PAC information to the ticket so that subsequent trust commands work. In other install scripts, we want to have private ccache so that we don't mess with user's default ccache. This entire problem should go away when krb5 is fixed, see https://bugzilla.redhat.com/show_bug.cgi?id=961235 Thus, your current fix for private ccaches is correct. Thanks, Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
