[Arthur de Jong]
> For this to work some code has been reshuffled to make this
> possible. This has been implemented in r733. Could you give it a
> try?
I've tested it, and it seem to work. It seem to be slower than my
code, but this might also be because the LDAP server some times are
slower.
On Sun, 2008-05-11 at 00:02 +0200, Petter Reinholdtsen wrote:
> > - I would really like to have the retry mechanism in myldap.c and
> > not outside because most of the retry code is already there and
> > this solution will probably conflict with that.
>
> I tried this, but the current API did n
[Arthur de Jong]
> I have a coulpe of problems with this patch (sorry, your work is
> very much appreciated):
No problem. It is a draft, and I am well aware that I do not know
enough to get it right on the first try. :)
> - I would really like to have the retry mechanism in myldap.c and not
>
On Fri, 2008-05-09 at 13:20 +0200, Petter Reinholdtsen wrote:
> Here is a better patch, making sure to only search once when the first
> search succeeds.
I have a coulpe of problems with this patch (sorry, your work is very
much appreciated):
- I would really like to have the retry mechanism in m
tags 474178 + patch
thanks
Here is a better patch, making sure to only search once when the first
search succeeds.
Index: nslcd/common.h
===
--- nslcd/common.h (revision 729)
+++ nslcd/common.h (working copy)
@@ -124,6 +124
Can a patch like this solve the problem? It is slightly tested. It
make sure to retry once if a search fail.
Index: nslcd/common.h
===
--- nslcd/common.h (revision 729)
+++ nslcd/common.h (working copy)
@@ -124,6 +124,10 @
[Petter Reinholdtsen]
> The problem still exist in version 0.6.2. I just deployed a
> backport in one of the Etch test machines, and here is the syslog
> entries.
After using this new module on my workstation for a few days, I got
the impression that the frequence of these LDAP lookup failures ha
The problem still exist in version 0.6.2. I just deployed a backport
in one of the Etch test machines, and here is the syslog entries.
May 5 08:41:40 slxtest nslcd[16438]: version 0.6.2 starting
May 5 08:41:40 slxtest nslcd[16438]: accepting connections
May 5 08:45:01 slxtest nslcd[16438]: con
[Arthur de Jong]
> The problem is probably that if the starting the search works
> without problems but lookup or connection errors are only reported
> when results are read, nslcd doesn't close the connection.
I tested the svn (709) version, and the problem is still present.
Here is the test run.
tags 474178 + pending
thanks
On Mon, 2008-04-21 at 23:56 +0200, Petter Reinholdtsen wrote:
> I was able to trigger this issue while running nslcd -d in the
> background. Notice how I get 5 "Can't connect LDAP server' in a row
> before getting a proper reply.
The problem is probably that if the s
[Petter Reinholdtsen]
> Do you have any idea how I can track down this error?
I was able to trigger this issue while running nslcd -d in the
background. Notice how I get 5 "Can't connect LDAP server' in a row
before getting a proper reply. This was after leaving the test
environment in piece for
[Petter Reinholdtsen]
> This issue is really annoying. I am not using libnss-ldapd on my
> work desktop for testing, and several times a day, when I try to ssh
> out from the machine, ssh fail with 'you do not exist, go away'.
> When I try again, ssh work as it should.
Here is another test run wh
This issue is really annoying. I am not using libnss-ldapd on my work
desktop for testing, and several times a day, when I try to ssh out
from the machine, ssh fail with 'you do not exist, go away'. When I
try again, ssh work as it should.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBS
Package: libnss-ldapd
Version: 0.6
Severity: important
Some times the getpwnam() call fail when using nss-ldapd. I have not
been able to figure out why. Here is an example:
% id pere
id: pere: No such user
% id pere
uid=43502(pere) gid=300(users) groups=300(users)
%
This make nss-ld
14 matches
Mail list logo
