[Freeipa-users] Howto re-deploy an IPA-client using kickstart
Dmitri Pal
dpal at redhat.com
Wed Jan 23 21:01:14 UTC 2013
On 01/23/2013 03:24 PM, Fred van Zwieten wrote:
> Dmitri,
>
> If I understand correcty this would mean I backup the keytab before
> reinstall en restore it after (easily done with Satellite), then do a
> ipa-client-install using the keytab. Does this mean the host record in
> IPA will never change during this process? Sounds good to me. This
> makes reinstalling a one-step process.
>
> When the ssh keys are not preserved during reinstall they must be
> refreshed in IPA, will ipa-client-install do that too in this case?
Yes I suspect, but that would be the same as the initial enroll. I
suspect the keytab, cert and ssh keys would be regenerated. We will just
use keytab to acquire ticket and then start the whole enrollment from
clean sheet.
>
> Fred
>
>
> On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal <dpal at redhat.com
> <mailto:dpal at redhat.com>> wrote:
>
> On 01/23/2013 01:56 PM, Charlie Derwent wrote:
>> Hi
>>
>> My team and I have been around this a few times and as far as we
>> can see the best and simplest way to make this work is if we
>> enrol once and back up all the relevant bits of information so in
>> the event of a rebuild we can restore the necessary components
>> and make it appear to the IPA server that it had never left.
>>
>> Disabling and re-enrolling was the preferred option initially but
>> it seems there are too many issues to make this viable going forward.
>>
>> * How to allow developers/administrators/robots access securely
>> between the disabling the host and re-enrolment (to say
>> reboot the server for PXEboot)
>> * Having to grant users permission to enrol servers even when
>> they only need to re-provision existing servers.
>> * OTP reuse being disabled preventing something simple like the
>> hostname of the server being used during re-enrolment
>> * The lack of a reusable OTP also makes the process two-step
>> (see Fred's mail) rather than the single step we previously had.
>>
>> To that end could someone please tell us or document all the
>> steps required to back up the key ipa-client files so we can get
>> past these problems and move onto the more interesting things
>> that the IPA server can provide.
>>
>> Any effort to simplify the backup and restore process within
>> an IPA client (and the server for that matter) would also be
>> greatly appreciated.
>>
> I suspect you opened the ticket:
> https://fedorahosted.org/freeipa/ticket/3373
> Anyways I replied in the ticket and I am pasting it here:
> Making OTP reusable defeats the purpose of the OTP. It becomes
> just another password. If you want this you can create an account
> in IPA, limit its privileges to just host enrollment and use the
> password associated with this account to re-provision systems.
> Would that solve the problem for you?
>
> If the backup seems like a good option I suggest we open an RFE to
> allow re-enrolling a host using keytab.
> I can file an RFE for it. What it would do is: add an argument to
> ipa-client-install to use keytab instead of OTP or password if you
> saved one. If the authentication successful the client will
> reconfigure the system once again.
>
> Would that solve the problem?
>
> I do not like the full backup idea as it is not consistent between
> the versions. Say you redeploy but with the updated version of
> software that changed something and config files from the previous
> version are not 100% the same. Things would break.
> And depending upon the commands you used we touch different files
> as SSSD can now be integrated with autofs, ssh, sudo.
> I am just not sure that backup and restore is really a sustainable
> approach project/product wise.
> We can probably craft a list but I am scared promoting it as a
> solution.
>
>
>> Regards,
>> Charlie.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 18, 2013 at 8:14 PM, Fred van Zwieten
>> <fvzwieten at vxcompany.com <mailto:fvzwieten at vxcompany.com>> wrote:
>>
>> Dmitri,
>>
>> Sure I can do this. I can make a script, and have this
>> executed from Satellite (remote command) and than perform the
>> server redeploy from Satellite. However, that makes it a two
>> step process, and that is what I now also have. However, I
>> would like to make it fully automated in a single step.
>>
>> Come to think of it...there is also an api for Satellite.
>> Maybe I can make a script that will first do the IPA stuff
>> and then call Satellite to redeploy the server.....
>> ....hmmm....will look into this...and report my findings
>>
>>
>> Met vriendelijke groeten,
>> *
>> Fred van Zwieten
>> *
>> *Enterprise Open Source Services*
>> *
>> Consultant*
>> /(vrijdags afwezig)/
>>
>> *VX Company IT Services B.V.*
>> *T* (035) 539 09 50 mobiel (06) 41 68 28 48
>> *F* (035) 539 09 08
>> *E* fvzwieten at vxcompany.com <mailto:fvzwieten at vxcompany.com>
>> *I* www.vxcompany.com <http://www.vxcompany.com/>
>>
>>
>> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal <dpal at redhat.com
>> <mailto:dpal at redhat.com>> wrote:
>>
>> On 01/18/2013 06:52 AM, Fred van Zwieten wrote:
>>> Hi Dmitri,
>>>
>>> Sorry for the late reply. I basically want to do the
>>> same as Charlie Derwent in another tread on this mailing
>>> list: To fully automate the re-installation of a server
>>> using Satellite/Spacewalk using kickstart. As the server
>>> is an IPA client, it must first get to be un-enrolled,
>>> before an ipa-client-install --unattened -w secret etc.
>>> can be done in a %post snippet of the kickstart file. It
>>> is the automation of the unenrollment proces that we are
>>> not able to set up.
>>>
>>> What I can do on any ipa-client to unenroll on the
>>> command line is:
>>>
>>> ipa --disable-host <server> and ipa host-mod
>>> --password=secret --ssh=
>>>
>>> This unprovisions the client, set's an OTP and removes
>>> the host ssh keys.
>>>
>>> However, this can only be done on an IPA client, and
>>> during a kickstart install the server is no longer an
>>> IPA client, because it is freshly being set up.
>>>
>>> It's a typical chicken-and-egg issue. You must first be
>>> ipa client to be able to execute ipa commands, but you
>>> cannot become an ipa client before unprovisioning
>>> yourself using those same ipa commands.
>>>
>>> Another approuch would be to unprovision the client just
>>> before the reboot to be kickstarted, however, I have no
>>> idea how to set that up. It would mean the server has to
>>> know somehow it is being rebooted because of a
>>> re-install, but afaik, there is no way for
>>> satellite/spacewalk to tell the server this..
>>>
>>> Regards,
>>>
>>> Fred
>>
>> IMO the right approach would be for the Satellite server
>> to perform "ipa --disable-host <server> and ipa host-mod
>> --password=secret --ssh=" as a part of the re-installation.
>> Satellite should be given an IPA identity and call into
>> IPA when it performs reinstall before rebooting the system.
>>
>> Tough... I will see what I can do.
>>
>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 12, 2013 at 10:06 PM, Dmitri Pal
>>> <dpal at redhat.com <mailto:dpal at redhat.com>> wrote:
>>>
>>> On 01/12/2013 03:28 AM, Fred van Zwieten wrote:
>>>> Hi there,
>>>>
>>>> We are in the process of implementing Satellite and
>>>> want to automate server installations 100% using
>>>> kickstart, cobbler, satellite.
>>>>
>>>> IPA clients can be scripted enrolled using
>>>> kickstart. Plenty of documentation about that.
>>>>
>>>> However, how to "re"-enroll IPA clients?
>>>>
>>>> Satellite gives me the option to re-install a
>>>> server. In this case, there are still host and
>>>> possibly service records for this host present in
>>>> IPA and DNS.
>>>>
>>>> One way to think about this is, that it's actually
>>>> OK to keep those records there, because it is a
>>>> "re"-installation, so why remove and re-enroll?
>>>> However, there is the krb5.keytab in /etc. I could
>>>> save that file during redeployment, but I'm not
>>>> sure if that will work. And iare there any other
>>>> gotcha's.
>>>>
>>>> So, the question is, how to re-install an IPA
>>>> client using kickstart (silent re-install)?
>>>
>>> The question is how/do you remove the client?
>>> Based on what you say above you use the same system
>>> so there are some leftovers. If you can run
>>> ipa-client-install --uninstall it should clean
>>> things like keytab and certs (there have been bugs
>>> fixed in freeIPA 3.0). If the client has access to
>>> the server it will clean (not remove) the host entry
>>> too. Then you can re-run the install. If you use OTP
>>> you would need to reset OTP first.
>>>
>>>>
>>>> Regards,
>>>>
>>>> Fred
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Sr. Engineering Manager for IdM portfolio
>>> Red Hat Inc.
>>>
>>>
>>> -------------------------------
>>> Looking to carve out IT costs?
>>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>>
>>>
>>>
>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>>
>>
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com <mailto:Freeipa-users at redhat.com>
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/ <http://www.redhat.com/carveoutcosts/>
>
>
>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130123/f27ac94b/attachment.htm>
More information about the Freeipa-users
mailing list