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 1743531 - sssd.service: main process exited, code=exited, status=4/NOPERMISSION
Summary: sssd.service: main process exited, code=exited, status=4/NOPERMISSION
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libldb
Version: 7.8
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-20 08:00 UTC by Selman Keskin
Modified: 2021-03-15 07:38 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-15 07:38:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Selman Keskin 2019-08-20 08:00:58 UTC 
Description of problem:
sssd running one client but fails another, any idea?

Actual results:

# journalctl -xe
-- Unit sssd.service has begun starting up.
Ağu 20 09:20:17 slreport.linktera.lan sssd[31252]: Starting up
Ağu 20 09:20:17 slreport.linktera.lan systemd[1]: sssd.service: main process exited, code=exited, status=4/NOPERMISSION
Ağu 20 09:20:17 slreport.linktera.lan systemd[1]: Failed to start System Security Services Daemon.

# cat /var/log/sssd/sssd.log
(Tue Aug 20 09:20:17 2019) [sssd] [confdb_get_domains] (0x0010): No domains configured, fatal error!
(Tue Aug 20 09:20:17 2019) [sssd] [main] (0x0010): No domains configured.

Expected results:
SSSD is running

Additional info:
i tried
  1. check permission of sssd.conf
  2. disable firewalls, selinux, firewalld
  3. configuring sssd.conf
Comment 2 Sumit Bose 2019-08-20 08:24:08 UTC 
Hi,

'No domains configured, fatal error!' sounds like you have a /etc/sssd/sssd.conf file but either the 'domains' option is missing in the [sssd] section or there is no matching [domain/...] section. Can you send your sssd.conf file (sanitized if needed)?.

bye,
Sumit
Comment 3 Selman Keskin 2019-08-20 09:48:52 UTC 
my sssd.conf file is:
What is the problem?

[sssd]
debug_level = 9
domains = linktera.lan
services = nss, sudo, pam, ssh, ifp

[domain/LINKTERA.LAN]
enumerate = true
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linktera.lan
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = slreport.linktera.lan
chpass_provider = ipa
ipa_server = _srv_, ipa.linktera.lan
ldap_tls_cacert = /etc/ipa/ca.crt

[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[secrets]

[session_recording]
Comment 4 Sumit Bose 2019-08-20 10:29:17 UTC 
Hi,

I just copied-and-pasted your config and it works for me. Can you check if the file /var/lib/sss/db/config.ldb exists and if yes, please install the ldb-tools package and send the output of

    ldbsearch -H /var/lib/sss/db/config.ldb

bye,
Sumit
Comment 5 Selman Keskin 2019-08-20 10:36:03 UTC 
my 
   ldbsearch -H /var/lib/sss/db/config.ldb
is:

# record 1
dn: cn=sssd,cn=config
cn: sssd
debug_level: 9
enable_files_domain: true
services: nss, sudo, pam, ssh, ifp
domains: implicit_files,linktera.lan
distinguishedName: cn=sssd,cn=config

# record 2
dn: cn=config
version: 2
lastUpdate: 1566296406
distinguishedName: cn=config

# record 3
dn: cn=nss,cn=config
cn: nss
homedir_substring: /home
distinguishedName: cn=nss,cn=config

# record 4
dn: cn=sudo,cn=config
cn: sudo
distinguishedName: cn=sudo,cn=config

# record 5
dn: cn=ssh,cn=config
cn: ssh
distinguishedName: cn=ssh,cn=config

# record 6
dn: cn=autofs,cn=config
cn: autofs
distinguishedName: cn=autofs,cn=config

# record 7
dn: cn=ifp,cn=config
cn: ifp
distinguishedName: cn=ifp,cn=config

# record 8
dn: cn=secrets,cn=config
cn: secrets
distinguishedName: cn=secrets,cn=config

# record 9
dn: cn=pac,cn=config
cn: pac
distinguishedName: cn=pac,cn=config

# record 10
dn: cn=pam,cn=config
cn: pam
distinguishedName: cn=pam,cn=config

# record 11
dn: cn=session_recording,cn=config
cn: session_recording
distinguishedName: cn=session_recording,cn=config

# record 12
dn: cn=linktera.lan,cn=domain,cn=config
access_provider: ipa
auth_provider: ipa
cache_credentials: True
chpass_provider: ipa
cn: linktera.lan
enumerate: true
id_provider: ipa
ipa_domain: linktera.lan
ipa_hostname: slreport.linktera.lan
ipa_server: _srv_, ipa.linktera.lan
krb5_store_password_if_offline: True
ldap_tls_cacert: /etc/ipa/ca.crt
distinguishedName: cn=linktera.lan,cn=domain,cn=config

# record 13
dn: cn=implicit_files,cn=domain,cn=config
cn: implicit_files
id_provider: files
distinguishedName: cn=implicit_files,cn=domain,cn=config

# returned 13 records
# 13 entries
# 0 referrals

thank you for your quick reply
Comment 6 Selman Keskin 2019-08-20 10:41:22 UTC 
there is a bug i think
Comment 7 Sumit Bose 2019-08-20 10:59:31 UTC 
Hi,

which RHEL version are you using and package versions? Can you send the output of:

    rpm -qa sssd
    rpm -qa libtalloc
    rpm -qa libtdb
    rpm -qa libldb
    rpm -qa libtevent

bye,
Sumit
Comment 8 Selman Keskin 2019-08-20 11:05:33 UTC 
I solved,

i changed system config language Turkish to English,
problem suddenly disappeared.

now sssd is working.

i thing there is a bug about turkih language packages
Comment 9 Selman Keskin 2019-08-20 11:06:29 UTC 
Thank you so much!
Comment 10 Sumit Bose 2019-08-20 11:14:40 UTC 
Hi,

glad to hear it is working for you now. Can you tell me what was the content of /etc/locale.conf before the change so that I can try to reproduce the issue with your original settings?

bye,
Sumit
Comment 11 Selman Keskin 2019-08-20 11:47:52 UTC 
# cat /etc/locale.conf
LANG="tr_TR.UTF-8"
Comment 12 Lukas Slebodnik 2019-08-20 18:12:13 UTC 
(In reply to Selman Keskin from comment #11)
> # cat /etc/locale.conf
> LANG="tr_TR.UTF-8"

(In reply to Sumit Bose from comment #10)
> Hi,
> 
> glad to hear it is working for you now. Can you tell me what was the content
> of /etc/locale.conf before the change so that I can try to reproduce the
> issue with your original settings?
> 


Sumit, that's bug in libldb
make check in libldb pass with de_DE.UTF-8 but fails with tr_TR.UTF-8
Comment 13 Sumit Bose 2019-08-21 06:23:41 UTC 
(In reply to Lukas Slebodnik from comment #12)
> (In reply to Selman Keskin from comment #11)
> > # cat /etc/locale.conf
> > LANG="tr_TR.UTF-8"
> 
> (In reply to Sumit Bose from comment #10)
> > Hi,
> > 
> > glad to hear it is working for you now. Can you tell me what was the content
> > of /etc/locale.conf before the change so that I can try to reproduce the
> > issue with your original settings?
> > 
> 
> 
> Sumit, that's bug in libldb
> make check in libldb pass with de_DE.UTF-8 but fails with tr_TR.UTF-8

Hi Lukas,

thanks for the info, do you know if this is already tracked somewhere or shall we move this ticket to the libldb component?

bye,
Sumit
Comment 14 Lukas Slebodnik 2019-08-21 17:14:52 UTC 
(In reply to Sumit Bose from comment #13)
> (In reply to Lukas Slebodnik from comment #12)
> > (In reply to Selman Keskin from comment #11)
> > > # cat /etc/locale.conf
> > > LANG="tr_TR.UTF-8"
> > 
> > (In reply to Sumit Bose from comment #10)
> > > Hi,
> > > 
> > > glad to hear it is working for you now. Can you tell me what was the content
> > > of /etc/locale.conf before the change so that I can try to reproduce the
> > > issue with your original settings?
> > > 
> > 
> > 
> > Sumit, that's bug in libldb
> > make check in libldb pass with de_DE.UTF-8 but fails with tr_TR.UTF-8
> 
> Hi Lukas,
> 
> thanks for the info, do you know if this is already tracked somewhere or
> shall we move this ticket to the libldb component?
> 
> bye,
> Sumit

I have no idea.
BTW I was testing with ldb-2.0.5 but I assume it is the same issue with older version.
Please double check on el7
Comment 15 Tomas Halman 2019-09-06 13:40:36 UTC 
I did some investigation and realy looks like ldb or lmdb bug.

SSSD log shows processing of /etc/sssd/sssd.conf and the content is written into /var/lib/sss/db/config.ldb. Then SSSD fails to read items back from ldb file.

When running `LANG=tr_TR.UTF-8 make check` in ldb source directory we can see several errors like this 

Running Python test with /usr/bin/python3: tests/python/index.py
...F...FF...F......F...FF...F....
======================================================================
FAIL: test_delete_index_multi_valued_truncated_keys (__main__.MaxIndexKeyLengthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/python/index.py", line 999, in test_delete_index_multi_valued_truncated_keys
    b"0123456789abcde1" + b"0123456789abcde1")
  File "tests/python/index.py", line 98, in checkGuids
    self.assertEqual(len(res), 1)
AssertionError: 0 != 1

The actual test writes into database and then it tries to read it but 0 items are returned back (AssertionError: 0 != 1 => 0 items returned, 1 expected)

I tested with 1.5.5
Comment 16 Guenther Deschner 2019-09-11 10:16:54 UTC 
Re-assigning to libldb for further inspection.
Comment 20 RHEL Program Management 2021-03-15 07:38:35 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.