Add other algorithms for DNS/DHCP (HMAC-SHA512) #7389
Conversation
Co-authored-by: Robert Sand <ros5549@psu.edu>
|
We reviewed both of these pull requests and this merge request should incorporate the changes from both of these with the addition of allowing a change in the key username. We also added info to the documentation. I wasn't sure of the proper way to pull everything together, so I created this pull request. I'm happy to do something differently. |
|
This should also resolve the concern with #6757 |
|
I've implemented these changes with success, would appreciate this being merged for future release version. |
|
@gurevichmark @besawn for your kind attention. |
|
@gskouson I believe you will need to sign the xCAT CLA for individuals and submit it for this PR to be accepted. (I'd had to do that for my first PR too.) It's a quick process. documented at https://xcat-docs.readthedocs.io/en/latest/developers/license/xcat_individual_contributor_license_agreement.html?highlight=CLA |
|
We've signed an organization agreement from Penn State. I should be on the contributor list. |
|
@gskouson I have received your contributor license agreement, thank you. |
|
A minor change that may be needed here: |
The PR is to fix issue _#7173
The modification include
Change ddns.pm to allow for other signing algorithms and key names
Without changes to the site table, this should default to working as expected in the past. The default is still HMAC-MD5
Change dhcp.pm to allow for other signing algorithms and key names
Without changes to the site table, this should default to the past functionality.
Summary of changes
In both cases an optional site table parameter (omapi-algorithm) is used to specify the signing algorithm for ddns and dhcp communication with the DNS server. It adds support for HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512 as possible signing options for DNS communications. While additional options may also be possible the code expects the above options, otherwise HMAC-MD5 is used.
It also allows the site table parameter (omapi-username) to choose a different username for the DNS communication. In some cases the DNS provider may require you to use the key name and secret they provide rather than allowing the use of the key name and secret provided by xCAT.
I have no specific unit tests for this change. I've build/installed RPMs based on this change with no impacts to existing test installation. I've successfully added the omapi-algorithm and omapi-username information to the site table and have updated the passwd table to reflect the username and secret. It seems to build local DNS configurations and also allow for externaldns=1 and allow to point at an external DNS provider when the external provider uses the appropriate key and username.
The UT result
No specific unit tests written for this change
##The UT output##