Announcing the System Security Services (SSSD) 1.1.91 Release
by Stephen Gallagher
The System Security Services Daemon team is proud to announce the 1.1.91
release. This is our release candidate for the 1.2.0 release. As of this
time, we are feature-complete and in string freeze.
== Highlights ==
* Better support for FreeIPA v2
* Allow use of DNS SRV records for failover
* Support dynamic DNS updates with FreeIPA v2
* Add deferred kinit feature for offline users
* When {{{krb5_store_password_if_offline}}} is set to true, the user
will automatically kinit when the SSSD comes online (e.g. connecting to VPN)
* Add retries option to pam_sss.so
* Better warnings for nearly-expired passwords
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
13 years, 11 months
How well do sssd scale?
by Petter Reinholdtsen
I am testing sssd and the pam and nss package on Ubuntu here at the
university, and ran into unexpected behaviour. sssd_be uses 100% CPU
most of the time, and top report that its virtual size is 244 MB and
its resident size is 152 MB. I've configured sssd to use LDAP as a
directory and as the authentication method.
The university have a lot of users and groups, and I wonder if this is
why the process is so big and use so much CPU. How well do sssd
scale? Can it handle a directory with 100 000 users and 10 000
groups?
Happy hacking,
--
Petter Reinholdtsen
13 years, 11 months
automounter support?
by Ondrej Valousek
Hi List,
Quick question: Is sssd functionality restricted only to /passwd/group/
maps or can it handle other maps like /services/automount/?
And if not, is such a support planned for the future?
Thanks,
Ondrej
13 years, 11 months
SSSD and community development
by Eugene Indenbom
Dear SSSD developers,
I am writing this e-mail to express my utter disappointment and
disillusionment with bazaar or community development at least as it
applies to SSSD.
I started a new project in the middle of February and have chosen IPA
and SSSD as SW platform for projects LDAP/Kerberos domain. I am working
with (and programming for) Linux since 1995 and starting from year 2000
I was looking for a decent solution for Linux domain. It was very
obvious from the very beginning that dedicated system security
daemon/service is required for domain to function properly and reliably.
So I jumped at SSSD and IPA as they were my dreams and years-old desire
coming to reality.
To my bitter disappointment nothing has functioned properly or even
functioned at all. You can dig into Red Hat's bugzilla for the bugs I
have filed. They would illustrate a number of problems I had to solve
prior my domain was usable at all.
And the biggest headache was SSSD. It crashed, it failed to restart
after an update, it returned system errors during authorization leaving
me no choice other than to use fall-back local file authentication.
Well I have decided: this is community work on the bleeding edge of
Linux and Open Source development and I can help not only my project,
but the community to deliver a robust Linux domain. So I invested
substantial amount of my personal time in fixing the problems in SSSD
and submitted the results to the SSSD development list.
What response have I got?
On 04/13/2010 06:44 PM, Simo Sorce wrote:
> On the 4th I'll try to do a bit more analysis later, but it looks a bit
> too complicated and out of style. In particular I don't like much the
> sdap_id_op idea and the associated _create() function. I will try to
> give some more constructive feedback on it later.
>
>
Nobody has ever considered my work for possible inclusion into upstream.
The only thing that disturbs Simo is how to find a good reason not to
include and to ditch my work.
It has taken me more than a month to convince Simo and others that
problems I have stated are valid, require attention and must be fixed.
You can dig into e-mail exchange and find out that all the objectives of
my patch are acknowledged, but the solution is not.
On 04/30/2010 06:53 PM, Simo Sorce wrote:
> On Fri, 30 Apr 2010 11:49:57 +0400
> Eugene Indenbom<eindenbom(a)gmail.com> wrote:
>
>
>> PS I still do not understand what is wrong with my patches. Why is it
>> not possible just to use them and not to redo the job?
>>
> To be honest, I think it is too complex.
>
> Simo.
>
>
And now the final blow comes. Simo's patch has comparable level of
complexity and Simo has admitted that:
On 04/16/2010 10:22 PM, Simo Sorce wrote:
> Note that the patch still includes my old changes to avoid freeing
> ctx->gsh, they are *not* necessary, but I think they are good hygiene
> anyway so I left them in.
>
>
So this patch is only "good hygiene", it provides no functionality, it
solves no problem, but it breaks all my efforts. And it is accepted and
included into master.
On 05/03/2010 01:21 PM, Sumit Bose wrote:
> ACK to both.
>
> I have seen Eugene comments on the patches and do not want to argure
> that these patches make the code only cleaner and more robust. But I
> think these improvements are still worth to be added to the current code
> base and some of them might get lost if we postponed them to a later
> patch.
>
And how about my work, will it be lost? After Simo's patch I have to
rewrite my solution as it conflicts with Simo's changes and I have to
retest them. What for? It will never be accepted.
The whole situation is a canonic illustration for NOT INVENTED HERE
syndrome.
Talking about code quality and testing of the LDAP provider, I was
devastated by the very poor code quality. There are other parts of SSSD
code that are good written and well commented. But not LDAP provider.
Hundreds of lines of duplicated code, copy and paste work making every
bug to replicate itself up to 7 times. I am not joking: one piece of
faulty code that caused the problems is duplicated 7 times. There is
code duplicated in the same file for no reason. Is it really hard to
make a function doing common job?
And testing. It looks like that nobody ever tests changes to LDAP
provider. In released SSSD 1.1 IPA provider simply aborted SSSD daemon
(see bug https://bugzilla.redhat.com/show_bug.cgi?id=576856). The same
story with patches submitted for review. For example, no testing has
been done on patch submitted on April 13.
And again my work is not good enough although it has been tested in the
__only__ IPA/SSSD domain.
So I would like to ask Stephen Gallagher to modify Wiki Contributions
Page according to the actual status:
No help is needed and no contribution will be accepted.
Eugene Indenbom
PS This is my last e-mail to SSSD Development mailing list. I
unsubscribe from it now as the whole business is obviously fruitless.
13 years, 11 months
[PATCH] Make ldap simple bind asynchronous
by Martin Nagy
Hi,
here it is. I included some description in the commit log, it is
necessary to read it in order to understand why I did some things this
way. Any suggestions to make the patch better are most welcome.
Martin
13 years, 12 months
[PATCH] Try all servers during Kerberos auth (sssd 1.2)
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Kerberos backend would previously try only the first server and if
it was unreachable, it immediatelly went offline.
This patch was rebased on top of Sumit's tevent_req rewrite of
krb_auth.c on the sssd-1-2 branch.
It also handles the case where the child times out and removes the
special-casing of SSS_PAM_CHAUTHTOK in krb5_resolve_kdc_done(). The
special casing didn't in fact have any effect as when using KDC for
password changes we don't distinguish between the kdc and kpasswd
service (they use the same "port" in terms of failover).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkva+PoACgkQHsardTLnvCX0XACfWTfPs9OljR9jrQN5pnBB2rF8
BAsAoJTA/JOLnbmdldTo/3xZQgBRRs6D
=inHf
-----END PGP SIGNATURE-----
13 years, 12 months
[PATCH] Fix uninitialized variable
by Jakub Hrozek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fixes an embarrassing bug that could result in marking the request as bad.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvexnQACgkQHsardTLnvCVaCACdF3wvpsA8jAyV9sgDWo/utwQ9
PuoAnRYp2L4kaVkRzz4Bzxkel2nGaAwm
=G99L
-----END PGP SIGNATURE-----
13 years, 12 months
