sssd-devel April 2010

sssd-devel@lists.fedorahosted.org

17 participants
63 discussions

[PATCH] Remove unused configure macro
by Stephen Gallagher 15 Apr '10

15 Apr '10

Some time ago, we removed support for invoking shadow-utils from the sss_* tools. We removed the m4 file containing the WITH_SHADOW_UTILS_PATH macro, but we forgot to remove it from configure.ac, which causes a nonfatal warning when running configure. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 3

[Patch] Fixing spec file to match the INI versions
by Dmitri Pal 14 Apr '10

14 Apr '10

Subj. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

2 2

[Patch] Fixing build...
by Dmitri Pal 14 Apr '10

14 Apr '10

Sorry! -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

2 3

[PATCH] Fix ini_config unit test
by Stephen Gallagher 14 Apr '10

14 Apr '10

When running 'make distcheck', the entire source directory is set to read-only, to ensure that the build process only has write access to $builddir. As a result, this was causing the unit test for file mode to fail, since the file it was testing resides in the $srcdir. This patch guarantees that the test file has the correct permissions prior to running the access test. This patch applies atop the ini metadata patches and should be pushed alongside them. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

3 7

[PATCHES] INI meta data interface patches
by Dmitri Pal 14 Apr '10

14 Apr '10

Hello, The following patches introduce the meta data interface as it was discussed earlier on the list. The whole work is split into 4 patches. It is done just for simplicity of the review. Each of the patches applies and runs on top of previous one. As I developed I saw some issues with the code so I corrected them (mostly in the last patch). The names of the patches speck for themselves. The comments in the patches are pretty thorough. Tickets addressed by the effort (tickets are not updated yet with some comments about the alternative ways the patches solve the problem expressed in the ticket): https://fedorahosted.org/sssd/ticket/405 <- interfaces now allow the caller to do it. https://fedorahosted.org/sssd/ticket/442 <- done https://fedorahosted.org/sssd/ticket/173 <- done differently but now available to the caller https://fedorahosted.org/sssd/ticket/82 <-security checks interfaces are added. The recommended approach is presented in the unit test. https://fedorahosted.org/sssd/ticket/140 <- the approach changed. This is the best we can do at the moment. But we can enhance meta data and add other checks as the need emerges. It still does not fix the lines collection. It just turns off the creation of it. I just do not know what to do with the lines collcetion at the moment. It will be needed for the grammar validation but until this part is built I am not sure which format for it is the best. So I know it will be needed but it is not needed now. Thus it is ifdefed at the moment. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

4 14

[TRACE] Adding ability to trace 64bit numbers
by Dmitri Pal 14 Apr '10

14 Apr '10

Addresses ticket https://fedorahosted.org/sssd/ticket/447 Applies only on to of my previous ini metadata patch. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

3 8

[PATCH] Fix warning in sysdb-tests.c
by Stephen Gallagher 14 Apr '10

14 Apr '10

When we converted to the synchronous sysdb interface, the synchronous-simulating function test_loop() became unnecessary, but we forgot to remove it. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 2

Re: [SSSD] Patch to fix LDAP ID backend GSSAPI credential expired messages
by Eugene Indenbom 13 Apr '10

13 Apr '10

Hi Simon, I have to admit that the patch is really quite big and, actually, it has by far exceeded size and time limits I would normally apply to patches to third party components. The patch can be theoretically split into 3 parts: 1. Changes to ldap_child related to returned ticket expiration date; 2. Changes to failover subsystem needed to return number of servers registered for failover; 3. Changes to LDAP ID backend connection and retry logic. As you can see, the first two items are really small and absolutely pointless without the last. The reason why the changes to LDAP ID backend connection and retry logic must go together are very simple: old logic relies on gsh member of sdap_id_ctx, while in new logic there is no such a member. The reason why gsh needs to go away is as follows: 1. gsh enforces that there will be one and only one connection to DS; 2. When connection is about to expire we can not use it for new request as it will expire halfway; 3. But at the same time connection could be yet busy with previous request; 4. Therefore we have to make a new connection and close old one as soon as requests using it are finished. > The goal of SSSD is to never use more than one connection at a time for > account information. So your patch is kind of changing our fundamental > goal by allowing multiple connections. We need to carefully evaluate > that part. As I have explained above, the only time we have more then one connection to DS is when old connection is about to expire and we need to open new one. So when ticket lifetime is long enough (as it is in normal Kerberos configuration) there will be no more then 2 connections open. > I see you started passing around sdap_id_op. The memory hierarchy > around sdap_is_op is very delicate and required a lot of very careful > handling to avoid having it disappear under our feet at the wrong time. > It is meant to represent a single ldap operation tied to a specific ldap > context, any changes to its use should be in a separate patch that I > want to review carefully. But ideally sdap_id_op is opaque to most of > the code and is internal to the processing of replies from the openldap > libraries. It should never be used out of this context. I agree that both sdap_id_op and sdap_id_connection are opaque types. You can move the definitions to ldap_common.c from headers. More over even declaration of sdap_id_connection can be visible only to ldap_common.c. I were not really sure what coding style is used in project. There are files coded quite differently from each other. On the other hand I do not see why you find handling of these structures delicate: 1. sdap_id_op is owned by operation state (e.g. by global_enum_state). So it will be automatically destroyed as operation (tevent request) is completed 2. sdap_id_connection is owned by sdap_id_ctx and logic of its life-cycle boils down to single method - sdap_id_release_connection. Connection is released when: a) There is no operation using it b) It is not cached c) It is not in connection notify loop (notify_lock == 0) I hope I have explained why changes were made the way they have been done. I really do not see a way to split the patch and would appreciate very much if you give me some advice on how to make it more readable and easier to understand. If you have any ideas on how to split the patch, I am ready to discuss them and implement if needed. Regards, Eugene

4 17

[Transifex] File submitted via email to SSSD | master
by admin＠transifex.net 12 Apr '10

12 Apr '10

Hello sssd, this is Transifex at http://www.transifex.net. The following attached files were submitted to SSSD | master by raven <piotrdrag(a)gmail.com> Please, visit Transifex at http://www.transifex.net/projects/p/sssd/c/master/ in order to see the component page. Thank you, Transifex

2 1

[Transifex] File submitted via email to SSSD | master
by admin＠transifex.net 12 Apr '10

12 Apr '10

Hello sssd, this is Transifex at http://www.transifex.net. The following attached files were submitted to SSSD | master by yurchor <yurchor(a)ukr.net> Please, visit Transifex at http://www.transifex.net/projects/p/sssd/c/master/ in order to see the component page. Thank you, Transifex

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel April 2010