On Wed, Jul 21, 2010 at 08:20:18PM +0400, Eugene Indenbom wrote:
On 07/21/2010 08:01 PM, Sumit Bose wrote:
On Wed, Jul 21, 2010 at 06:18:31PM +0400, Eugene Indenbom wrote:
On 07/21/2010 05:46 PM, Sumit Bose wrote:
On Wed, Jul 21, 2010 at 04:43:41PM +0400, Eugene Indenbom wrote:
The patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2010 05:32 AM, David O'Brien wrote:
Hi
The current doc includes the following statement in the section on
configuring failover (Section 15.2.3.2.4. Configuring Failover):
Future versions of SSSD will throw an error upon receiving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/2010 11:51 AM, Jakub Hrozek wrote:
In addition to validating the keytab everytime a TGT is requested, we
also validate the keytab on back end startup to give early warning that
the keytab is not usable.
Fixes: #556
Nack.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2010 02:06 PM, Stephen Gallagher wrote:
Nack.
sss_krb5_verify_keytab() should not be passed a memctx. No memory
created in this function is being passed back to the caller. It would be
much better to create a tmp_ctx (at the top-level)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sssd_dbus_common.c conditionally builds parts of code based on
HAVE_DBUS_WATCH_GET_UNIX_FD but does not include config.h
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2010 11:39 AM, Jakub Hrozek wrote:
sssd_dbus_common.c conditionally builds parts of code based on
HAVE_DBUS_WATCH_GET_UNIX_FD but does not include config.h
config.h is included by util/util.h, so this isn't strictly necessary.
I'm not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2010 06:34 PM, Stephen Gallagher wrote:
config.h is included by util/util.h, so this isn't strictly necessary.
I'm not sure it's worth including explicitly.
The problem I was seeing was caused by addition of -Wl,--as-needed into
my CFLAGS
Jakub Hrozek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/22/2010 05:32 AM, David O'Brien wrote:
Hi
The current doc includes the following statement in the section on
configuring failover (Section 15.2.3.2.4. Configuring Failover):
Future versions of SSSD will throw an