On 01/27/2012 02:28 PM, Simo Sorce wrote:
> On Fri, 2012-01-27 at 14:21 -0500, Dmitri Pal wrote:
>> On 01/25/2012 07:38 PM, ~Stack~ wrote: 
>>> On 01/25/2012 05:18 PM, Sigbjorn Lie wrote:
>>>> On 01/25/2012 02:30 AM, ~Stack~ wrote:
>>>>> 2) How do I get dhcpd to update DNS?
>>>>>
>>>>> Since I can't find the place to add rndc-keys to BIND, right now I have
>>>>> to add every host manually in the web interface because dhcpd isn't
>>>>> updating named. This is time consuming and a pain when dealing with
>>>>> large amounts of systems. If I could figure out where the named zones
>>>>> are stored in IPA I should be able to add my rndc-key and be OK, but
>>>>> that gets back into question 1.
>>>>>
>>>>> My /etc/dhcp/dhcpd.conf file is pretty basic but all the PXE clients
>>>>> have host entries to match their MAC with the group that allows PXE
>>>>> booting (ex: host pxe001.project.local{hardware ethernet
>>>>> 00:16:17:AB:E9:88; fixed-address 172.31.203.1}).  Unless I mange both
>>>>> this file and the IPA interface, the nodes have issues figuring out
>>>>> their name. One or the other and the node has issues; both and it works.
>>>>> I would really prefer not to manage two locations for all these nodes.
>>>>>
>>>>> The normal way for dhcpd to talk to BIND(named) is by having a rndc-key.
>>>>> However, me fighting with named.conf was the big part of my problems
>>>>> before so I am hoping there is a simple way of doing this inside IPA.
>>>>>
>>>>> Any ideas?
>>>> This is what I have done to work around issues similar to yours.
>>>>
>>>> Over a few years I have developed a pxe boot toolbox called
>>>> OneClickKick. OCK manages DHCPD by generating config files based upon
>>>> information looked up from naming sources such as Mysql, NIS, or LDAP
>>>> (IPA). It also creates the PXE boot files in tftpboot/pxelinux.cfg, and
>>>> serves kickstart files when PXE booting clients.
>>>>
>>>> I have integrated OCK with IPA to make IPA keep records of the MAC
>>>> address, and base my DHCP config upon the information I get from IPA.
>>>> For your configuration, the steps for adding a new client would be the
>>>> following:
>>>>
>>>> 1. Add the host to IPA, specify an IP address so that forward and
>>>> reverse DNS records are created for the host
>>>> 2. The host will appear in OneClickKick, select modify, add the MAC
>>>> address (this is being written to the host object in IPA), and select it
>>>> for PXE boot / kickstart. This will generate the DHCP config file,
>>>> reload dhcpd, and create the required files in the tftpboot/pxelinux.cfg
>>>> directory (if you enabled it for PXE booting).
>>>> 3. PXE boot the client.
>>>>
>>>> By doing this you eliminate the need for dhcpd to update the DNS server,
>>>> because the records are already there.
>>>>
>>>> The MAC addresses stored in IPA can also be used by normal Linux and
>>>> Solaris (Jumpstart) clients by utilizing their "ethers" table in
>>>> nsswitch.conf.
>>>>
>>>> Have a look at the link below to read more and download if you think
>>>> OneClickKick could suit your environment.
>>>>
>>>> http://sourceforge.net/projects/oneclickkick/
>>> Thank you! I will take a look at it tomorrow.
>>>
>>> ~Stack~
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users@redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
>> What Adam was trying to say is that if you want a little bit more
>> security to this enrollment process you need when you register host
>> with IPA ask IPA for generated OTP (or provide your own). This OTP
>> needs then to be seeded into the kickstart file. As the Kickstart file
>> is processed the ipa-client-install command will be called with this
>> OTP as one of the parameters. The ipa-client will authenticate to IPA
>> server and finish the configuration of the system provisioning the
>> keys.
>>
>> When the machine is rebooted you need to do the same sequence except
>> you need to delete and re add the host or clean its keytab and status
>> (both options would work).
>>
>> The OTP capability was specifically added to address automatic
>> provisioning like this in a secure way.
>>
>> Would it work for you?       
> This needs some more explanation.
>
> Recycling the keytab very often can lead to connection errors (users may
> have valid tickets for the machine, and the machine will not longer
> recognize them).
>
> Keeping around the keytab for these host would be safer, even if you end
> up refreshing the keytab using the OTP method, although if you keep
> around the keytab then using the OTP seem more burden than anything.
>
> Simo.
>
This depends on the assumption about the infrastructure.
If the reboot means that it is a completely new entity may be the
tickets should actually not be valid any more. But then the name should
probably be different too and reboot would be = provisioning. With the
stateless systems it is really hard to draw the line between the two.
 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
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

Reply via email to