Hi!
Sorry for the late respond from the package maintainer, but there
wasn't much I could have added to what David as author of the tool
already said.
On Fri, Apr 27, 2007 at 10:20:40AM +0200, Christoph Scheurer wrote:
When ldapvi is started with SSL (by URL) or TLS
ldapvi -Z
Hi,
Perhaps one the Debian people could re-assign this bug from ldapvi to
libldap2, so that the LDAP package maintainers become aware of this and
can add it to the ever-growing list of ancient libldap issues.
Yes, I think that would be the right thing to do. I have checked python-ldap
and gq
Hi,
Quoting Christoph Scheurer ([EMAIL PROTECTED]):
[...]
As one can see this ldapvi uses now the same libldap as ldapsearch and the
problem goes away!
I guess, ldapvi would have to be built with a more recent version of the ldap
libraries.
thanks for the analysis! Since I am just the
Package: ldapvi
Version: 1.6-3
Severity: important
Hello,
we are using Kerberos 5 and LDAP for user authentificationa and management at
our site. The KDC and LDAP servers are still running sarge. So far we used a
locally built version of ldapvi (1.3pfn_sasl, with the SASL patches applied)
on
Hi,
Quoting Christoph Scheurer ([EMAIL PROTECTED]):
For comparison
ldapsearch -ZZ -Y GSSAPI '(uid=)'
which, as I understand, does exactly the same as ldapvi until the editor is
opened, yields a search result immediately and does not use a noticable amount
of CPU on the exact same
Hi,
you were indeed right. It is a problem with the version of libldap and the use
of openssl.
I first tried to build upstream ldapvi on etch using openssl and the default
libldap2-dev (2.1.30-13.3) which didn't solve the problem. I then built ldap
libraries from the
6 matches
Mail list logo