On Fri, Aug 10, 2012 at 09:26:49AM +0200, Pavel Březina wrote:
On 08/08/2012 04:24 PM, Jakub Hrozek wrote:
On Wed, Aug 08, 2012 at 02:23:04PM +0200, Pavel Březina wrote:
This bug was probably introduced with the subdomain patches. The
problem was that sss_dp_get_domains_send() is called even
On Fri, Aug 10, 2012 at 07:12:38PM +0200, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 07:09:13PM +0200, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 05:13:48PM +0200, Michal Zidek wrote:
This should fix the duplicate detection. Patch is attached. Please
review with caution, i was in hurry.
On Thu, Aug 09, 2012 at 02:20:23PM +0200, Sumit Bose wrote:
Hi,
I would like to find a range/slice for Posix IDs based on a domain SID
on the IPA server the same way as sssd does. For this I need python
bindings for the murmurhash3() call. The attached patch adds them and a
small test.
On Mon, Aug 13, 2012 at 11:10:36AM +0200, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 09:26:49AM +0200, Pavel Březina wrote:
On 08/08/2012 04:24 PM, Jakub Hrozek wrote:
On Wed, Aug 08, 2012 at 02:23:04PM +0200, Pavel Březina wrote:
This bug was probably introduced with the subdomain
Hi,
As discussed in #SSSD on Friday the TTL used in the nsupdate when SSSD
carries out a needed update is set quite high (86400 seconds) and is
not in line with the TTL originally by an IPA client install (1200
seconds).
I've filed bug #1476 for this on the SSSD fedorahosted trac instance
and
On Fri, Aug 10, 2012 at 06:40:35PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1460
Please see the commit. I'm wondering if there is still a (small) race
condition between the call to pthread_cleanup_pop() and unlocking the
mutex. Would it be better to i.e. always call
On Mon, 2012-08-13 at 11:44 +0100, James Hogarth wrote:
Hi,
As discussed in #SSSD on Friday the TTL used in the nsupdate when SSSD
carries out a needed update is set quite high (86400 seconds) and is
not in line with the TTL originally by an IPA client install (1200
seconds).
I've filed
On Mon, Aug 13, 2012 at 01:30:21PM +0200, Sumit Bose wrote:
On Fri, Aug 10, 2012 at 06:40:35PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1460
Please see the commit. I'm wondering if there is still a (small) race
condition between the call to pthread_cleanup_pop()
Hi Devs,
I am seeing an issue with sssd-1.8.0-32.el6.x86_64
Issue description.
When system is on a different VLAN as the Active directory servers
logins are really slow or timeout and I see these errors.
I see this in the syslog
Aug 13 10:27:32 m4deploy01 sssd_be: GSSAPI Error: An invalid name
On Mon, Aug 13, 2012 at 10:46:43AM -0400, Derek Page wrote:
Hi Devs,
I am seeing an issue with sssd-1.8.0-32.el6.x86_64
Issue description.
When system is on a different VLAN as the Active directory servers
logins are really slow or timeout and I see these errors.
I see this in the
On 08/13/2012 11:13 AM, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 07:12:38PM +0200, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 07:09:13PM +0200, Jakub Hrozek wrote:
On Fri, Aug 10, 2012 at 05:13:48PM +0200, Michal Zidek wrote:
This should fix the duplicate detection. Patch is attached.
Thanks,
That did the trick.
I did not have this defined in either my 1.5 or 1.8 instances? Not
sure why 1.8 acts differently.
This fixed my issues for 1.8 not being able to authenticate as well as
sped up authentication for my 1.5.
On Mon, Aug 13, 2012 at 10:52 AM, Stephen Gallagher
https://fedorahosted.org/sssd/ticket/1415
I tripped over this bug again when I was testing the threading issue,
so I decided to just fix it.
From a11573a82a05f109a397553d2995617187d46927 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek jhro...@redhat.com
Date: Mon, 13 Aug 2012 18:03:24 +0200
Subject:
On Mon, Aug 13, 2012 at 04:40:03PM +0200, Jakub Hrozek wrote:
On Mon, Aug 13, 2012 at 01:30:21PM +0200, Sumit Bose wrote:
On Fri, Aug 10, 2012 at 06:40:35PM +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1460
Please see the commit. I'm wondering if there is still a
On Mon, 2012-08-13 at 18:11 +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1415
I tripped over this bug again when I was testing the threading issue,
so I decided to just fix it.
Obvious ack
signature.asc
Description: This is a digitally signed message part
https://fedorahosted.org/sssd/ticket/1478
I've tested that the following Python code now works fine:
from SSSDConfig import SSSDConfig
sssdconfig = SSSDConfig()
sssdconfig.import_config('/etc/sssd/sssd.conf')
ldap_domain = sssdconfig.new_domain('autofstest')
ldap_domain.add_provider('ldap',
On Mon, 2012-08-13 at 20:34 +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1478
I've tested that the following Python code now works fine:
from SSSDConfig import SSSDConfig
sssdconfig = SSSDConfig()
sssdconfig.import_config('/etc/sssd/sssd.conf')
ldap_domain =
On Mon, 2012-08-13 at 14:36 -0400, Stephen Gallagher wrote:
On Mon, 2012-08-13 at 20:34 +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1478
I've tested that the following Python code now works fine:
from SSSDConfig import SSSDConfig
sssdconfig = SSSDConfig()
On Mon, Aug 13, 2012 at 02:41:18PM -0400, Stephen Gallagher wrote:
On Mon, 2012-08-13 at 14:36 -0400, Stephen Gallagher wrote:
On Mon, 2012-08-13 at 20:34 +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1478
I've tested that the following Python code now works fine:
On Mon, Aug 13, 2012 at 12:13:00PM -0400, Stephen Gallagher wrote:
On Mon, 2012-08-13 at 18:11 +0200, Jakub Hrozek wrote:
https://fedorahosted.org/sssd/ticket/1415
I tripped over this bug again when I was testing the threading issue,
so I decided to just fix it.
Obvious ack
Pushed to
Hi - When our primary DNS is unreachable, SSSD with LDAP breaks, or is
incredibly slow. I've traced it to the fact that several of the LDAP
timeout values are 6 seconds. This is not long enough, because the
default DNS timeout failover is 5 seconds. Incoming SSH connections are
impossible
Mark London wrote:
Hi - When our primary DNS is unreachable, SSSD with LDAP breaks, or is
incredibly slow. I've traced it to the fact that several of the LDAP
timeout values are 6 seconds. This is not long enough, because the
default DNS timeout failover is 5 seconds. Incoming SSH
22 matches
Mail list logo
