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 <d...@redhat.com > <mailto:d...@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 >> <fvzwie...@vxcompany.com <mailto:fvzwie...@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* fvzwie...@vxcompany.com <mailto:fvzwie...@vxcompany.com> >> *I* www.vxcompany.com <http://www.vxcompany.com/> >> >> >> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal <d...@redhat.com >> <mailto:d...@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 >>> <d...@redhat.com <mailto:d...@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@redhat.com <mailto:Freeipa-users@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@redhat.com <mailto:Freeipa-users@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/
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
