The tests - test_reset_password_unlock - test_proxycommand_invalid_shell
test_reset_password_unlock
test_proxycommand_invalid_shell
are failing in [testing_master_latest] Nightly PR #3676 with an error:
tasks.kinit_admin(self.master) tasks.user_add(self.master, user, password=original_passwd) tasks.kinit_user( self.master, user, '{0}\n{1}\n{1}\n'.format(original_passwd, new_passwd) ) # Lock out the user on master for _i in range(0, 7): tasks.kinit_user(self.master, user, bad_passwd, raiseonerr=False) tasks.kinit_admin(self.replicas[0]) # Administrative reset on a different server self.replicas[0].run_command( ['ipa', 'passwd', user], stdin_text='{0}\n{0}\n'.format(original_passwd) ) # Wait for the password update to be replicated from replicas[0] # to other servers ldap = self.replicas[0].ldap_connect() tasks.wait_for_replication(ldap) # The user can log in again > tasks.kinit_user( self.master, user, '{0}\n{1}\n{1}\n'.format(original_passwd, new_passwd) ) test_integration/test_commands.py:1411 ... E subprocess.CalledProcessError: Command '['kinit', 'tuser']' returned non-zero exit status 1. pytest_ipa/integration/host.py:202: CalledProcessError ----------------------------- Captured stderr call ----------------------------- ipa: ERROR: stderr: kinit: Client's credentials have been revoked while getting initial credentials
and subsequently
E subprocess.CalledProcessError: Command '['sudo', '-u', 'ruser', 'sshpass', '-p', 'Secret123', 'ssh', '-v', '-o', 'StrictHostKeyChecking=no', 'tuser1@master.ipa.test', 'cat /etc/hosts']' returned non-zero exit status 5. debug1: No credentials were supplied, or the credentials were unavailable or inaccessible No Kerberos credentials available (default cache: KCM:) debug1: No credentials were supplied, or the credentials were unavailable or inaccessible No Kerberos credentials available (default cache: KCM:) debug1: Next authentication method: publickey debug1: Trying private key: /home/ruser/.ssh/id_rsa debug1: Trying private key: /home/ruser/.ssh/id_ecdsa debug1: Trying private key: /home/ruser/.ssh/id_ecdsa_sk debug1: Trying private key: /home/ruser/.ssh/id_ed25519 debug1: Trying private key: /home/ruser/.ssh/id_ed25519_sk debug1: Trying private key: /home/ruser/.ssh/id_xmss debug1: Trying private key: /home/ruser/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive
Full report, logs
I'm not sure what I had in mind in test_reset_password_unlock() using multiple servers. I see no benefit to resetting the password on the replica as it just adds complexity.
It's hard to tell what wait_for_replication() has done, I think because it logs at the debug level so isn't displayed?
A sleep(2) would probably fix this as well. We could even keep the wait as a just-in-case.
I'm not sure what I had in mind in test_reset_password_unlock() using multiple servers.
I cannot answer that question for you, but imagine an unlikely scenario, where resetting password on replica wouldn't reset password on master. Improbable? Yes. Huge impact if true? Definitely.
Since it seems like an easy fix, I can take care of it.
Metadata Update from @mpolovka: - Issue assigned to mpolovka
Log in to comment on this ticket.