Thanks for your reply, I'm happy you picked this up, I really am!

My responses to your points:

1. I think it's not needed for them, but as foreman can use the dhcp always 
instead with static leases instead of bootstrapping only we have this issue 
indeed. Also because foreman deployment is DNS based, isc doesn't think 
about this I think but I know the new DHCP server they developed does this 
different.

2.I think this is the best solution as you can even chose then which DNS is 
primary and which one is not. You can also select a dhcp server in a whole 
different subnet as long as they are in your dhcp-helpers in your switch. I 
think this would be best. About failing, if it can contact one server you 
will be noticed and you need to click a proceed button again ? If the 
machine is build you can always do later on an edit and submit of the host 
again to update the second dhcp, or first dhcp server. Maybe some button @ 
the host page, or in the overview in the dropdown would be nice to have, 
something like... redeploy/update dhcp and dns. We can always show an 
overviews of which servers were deplyed with one of the two servers 
available so you can easy update them.

3. Sounds good, but I think it's best to handle this from foreman as we are 
in control what happens where then. you can also deploy as in point 2 with 
one dhcp server failing.

I can't wait to test this as this would be awesome for redundancy!

Thanks for catching up so far!!

Cheers,

Matt



Op maandag 15 augustus 2016 18:02:50 UTC+2 schreef Alvin Starr:
>
> I have looked at this a bit more and your right.
> Its hard to believe that the ISC develpers would be that short sighted to 
> not extend the design so that changes made to the primary are copied to the 
> secondary.
>
> I can see 3 possible solutions.
> 1) fix the ISC DHCP server.
>     Fixing the DHCP server would be a major pain and there may be some 
> fundamental reason that its not possible to copy the static entries
>
> 2) change dhcp_isc_main.rb to contact both primary and secondary DHCP 
> servers.
>     Looking at the code it would be possible to change the omcmd routine 
> to talk to a secondary server.
>     This would require adding configuration items to handle the secondary.
>     The problem I can see here is what to do in the case of an error 
> condition from one server and not the other?
>
> 3) replace omshell with a shell that writes to both servers.
>     An omshell wrapper could parse the dhcpd.conf file and determine if 
> there is a secondary server.
>     If there is a secondary server the commands could be piped to both 
> servers.
>     Once again there is the issue of what to do about errors in one server 
> and not the other.
>     This solution would also likely require a small patch to dhcp_isc_main.rb 
> to allow for changing.
>
> I could supply a patch to the dhcp_isc_main.rb and do some testing on my 
> environment so that it would pass the initial sniff test but I am not in a 
> position to do a full pull request and then submit the patches via usual 
> developer channel.
>
>
>
>
> On 08/11/2016 06:40 PM, [email protected] <javascript:> wrote:
>
> DHCP will not replicate the static leases as I said before, you need twice 
> the omapi using omshell.
>
> I have discussed this with the ISC guys.
>
>
> Op vrijdag 12 augustus 2016 00:26:15 UTC+2 schreef Alvin Starr: 
>>
>> We have slightly different problems but are both limited by the nature of 
>> foremans dhcp-proxy.
>>
>> If you create static leases using omshell then I believe the data will be 
>> replicated to a failover dhcp server.
>> Forman will create new hosts using omshell.
>>
>> The comment about DNS is only because foreman can cleanly interact with 
>> DNS remotely.
>>
>>
>> On 08/11/2016 06:05 PM, [email protected] wrote:
>>
>> You are completely wrong.
>>
>> What we like to have is a second DHCP with a proxy where is talked to 
>> using OMAPI by foreman so we have a replication about the static leases.
>>
>> DHCP itself is unable to sync them this way and for Failover we need to 
>> have 2 writes to 2 DHCP servers which are in clutser mode.
>>
>> DNS is not involved here.
>>
>> Op donderdag 11 augustus 2016 23:50:43 UTC+2 schreef Alvin Starr: 
>>>
>>> A standalone DHCP server without lots of extra software installed.
>>> I do not want to install the whole forman-proxy on the DHCP or DNS ser
>>> vers
>>>
>>>
>>> As an aside the isc_dhcp proxy does not parse correctly formatted 
>>> dhcpd.conf files(I just filed a bug report).
>>>
>>>
>>> Looking at omapi I could be convinced that it is impossible to get the 
>>> current dhcp config information remotely.
>>>
>>>
>>> On 08/11/2016 05:26 PM, [email protected] wrote:
>>>
>>> What do you mean by a standalone DHCP server ? The proxy handles that 
>>> when you installed the proxy on the DHCP server.
>>>
>>> This goes about a second DHCP server that knows the same static leases 
>>> as the proxy knows for failover whent the primary, with proxy, fails.
>>>
>>> Op donderdag 11 augustus 2016 22:39:40 UTC+2 schreef Alvin Starr: 
>>>>
>>>> I have wondered about the same problem.
>>>> Since foreman needs to read and write the leases and config files it 
>>>> means that you cannot have a remote standalone DHCP server.
>>>>
>>>>
>>>> On 08/11/2016 04:32 PM, [email protected] wrote:
>>>>
>>>> Is this me or does no-one care about DHCP redundancy ?
>>>>
>>>>
>>>>
>>>> Op zaterdag 16 januari 2016 20:06:30 UTC+1 schreef Matt .: 
>>>>>
>>>>> Hi, 
>>>>>
>>>>> I was wondering if someone has a workaround for DHCP sync with 
>>>>> failover. 
>>>>>
>>>>> As foreman writes to the leases file directly this is an issue for 
>>>>> syncing. 
>>>>>
>>>>> Can't we write to a config file we include to the dhcpd.conf and 
>>>>> reload dhcp when the proxy did something to dhcp ? 
>>>>>
>>>>> Ideas are welcome. 
>>>>>
>>>>> Cheers, 
>>>>>
>>>>> Matt 
>>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Foreman users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at <https://groups.google.com/group/foreman-users>
>>>> https://groups.google.com/group/foreman-users.
>>>> For more options, visit <https://groups.google.com/d/optout>
>>>> https://groups.google.com/d/optout.
>>>>
>>>>
>>>> -- 
>>>> Alvin Starr                   ||   voice: (905)513-7688
>>>> Netvel Inc.                   ||   Cell:  (416)[email protected]    
>>>>           ||
>>>>
>>>>
>>> -- 
>>> Alvin Starr                   ||   voice: (905)513-7688
>>> Netvel Inc.                   ||   Cell:  (416)[email protected]     
>>>          ||
>>>
>>>
>> -- 
>> Alvin Starr                   ||   voice: (905)513-7688
>> Netvel Inc.                   ||   Cell:  (416)[email protected]      
>>         ||
>>
>>
> -- 
> Alvin Starr                   ||   voice: (905)513-7688
> Netvel Inc.                   ||   Cell:  (416)[email protected] 
> <javascript:>              ||
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to