1379824 – ns-accountstatus.pl shows wrong status for accounts inactivated by Account policy plugin

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 1379824 - ns-accountstatus.pl shows wrong status for accounts inactivated by Account policy plugin

Summary: ns-accountstatus.pl shows wrong status for accounts inactivated by Account po...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	389-ds-base
Sub Component:
Version:	7.3
Hardware:	x86_64
OS:	Linux
Priority:	urgent
Severity:	urgent
Target Milestone:	rc
Target Release:	---
Assignee:	Noriko Hosoi
QA Contact:	Viktor Ashirov
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1390342
TreeView+	depends on / blocked

Reported:	2016-09-27 18:38 UTC by Sankar Ramalingam
Modified:	2023-09-14 03:31 UTC (History)
CC List:	8 users (show)
Fixed In Version:	389-ds-base-1.3.6.1-3.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	1390342 (view as bug list)
Environment:
Last Closed:	2017-08-01 21:10:21 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 2073	0	None	None	None	2020-09-13 21:52:19 UTC
Red Hat Product Errata	RHBA-2017:2086	0	normal	SHIPPED_LIVE	389-ds-base bug fix and enhancement update	2017-08-01 18:37:38 UTC

Description Sankar Ramalingam 2016-09-27 18:38:20 UTC

Description of problem: The output of ns-accountstatus.pl script is misleading. Checking whether account is active/inactive for users which are inactivated by account policy plugin, it shows account is activated. 


Version-Release number of selected component (if applicable): 389-ds-base-1.3.5.10-11


How reproducible: Consistently with 389-ds-base-1.3.5 versions


Steps to Reproduce:
1. Install 389-ds-base-1.3.5.10-11 on RHEL7.3 machines.
2. Create an instance and configure global account policy plugin.

[root@ratangad ]# PORT=3989 ; ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT -x  -vf /export/Backups/AccountPolicy/Global.ldif 

[root@ratangad ]# cat /export/Backups/AccountPolicy/Global.ldif
dn: cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
-
replace: nsslapd-pluginarg0
nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config

dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: alwaysrecordlogin
alwaysrecordlogin: yes
-
replace: stateattrname
stateattrname: lastLoginTime
-
replace: altstateattrname
altstateattrname: createTimestamp
-
replace: specattrname
specattrname: acctPolicySubentry
-
replace: limitattrname
limitattrname: accountInactivityLimit
-
replace: accountInactivityLimit
accountInactivityLimit: 120

3. Add few entries to the suffix, dc=example,dc=com

4. Wait for 120 secs and check if account is inactivated.
[root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-accountstatus.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 -b $USER3 -f objectclass=*
uid=Anewnew1,ou=Testing,dc=test_accpol,dc=com - activated.

5. Check if the user is active by binding.
[ root@ratangad slapd-M1]#  PORT=3989; USER="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "$USER" -w Secret123 -b "$USER"
ldap_bind: Constraint violation (19)
	additional info: Account inactivity limit exceeded. Contact system administrator to reset.

Actual results: ns-accountstatus.pl shows wrong status for inactive users.


Expected results: It should print the correct status of user accounts.


Additional info:

There are test failures from account inactivity reliability tests, which we didn't observe with 389-ds-base-1.3.4.0 builds.

RHEL73 - wiki-old.idm.lab.bos.redhat.com/qa/archive/beaker/RHDS/RHEL73/389-ds-base-1.3.5.10-11.el7.x86_64/Tier2/output/Linux/20160914-140158/accountinact/reliability/accountinact_reliab.run.out.4592
RHEL72 - http://wiki-old.idm.lab.bos.redhat.com/qa/archive/beaker/x86_64/389-ds-base-1.3.4.0-23.el7_2.x86_64/output/Linux/20160113-045003/accountinact/reliability/accountinact_reliab.run.out.4634


[root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 
uid=Anewnew1,ou=testing,dc=test_accpol,dc=com already activated.

[root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 
uid=Anewnew1,ou=testing,dc=test_accpol,dc=com inactivated.

[root@ratangad slapd-M1]# PORT=3989 ; USER3="uid=Anewnew1,ou=testing,dc=test_accpol,dc=com"; ns-accountstatus.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 -b $USER3 -f objectclass=*
uid=Anewnew1,ou=Testing,dc=test_accpol,dc=com - inactivated (directly locked).

Comment 2 Noriko Hosoi 2016-09-27 19:58:15 UTC

I could reproduce the problem...

$ ldapsearch -LLLx -D 'uid=tuser996,ou=People,dc=example,dc=com' -w tuser996 -b "" -s base
ldap_bind: Constraint violation (19)
	additional info: Account inactivity limit exceeded. Contact system administrator to reset.

# ns-accountstatus.pl -Z test0 -D "cn=Directory Manager" -W -I "uid=tuser996,ou=People,dc=example,dc=com"
uid=tuser996,ou=People,dc=example,dc=com - activated.

The script searches cn=nsdisabledrole,<SUFFIX>, which fails with 32.
[..] conn=45 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[..] conn=45 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[..] conn=45 op=1 SRCH base="cn=nsdisabledrole,dc=example,dc=com" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRoleDN"
[..] conn=45 op=1 RESULT err=32 tag=101 nentries=0 etime=0
[..] conn=45 op=2 UNBIND

And indeed there is no such entry.
ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=nsdisabledrole,dc=example,dc=com" -s base "(|(objectClass=*)(objectClass=ldapsubentry))" 
No such object (32)
Matched DN: dc=example,dc=com

The cn=nsdisabledrole,dc=example,dc=com entry is only created and managed by ns-*activate.pl scripts (or Console, too?).  Just by adding an entry and let the entry expire by the Account Policy config with no interaction with the ns-*activate.pl scripts, I don't think ns-accountstatus.pl can display the right status.  I'm doubting it was working on 1.3.4.0, either...

My vote is this is minor enough for rhel-7.3 and should be pushed to 7.4.  What do you think, Mark?

Comment 3 mreynolds 2016-09-28 02:24:54 UTC

(In reply to Noriko Hosoi from comment #2)
> I could reproduce the problem...
> 
> $ ldapsearch -LLLx -D 'uid=tuser996,ou=People,dc=example,dc=com' -w tuser996
> -b "" -s base
> ldap_bind: Constraint violation (19)
> 	additional info: Account inactivity limit exceeded. Contact system
> administrator to reset.
> 
> # ns-accountstatus.pl -Z test0 -D "cn=Directory Manager" -W -I
> "uid=tuser996,ou=People,dc=example,dc=com"
> uid=tuser996,ou=People,dc=example,dc=com - activated.
> 
> The script searches cn=nsdisabledrole,<SUFFIX>, which fails with 32.
> [..] conn=45 op=0 BIND dn="cn=Directory Manager" method=128 version=3
> [..] conn=45 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory
> manager"
> [..] conn=45 op=1 SRCH base="cn=nsdisabledrole,dc=example,dc=com" scope=0
> filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsRoleDN"
> [..] conn=45 op=1 RESULT err=32 tag=101 nentries=0 etime=0
> [..] conn=45 op=2 UNBIND
> 
> And indeed there is no such entry.
> ldapsearch -LLLx -D 'cn=directory manager' -W -b
> "cn=nsdisabledrole,dc=example,dc=com" -s base
> "(|(objectClass=*)(objectClass=ldapsubentry))" 
> No such object (32)
> Matched DN: dc=example,dc=com
> 
> The cn=nsdisabledrole,dc=example,dc=com entry is only created and managed by
> ns-*activate.pl scripts (or Console, too?).  Just by adding an entry and let
> the entry expire by the Account Policy config with no interaction with the
> ns-*activate.pl scripts, I don't think ns-accountstatus.pl can display the
> right status.  I'm doubting it was working on 1.3.4.0, either...
> 
> My vote is this is minor enough for rhel-7.3 and should be pushed to 7.4. 
> What do you think, Mark?

Actually this is bad if it's reporting the wrong status.  Can it go into a batch update for 7.3?

Comment 4 Sankar Ramalingam 2016-09-28 09:42:43 UTC

I just figured out the actual regression for ns-activate.pl script. This is the reason why the account inactivity reliability tests fail.

With Account policy plugin configured, the ns-activate.pl script returns exit status as 100 for users already activated. Where as, if no Account policy plugin configured, then it never returns exit status 100 for active users. The script is expected to return exit status 100, if you are running ns-activate.pl script when the user is already active.

With account policy plugin configured:

[root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 ; echo $?
uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated.
100
[root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 ; echo $?
uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com inactivated.
0
[root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 ; echo $?
uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already inactivated.
100

[root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 ; echo $?
uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com activated.
0
[root@ratangad MMR_WINSYNC]# PORT=3989 ; USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I $USER3 ; echo $?
uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated.
100

No account policy plugin configured:

[root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I $USER3 ; echo $?
uid=newnew2,ou=testing,dc=accpol,dc=com activated.
0
[root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I $USER3 ; echo $?
uid=newnew2,ou=testing,dc=accpol,dc=com inactivated.
0
[root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I $USER3 ; echo $?
uid=newnew2,ou=testing,dc=accpol,dc=com already inactivated.
100
[root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I $USER3 ; echo $?
uid=newnew2,ou=testing,dc=accpol,dc=com activated.
0
[root@ratangad MMR_WINSYNC]# PORT=4989 ; USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I $USER3 ; echo $?
uid=newnew2,ou=testing,dc=accpol,dc=com activated.
0

This is where we expect the script to return 100, but it returns 0 always.

Comment 5 mreynolds 2016-10-06 15:46:34 UTC

(In reply to Sankar Ramalingam from comment #4)
> I just figured out the actual regression for ns-activate.pl script. This is
> the reason why the account inactivity reliability tests fail.
> 
> With Account policy plugin configured, the ns-activate.pl script returns
> exit status as 100 for users already activated. Where as, if no Account
> policy plugin configured, then it never returns exit status 100 for active
> users. The script is expected to return exit status 100, if you are running
> ns-activate.pl script when the user is already active.
> 
> With account policy plugin configured:
> 
> [root@ratangad MMR_WINSYNC]# PORT=3989 ;
> USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I
> $USER3 ; echo $?
> uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated.
> 100
> [root@ratangad MMR_WINSYNC]# PORT=3989 ;
> USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I
> $USER3 ; echo $?
> uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com inactivated.
> 0
> [root@ratangad MMR_WINSYNC]# PORT=3989 ;
> USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-inactivate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I
> $USER3 ; echo $?
> uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already inactivated.
> 100
> 
> [root@ratangad MMR_WINSYNC]# PORT=3989 ;
> USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I
> $USER3 ; echo $?
> uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com activated.
> 0
> [root@ratangad MMR_WINSYNC]# PORT=3989 ;
> USER3="uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst3 -I
> $USER3 ; echo $?
> uid=Bnewnew2,ou=testing,dc=test_accpol,dc=com already activated.
> 100
> 
> No account policy plugin configured:
> 
> [root@ratangad MMR_WINSYNC]# PORT=4989 ;
> USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I
> $USER3 ; echo $?
> uid=newnew2,ou=testing,dc=accpol,dc=com activated.
> 0
> [root@ratangad MMR_WINSYNC]# PORT=4989 ;
> USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I
> $USER3 ; echo $?
> uid=newnew2,ou=testing,dc=accpol,dc=com inactivated.
> 0
> [root@ratangad MMR_WINSYNC]# PORT=4989 ;
> USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-inactivate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I
> $USER3 ; echo $?
> uid=newnew2,ou=testing,dc=accpol,dc=com already inactivated.
> 100
> [root@ratangad MMR_WINSYNC]# PORT=4989 ;
> USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I
> $USER3 ; echo $?
> uid=newnew2,ou=testing,dc=accpol,dc=com activated.
> 0
> [root@ratangad MMR_WINSYNC]# PORT=4989 ;
> USER3="uid=newnew2,ou=testing,dc=accpol,dc=com"; ns-activate.pl -D
> "cn=Directory Manager" -w Secret123 -h localhost -p $PORT  -Z newinst4 -I
> $USER3 ; echo $?
> uid=newnew2,ou=testing,dc=accpol,dc=com activated.
> 0
> 
> This is where we expect the script to return 100, but it returns 0 always.


This is the correct behavior.  When the script correctly accomplishes its task, it returns zero.  If something goes wrong, or a user was already activated or inactivated, then it returns an error code.  This is a change in behavior, but the old behavior was wrong.  

There is still a potential issue regarding comment 2.

Comment 6 mreynolds 2016-10-20 16:34:26 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/49014

Comment 7 mreynolds 2016-10-20 21:12:39 UTC

Fixed upstream

Comment 8 Marc Sauton 2016-10-25 00:58:14 UTC

GSS Approved Z-Stream

Comment 9 Noriko Hosoi 2016-10-26 22:14:58 UTC

Hello Marcel,

The devel freeze date for RHEL-7.3.z batch 1 is approaching (November 1).

Could you please give an approval and clone this bug for rhel-7.3.z?

Thanks!
--noriko

Comment 10 Noriko Hosoi 2016-10-31 18:13:48 UTC

Fixing 7.4.0 flag first, which was mistakenly cleared.

Comment 13 Sankar Ramalingam 2017-05-15 04:00:02 UTC

dirsrvtests/tests/suites/plugins/accpol_test.py::test_glinact_nsact OK group dirsrv exists
OK user dirsrv exists
INFO:lib389.utils:Configuring Global account policy plugin, pwpolicy attributes and restarting the server
INFO:lib389.utils:AccountInactivityLimit set to 12. Account will be inactivated if not accessed in 12 secs
INFO:lib389.utils:add_users: Pass all of these as parameters suffix, subtree, userid and nousrs
INFO:lib389.utils:Sleep for 3 secs to check if account is not inactivated, expected value 0
INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl
INFO:lib389.utils:Running ns-activate.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com
INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com already activated.

INFO:lib389.utils:Sleep for 10 secs to check if account is inactivated, expected value 19
INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl
INFO:lib389.utils:Running ns-activate.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com
INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com already activated.

INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl
INFO:lib389.utils:Running ns-accountstatus.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com
INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com - inactivated (inactivity limit exceeded).

INFO:lib389.utils:Enable account by replacing lastLoginTime/createTimeStamp/ModifyTimeStamp attribute
INFO:lib389.utils:Account activate/in-activate/status using ns-activate/inactivate/accountstatus.pl
INFO:lib389.utils:Running ns-accountstatus.pl for uuser uid=nsactusr1,ou=groups,dc=example,dc=com
INFO:lib389.utils:output: uid=nsactusr1,ou=groups,dc=example,dc=com - activated.

INFO:lib389.utils:del_users: Pass all of these as parameters suffix, subtree, userid and nousrs
PASSEDINFO:lib389.utils:Disabling Global accpolicy plugin and removing pwpolicy attrs
Instance slapd-standalone_1 removed.


====== 1 passed in 26.80 seconds ======
[0 root@qeos-130 ds]# rpm -qa |grep -i 389-ds
389-ds-base-1.3.6.1-13.el7.x86_64
389-ds-base-debuginfo-1.3.6.1-13.el7.x86_64
389-ds-base-snmp-1.3.6.1-13.el7.x86_64
389-ds-base-libs-1.3.6.1-13.el7.x86_64

Comment 14 errata-xmlrpc 2017-08-01 21:10:21 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, 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-2017:2086

Comment 15 Red Hat Bugzilla 2023-09-14 03:31:31 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days

Note You need to log in before you can comment on or make changes to this bug.