IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2024-12-23 07:33:27 -06:00
Code Issues Packages Projects Releases Wiki Activity

pylint: fix comparison-of-constants

Browse Source 
Related: https://pagure.io/freeipa/issue/9278

Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
This commit is contained in:
Florence Blanc-Renaud 2022-11-22 09:45:39 +01:00
parent 416c210fc3
commit a4102b9960
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
ipatests/test_cmdline/test_ipagetkeytab.py
View File

@ -463,8 +463,8 @@ class test_smb_service(KeytabRetrievalTest):
try:
conn.update_entry(entry)
except errors.ACIError:
assert ('No correct ACI to the allow ipaNTUserAttrs '
'for SMB service' in "failure")
assert False, ('No correct ACI to the allow ipaNTUserAttrs '
'for SMB service')
# Step 2. With ipaNTUserAttrs in place, we can ask to regenerate
# ipaNTHash value. We can also verify it is possible to write to
@ -476,15 +476,14 @@ class test_smb_service(KeytabRetrievalTest):
try:
conn.update_entry(entry)
except errors.ACIError:
assert ("No correct ACI to the ipaNTHash for SMB service"
in "failure")
assert False, "No correct ACI to the ipaNTHash for SMB service"
except errors.EmptyResult:
assert "No arcfour-hmac in Kerberos keys" in "failure"
assert False, "No arcfour-hmac in Kerberos keys"
except errors.DatabaseError:
# Most likely ipaNTHash already existed -- we either get
# OPERATIONS_ERROR or UNWILLING_TO_PERFORM, both map to
# the same DatabaseError class.
assert "LDAP Entry corruption after generation" in "failure"
assert False, "LDAP Entry corruption after generation"
# Update succeeded, now we have either MagicRegen (broken) or
# a real NT hash in the entry. However, we can only retrieve it as