[PATCH] Improve logging of pam_sss
by Sumit Bose
Hi,
this patch makes the logging of pam_sss a bit clearer and less verbose.
This should fix bz556534.
This patch might affect testing, because some log messages are changed.
bye,
Sumit
14 years, 2 months
Announcing SSSD 1.0.4 bugfix release
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right on the heels of SSSD 1.0.3, we release SSSD 1.0.4.
We discovered a bug in the 32-bit alignment fix in 1.0.3 that caused a
regression of behavior on 64-bit platforms. SSSD 1.0.4 is being released
immediately to correct this.
As always, SSSD 1.0.4 can be downloaded at https://fedorahosted.org/sssd/
=== Detailed Changelog ===
Stephen Gallagher (3):
* Fix release script to use version.m4
* Fix size error on 64-bit systems
* Release version 1.0.4
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAktd5xoACgkQeiVVYja6o6MyGgCfSPgipG7O+FEITrvviHKMjpzR
LQIAoKRYXiNKnVvO2U++9f07BtD9MRWN
=9jsW
-----END PGP SIGNATURE-----
14 years, 2 months
[PATCH] Fix size error on 64-bit systems
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The patch for supporting integer alignment had a bug where we were
memcpy()ing a 32-bit value onto a 64-bit size_t. This meant that it was
overwriting the high-order bits, resulting in a much larger value than
it should have had. This patch forces that variable to be 32-bit.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAktdozsACgkQeiVVYja6o6NL3gCfY/OhZU71e+hJQ5LJyaRrqS8B
giIAn3ZTiN/o1kk11RzgKc08VRvFYDBp
=gRAb
-----END PGP SIGNATURE-----
14 years, 2 months
About caching of users and group information.
by Simo Sorce
While dealing with other related issue, today I was thinking about our
caching strategy on the clients.
We have 2 options in sssd today:
- we can fully enumerate regularly using an enumeration task
- we update the information at log-in time.
the first option may be very expensive in big domains, but in the
second case we have some problems in deciding how to deal with
refreshing and more importantly deleting stale data.
One option we put on the table is to always delete data when it
"expires" (and we are still online) and let the client application
trigger a refresh only if they need data.
This seems a good solution under most points of view as it will
guarantee we keep around data that is used and introduces only a small
latency and only when necessary if we need to refresh data that is
explicitly requested.
It leaves out 2 cases though:
- application performs a generic enumeration and does not request
explicitly for a user or a group.
- data expires and is removed while online, then clients goes offline
and needs the data.
The second scenario is what convinced me we cannot just delete expired
data. So how do we know what data to delete and what to keep ?
Well we have one more piece of data that we can use to decide when to
throw away data and when not.
Each user have 2 important bits of information we can use:
Last login date and the memberof attribute
The Last login date can be used to decide when to delete a user account
from the cache. This is not the same as the expiration date, the
expiration date is used to decide when it is time to refresh the data
even if we have it. So if the user data is expired, and the last login
date is X days in the past, we can decide to remove the user from the
cache without having to check the central authority (the LDAP server).
The memberof attribute instead is fundamental to do the same operation
for groups. Any group that is referenced by a user entry cannot be
deleted or it would be missing is a cached login is performed while
offline. But if a group is expired and it is not referenced by any user
then it can be deleted. The memberof attribute for users is
recalculated at each online login so that will assure that the groups
that falls off of it are really not intersting anymore the client
system.
Please think about this and let me know if you see any problem with
this proposal. Also please let me know if someone feels like
volunteering for implementing it. It should be fairly simple to
implement this logic and should completely replace the current cleanup
task logic.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
14 years, 2 months
[PATCH] Handle IPv6 addresses with the async resolver
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If a DNS lookup fails to return an IPv4 address for a hostname, we
will attempt to look up an IPv6 address before returning a failure.
Note: this only ensures that the async resolver identifies the correct
address. Currently, there is still a bug in the LDAP code somewhere
that prevents our connecting to an LDAP server over IPv6. I am looking
into this separately.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAktOAbUACgkQeiVVYja6o6NV4gCbB0gBEj3aKxFe30Afsg2HNE/2
xcAAoI4VCnYGxrYV2W9q3Z9UwkPZy/6o
=O8Zz
-----END PGP SIGNATURE-----
14 years, 3 months
[PATCH] INI allow string list to have empty values
by Dmitri Pal
Hello,
This patch allows proper parsing of values like this:
fruit=apple,,orange
The added function would return the list of three items:
apple
<empty>
orange
Previously existing parsing functions in this case could only return
apple
orange
This is used in the ELAPI configuration to provide alternative names for
the column headers.
This is the last of the non ELAPI patche that I have in my repo.
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
14 years, 3 months
Announcing SSSD 1.0.3 bugfix release
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The SSSD team is proud to announce the release of version 1.0.2 of the
System Security Services Daemon. This is the third maintenance release
for the stable 1.0.x branch of the SSSD. This release is intended to
address several serious bugs and segmentation faults, and is a highly
recommended upgrade for anyone using an earlier version.
== Highlights ==
* Fixes link error on platforms that do not do implicit linking
* Fixes double-free segfault in PAM
* Fixes double-free error in async resolver
* Fixes support for TCP-based DNS lookups in async resolver
* Manpage fixes
== Detailed Changelog ==
George !McCollister (1):
* Pointers to non 32 bit aligned data were being cast to uint32_t *
Jakub Hrozek (2):
* document debug_timestamps
* Deleting nonexistent users or groups is not a noop
Stephen Gallagher (7):
* Fix timeout memory heirarchy
* Use version.m4 for setting the SSSD version
* Add 'prerelease-srpms' target to Makefile
* Add 'prerelease-rpms' target to Makefile
* Add missing link for Kerberos
* Fix async resolver integration with tevent
* Update version to 1.0.3
Sumit Bose (1):
* Fix a double free bug
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAktZvlwACgkQeiVVYja6o6PCHQCfUWckvqoE8v+Rc2+KOE0e2SFx
UiQAoIy734Sp/d8Y6+72P76sErcoEm3+
=tOXt
-----END PGP SIGNATURE-----
14 years, 3 months
Re: [SSSD] AD interoperability
by Timo Aaltonen
On Fri, 22 Jan 2010, Simo Sorce wrote:
> On Fri, 22 Jan 2010 13:49:54 +0200 (EET)
> Timo Aaltonen <tjaalton(a)cc.hut.fi> wrote:
>
>>
>> Hi
>>
>> I've understood that sssd still isn't fully tested against an
>> Active Directory? We've got one and I'm trying to make an Ubuntu
>> linux client to work with it by using samba, MIT krb5 libs and sssd.
>> Things aren't going too strong though. AD seems to support only HOST$
>> -style principals and not SPN's, but even if I specify
>> ldap_sasl_authid to that I only get an "Invalid credentials" when the
>> daemon is trying to bind
>>
>> [sssd[be[AALTO]]] [sasl_bind_send] (4): Executing sasl bind mech:
>> GSSAPI, user: NEXUS6$ [sssd[be[AALTO]]] [sasl_bind_send] (1):
>> ldap_sasl_bind failed (49)[Invalid credentials]
>>
>> So, am I missing something or is there something to be fixed :)
>
> We have only experimental support to use AD as an LDAP server.
> But I don't think we ever tested using the host keytab and kerberos to
> authenticate system ldap connections agains it.
>
> I think you should use winbind for now agtainst AD.
Winbind doesn't work properly, it fails to map uidNumber while gidNumber
etc is mapped.. I was hoping for sssd to work better, but guess I just
have to file a bug against samba.
--
Timo Aaltonen
Systems Specialist
IT Services, Aalto University School of Science and Technology
14 years, 3 months
[PATCH] Support TCP-based DNS requests in the async resolver
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We weren't properly setting the flags on the tevent fd object in order
to support the necessary bidirectional communication for TCP-based DNS
requests.
c-ares switches to TCP-based DNS lookups when the reply from the
UDP-based lookup reports TRUNCATED (as when there are too many possible
responses).
This is the real fix to https://fedorahosted.org/sssd/ticket/388
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEUEARECAAYFAktYmH8ACgkQeiVVYja6o6P2YACeMm4J+rdz6/CmmiT6hk5XjD5G
nzMAmPZ3W9405gpAyNU9WjanVDI3Toc=
=1Giw
-----END PGP SIGNATURE-----
14 years, 3 months
