On Wed, Jan 23, 2013 at 10:01 PM, Dmitri Pal <d...@redhat.com> wrote:
> 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. > That would be a perfectly workable solution for me. > > Fred > > > On Wed, Jan 23, 2013 at 8:56 PM, Dmitri Pal <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> 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 >>> *I* www.vxcompany.com >>> >>> >>> On Fri, Jan 18, 2013 at 6:09 PM, Dmitri Pal <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> 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 >>>>> listFreeipa-users@redhat.comhttps://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/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?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