action #125750
closed
QA (public) - coordination #121720: [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuring availability
In salt-states-openqa support machines requiring ssh password login for root user size:M
Added by okurz almost 2 years ago.
Updated over 1 year ago.
Description
Motivation¶
openqaw5-xen requires login of root with password over ssh for openQA tests, see https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls#L138, hence we can not directly apply https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/sshd/sshd_config#L44
PermitRootLogin without-password
Acceptance criteria¶
- AC1: openqaw5-xen can be controlled by salt while allowing root-ssh-password login
- AC2: By default all machines in salt still prevent password authentication in salt
Suggestions¶
- Optional: We could temporarily change to allow password login over ssh
- Find a way to allow individual machines root-ssh-password login
- Optional: Adapt os-autoinst backend to support ssh key login
- Ensure by default machines still apply
PermitRootLogin without-password
Rollback steps¶
- Add openqaw5-xen back to salt and ensure a high state can be applied while still allowing password login for root on this machine
- Copied from action #125534: Consolidate the installation of openqaw5-xen with SUSE QE Tools maintained machines size:M added
- Subject changed from In salt-states-openqa support machines requiring ssh password login for root user to In salt-states-openqa support machines requiring ssh password login for root user size:M
- Status changed from New to Workable
- Status changed from Workable to In Progress
- Assignee set to osukup
- Due date set to 2023-04-11
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Feedback
- Status changed from Feedback to In Progress
- Status changed from In Progress to Feedback
both AC completed ..
for next --> use custom grains to enable password login instead hardcoded grains['host'] == host
To avoid hard-coding concrete hostnames in the salt states, you could follow a similar approach to what I've recently done to exclude a systemd service on a specific host from alerting (see #127097#note-11).
- Due date changed from 2023-04-11 to 2023-04-18
- Priority changed from Normal to High
- Status changed from Feedback to Resolved
changes merged.
while deploying host which needs root password login enabled simply add to configuration steps for salt minion echo 'passwordlogin: True' >> /etc/salt/grains
- Description updated (diff)
- Due date changed from 2023-04-18 to 2023-04-28
- Status changed from Resolved to In Progress
- Priority changed from High to Urgent
sudo salt --no-color --state-output=changes 'openqaw5-xen.qa.suse.de' state.apply test=True shows that the configuration is reset to "PasswordAuthentication no" and "PermitRootLogin without-password". I removed openqaw5-xen from salt-keys. Please look into this again.
- Due date deleted (
2023-04-28)
- Status changed from In Progress to Resolved
- Priority changed from Urgent to High
I checked locally on openqaw5-xen.qa.suse.de with salt-call --no-color --state-output=changes state.show_sls sshd | less && salt-call --no-color --state-output=changes state.apply sshd; grep -i password /etc/ssh/sshd_config and I could confirm that the files are properly evaluated and the password authentication is kept properly. I guess test=True does not evaluate grains or so. So everything looks fine. salt key is added, state is cleanly applied from OSD.
Also available in: Atom
PDF