[PATCH] fix ipa provider (already pushed)
by Simo Sorce
After recent changes the ipa provider was broken.
The problem is in the code the looks at the rootdse, it assumed the
sudorule_map to be always available and unconditionally referenced that.
That map is configured only if sudo_provider = ldap is configure in the
ldap case, however it is never configured in the ipa case as a
sudo_provider = ipa has not been made available.
This may not be the ultimate way to fix the issue however because there
is no sudo provider for ipa there is no other workaround to avoid
sssd_be crashing so I pushed this patch under the onliner and unbreak
the ipa provider rule (yes I made that last one up :-D but I use it
daily so it is important to never completely break it for me).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11 years, 9 months
[PATCH] KRB5: Initialize the credential cache type properly
by Stephen Gallagher
We weren't guaranteeing that the cctype-specific callbacks were
initialized before using them.
This bug only presented itself for users who were logging in
without a ccacheFile attribute in the LDB (for example, first-time
logins).
I missed this in review because I was testing with users that were
already in the cache.
11 years, 10 months
[PATCHES][PRELIMINARY] sudo - new design
by Pavel Březina
Hello everybody,
here is the first set of patches for the new sudo clothes. [1]
As it does not touch the responder, I believe it does not require the
patches from the other preliminary sudo thread (already acked). However
it was written atop them.
[2/10]
This is the main change for the async processing of the sudo rules. It
make sdap_sudo_refresh_send() more generic by adding there two filters:
ldap_filter - used for search in the LDAP
sysdb_filter - used for a deletion of the rules from sysdb
This way we can have many different refresh styles without touching
this fundamental function.
From this patch further the provider will return an error to the
responder making it unusable.
[...]
The rest of the patches has a self-describing subject. Don't be afraid
of the count, these patches are very small :-)
The next set of patches is where the fun begin, so be patient :-)
[1] https://fedorahosted.org/sssd/wiki/DesignDocs/SUDOCachingRules
11 years, 10 months
Re: [SSSD] Very slow listing of files owned by many different, users. Any solution?
by Mark London
sgallagh(a)redhat.com wrote:
> On Wed, 2012-06-27 at 13:18 -0400, Mark London wrote:
>> Hi - We are running SSSD with LDAP at our site, where we have several
>> hundred users. LDAP is being served by our Windows domain server.
>>
>> With entry_cache_timeout set to a short value, when someone does an
>> operation that requires information for multiple users, i.e. listing the
>> owners of all of the user's home directories via the command "ls -l
>> /home", this will take many many minutes to complete. Of course, this
>> happens, because an LDAP request has to be issued for each user, and
>> then stored in the database. Further similar operations will complete
>> quickly, during the entry_cache_timeout period. But such operations do
>> not occur that frequent enough for the data to be kept in the cache.
>>
>> The only solution seems to be sto imply increase entry_cache_timeout to
>> a very large value. Of course, this is not ideal, because changes to
>> the ldap entries will not be seen for a long time. A kludge workaround,
>> would be to keep a low timeout, and have a cron job that runs the
>> command "ls -l /home" every 5 minutes, on each workstation.
>>
>> Is there a more elegant way to solve this problem? Thanks. - Mark
>
> If this action is a very common one (listing all of /home), then in your
> particular environment you will probably want to set 'enumerate = True'
> in the [domain/DOMAINNAME] section of sssd.conf.
>
> What this does is instruct SSSD to poll for cache updates on a regular
> basis and store cached information about all users and groups at alltimes.
Hi - We have enumerate turned on and it works great when SSSD is
started, as "ls -l /home" returns immediately. However, that's not the
case, no matter what I set ldap_enumeration_refresh_timeout. I.e. After
I received your email, I thought maybe that the enumeration data was
being cleared out of the cache somehow. So I tried setting the
ldap_enumeration_refresh_timeout to much less than entry_cache_timeout.
Should that prevent the cached entries from ever timing out? In any
event, it doesn't appear to work. "ls - /home" still takes a long time
and triggers requests.
(Thu Jun 28 08:04:06 2012) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'hereiam' matched without domain, user is hereiam
(Thu Jun 28 08:04:06 2012) [sssd[nss]] [nss_cmd_getpwnam_cb] (0x0400):
Requesting info for [hereiam] from [<ALL>]
(Thu Jun 28 08:04:06 2012) [sssd[nss]] [sss_ncache_check_str] (0x2000):
Checking negative cache for [NCE/USER/PSFC/hereiam]
(Thu Jun 28 08:04:06 2012) [sssd[nss]] [nss_cmd_getpwnam_search]
(0x0100): Requesting info for [hereiam@PSFC]
Here's our sssd.conf. Thanks for any help. - Mark
[sssd]
config_file_version = 2
# Number of times services should attempt to reconnect in the
# event of a crash or restart before they give up
reconnection_retries = 3
# If a back end is particularly slow you can raise this timeout here
sbus_timeout = 30
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
; domains = LOCAL,LDAP
domains = PSFC
[nss]
# The following prevents SSSD from searching for the root user/group in
# all domains (you can add here a comma-separated list of system
accounts that
# are always going to be /etc/passwd users, or that you want to filter out).
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 0
# The entry_cache_timeout indicates the number of seconds to retain an
# entry in cache before it is considered stale and must block to refresh.
# The entry_cache_nowait_timeout indicates the number of seconds to
# wait before updating the cache out-of-band. (NSS requests will still
# be returned from cache until the full entry_cache_timeout). Setting this
# value to 0 turns this feature off (default).
; entry_cache_timeout = 600
; entry_cache_nowait_timeout = 300
[pam]
reconnection_retries = 3
debug_level = 0
[domain/PSFC]
description = LDAP domain with AD server
enumerate = true
min_id = 501
cache_credentials = true
entry_cache_timeout = 600
debug_level = 0
ldap_enumeration_refresh_timeout = 120
id_provider = ldap
chpass_provider = none
auth_provider = ldap
ldap_uri = _srv_,ldaps://198.125.180.133
ldap_tls_cacertdir = /etc/openldap/cacerts
#ldap_tls_cacert = /etc/openldap/cacerts/test.cer
ldap_schema = rfc2307bis
ldap_search_base = dc=psfc,dc=mit,dc=edu
ldap_user_search_base = dc=psfc,dc=mit,dc=edu
ldap_group_search_base = dc=psfc,dc=mit,dc=edu
ldap_default_bind_dn = CN=ADldapreadonly,OU=Computer Group,OU=PSFC
Users,DC=psfc,DC=mit,DC=edu
ldap_default_authtok_type = password
ldap_default_authtok = ldapread
#ldap_pwd_policy = none
ldap_user_object_class = person
ldap_user_name = sAMAccountName
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_member = msSFU30PosixMember
ldap_user_member_of = msSFU30PosixMemberOf
ldap_group_name = name
ldap_group_gid_number = msSFU30GidNumber
ldap_force_upper_case_realm = True
11 years, 10 months
Unspecified error loading config db
by Jan Engelhardt
Installed sssd-1.8.3 on a fresh openSUSE_Factory, where it happens to
not work. Unfortunately, I just can't make anything out from these error
message. What's "unavailable" supposed to mean?
v-sfac:/var/log # sssd -d 99 -i
ldb: module version mismatch in src/ldb_modules/memberof.c :
ldb_version=1.1.6 module_version=1.0.2
ldb: failed to initialise module /usr/lib64/ldb/memberof.so :
Unavailable
(Wed Jun 27 17:50:01:328016 2012) [sssd] [load_configuration] (0x0010):
The confdb initialization failed
(Wed Jun 27 17:50:01:328127 2012) [sssd] [main] (0x0020): Error loading
configuration database: [5]: Input/output error
v-sfac:/var/lib/sss # ls -l /usr/lib64/ldb/memberof.so
-rwxr-xr-x 1 root root 52328 May 14 11:39 /usr/lib64/ldb/memberof.so
libldb-1.1.6 is installed. Wrong kind of version?
11 years, 10 months
Online detection issues going forward
by Stephen Gallagher
Right now, SSSD has two mechanisms for detecting a shift in network
state in order to determine if it should attempt to go online
immediately. This is done to ensure that cached entries get updated as
quickly as possible and so that if the provider offers online callbacks
(such as the deferred kinit feature of the krb5 provider) they will fire
immediately.
1) We register with libnl (a library providing access to kernel netlink
APIs) to be notified whenever a network interface comes up or goes down
on the system.
2) We set an inotify watch on /etc/resolv.conf to be notified if the DNS
information changes.
In the current default configuration of Fedora, we actually end up
relying more often on 2) than 1) in the case of VPNs. The reason for
this is that when we join a VPN, we are notified that the network has
changed, but in many cases we still cannot connect to the servers until
NetworkManager has also updated /etc/resolv.conf. This is because in the
common VPN case, the DNS entry for the identity and authentication
servers are also located inside the VPN.
So in this situation, our current behavior is to actually try twice to
connect to the servers; the first time when we notice the network change
and the second for when resolv.conf is modified. In situations where DNS
for the identity and auth servers are inside the VPN, it's always this
second attempt that succeeds.
However, this behavior makes one very basic assumption: When a VPN or
other connection is established to a new network, /etc/resolv.conf will
be updated with new data. This is the current default for NetworkManager
on Fedora and RHEL systems, but this will not be the case soon.
Currently, it is possible to set up NetworkManager to use dnsmasq for
DNS caching by adding dns=dnsmasq to NetworkManager.conf. The effect of
this is that NetworkManager will update dnsmasq configuration instead
of /etc/resolv.conf. /etc/resolv.conf will then remain static and always
pointed at 127.0.0.1. This means that our inotify backup above becomes
useless.
This becomes more urgent because a similar approach is currently planned
to become the default in Fedora 18. This approach will use 'unbound'
instead of 'dnsmasq' in order to facilitate the use of DNSSEC on all
Fedora clients, but the effect will be the same. /etc/resolv.conf will
remain static and configuration changes will occur in 'unbound' instead.
So we need to come up with a new way to deal with the "DNS servers
behind a VPN" use-case that will play nicer with these two solutions (or
better still, work generically).
As a final note, we are not *completely* broken in these situations. We
will still eventually go on once a full minute has passed *and* a
request that cannot be answered by the cache occurs. But for those users
relying on the deferred kinit feature as part of their workflow will see
a definite regression in behavior under this scenario.
11 years, 10 months
Very slow listing of files owned by many different users. Any solution?
by Mark London
Hi - We are running SSSD with LDAP at our site, where we have several
hundred users. LDAP is being served by our Windows domain server.
With entry_cache_timeout set to a short value, when someone does an
operation that requires information for multiple users, i.e. listing the
owners of all of the user's home directories via the command "ls -l
/home", this will take many many minutes to complete. Of course, this
happens, because an LDAP request has to be issued for each user, and
then stored in the database. Further similar operations will complete
quickly, during the entry_cache_timeout period. But such operations do
not occur that frequent enough for the data to be kept in the cache.
The only solution seems to be sto imply increase entry_cache_timeout to
a very large value. Of course, this is not ideal, because changes to
the ldap entries will not be seen for a long time. A kludge workaround,
would be to keep a low timeout, and have a cron job that runs the
command "ls -l /home" every 5 minutes, on each workstation.
Is there a more elegant way to solve this problem? Thanks. - Mark
11 years, 10 months
