Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
Description of problem:
Support team is heavily relies on the provided sosreports as to isolate issues and to move forward with tshoot. Focusing on IDM, after the release of RHEL 7.3
there are some new features that were added to a tool for sssd tshoot - sssctl - It would be beneficial to have the information related commands of this tool gathered withing the sosreport
Version-Release number of selected component (if applicable):
RHEL 7.3
Steps to Reproduce:
1. Generate SOS report
Actual results:
# sssctl domain-list
jstephen.local
ADCORP.jstephen.local
example.com
# sssctl domain-status -o jstephen.local
Online status: Online
# sssctl config-check
Expected results:
To see the above output in the sos_commands dir (under sssctl for example. if the system is configured and have the appropriate packages installed)
Additional info:
requirements as seen in the docs
1) Ensure you are running SSSD 1.14 version or higher and install the
sssd-tools rpm
# rpm -q sssd
# yum install sssd-tools
2) Add ifp to the services section in sssd.conf
[sssd]
services = nss, pam, sudo, ifp
---
for now I am just adding
a. this article that explains a plethora of them
https://access.redhat.com/articles/2751311
b. the official doc
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#sssctl
> under sssctl for example. if the system is configured and have the appropriate
> packages installed
The default location would be 'sos_commands/sssd/sssctl_$CMD_OPTS' - a new command added to the existing 'sssd' plugin (there doesn't seem to be any justification for a whole new plugin here).
> 2) Add ifp to the services section in sssd.conf
> [sssd]
> services = nss, pam, sudo, ifp
What does mean for sos, in terms of calling the sssctl command?
If this configuration change is required then we will only be able to collect this from customer systems where this change has already been made - sos does not modify customer configurations under any circumstances.
(In reply to Bryn M. Reeves from comment #1)
Hello,
> > under sssctl for example. if the system is configured and have the appropriate
> > packages installed
>
> The default location would be 'sos_commands/sssd/sssctl_$CMD_OPTS' - a new
> command added to the existing 'sssd' plugin (there doesn't seem to be any
> justification for a whole new plugin here).
>
ok, thanks for the clarification
> > 2) Add ifp to the services section in sssd.conf
> > [sssd]
> > services = nss, pam, sudo, ifp
>
> What does mean for sos, in terms of calling the sssctl command?
>
> If this configuration change is required then we will only be able to
> collect this from customer systems where this change has already been made -
> sos does not modify customer configurations under any circumstances.
no, not at all, my apologies for the inconvenience. I just wanted to highlight how this should be configured. This command is working only if this ifp parameter is in place and I am not aware if you have to specify any kind of checks similar to if this option then execute
Regards
M.Panaousis