Greg B wrote:
Before I perform initial bind (using ldap_sasl_bind and SSL context),
I set LDAP_OPT_NETWORK_TIMEOUT to 5 seconds... this seems to work a
treat on the bind time-out. The problem occurs after I unplug the
network cable on the LDAP server machine and try to perform a
search using the
As I mailed yesterday, I've been seeing my slaves not get updates once their
initial kerberos ticket period expires.
On the server, I see this, using -d-1 on the master:
SASL [conn=1] Failure: GSSAPI Error: The context has expired (No error)
sb_sasl_write: failed to encode packet: generic
--On Thursday, August 31, 2006 10:29 AM -0400 Allan E. Johannesen
[EMAIL PROTECTED] wrote:
As a wild guess, I think I may be seeing this problem since I may be
using a different version sasl (2.1.21) than others. It could be that an
older sasl may not have been checking ticket age.
I
--On Thursday, August 31, 2006 8:10 AM -0700 Atom Powers
[EMAIL PROTECTED] wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, August 30, 2006 8:44 PM -0700 Atom Powers
[EMAIL PROTECTED] wrote:
It is possible to set limits on an ou that are different from the
default limits?
I would like
--On Thursday, August 31, 2006 10:18 AM -0700 Quanah Gibson-Mount
[EMAIL PROTECTED] wrote:
--On Thursday, August 31, 2006 10:29 AM -0400 Allan E. Johannesen
[EMAIL PROTECTED] wrote:
As a wild guess, I think I may be seeing this problem since I may be
using a different version sasl
Quanah Gibson-Mount wrote:
Sure, I can use that to set a limit for a user but this application
needs
to bind anonymously (or the equivalent of anonymous, since the
credentials would have to be public).
I couldn't find anything in the limits directive that would let me
specify a part of the
quanah == Quanah Gibson-Mount [EMAIL PROTECTED] writes:
quanah Oh, I had another thought... Why are your replica's getting
quanah disconnected in the first place? The point of the persistent
quanah connection is for it to always stay active. Do you have some type of
quanah limits set on the
On Thu, Aug 31, 2006 at 07:47:32PM +0200, Pierangelo Masarati wrote:
Quanah Gibson-Mount wrote:
Sure, I can use that to set a limit for a user but this application
needs
to bind anonymously (or the equivalent of anonymous, since the
credentials would have to be public).
I couldn't find
--On Thursday, August 31, 2006 2:19 PM -0400 Allan E. Johannesen
[EMAIL PROTECTED] wrote:
quanah == Quanah Gibson-Mount [EMAIL PROTECTED] writes:
quanah Oh, I had another thought... Why are your replica's getting
quanah disconnected in the first place? The point of the persistent
quanah
Hello,
Context:
We have 2 directories, 1 Microsoft for domain domain1.fr, 1 Notes for
domain domain2.fr. In reality, we have more domains and 3 directories
but the problem remains the same.
We have an application which can produce only one type of request like
the following : ldapsearch -Wxy
--On Thursday, August 31, 2006 4:05 PM -0400 Allan E. Johannesen
[EMAIL PROTECTED] wrote:
First, as the subject has always said, I figure I've done something odd.
However, I don't know what that is.
quanah == Quanah Gibson-Mount [EMAIL PROTECTED] writes:
quanah Do you have some type of
First, as the subject has always said, I figure I've done something odd.
However, I don't know what that is.
quanah == Quanah Gibson-Mount [EMAIL PROTECTED] writes:
quanah Do you have some type of limits set on the master for connections? If
quanah you do, you need to bypass those for your
Johann Heymes wrote:
Hello,
Context:
We have 2 directories, 1 Microsoft for domain domain1.fr, 1 Notes for
domain domain2.fr. In reality, we have more domains and 3 directories
but the problem remains the same.
We have an application which can produce only one type of request like
the
quanah == Quanah Gibson-Mount [EMAIL PROTECTED] writes:
quanah --On Thursday, August 31, 2006 2:19 PM -0400 Allan E. Johannesen
quanah [EMAIL PROTECTED] wrote:
quanah But my point is, it shouldn't be initiating a disconnect in the first
quanah place (because then the connection isn't
If you're using MIT Kerberos, I strongly suspect that the problem you're seeing
is due to the behaviour of its GSSAPI library. With MIT's implementation a
gssapi context is only valid for the lifetime of the initiator's credential.
So, when your clients credentials expire, the security context
simon == [EMAIL PROTECTED] writes:
simon Just renewing your credentials won't help, as the new credentials will
simon only be used when establishing a new security context, which only
simon happens when a new connection is opened.
Thanks. Yes, that's exactly what I was seeing.
Hi,
I am configuring ldap service for my network. On the server, slapcat
print out correct directories that have been added. However, on the
client, it doesn't seem that the client can connect to the server. Using
ldapwhoami or ldapsearch 'root' yield the following error:
17 matches
Mail list logo