[BUG]: sonic_bgp_neighbors changes encrypted password every time, even though unencrypted password is unchanged #362
Comments
This is accurate and intended behavior. Also, the encrypted password is what's stored in the switch's config. We should also check what's the "Ansible-correct" way of handling this type of behavior for
We can investigate this. |
In my opinion, the ideal behaviour would be to check if there is already an encrypted password string stored in the switch's config. If there is, re-use the salt from that password string to encrypt the plain text passord passed to the module via the Next, check the encrypted password string already present on the device with the one you just generated. If they are equal, no update is necessary. If they are unequal, update the switch config and report changes were performed (possibly after re-encrypting the plain-text password from
Great, let me know if you want me to open a separate bug report for this. |
Tested the playbook in the description.
So this issue is not a bug. |
Would it not be possible for the module to obtain the salt from encrypted password already stored in on the switch, and re-use that when encrypting the unencrypted password passed to the module (instead of generating a new salt on every run)? If so, the encrypted password generated by the module and the one already stored on the switch should be identical, and the module would be able to detect that no change would be needed. |
|
SONIC does not have API for obtaining the salt. The salt generation and encryption methods are controlled and done by SONIC internally. |
|
I see. I will leave this bug open in case you want to investigate what I mentioned earlier:
|
|
On second thought. As I pointed out in my initial message, when run with This encrypted password string includes the salt, does it not? Would it not be possible to extract the salt from it, use it to encrypt the plain-text password, and then check the encrypted password strings for equality before deciding to PATCH? |
From my test, the actual encrypted password on the switch is changed and is same as one in "after" clause in verbose logs. |
I do not think it is possible to extract the salt without salt handing method and/or key and/or key generation method and/or encrypt/decrypt methods. All those are handled by SONIC internally. Ansible, as config API, should not get involving. |
Apologies for the late response, been extremely busy lately. Here's how I can reproduce this. I start out by applying a playbook as follows: - hosts: ent_sonic
tags: ent_sonic
gather_facts: false
tasks:
- name: Configure BGP
dellemc.enterprise_sonic.sonic_bgp:
config:
- bgp_as: 1234
router_id: 1.2.3.4
- name: Configure BGP neighbors
dellemc.enterprise_sonic.sonic_bgp_neighbors:
config:
- bgp_as: 1234
peer_group:
- name: FOO
remote_as:
peer_type: external
ebgp_multihop:
enabled: true
auth_pwd:
pwd: U2FsdGVkX1+WGtc2YexgKR06rLE5YPb+dyW3n2gsxuQ=
encrypted: trueThis produces the following configuration on the switch: If I run the playbook again, it reports no changes are necessary, as expected: Next, I change the password on the switch: …and then I run the playbook again, which now reports changes are necessary (again as expected): However, if I check the running configuration on the switch, the password has unexpectedly not been changed to the Repeated attempts at running the playbook yields the same result, it reports If I manually change the password back using So as far as I can tell, |
Bug Description
When running a task that uses sonic_bgp_neighbors to create a neighbor with an unencrypted password, each and every subsequent run of the playbook will change the encrypted password, even though the unencrypted password remains unchanged.
Furthermore, even though
--diffis being specified, no diff is being reported. (This may be a systemic issue as I've seen this behaviour in #361 and #359 as well.)Product Name
SONiC-OS-4.2.0-Enterprise_Base
Component or Module Name
sonic_bgp_neighbors
DellEMC Enterprise SONiC Ansible Collection Version
dellemc.enterprise_sonic 2.4.0
SONiC Software Version
SONiC-OS-4.2.0-Enterprise_Base
Configuration
Steps to Reproduce
Run a playbook with the following tasks repeatedly:
Expected Behavior
a. If the unencryped password does not change between subsequent runs, no changes should be reported (but
ok)b. The module should display a diff of the changes applied when ansible-playbook is run with
--diffActual Behavior
a. Changes are reported and applied on each run
b. The module does not display a diff of the changes applied even though ansible-playbook is run with
--diffLogs
Screenshots
Diffing the
beforeandafterblobs reported from--verboseoutput shows the change to the password:The encryped password was indeed changed accordingly:
I suspect this happens because a randomly generated salt is generated on each run, instead of re-using the same salt every time.
A viable workaround is to specify the password as encrypted instead of unencrypted. This way,
okis reported on subsequent runs after the password was initially set. However, this workaround reveals another bug (which I do not have time to report separately now): the module fails to change an encrypted password (i.e., if I change the value ofpwdin theconfigdict, ansible-playbook will reportchanged:on each subsequent, but the actual encrypted password on the switch remains unchanged.)Additional Information
No response
The text was updated successfully, but these errors were encountered: