RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1862971 - dsidm user status fails with Error: 'nsUserAccount' object has no attribute 'is_locked'
Summary: dsidm user status fails with Error: 'nsUserAccount' object has no attribute '...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Simon Pichugin
QA Contact: RHDS QE
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-03 11:02 UTC by Viktor Ashirov
Modified: 2021-05-18 15:45 UTC (History)
9 users (show)

Fixed In Version: 389-ds-devel-1.4-8040020201105165416.866effaa
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 15:45:26 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 4281 0 None closed dsidm user status fails with Error: 'nsUserAccount' object has no attribute 'is_locked' 2020-12-14 09:37:06 UTC

Description Viktor Ashirov 2020-08-03 11:02:58 UTC 
Description of problem:
Create a user using `dsidm user create` and try to get its status using `dsidm user status`:
```
dsidm -b dc=example,dc=com myinst user status
Enter uid to check : test
Error: 'nsUserAccount' object has no attribute 'is_locked'
```

Version-Release number of selected component (if applicable):

389-ds-base-1.4.3.8-4.module+el8.3.0+7193+dfd1e8ad.x86_64
Comment 1 Tony 2020-08-09 23:01:48 UTC 
I'm seeing this as well. I tried adding locking and unlocking the account, in case that action would add the appropriate attribute, but that didn't work. The problem happened with the demo account as well as one I added. This is a new DS installation on a Fedora 32 VM,installed via Cockpit.

 389-ds-base.x86_64                                 1.4.3.12-1.fc32
 python3-lib389.noarch                              1.4.3.12-1.fc32

 [root@fedora389 t]# dsidm -b 'dc=test,dc=com' slapd-testnomer user status demo_user
 Error: 'nsUserAccount' object has no attribute 'is_locked'
 [root@fedora389 t]# dsidm -b 'dc=testn,dc=com' slapd-testnomer user lock demo_user
 locked demo_user
 [root@fedora389 t]# dsidm -b 'dc=test,dc=com' slapd-testnomer user status demo_user
 Error: 'nsUserAccount' object has no attribute 'is_locked'
 [root@fedora389 t]# dsidm -b 'dc=test,dc=com' slapd-testnomer user unlock demo_user
 unlocked demo_user
 [root@fedora389 t]# dsidm -b 'dc=test,dc=com' slapd-testnomer user status demo_user
 Error: 'nsUserAccount' object has no attribute 'is_locked'
 [root@fedora389 t]#
Comment 2 Simon Pichugin 2020-08-11 14:56:39 UTC 
We've depricating 'user status', 'user lock', 'user unlock' as the functionality is present under 'account' and 'role' subcommands.

More information can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=1868052
Comment 3 Tony 2020-08-11 17:00:31 UTC 
(In reply to Simon Pichugin from comment #2)
> We've depricating 'user status', 'user lock', 'user unlock' as the
> functionality is present under 'account' and 'role' subcommands.
> 
> More information can be found here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1868052

Thank you. This is certainly some fresh information. When I try with the 'account entry-status' command, the system does not produce the 'nsUserAccount' object has no attribute 'is_locked' error. Does that mean there is no problem with the accounts and that, perhaps, the 'user status' command is not being updated, so is treating the account record incorrectly?

-Tony
Comment 4 Simon Pichugin 2020-08-12 11:36:47 UTC 
(In reply to Tony from comment #3)
> Thank you. This is certainly some fresh information. When I try with the
> 'account entry-status' command, the system does not produce the
> 'nsUserAccount' object has no attribute 'is_locked' error. Does that mean
> there is no problem with the accounts and that, perhaps, the 'user status'
> command is not being updated, so is treating the account record incorrectly?
> 
> -Tony

Yes, probably, there is no problems with your accounts.

'user status/lock/unlock' were broken after we implemented all of the functionality in the 'account' subcommand. 'user status/lock/unlock' will be depricated with the next build (the change is already in 'master').

And thanks for the testing!
Comment 5 Tony 2020-08-12 12:11:47 UTC 
Excellent. Thank you!
Comment 11 Viktor Ashirov 2020-08-26 15:39:29 UTC 
I've checked the fix on a scratch build, there are still some issues (copy-pasted message):

[root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32 -b dc=example,dc=com account entry-status
Enter dn to check : uid=test,ou=people,dc=example,dc=com
Entry DN: uid=test,ou=people,dc=example,dc=com
Entry Creation Date: 20200826153047Z (2020-08-26 15:30:47)
Entry Modification Date: 20200826153047Z (2020-08-26 15:30:47)
Entry State: activated

[root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32 -b dc=example,dc=com account lock
Enter dn to check : uid=test,ou=people,dc=example,dc=com
Entry uid=test,ou=people,dc=example,dc=com is locked

The message should be "Enter dn to lock"

[root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32 -b dc=example,dc=com account unlock
Enter dn to check : uid=test,ou=people,dc=example,dc=com
Entry uid=test,ou=people,dc=example,dc=com is unlocked

The message should be "Enter dn to unlock"

The rest looks good, `entry-status/lock/unlock` were moved from `user` to `account` subcommand.
Comment 12 Simon Pichugin 2020-08-27 13:30:12 UTC 
(In reply to Viktor Ashirov from comment #11)
> I've checked the fix on a scratch build, there are still some issues
> (copy-pasted message):
> 
> [root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32
> -b dc=example,dc=com account entry-status
> Enter dn to check : uid=test,ou=people,dc=example,dc=com
> Entry DN: uid=test,ou=people,dc=example,dc=com
> Entry Creation Date: 20200826153047Z (2020-08-26 15:30:47)
> Entry Modification Date: 20200826153047Z (2020-08-26 15:30:47)
> Entry State: activated
> 
> [root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32
> -b dc=example,dc=com account lock
> Enter dn to check : uid=test,ou=people,dc=example,dc=com
> Entry uid=test,ou=people,dc=example,dc=com is locked
> 
> The message should be "Enter dn to lock"
> 
> [root@server-f32 ds]# dsidm  -D cn=directory\ manager -w password server-f32
> -b dc=example,dc=com account unlock
> Enter dn to check : uid=test,ou=people,dc=example,dc=com
> Entry uid=test,ou=people,dc=example,dc=com is unlocked
> 
> The message should be "Enter dn to unlock"
> 
> The rest looks good, `entry-status/lock/unlock` were moved from `user` to
> `account` subcommand.

The changes are made. The fix is in master, 1.4.2, and 1.4.3.
Comment 17 bsmejkal 2020-11-13 15:04:13 UTC 
==================================================================================== test session starts =====================================================================================
platform linux -- Python 3.6.8, pytest-6.1.2, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python3.6
cachedir: .pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-4.18.0-247.el8.x86_64-x86_64-with-redhat-8.4-Ootpa', 'Packages': {'pytest': '6.1.2', 'py': '1.9.0', 'pluggy': '0.13.1'}, 'Plugins': {'metadata': '1.10.0', 'html': '2.1.1', 'libfaketime': '0.1.2'}}
389-ds-base: 1.4.3.16-1.module+el8.4.0+8740+d5ec8778
nss: 3.53.1-11.el8_2
nspr: 4.25.0-2.el8_2
openldap: 2.4.46-16.el8
cyrus-sasl: 2.1.27-5.el8
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests, configfile: pytest.ini
plugins: metadata-1.10.0, html-2.1.1, libfaketime-0.1.2
collected 1 item                                                                                                                                                                             

dirsrvtests/tests/suites/clu/dsidm_account_test.py::test_dsidm_account_entry_status_with_lock PASSED                                                                                   [100%]

=============================================================================== 1 passed in 10.29s ==========================================================================================

Marking as Verified:Tested.
Comment 23 sgouvern 2020-11-30 16:44:37 UTC 
verified:tested (see comment 17) with build 389-ds-1.4-8040020201125182123.866effaa / 389-ds-base-libs-1.4.3.16-2.module+el8.4.0+8803+fd0f8fe3.x86_64
-> marking as VERIFIED
Comment 25 errata-xmlrpc 2021-05-18 15:45:26 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds:1.4 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1835
Note You need to log in before you can comment on or make changes to this bug.