On 03/20/2012 06:16 PM, Lars Sjöström wrote: >> Lars Sjöström wrote: >>> Hi, >>> >>> Understood! Would it be ok to add an optional flag then? >>> like --reacquire ? >>> >>> like so: >>> # run only if force and reacquire is set >>> if options.force and options.reacquire: >>> # try to fetch keytab... >>> >>> Cheers, >>> Lars >> >> That sounds reasonable. In what case would you want to re-enroll a host >> without disabling it first? > One use case is where you for instance reinstall your OS a lot (in a > automated fashion), the client will not have any traces left of the > IPA client config which means the client can't unenroll it self > easily. If you know you're reinstalling a lot one would put > ipa-client-install with the re-acquire flag set to let the client try > to repair it self. > > One could always skip the the ipa-client-install command and script > around the ipa* commands, but I would prefer to have it supported by > ipa-client-install. > > Would that make any sense? :)
Let us define the problem namespace first and see what the scenarios are. We do not need to implement all the scenarios but knowing them would be helpful to define what the right combination of flags should be exposed. 1) Client is not enrolled, no host entry or host entry exists and admin has rights to provision or it is a bulk enrollment using OTP 2) Client is completely re-installed, nothing on server changed yet 3) Client was enrolled, so has a key but it is corrupt or for other reason is invalid or completely missing but server has the old key 4) Client is enrolled by host entry was removed 5) Client is enrolled by host entry was recreated The cases 1 & 2 are new installs. The 1 should just go through (assuming permissions are correct). 2 will fail and you need to provide --force flag to force the client Cases 3-5 are more a repair use cases. 3 & 5 would fail without the --force but should succeed with the --force Use case 4 would go through as is with just a repair flag My point is that the relation between the flags is different depending upon what is going on the server. So it seems (I do not know the code but) that logic should be if no repair if no force enroll as new else force overwrite do full client config else if no force enroll as new else force overwrite do client config sanity check (instead of fill reconfig) Something like... > Cheers, > Lars > >> rob >> >> >>> Den 20 mars 2012 13:44 skrev Simo Sorce<s...@redhat.com>: >>>> On Tue, 2012-03-20 at 13:00 +0100, Lars Sjöström wrote: >>>>> Hello fellow devs, >>>>> >>>>> I have a proposed patch for ticket #2106 >>>>> (https://fedorahosted.org/freeipa/ticket/2106) >>>>> >>>>> if return code is 13 (Host already joined) of ipa-join command the >>>>> host will try to reacquire the keytab file. >>>>> >>>>> Feedback appreciated! >>>> >>>> Hi Lars, at the very least this should be conditional and be allowed >>>> only when an override flag is passed. The reason we punt here is that >>>> you may be trying to join a machine with the same name of an already >>>> joined and working machine by mistake. >>>> We do not want to void that other machine credentials unless the admin >>>> wants to force it. >>>> >>>> Simo. >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >>> >>> > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel