Your message dated Sat, 10 May 2008 13:17:35 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#421214: ldapvi: startup incredibly slow with TLS/SSL
has caused the Debian Bug report #421214,
regarding ldapvi: startup incredibly slow with TLS/SSL
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
421214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421214
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
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 sarge clients for administration and everything was fine. We wanted to
update to etch and use the regular ldapvi 1.6 Debian package now.
When ldapvi is started with SSL (by URL) or TLS
ldapvi -Z --tls strict -Y GSSAPI '(uid=XXXX)'
it takes about 40-50 seconds until the actual editor is opened. During this
time the CPU has 100% load (2GHz Athlon) from ldapvi. This does not happen and
the editor is opened immediately when no SSL/TLS is used.
For comparison
ldapsearch -ZZ -Y GSSAPI '(uid=XXXX)'
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 client machine.
An strace of a running ldapvi with TLS shows that during the 40 second period
ldapvi is going trough the certificates in /etc/ssl/certs, which is what
ldapsearch also does on startup, yet ldapvi is using considerably more
resources and time.
I mark this bug as important since it renders ldapvi practicably unusable for
administration and general LDAP editing at sites that employ either SSL (-h
ldaps://hostname) or STARTTLS (-Z).
Kind regards,
Ch. Scheurer
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages ldapvi depends on:
ii emacs21 [editor] 21.4a+1-3 The GNU Emacs editor
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libglib2.0-0 2.12.4-2 The GLib library of C routines
ii libldap2 2.1.30-13.3 OpenLDAP libraries
ii libncurses5 5.5-5 Shared libraries for terminal hand
ii libpopt0 1.10-3 lib for parsing cmdline parameters
ii libreadline5 5.2-2 GNU readline and history libraries
ii nano [editor] 2.0.2-1 free Pico clone with some new feat
ii vim [editor] 1:7.0-122+1etch2 Vi IMproved - enhanced vi editor
ldapvi recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.7-4+b1
On Tue, Jan 29, 2008 at 12:48:59PM +0100, Gerfried Fuchs wrote:
> 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 --tls strict -Y GSSAPI '(uid=XXXX)'
> > it takes about 40-50 seconds until the actual editor is opened. During this
> > time the CPU has 100% load (2GHz Athlon) from ldapvi. This does not happen
> > and
> > the editor is opened immediately when no SSL/TLS is used.
>
> Does this behavior still happen to you with the version of ldavpi in
> unstable/testing (please make sure you got 1.7-4+b1 as version of the
> package)? That one is now finally linked against a newer libldap version
> - the reasoning behind the delay for that happened didn't lie with me
> and I couldn't do much against it, but well, finally it happened.
As I haven't heard back from you I guess the issue is fixed for you as
you originally wrote that linking against the newer libldap fixed the
problem for you.
If it hasn't feel free to reopen the bug and submit further
informations for it.
So long, and thanks.
Rhonda
--- End Message ---
