[Freeipa-devel] Hosts, A recs, and AAAA recs

Dmitri Pal dpal at redhat.com
Wed Feb 9 21:41:15 UTC 2011


On 02/09/2011 11:06 AM, Adam Young wrote:
> On 02/09/2011 10:56 AM, Dmitri Pal wrote:
>> On 02/08/2011 11:30 PM, Simo Sorce wrote:
>>> On Tue, 08 Feb 2011 22:10:16 -0500
>>> Adam Young<ayoung at redhat.com>  wrote:
>>>
>>>> The current process to add a host today is:
>>>>
>>>> Create an A record
>>>> run add host
>>>>
>>>> We have --force which will allow us to add the host even if the A
>>>> record doesn't exist, but do we have a way to say,  add this host, A
>>>> record, and AAAA record all at the same time?
>>>>
>>>>
>>>>   From a cloud perspective, it seems like we are going to get a lot of
>>>> short lived VMs that will need all three at once.  I can see a work
>>>> flow like this:
>>>>
>>>>
>>>> User requests a number of VMs.
>>>> VMs get clones from templates and spun up
>>>> VMs get IP address from DHCP server.
>>>> DHCP server notifies IPA server of new hosts
>>> What do you mean by this ^^^^ ?
>>> Do you want to give the DHCP server the power to perform DNS updates ?
>>> Can be done although I am not sure DHCP Servers know how to do GSS-TSIG
>>> protected updates, we may have to open up DNS access control to accept
>>> everything from the DHCP Server.
>>>
>>>> IPA server adds host entries, A and AAAA records
>>> Host entries must be added by the cloud engine as it needs to set the
>>> enrollment password it passes down to the VM.
>>>
>>>> VM runs ipa-client install as part of firstboot
>>> ipa-client-install could also add DNS records, but there is a
>>> credential problem if it is an automated process.
>>>
>>>> The IPA server might even get notified earlier.  I could see the
>>>> cloud provider pushing the info to ipa prior to cloning the VM.
>>> This might be a better choice as long as the cloud provider can also
>>> change the DHCP configuration to assign the right IP address to the
>>> VMs using the MAC address.
>>>
>>>> How would we go about doing that today?
>>> I think we are missing the part that creates the VMs yet, so ...
>>>
>>> Simo.
>>>
>> In the cloud the cloud provider gives a VM a name and IP that it knows
>> about.
>> It is completely different from what you want the machine to think about
>> itself.
>> I did some emulation of the bootstrapping sequence as a proof of concept
>> to make sure we can enroll the host with a different hostname.
>>
>> To emulate the provisioning of a new VM in the cloud I created a new
>> host in IPA with corresponding DNS entries. I gave it a generated static
>> IP of 1.1.1.1.
>> It created an OTP for me.
>> Then I turned around and to the client added ipa to the resolve.conf of
>> the client and ran the ipa-client-install passing in the OTP, ipa host
>> name and machine name.
>> That completed the provisioning.
>>
>> The cloud engine will be driving the creation of the DNS and host
>> entries. IPA already has all capabilities that are needed.
>> What you suggest seems to be an optimization that would save cloud
>> engine a line in a script.
>>
>> Simo is right about firstboot - it is not implemented yet.
>
> To create a new vm is just a matter of using libvirt's clone  call. 
> But I'm not sure if libvirt has the means to notify the IPA server
> "new machine is about to come up, I'm going to give it the IP Address
> 10.1.1.1"
>
> What do you mean about firstboot?
>

I talking about a generic case.
When you are bringing up machine in a cloud you can't assume libvirt.
It can be Amazon cloud or Rackspace or GoGrid or something else.
In such cases Cloud Engine will tell the cloud provider: here is the
image, boot it and pass those parameters to it (parameters are passed in
different ways for different cloud providers).
On the "first boot" (and this is where the first boot comes from) the
image comes up and executes "First boot sequence".
As a part of the sequence it connects to the configuration server to
pull in its configuration. But before this it needs to register to IPA
using passed in OTP.
The cloud engine would pre-create the right entries on the IPA server
side (host and DNS) and pass the OTP, its name and host name of the
machine to the VM as parameters.
The first boot script will do ipa-client-install with those parameters
and then using obtained ticket connect to the configuration server.
Since the VM is now authenticated the Configuration server would be able
to tell VM what to do next and how to configure itself.

Bottom line is that there is a third party called Cloud Engine that will
orchestrate the process.


>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the Freeipa-devel mailing list