help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does anybody have EUDC and OpenLDAP working?


From: Martin Morgan
Subject: Re: Does anybody have EUDC and OpenLDAP working?
Date: 16 Jan 2004 10:41:38 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

> Bruce.Skinner@drdc-rddc.gc.ca (Bruce S. Skinner) 14:22 15/1/2004 wrote:
> 
>  BSS> When doing a directory search I get the error:
> 
>  BSS>   Opening input file: no such file or directory,
>  BSS>   /home/skinner/unrecognized option -B
> 
>  BSS> My environment is Emacs v21.2.1, OpenLDAP 2.1.22

I've just been struggling with this.

I think there are two things. First, the variable
ldap-host-parameters-alist has a default option -B, but I think
openldap doesn't recognize this option. So use customize-variable
ldap-host-parameters-alist and delete this.

Second and more problematic is in the ldap.el file. The function
ldap-search-internal parses the info that comes back from ldapsearch
with this snippet:

  (while (looking-at "^\\(\\w*\\)[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
        (setq name (match-string 1)
                  value (match-string 3))
                (save-excursion
                  (set-buffer bufval)
                  (erase-buffer)
                  (insert-file-contents-literally value)
                  (delete-file value)
                  (setq value (buffer-substring (point-min) (point-max))))
        (setq record (cons (list name value)
                                           record))
        (forward-line 1))

although written otherwise, the regexp is designed for ldapsearch
storing each search key in a temporary file (with OpenLDAP this would
be accomplished by the variable -tt), and the search itself returning
a list of keys and the file they're stored in. The regexp extracts the
file tag and file name, and then, in the save-excursion retrieves the
info from the file. What actually happens with the default arguments
is that the keys are not saved to file, but are returned as key: value
pairs. The regexp picks up the value, but the value is treated as a
file name. Here's my kludge:

  (while (looking-at "^\\(\\w*\\)[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
        (setq name (match-string 1)
                  file (match-string 2) ; mtm -- only match with binary files
                  value (match-string 3))
        (if file                                        ; mtm -- read any 
binary files
                (save-excursion
                  (set-buffer bufval)
                  (erase-buffer)
                  (insert-file-contents-literally value)
                  (delete-file value)
                  (setq value (buffer-substring (point-min) (point-max))))
          )                                                     ; mtm -- end if

Basically, only replace the value with file contents when a value is
actually returned in a file (apparently, this can happen with the -t
option if, for instance, the LDAP server stores, e.g., pictures of
each entry).

It's not enough just to feed -tt as an option in
ldap-host-parameters-alist (which would be overkill anyway, storing
all values in temporary files) because earlier in the
ldap-search-internal routine there's an assumption about the format of
the output (that the first line after blank is dn: value) that isn't
true for the default ldapsearch parameters (where the first line after
a blank is a comment). I *think* the non-coding solution is to
customize the ldap-host-parameters-alist to -LLL and -tt. If you go
with this option, you might need to make ensure file naming
conventions so that OpenLDAP deals with spaces in file names
correctly.

Hope that helps!

Dmitry Astapov <adept@ukr.net> writes:

> Evening, Bruce. 
> 
> 
> Lucky you. I (with xemacs 21.4.14 and openldap 2.1.23) often get my xemacs
> crashed on the first (after reboot) eudc search. It goes on for quite a
> long time and I honestly dont know what to do about it ...

This, unfortunately, I cannot help with.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]