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 2115254 - 'No such object' message is displayed on the console when ipa-healthcheck is run.
Summary: 'No such object' message is displayed on the console when ipa-healthcheck is ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: 8.7
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 8.8
Assignee: Simon Pichugin
QA Contact: LDAP QA Team
URL:
Whiteboard: sync-to-jira
: 2109958 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-08-04 08:49 UTC by Sudhir Menon
Modified: 2023-05-16 09:42 UTC (History)
9 users (show)

Fixed In Version: 389-ds-1.4-8080020221115220516.6e2e7265
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-16 08:33:01 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker IDMDS-2559 0 None None None 2022-10-12 16:00:36 UTC
Red Hat Issue Tracker IDMDS-2719 0 None None None 2023-01-11 12:55:32 UTC
Red Hat Issue Tracker RHELPLAN-130279 0 None None None 2022-08-04 08:52:49 UTC
Red Hat Product Errata RHBA-2023:2811 0 None None None 2023-05-16 08:33:34 UTC

Description Sudhir Menon 2022-08-04 08:49:01 UTC
Description of problem: 'No such object' message is displayed on the console when ipa-healthcheck is run.

Version-Release number of selected component (if applicable):
ipa-server-4.9.10-5.module+el8.7.0+16195+c459c321.x86_64
389-ds-base-1.4.3.30-3.module+el8.7.0+15600+347cafc6.x86_64
krb5-server-1.18.2-21.el8.x86_64
ipa-healthcheck-0.7-14.module+el8.7.0+15352+88b578e5.noarch

How reproducible:
Always

Steps to Reproduce:
1. ipa-healthcheck --all

Actual results:
[root@server yum.repos.d]# ipa-healthcheck --all --output-type=human
args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such object', 'ctrls': [], 'ldap_request': "search_ext_s(('cn=changelog5,cn=config', 0, '(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'], 'serverctrls': None, 'clientctrls': None, 'escapehatch': 'i am sure'}) on instance RHEL87-TEST"},)
SUCCESS: ipahealthcheck.meta.services.certmonger
SUCCESS: ipahealthcheck.meta.services.dirsrv
SUCCESS: ipahealthcheck.meta.services.gssproxy
SUCCESS: ipahealthcheck.meta.services.httpd
SUCCESS: ipahealthcheck.meta.services.ipa_custodia
SUCCESS: ipahealthcheck.meta.services.ipa_dnskeysyncd
SUCCESS: ipahealthcheck.meta.services.ipa_otpd
SUCCESS: ipahealthcheck.meta.services.kadmin
.......

SUCCESS: ipahealthcheck.system.filesystemspace.FileSystemSpaceCheck: /tmp: free space percentage within limits: 84% >= 20%
SUCCESS: ipahealthcheck.system.filesystemspace.FileSystemSpaceCheck: /tmp: free space within limits: 17315 MiB >= 512 MiB

Expected results:
The below message is seen recently.

args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such object', 'ctrls': [], 'ldap_request': "search_ext_s(('cn=changelog5,cn=config', 0, '(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'], 'serverctrls': None, 'clientctrls': None, 'escapehatch': 'i am sure'}) on instance RHEL87-TEST"},)

Additional info:

Comment 1 Rob Crittenden 2022-08-04 12:40:05 UTC
Mark, I'd swear we talked about this one but I can't find an open BZ on it.

Either way it is just extra output on stderr and does not impact operation.

Comment 2 mreynolds 2022-08-04 13:24:53 UTC
(In reply to Rob Crittenden from comment #1)
> Mark, I'd swear we talked about this one but I can't find an open BZ on it.
> 
> Either way it is just extra output on stderr and does not impact operation.

Hmm, yeah I recall this topic as well.  We don't have changelog5 anymore in 8.7 (or 8.6 maybe not in 8.5) so let me look into this.  I hope we didn't have some sort of merge commit that undid this change. :-(

Comment 3 Rob Crittenden 2022-08-24 18:12:53 UTC
Changing component since this message appears to originate in the lib389 checks.

Comment 4 mreynolds 2022-10-12 15:21:16 UTC
*** Bug 2109958 has been marked as a duplicate of this bug. ***

Comment 5 mreynolds 2022-10-21 19:18:52 UTC
I can reproduce this issue using ipa-healthcheck.  But on the same system calling DS's "dsctl healthcheck" I do not see these errors.

Looking at DS lint code used by our healthcheck we catch the error 32 and just ignore it:

        try:
            # Check if replication is enabled
            replicas.get(suffix)
            # Check the changelog
            cl = Changelog5(self._instance)
            if cl.get_attr_val_utf8('nsslapd-changelogmaxentries') is None and \
               cl.get_attr_val_utf8('nsslapd-changelogmaxage') is None:
                report = copy.deepcopy(DSCLLE0001)
                report['fix'] = report['fix'].replace('YOUR_INSTANCE', self._instance.serverid)
                report['check'] = f'backends:{bename}::cl_trimming'
                yield report
        except:
            # Suffix is not replicated
            self._log.debug(f"_lint_cl_trimming - backend ({suffix}) is not replicated")
            pass


I forget how IPA uses DS healthchecks from lib389, Rob can you refresh my memory on how it gets pulled into ipa-healthcheck?

Comment 6 Rob Crittenden 2022-10-21 19:56:26 UTC
The DSPlugin class is the bridge between the DS checks and the healthchecks, https://github.com/freeipa/freeipa-healthcheck/blob/master/src/ipahealthcheck/ds/plugin.py#L29

This is the base class for the checks in the other files which take the form of, for example:

@registry
class DSECheck(DSPlugin):
    """
    Check the dse.ldif/cn=config for obvious issues
    """
    check_class = DSEldif

The DSPlugin catches the check() call from healthcheck and calls the 389-ds equivalent, then transforms the result into something healthcheck can understand.

Comment 7 mreynolds 2022-10-21 20:33:49 UTC
This is beyond my python skills.  I can absolutely confirm that the DS code is catching the exception and properly handling it, but the healthcheck code is somehow detecting the exception and capturing and reporting the exception message.  I don't know what I could do differently in the DS code to prevent this from happening.

Comment 8 mreynolds 2022-10-24 19:00:06 UTC
Moving back to ipa-healthcheck because I see nothing wrong in the DS code (try/except/pass is working), or no way to prevent the calling code from detecting that an exception was caught.

Comment 9 Rob Crittenden 2022-10-26 18:12:01 UTC
Mark, the error appears to originate in python-ldap. The call to _search_ext_s() produces this output:

args=({'msgtype': 101, 'msgid': 3, 'result': 32, 'desc': 'No such object', 'ctrls': [], 'ldap_request': "search_ext_s(('cn=changelog5,cn=config', 0, '(objectClass=*)'),{'attrlist': ['nsslapd-changelogmaxentries'], 'serverctrls': None, 'clientctrls': None, 'escapehatch': 'i am sure'}) on instance EXAMPLE-TEST"},)
Traceback (most recent call last):

I can't tell why it only outputs on this specific call.

Comment 10 Rob Crittenden 2022-11-03 21:32:28 UTC
The message first appears in the healthcheck output in 389-ds-base-1.4.3.30-3.module+el8.7.0+15600+347cafc6.x86_64

It does not appear prior to that.

The problem is this logging statement in the roll-up patch:

++++ b/src/lib389/lib389/_mapped_object.py
...
++# Define wrappers around the ldap operation to have a clear diagnostic
++def _ldap_op_s(inst, f, fname, *args, **kwargs):
++    # f.__name__ says 'inner' so the wanted name is provided as argument
++    try:
++        return f(*args, **kwargs)
++    except ldap.LDAPError as e:
++        new_desc = f"{fname}({args},{kwargs}) on instance {inst.serverid}";
++        if len(e.args) >= 1:
++            e.args[0]['ldap_request'] = new_desc
++            logging.getLogger().error(f"args={e.args}")
              ^^^ here

I commented that out and no more message.

Re-assigning product to 389-ds-base.

Comment 11 mreynolds 2022-11-16 17:44:41 UTC
(In reply to Rob Crittenden from comment #10)
> The message first appears in the healthcheck output in
> 389-ds-base-1.4.3.30-3.module+el8.7.0+15600+347cafc6.x86_64
> 
> It does not appear prior to that.
> 
> The problem is this logging statement in the roll-up patch:
> 
> ++++ b/src/lib389/lib389/_mapped_object.py
> ...
> ++# Define wrappers around the ldap operation to have a clear diagnostic
> ++def _ldap_op_s(inst, f, fname, *args, **kwargs):
> ++    # f.__name__ says 'inner' so the wanted name is provided as argument
> ++    try:
> ++        return f(*args, **kwargs)
> ++    except ldap.LDAPError as e:
> ++        new_desc = f"{fname}({args},{kwargs}) on instance {inst.serverid}";
> ++        if len(e.args) >= 1:
> ++            e.args[0]['ldap_request'] = new_desc
> ++            logging.getLogger().error(f"args={e.args}")
>               ^^^ here
> 
> I commented that out and no more message.

I don't think we should remove that code...

I think I don't see this issue when I run our healthcheck tool is because we explicitly set the logger to stdout.  I could be wrong, but it seems that the logger is the only difference between our tools:

    logger = logging.getLogger()
    log_handler = logging.StreamHandler(sys.stdout)
    logger.addHandler(log_handler)

I am curious to see if this code fixes the issue in ipa healthcheck tool (not sure where it should be added though).  I'll try and work on it next week...

Comment 12 mreynolds 2022-11-18 15:43:24 UTC
Adding that logging change actually makes the message print twice. smh.  Assigning to Simon to continue investigation...

Comment 13 Simon Pichugin 2022-12-06 19:23:26 UTC
Actually, looks like you've fixed it already, Mark!

As Rob pointed out, the issue happens precisely because of this line in src/lib389/lib389/_mapped_object.py:

    logging.getLogger().error(f"args={e.args}")

It reports to 'error' and the IPA tool reports it (as everything in 'error' level is reported).
If we change it to:

    logging.getLogger().debug(f"args={e.args}")

The issue is fixed.
The commit https://github.com/389ds/389-ds-base/commit/01a3d566babb746beb03fba84cad186cbaf7af68 is already in 1.4.3 upstream.
We just need to create a build with the change in Downstream.

I've made a scratch build with the commit and it fixed the issue for me. Feel free to check it, in a meanwhile:
http://brew-task-repos.usersys.redhat.com/repos/scratch/spichugi/389-ds-base/1.4.3.30/6ipahlthcheck.el8_7/

Comment 14 mreynolds 2022-12-09 16:44:31 UTC
(In reply to Simon Pichugin from comment #13)
> Actually, looks like you've fixed it already, Mark!
> 

So I did ;-)  It is in the current 8.8 build, moving bug to modified

Comment 21 bsmejkal 2023-01-24 15:42:20 UTC
As per comment #c20, marking as VERIFIED.

Comment 23 errata-xmlrpc 2023-05-16 08:33:01 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-2023:2811


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