Bug 2068450

Moving back to ipa as the connection originates there. This may be related to gymnastics we have to do when loading profiles against the local server.

Note that the hostname isn't an IP address. It's a hostname that contains the address within it for automation purposes.

Interestingly this isn't a traceback. The logging includes exc_info=True so the logging prints the traceback but this isn't an uncaught error.

This is intended behavior for the most part, not necessarily the traceback, but IMHO its worth keeping the exc_info=True.

This is related to upstream issue https://pagure.io/freeipa/issue/9100 and is commit https://github.com/freeipa/freeipa/commit/8c241869dda779d38fee4c23e44c89eb81a2a4d4

Basically it is trying port 443 first to connect to the CA to import the profiles which is failing because we haven't configured or started Apache yet. That fails so it next tries 8443 which is available only to the local machine (no open firewall port). That succeeds and installation continues.

Resetting Assignee and QE Contact to default.

@sumenon do you know if this is still happening?

The decision to make is whether to disable exc_info=True since it produces a scary traceback.

This is otherwise a red herring.

The relevant portion of code is https://github.com/freeipa/freeipa/blob/ae6549ffae1ffe2bb6a1ba7dce0620ec0c20cabf/ipapython/dogtag.py#L269-L280:

    try:
        conn = connection_factory(host, port, **connection_options)
        conn.request(method, path, body=request_body, headers=headers)
        res = conn.getresponse()

        http_status = res.status
        http_headers = res.msg
        http_body = res.read()
        conn.close()
    except Exception as e:
        logger.debug("httplib request failed:", exc_info=True)
        raise NetworkError(uri=uri, error=str(e))


If we remove exc_info=True, the traceback won't be printed any more in the debug logs but we will still see the next message:
2022-03-21T17:21:50Z DEBUG httplib request failed:
2022-03-21T17:21:50Z DEBUG Overriding CA port: cannot connect to 'https://ip-addr.testrealm.test:443/ca/rest/account/login': [Errno 111] Connection refused

IMO we can remove exc_info=True as the debug would contain enough information anyway.

I dug a little deeper. This traceback was originally displayed to the user and was addressed in https://pagure.io/freeipa/issue/6674 with 53c8e9a53f026d83d5328896d1ea0cf72690cf24 . The log level was changed from exception to debug and exc_info=True was added. I don't think that in the ipactl case it adds much value, but dogtag.https_request is called in other contexts too where a connection failure is unexpected. Perhaps we can add an argument to https_request to provide the traceback or not.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.