[SSSD] [PATCH] Do not leak netgroups hash table

2011-05-06 Thread Jakub Hrozek
Nothing dangerous but still a leak From 6026a7a8421d0b984a74d783163f721e359b6771 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhro...@redhat.com Date: Fri, 6 May 2011 13:12:31 +0200 Subject: [PATCH] Do not leak netgroups hash table --- src/responder/nss/nsssrv.c | 12 1 files

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 13:10 +0200, Jan Zelený wrote: Since sdap_async_accounts.c is becoming a great monstrosity, I've created a call graph of functions defined in there. The graph shows where in the file is each function defined there called and it already takes Jakub's last big set of

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Jan Zelený
On Fri, 2011-05-06 at 13:10 +0200, Jan Zelený wrote: Since sdap_async_accounts.c is becoming a great monstrosity, I've created a call graph of functions defined in there. The graph shows where in the file is each function defined there called and it already takes Jakub's last big set of

[SSSD] [PATCH] Add support for openldap24 package on RHEL 5.7

2011-05-06 Thread Sumit Bose
Hi, this is a revised version of Stephen patch to support the openldap24 package on RHEL 5.7. I have moved the code to find the right include and library path into ldap.m4 and added a check in the spec file if the platform is RHEL 5.7 to allow the spec file to be used on older RHEL5 versions,

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Simo Sorce
On Fri, 2011-05-06 at 07:55 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 13:10 +0200, Jan Zelený wrote: Since sdap_async_accounts.c is becoming a great monstrosity, I've created a call graph of functions defined in there. The graph shows where in the file is each function

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 09:03 -0400, Simo Sorce wrote: On Fri, 2011-05-06 at 07:55 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 13:10 +0200, Jan Zelený wrote: Since sdap_async_accounts.c is becoming a great monstrosity, I've created a call graph of functions defined in there.

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Jakub Hrozek
On 05/06/2011 03:12 PM, Stephen Gallagher wrote: I would much prefer that the RFC2307 and RFC2307bis pieces be separated out. +1 they are really separate code paths. signature.asc Description: OpenPGP digital signature ___ sssd-devel mailing list

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Simo Sorce
On Fri, 2011-05-06 at 15:22 +0200, Jakub Hrozek wrote: On 05/06/2011 03:12 PM, Stephen Gallagher wrote: I would much prefer that the RFC2307 and RFC2307bis pieces be separated out. +1 they are really separate code paths. Then we should rather split along those lines instead of users vs

Re: [SSSD] Call graph of sdap_async_accounts

2011-05-06 Thread Jan Zelený
On Fri, 2011-05-06 at 09:03 -0400, Simo Sorce wrote: On Fri, 2011-05-06 at 07:55 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 13:10 +0200, Jan Zelený wrote: Since sdap_async_accounts.c is becoming a great monstrosity, I've created a call graph of functions defined in there.

Re: [SSSD] [PATCH] Add options to override GID, homedir and shell

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 13:56 +0200, Jakub Hrozek wrote: [PATCH 1/2] Add a confdb_get_uint32_t convenience function A convenience function to fetch the gid override from confdb Ack [PATCH 2/2] Add options to override GID, homedir and shell The functionality to override the shell is a little

Re: [SSSD] [PATCH] Add support for openldap24 package on RHEL 5.7

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 14:56 +0200, Sumit Bose wrote: Hi, this is a revised version of Stephen patch to support the openldap24 package on RHEL 5.7. I have moved the code to find the right include and library path into ldap.m4 and added a check in the spec file if the platform is RHEL 5.7 to

Re: [SSSD] [PATCH] Remove unused constants from data_provider.h

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 13:55 +0200, Jakub Hrozek wrote: These constants were harmless, but unused Ack. signature.asc Description: This is a digitally signed message part ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org

Re: [SSSD] [PATCH] Do not leak netgroups hash table

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 13:55 +0200, Jakub Hrozek wrote: Nothing dangerous but still a leak Not really a leak, since it's always used until the program exits, wherein it would be cleaned up anyway, but this is good practice nonetheless. Ack. signature.asc Description: This is a digitally

Re: [SSSD] [PATCHES] Allow changing log-level without restarting SSSD

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 10:55 +0200, Jakub Hrozek wrote: On Thu, May 05, 2011 at 12:58:24PM -0400, Stephen Gallagher wrote: New patches attached. (Patch 0002 is unchanged) Ack to both Pushed to master signature.asc Description: This is a digitally signed message part

Re: [SSSD] [PATCH] Add support for openldap24 package on RHEL 5.7

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 10:08 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 14:56 +0200, Sumit Bose wrote: Hi, this is a revised version of Stephen patch to support the openldap24 package on RHEL 5.7. I have moved the code to find the right include and library path into ldap.m4

Re: [SSSD] [PATCH] Remove unused constants from data_provider.h

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 10:08 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 13:55 +0200, Jakub Hrozek wrote: These constants were harmless, but unused Ack. Pushed to master. signature.asc Description: This is a digitally signed message part

Re: [SSSD] [PATCH] Do not leak netgroups hash table

2011-05-06 Thread Stephen Gallagher
On Fri, 2011-05-06 at 10:09 -0400, Stephen Gallagher wrote: On Fri, 2011-05-06 at 13:55 +0200, Jakub Hrozek wrote: Nothing dangerous but still a leak Not really a leak, since it's always used until the program exits, wherein it would be cleaned up anyway, but this is good practice