Closed ololdach closed 6 months ago
see the help text:
The name of this server, should match with one of the entries in the HA peers. Leave empty to use this machines hostname
Hi Ad,
Thanks for looking into this. The help text is not clear and the effect is not intuitive. The help suggests that the “This Server Name” box should be set. If it is set on the HA-Peer 1, it will overwrite the setting on HA-Peer-2 and HA sync will stop working. IMHO the box should not be in the gui and the peers should default to the hostname to keep things simple and intuitive. If it were in the UI, it should be exempt from synchronization because, obviously, setting the box breaks things.
Freundliche Grüße / Best Regards Oliver Oldach Head of Strategic Consulting
Telefon:
E-Mail: Website: +49 7031 9859 472<tel:+49%207031%209859%20472>
@.**@.> www.enthus.dehttps://www.enthus.de/ secadm GmbH Standort München Am Hochacker 3-5 85630 München
Sitz der Gesellschaft: Böblingen Amtsgericht: Stuttgart HRB 787137 USt-IdNr.: DE251573157 Geschäftsführer: Stefan Voß
Informationen zum Datenschutz Kunden, Interessenten, Bewerber, Netzwerkpartner, Lieferanten und Geschäftspartner finden unter folgendem Link die gesetzlich vorgeschriebenen Informationen zum Datenschutz nach Artikel 13 DSGVO: https://enthus.de/datenschutz
From: Ad Schellevis @.> Date: Wednesday, 3. April 2024 at 19:32 To: opnsense/core @.> Cc: Oliver Oldach @.>, Author @.> Subject: Re: [opnsense/core] [BUG] OPNSense HA Replication breaks Kea HA Replication settings by overwriting /usr/local/etc/kea/dhcp*.conf (Issue #7354)
see the help text:
The name of this server, should match with one of the entries in the HA peers. Leave empty to use this machines hostname
— Reply to this email directly, view it on GitHubhttps://github.com/opnsense/core/issues/7354#issuecomment-2035188306, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALFKZGLQ34URPHJTGG63IA3Y3Q4IXAVCNFSM6AAAAABFVTAJXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVGE4DQMZQGY. You are receiving this because you authored the thread.Message ID: @.***>
Thanks for looking into this. The help text is not clear and the effect is not intuitive.
Suggestions are welcome, just open a pull-request to propose modifications.
IMHO the box should not be in the gui and the peers should default to the hostname to keep things simple and intuitive
That's exactly what they do.... the gui even shows the current value as placeholder when left empty.
Hi Ad,
We can close this issue. I have moved on to use the deprecated ISC for the ability to define boot options more granularly and the stability. I think the kea needs some work and I will spend some time on it, eventually. Right now, I am short on resources and pressed for results.
Thank you, for your support and effort in this. Oliver
Freundliche Grüße / Best Regards Oliver Oldach Head of Strategic Consulting
[cid:enthus_21ac4623-3bd8-44cb-b5ea-6f132455547f.jpg]https://www.enthus.de Telefon:
E-Mail: Website:
+49 7031 9859 472<tel:+49%207031%209859%20472>
@.**@.> www.enthus.dehttps://www.enthus.de/
secadm GmbH Standort München Am Hochacker 3-5 85630 München
[cid:enthus_cloud_87d036ce-4795-44e2-89bc-ba065c99e1dc.jpg]https://enthus.de/services-xaas/xaas/enthus-cloud?utm_source=signature&utm_medium=email&utm_campaign=enthuscloud&utm_content=version1https://enthus.de/blog/enthus-gewinnt-platin-award-als-bestes-systemhaus/?utm_source=signature&utm_medium=email&utm_campaign=systemhaus&utm_content=version1 Sitz der Gesellschaft: Böblingen Amtsgericht: Stuttgart HRB 787137 USt-IdNr.: DE251573157 Geschäftsführer: Stefan Voß
Informationen zum Datenschutz Kunden, Interessenten, Bewerber, Netzwerkpartner, Lieferanten und Geschäftspartner finden unter folgendem Link die gesetzlich vorgeschriebenen Informationen zum Datenschutz nach Artikel 13 DSGVO: https://enthus.de/datenschutz
From: Ad Schellevis @.> Date: Friday, 5. April 2024 at 18:33 To: opnsense/core @.> Cc: Oliver Oldach @.>, Author @.> Subject: Re: [opnsense/core] [BUG] OPNSense HA Replication breaks Kea HA Replication settings by overwriting /usr/local/etc/kea/dhcp*.conf (Issue #7354)
Thanks for looking into this. The help text is not clear and the effect is not intuitive.
Suggestions are welcome, just open a pull-request to propose modifications.
IMHO the box should not be in the gui and the peers should default to the hostname to keep things simple and intuitive
That's exactly what they do.... the gui even shows the current value as placeholder when left empty.
— Reply to this email directly, view it on GitHubhttps://github.com/opnsense/core/issues/7354#issuecomment-2040222525, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALFKZGISCOPPFYJHB2SMPKDY33G35AVCNFSM6AAAAABFVTAJXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQGIZDENJSGU. You are receiving this because you authored the thread.Message ID: @.***>
Hi Oliver,
Sure, I'll close it. More features will be added to KEA in time, in the meantime isc remains the default anyway. I expect we will change the default in 25.1 (and keep isc for at least another year after that).
Best regards,
Ad
Describe the bug
Checking the HA sync setting on OPNsense 21.4.1 for "Kea DHCP" replaces the /usr/local/etc/kea/kea-dhcp4.conf file on the backup firewall with the one from the primary. This overwrites the "this-server-name" setting in the "hooks-libraries" section for libdhcp_ha.so. Afterwards both kea instances on both firewalls behave as if they were the same primary "server" and HA replication fails. It is a bug to overwrite the "this-server-name" setting, leaving the Kea-HA settings broken.
To Reproduce
2024-04-03T15:08:09 Warning kea-dhcp4 WARN [kea-dhcp4.ha-hooks.0x8336a6900] HA_COMMUNICATION_INTERRUPTED communication with opnsense-2 is interrupted
Note that both instances of Kea try to contact the same IP, caused by both instances assuming that they are indeed the primary firewall. Changing the this-server-name setting on the secondary firewall and restarting kea fixes the installation.
Also, please note that after syncing the files both nodes are in "hot-standby" mode and that the backup FW has happened to come up as primary DHCP server in my setting. I haven't tested if that will lead to any issues in combination with virtual IPs. Actually it shouldn't since DHCP is multicast. Just mentioning it.
Suggested fixes:
I'm happy to assist in further investigation Cheers