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 >>> Freeipafirstname.lastname@example.org <mailto:Freeipaemail@example.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 > Freeipafirstname.lastname@example.org <mailto:Freeipaemail@example.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/
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users