On 11/01/2012 04:43 PM, Simo Sorce wrote:
On Thu, 2012-07-19 at 22:20 +0930, William Brown wrote:
Find attached two different ldifs showing how the tree for DHCP services
could be layed out. I personally prefer 2 due to the way that
sharedNetwork segments can be named uniquely in a location with
On Thu, 2012-07-19 at 22:20 +0930, William Brown wrote:
> Find attached two different ldifs showing how the tree for DHCP services
> could be layed out. I personally prefer 2 due to the way that
> sharedNetwork segments can be named uniquely in a location without
> clashing with another location. T
On 19/07/12 22:59, Simo Sorce wrote:
> On Thu, 2012-07-19 at 22:44 +0930, William Brown wrote:
>>> does not add any dhcpHost objects not the dhcpFailOverPeer information.
>>
>> I have found why this is. I was setting ldap-method to dynamic, meaning
>> that the contents of this object were only rea
On Thu, 2012-07-19 at 22:44 +0930, William Brown wrote:
> > does not add any dhcpHost objects not the dhcpFailOverPeer information.
>
> I have found why this is. I was setting ldap-method to dynamic, meaning
> that the contents of this object were only read at lease request time.
> setting this t
> does not add any dhcpHost objects not the dhcpFailOverPeer information.
I have found why this is. I was setting ldap-method to dynamic, meaning
that the contents of this object were only read at lease request time.
setting this to static has allowed these objects to be read at dhcpd
initilizati
Find attached two different ldifs showing how the tree for DHCP services
could be layed out. I personally prefer 2 due to the way that
sharedNetwork segments can be named uniquely in a location without
clashing with another location. The way that ISC-DHCP generates the
config is through essentially
