Fwd: Re: [SSSD-users] ldap config
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forwarding back to the sssd-users list, because it contains useful
information that other developers might need to see. Please make sure
to keep this list in all replies.
So this confirms my hypothesis. Something is happening during the
RootDSE lookup that is causing the SSSD to freeze forever here. The
monitor notices this after 30s and sends a SIGTERM, which is never
handled. After another 30s, it sends a SIGKILL which forcibly restarts it.
Brandon, can you tell us the exact version of SSSD you are using? You
can get this by running 'rpm -q sssd'. Please report the entire string
it gives back.
- -------- Original Message --------
Subject: Re: [SSSD-users] ldap config
Date: Fri, 26 Apr 2013 09:13:13 -0700
From: Brandon Foster <brandon.foster(a)liferay.com>
To: Stephen Gallagher <sgallagh(a)redhat.com>
On Fri, Apr 26, 2013 at 4:28 AM, Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
> On 04/25/2013 05:49 PM, Brandon Foster wrote:
>> No, i never tried to log in during that time, and I did not shut
>> it down manually, it must have crashed.
>
>> So adding in that time out line seems to have done something.
>> Now with the timeout line it wont even search ldap for my user.
>> the search does not show up in sssd_default.log, and it still
>> returns no such user.
>
>> here is my sssd.conf with the timeout line:
>
>> ------------------------- [sssd] config_file_version = 2 services
>> = nss, pam domains = default
>
>> [nss] filter_users =
>> root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
>
>> [pam]
>
>> [domain/default] timeout = 5400 auth_provider = ldap debug_level
>> = 9 enumerate = True cache_credentials = True chpass_provider =
>> ldap entry_cache_timeout = 600 ldap_chpass_uri =
>> ldaps://66.117.7.48:11389/ id_provider = ldap ldap_group_member
>> = uniquemember ldap_group_object_class = group
>> ldap_id_use_start_tls = False ldap_pwd_policy = none
>> ldap_search_base = ou=Liferay\,
>> Inc.,ou=Organizations,ou=liferay.com,o=Liferay ldap_tls_cacertdir
>> = /etc/openldap/cacerts ldap_tls_reqcert = never ldap_uri =
>> ldaps://66.117.7.48:11389/ ldap_user_gecos = displayName
>> ldap_user_home_directory = unixHomeDirectory ldap_user_name = cn
>> ldap_user_object_class = user -----------------------
>
>> good news is it isnt crashing anymore. but still not working
>
>
> Ok, so what that suggests to me is that the problem was never
> *actually* a crash, but instead may have been a tight loop
> problem. The sssd_be may have gotten into an infinite loop, which
> prevents it from replying to the ping from the service monitor,
> which eventually kills it forcibly.
>
> Let's try to verify this hypothesis. Please add 'debug_level = 9'
> to your [sssd] section, remove the 'timeout = 5400' from the
> [domain/default] section, truncate or delete the logs in
> /var/log/sssd and restart sssd.
>
> Then *run the user login* and send us /var/log/sssd/sssd.log and
> /var/log/sssd/sssd_default.log
>
> This should hopefully give us enough to go on. Sorry for the
> repeated back-and-forth, but debugging without being able to
> reproduce the problem locally is tricky.
>
>
> Side-note: I notice you are using "uniquemember" for the member
> attribute, but you're not setting ldap_schema = rfc2307bis. If I
> remember correctly 'uniquemember' (like 'member') stores the
> user/group DN, not the username. If that's correct, you really need
> to set 'ldap_schema = rfc2307bis' or you won't see group
> memberships correctly.
thanks again for your help.
as far as the uniquemember, what should this be to be the username?
Also i dont know which schema my ldap is but i've tried both and
neither has worked with the current set up.
just as an example i have a user who's dn is:
cn=testuser,ou=organizationunit3,ou=organizationunit2,ou=organizationunit1,o=domain
and i want him to log in as testuser. would I then set ldap_group_member
to cn?
i've attached the complete sssd.log and sssd_default.log
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlF6qPcACgkQeiVVYja6o6OvvgCfShTffrzINj64pTg/sWgqQiDn
GdwAn1qLAuMkzG9yzxoJaBxz3DnANHH5
=fwPX
-----END PGP SIGNATURE-----
10 years, 7 months
build fails to run on Ubuntu 13.04
by steve
Hi everyone
After a successful build and install sssd fails with:
sudo sssd
ldb: unable to dlopen
/usr/lib/i386-linux-gnu/ldb/modules/ldb/samba/ildap.so : libdbwrap.so:
cannot open shared object file: No such file or directory
ldb: unable to dlopen
/usr/lib/i386-linux-gnu/ldb/modules/ldb/samba/ldbsamba_extensions.so :
libdbwrap.so: cannot open shared object file: No such file or directory
ldb: unable to dlopen
/usr/lib/i386-linux-gnu/ldb/modules/ldb/samba/secrets_tdb_sync.so :
libdbwrap.so: cannot open shared object file: No such file or directory
ldb: unable to dlopen
/usr/lib/i386-linux-gnu/ldb/modules/ldb/samba/update_keytab.so :
libdbwrap.so: cannot open shared object file: No such file or directory
I used the same list of dependencies as on Ubuntu 12.10. I tried to find
the missing files under /usr/local, but nada. Is these something I'm
missing?
Cheers, Steve
10 years, 7 months
[PATCH] Two man page patches
by Jakub Hrozek
I had a couple of minutes before a meeting starts, so I squashed away
these two man page tickets.
10 years, 7 months
[PATCH] DB: Switch to new libini_config API
by Ondrej Kos
Hi,
Attached is patch for https://fedorahosted.org/sssd/ticket/1786
Patch extends sssd code so it's capable to build with current version of
libini_config (0.7 at the time, supported versions up from 0.6.1) and
with version 1.0.0, which will be released soon.
Ondra
--
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech
phone: +420-532-294-558
cell: +420-736-417-909
ext: 82-62558
loc: 1013 Brno 1 office
irc: okos @ #sssd #brno
10 years, 7 months
Build error on Ubuntu 12.10
by linux
Hi,
I'm trying to build sssd 1.9.5 on Ubuntu 12.10 and I got the following
error:
Running suite(s): sysdb
99%: Checks: 800, Failures: 1, Errors: 1
../src/tests/sysdb-tests.c:701:E:SYSDB Tests:test_sysdb_add_user:27000:
(after this point) Test timeout expired
../src/tests/sysdb-tests.c:854:F:SYSDB Tests:test_sysdb_getpwnam:27000:
Invalid number of replies. Expected 1, got 0
FAIL: sysdb-tests
==================================================
1 of 23 tests failed
Please report to sssd-devel(a)lists.fedorahosted.org
==================================================
Do you need more information?
Regards,
Tobias
10 years, 7 months
Design Discussion: Periodical refresh of expired entries
by Pavel Březina
Here is design document for #1713.
https://fedorahosted.org/sssd/wiki/DesignDocs/PeriodicalRefreshOfExpiredE...
It is not yet fully complete because I believe is miss one thing. The
whole point of this ticket to to reduce latency when refreshing a large
amount of entries. So we create a periodic task that will refresh the
entries out of bound instead of doing it during login time.
But I'm not sure if this is enough, because the amount of entries may be
to large to refresh all of them in reasonable time. It may also block
the back end for a while. I think we should do this in some sort o batch.
Jakub suggested that we will adapt to the current network status. For
example:
1. try to update 200 entries
2. if the update finishes in less than 5 seconds, increase the batch
3. if it finishes in more than 5 seconds, decrease the batch
4. next batch will be filed in the next period
Another approach may be to make the batch fixed size configurable in
sssd.conf.
Suggestions are welcome.
10 years, 7 months