OCPBUGS-83830: Apply password only if changes exist#5889
Conversation
This change fixes the issue in SSH keys and user passwords that made the rollback useless as it tried to apply the new configuration instead of the previous one. Signed-off-by: Pablo Rodriguez Nava <git@amail.pablintino.eu>
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
@pablintino: This pull request references Jira Issue OCPBUGS-83830, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: openshift/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe update flow restricts password-hash changes to the Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 10 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (10 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pkg/daemon/update.go`:
- Around line 1252-1255: The passwd-section diff currently triggers
SetPasswordHash even when only SSH keys changed; add a targeted comparison that
detects real password-hash intent changes and use that to guard SetPasswordHash
and the related passwd-handling block (the code that currently checks
diff.passwd). Implement a helper like passwordHashChanged(newUsers, oldUsers)
that normalizes nil/empty to a placeholder and compares per-user password hashes
(and detects removed users with a non-placeholder old hash), then replace the
diff.passwd condition with a call to this helper before invoking
dn.SetPasswordHash (and likewise for the block at the other occurrence around
the SetPasswordHash usage) so usermod -p runs only when hashes actually changed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: fbb6ae67-6748-4e2a-86f0-63abfdbe9764
📒 Files selected for processing (1)
pkg/daemon/update.go
|
/test unit |
This bugfix ensures that the MCD only runs `usermod` if the password hash has actually changed and not in every update. This aligns the behavior we currently have for SSH passwords. Signed-off-by: Pablo Rodriguez Nava <git@amail.pablintino.eu>
fdfe7de to
867a618
Compare
|
/test unit |
yuqi-zhang
left a comment
There was a problem hiding this comment.
/lgtm
Left some thoughts inline but logically should be sound
| defer func() { | ||
| if retErr != nil { | ||
| if err := dn.updateSSHKeys(newIgnConfig.Passwd.Users, oldIgnConfig.Passwd.Users); err != nil { | ||
| if err := dn.updateSSHKeys(oldIgnConfig.Passwd.Users, newIgnConfig.Passwd.Users); err != nil { |
There was a problem hiding this comment.
Good thing this almost never fails since we probably never had a functional rollback
| } | ||
|
|
||
| // Check if hash update is needed. Skip if not. | ||
| currentHash, err := getUserPasswordHash(u.Name) |
There was a problem hiding this comment.
So the vast majority of users would never have this set. I guess with our current logic, we'd always just be doing a usermod with an empty password hash and this is triggering the policy described in the bug?
I'm wondering if we just exit out of this function if passwordhash is unset. I guess we'd have to have special logic if the user deletes a password entry, so probably fine to keep it as is since most users wouldn't be hitting this with your conditional changes above.(just thinking if we can bypass the ondisk check)
There was a problem hiding this comment.
Yeah, I thought about it, but I took the "Ansible" approach. "I'd do my best to make your state match the machine state". With an early exit or check, the user would be able to modify the node shadow and we won't never try to patch it to match the MC, that I'd say it's the sourth of true.
|
Scheduling tests matching the |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pablintino, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest-required |
|
Pre-merge verification: Environment setup Steps:
$ oc logs machine-config-daemon-m5hrp | grep -i pass
Defaulted container "machine-config-daemon" out of: machine-config-daemon, kube-rbac-proxy
I0504 09:24:54.865427 2595 update.go:3050] "Starting update from rendered-worker-737dab4eec887af16a8ddbaeb4c5f2c9 to rendered-worker-6777d90e72fda93e143ed864ed564d2e: &{osUpdate:false kargs:false fips:false passwd:false files:true units:false kernelType:false extensions:false oclEnabled:false revertFromOCL:false}"
I0504 12:18:35.475096 2595 update.go:3050] "Starting update from rendered-worker-6777d90e72fda93e143ed864ed564d2e to rendered-worker-9f5f45a95e1cfd12963390242321d1e2: &{osUpdate:false kargs:false fips:false passwd:true files:false units:false kernelType:false extensions:false oclEnabled:false revertFromOCL:false}"
I0504 12:18:36.373371 2595 update.go:2495] Password has been configured
$ oc logs machine-config-daemon-m5hrp | grep -i pass
Defaulted container "machine-config-daemon" out of: machine-config-daemon, kube-rbac-proxy
I0504 09:24:54.865427 2595 update.go:3050] "Starting update from rendered-worker-737dab4eec887af16a8ddbaeb4c5f2c9 to rendered-worker-6777d90e72fda93e143ed864ed564d2e: &{osUpdate:false kargs:false fips:false passwd:false files:true units:false kernelType:false extensions:false oclEnabled:false revertFromOCL:false}"
I0504 12:18:35.475096 2595 update.go:3050] "Starting update from rendered-worker-6777d90e72fda93e143ed864ed564d2e to rendered-worker-9f5f45a95e1cfd12963390242321d1e2: &{osUpdate:false kargs:false fips:false passwd:true files:false units:false kernelType:false extensions:false oclEnabled:false revertFromOCL:false}"
I0504 12:18:36.373371 2595 update.go:2495] Password has been configured
I0504 12:33:16.327508 2595 update.go:3050] "Starting update from rendered-worker-9f5f45a95e1cfd12963390242321d1e2 to rendered-worker-8fa8dc0847e6def22b9195de217fbb7d: &{osUpdate:false kargs:false fips:false passwd:true files:false units:false kernelType:false extensions:false oclEnabled:false revertFromOCL:false}"
I0504 12:33:17.157884 2595 update.go:2495] Password has been configured
On without fix cluster, the logs were triggered for ssh. /label qe-approved |
|
@ptalgulk01: This PR has been marked as verified by DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/jira refresh |
|
@pablintino: once the present PR merges, I will cherry-pick it on top of DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@pablintino: This pull request references Jira Issue OCPBUGS-83830, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/retest-required |
|
@pablintino: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
@pablintino: Jira Issue Verification Checks: Jira Issue OCPBUGS-83830 Jira Issue OCPBUGS-83830 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@pablintino: new pull request created: #6023 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Fix included in release 5.0.0-0.nightly-2026-05-09-013211 |
Closes: #OCPBUGS-83830
- What I did
This bugfix ensures that the MCD only runs
usermodif the password hash has actually changed and not in every update. This aligns the behavior we currently have for SSH passwords.- How to verify it
TBD
- Description for the changelog
This bugfix ensures that the MCD only runs
usermodif the password hash has actually changed and not in every update.Summary by CodeRabbit