( ud lists only E-Mail address, but not preferredRfc822Originator and
preferredRfc822Recipient. These two attributes are defined by cdc.
They were used by the mail-gateway-software to make adress rewriting.)
Can anyone tell me how I can configure ud to use ldaptemplate.conf and
ldapsearchprefs.conf?
Thanks in advance
Gabi Dobler
Post: Martensstrasse 1, 91058 Erlangen
SMTP: Gabriele.Dobler@rrze.uni-erlangen.de
X400: G=Gabriele S=Dobler OU=RRZE PRMD=Uni-Erlangen ADMD=D400 C=DE
Fax: 09131 302941
Tel: 09131 85-7813
Mailprobleme an: PostLeute@rrze.uni-erlangen.de
From ldap-errors Tue Feb 27 11:59:54 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id LAA02323; Tue, 27 Feb 1996 11:59:54 -0500 (EST)
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
with X.500 id LAA02321; Tue, 27 Feb 1996 11:59:54 -0500 (EST)
Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with SMTP id LAA02301; Tue, 27 Feb 1996 11:59:35 -0500 (EST)
Message-Id: <199602271659.LAA02301@terminator.rs.itd.umich.edu>
From: "Tim Howes" <tim@umich.edu>
To: Gabi Dobler <Gabriele.Dobler@rrze.uni-erlangen.de>
cc: ldap@umich.edu
Subject: Re: ud does not use ldaptemplate.conf and ldapsearchprefs.conf
In-reply-to: Your message of "Tue, 27 Feb 1996 16:38:50 GMT."
<3133339c5511002@max3.rrze.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 27 Feb 1996 11:59:34 -0500
Sender: tim@terminator.rs.itd.umich.edu
> From: Gabi Dobler <Gabriele.Dobler@rrze.uni-erlangen.de>
> To: ldap@umich.edu
> i want to use the ldap client ud , to get some "user definded" attributes
> searching for people.
>
> ( ud lists only E-Mail address, but not preferredRfc822Originator and
> preferredRfc822Recipient. These two attributes are defined by cdc.
> They were used by the mail-gateway-software to make adress rewriting.)
>
> Can anyone tell me how I can configure ud to use ldaptemplate.conf and
> ldapsearchprefs.conf?
Unfortunately ud is a bit of a relic that predates the template
and search pref support in libldap. It would require a lot of work
to change it. But, you can probably accomplish what you want (making
ud aware of some new attributes) by editing the clients/ud/globals.c
file. -- Tim
From ldap-errors Fri Mar 1 07:54:26 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id HAA12891; Fri, 1 Mar 1996 07:54:26 -0500 (EST)
Received: from truelies.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with ESMTP id HAA12888; Fri, 1 Mar 1996 07:54:25 -0500 (EST)
Received: by truelies.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id HAA24360; Fri, 1 Mar 1996 07:54:25 -0500 (EST)
Received: from grim.kvatro.no by truelies.rs.itd.umich.edu (8.7.4/2.2)
with ESMTP id HAA24344; Fri, 1 Mar 1996 07:54:18 -0500 (EST)
Received: from odin (odin.kvatro.no [193.216.2.140]) by grim.kvatro.no (8.7.4/8.7.1) with SMTP id NAA02363 for <ldap@umich.edu>; Fri, 1 Mar 1996 13:53:53 +0100 (MET)
X400-Received: by mta odin in /PRMD=notis/ADMD=TELEMAX/C=NO/; Relayed;
Fri, 1 Mar 1996 13:53:26 +0100
Date: Fri, 1 Mar 1996 13:53:26 +0100
X400-Originator: Nils.Thommesen@odin.kvatro.no
X400-Recipients: ldap@umich.edu
X400-MTS-Identifier: [/PRMD=notis/ADMD=TELEMAX/C=NO/;6044 96/03/01 13:53]
Content-Identifier: 6044 96/03/01
Alternate-Recipient: Allowed
From: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
Message-ID: <"6044 96/03/01 13:53*/G=Nils/S=Thommesen/PRMD=notis/ADMD=TELEMAX/C=NO/"@MHS>
To: ldap@umich.edu
Subject: How do I solve "Decoding Error"?
I am currently using LIBLDAP version 3.2, and when connecting to *some*
servers, I get "Decoding Error". I have tried to use the debug version of
LIBLDAP.DLL, but I couldn't figure out what went wrong, or *where*
things got wrong.
So, my question is: how can I figure out what and where things go wrong when I
try to connect to some servers?
FYI: It is the ldap_simple_bind call that returns Decoding error. I do not run any
LDAP servers myself.
Nils Andreas Thommesen -- Nils.Thommesen@kvatro.no
- - - - - - - - - - - - - - - - - - - - - -
Work: Kvatro-Notis, Pirsenteret, N-7005 Trondheim; +47 73 545 722
Home: E.B Schieldropsv. 9-24,7033 Trondheim,Norway; +47 73 8888 93
Fax : +47 73 545 750
WWW : http://www.kvatro.no/~nat http://www.kvatro.no/notis
- - - - - - - - - - - - - - - - - - - - - -
I'm left-handed, left-eyed, left-footed but not left behind!
From ldap-errors Fri Mar 1 09:36:26 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id JAA15320; Fri, 1 Mar 1996 09:36:26 -0500 (EST)
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
with X.500 id JAA15318; Fri, 1 Mar 1996 09:36:26 -0500 (EST)
Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with SMTP id JAA15172; Fri, 1 Mar 1996 09:31:14 -0500 (EST)
Message-Id: <199603011431.JAA15172@terminator.rs.itd.umich.edu>
From: "Tim Howes" <tim@umich.edu>
To: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
cc: ldap@umich.edu
Subject: Re: How do I solve "Decoding Error"?
In-reply-to: Your message of "Fri, 01 Mar 1996 13:53:26 +0100."
<"6044 96/03/01 13:53*/G=Nils/S=Thommesen/PRMD=notis/ADMD=TELEMAX/C=NO/"@MHS>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 01 Mar 1996 09:31:14 -0500
Sender: tim@terminator.rs.itd.umich.edu
> From: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
> To: ldap@umich.edu
> I am currently using LIBLDAP version 3.2, and when connecting to *some*
> servers, I get "Decoding Error". I have tried to use the debug version of
> LIBLDAP.DLL, but I couldn't figure out what went wrong, or *where*
> things got wrong.
>
> So, my question is: how can I figure out what and where things go wrong when I
> try to connect to some servers?
>
> FYI: It is the ldap_simple_bind call that returns Decoding error. I do not ru
- n any
> LDAP servers myself.
No doubt these are 3.0 LDAP servers that you connecting to when you
get the decoding error. There is a known bug with older servers that
caused some protocol elements (namely, the bind request) to be
encoded incorrectly. Versions later than that fix the problem, and
later servers understand both formats (the old broken one and the
new correct one). New clients only speak the new correct format,
though. So your best bet is to try and encourage those sites running
the old stuff to upgrade. -- Tim
From ldap-errors Wed Mar 6 07:19:56 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id HAA24378; Wed, 6 Mar 1996 07:19:56 -0500 (EST)
Received: from totalrecall.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with ESMTP id HAA24375; Wed, 6 Mar 1996 07:19:49 -0500 (EST)
Received: by totalrecall.rs.itd.umich.edu (8.7.4/2.3)
with X.500 id HAA17913; Wed, 6 Mar 1996 07:19:49 -0500 (EST)
Received: from grim.kvatro.no by totalrecall.rs.itd.umich.edu (8.7.4/2.3)
with ESMTP id HAA17908; Wed, 6 Mar 1996 07:19:43 -0500 (EST)
Received: from odin (odin.kvatro.no [193.216.2.140]) by grim.kvatro.no (8.7.4/8.7.1) with SMTP id NAA09864 for <ldap@umich.edu>; Wed, 6 Mar 1996 13:16:00 +0100 (MET)
X400-Received: by mta odin in /PRMD=notis/ADMD=TELEMAX/C=NO/; Relayed;
Wed, 6 Mar 1996 13:15:30 +0100
Date: Wed, 6 Mar 1996 13:15:30 +0100
X400-Originator: Nils.Thommesen@odin.kvatro.no
X400-Recipients: ldap@umich.edu
X400-MTS-Identifier: [/PRMD=notis/ADMD=TELEMAX/C=NO/;6122 96/03/06 13:15]
Content-Identifier: 6122 96/03/06
Alternate-Recipient: Allowed
From: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
Message-ID: <"6122 96/03/06 13:15*/G=Nils/S=Thommesen/PRMD=notis/ADMD=TELEMAX/C=NO/"@MHS>
To: ldap@umich.edu
Subject: LDAP and character sets
My LDAP-client is approaching its final stages, with much help from this
list. Thank you!
My current question has to do with those non-standard characters, as
those found in any "international" font, with accents, slashes, rings,
tildes, umlauts etc.
My client runs under Windows, and for instance I get "n pluss tilde"
where it really is supposed to be "aelig". Another example is "u with
accent egu" instead of "o-slash".
Does anyone have any pointers to more information on how I can solve this
problem? Should it be solved on the server, by using some speacial
encoding? Or should it be solve be the server, by using some substitution
scheme?
Nils Andreas Thommesen -- Nils.Thommesen@kvatro.no
- - - - - - - - - - - - - - - - - - - - - -
Work: Kvatro-Notis, Pirsenteret, N-7005 Trondheim; +47 73 545 722
Home: E.B Schieldropsv. 9-24,7033 Trondheim,Norway; +47 73 8888 93
Fax : +47 73 545 750
WWW : http://www.kvatro.no/~nat http://www.kvatro.no/notis
- - - - - - - - - - - - - - - - - - - - - -
I'm left-handed, left-eyed, left-footed but not left behind!
From ldap-errors Wed Mar 6 11:15:53 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id LAA02084; Wed, 6 Mar 1996 11:15:53 -0500 (EST)
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
with X.500 id LAA02082; Wed, 6 Mar 1996 11:15:52 -0500 (EST)
Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with SMTP id LAA02043; Wed, 6 Mar 1996 11:15:12 -0500 (EST)
Message-Id: <199603061615.LAA02043@terminator.rs.itd.umich.edu>
From: Mark Smith <mcs@umich.edu>
To: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
cc: ldap@umich.edu
Subject: Re: LDAP and character sets
In-reply-to: Your message of "Wed, 06 Mar 1996 13:15:30 +0100."
<"6122 96/03/06 13:15*/G=Nils/S=Thommesen/PRMD=notis/ADMD=TELEMAX/C=NO/"@MHS>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Mar 1996 11:15:12 -0500
Sender: mcs@terminator.rs.itd.umich.edu
>From: Nils Andreas Thommesen <Nils.Thommesen@odin.kvatro.no>
> To: ldap@umich.edu
>
> My current question has to do with those non-standard characters, as
> those found in any "international" font, with accents, slashes, rings,
> tildes, umlauts etc...
Many string-based attribute values can hold characters in the T.61
character set, which includes some of the common international
characters. These characters will be returned over LDAP as T.61
characters, and you will need to translate them in your client to a
useful character set such as 8859-1 or whatever your client/OS can
handle.
The good news is that our LDAP 3.2 release contains some (optional)
code to help with the translation task -- take a look at the
ldap_charset manual page for more information. It is available in the
LDAP 3.2 distribution, and also on the WWW here:
http://www.umich.edu/yp-cgi-bin/ldapman?ldap_charset
One thing to note: I am not sure if the character set support has been
tested on Windows or not.
-Mark
From ldap-errors Thu Mar 14 20:03:38 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id UAA11741; Thu, 14 Mar 1996 20:03:38 -0500 (EST)
Received: from judgmentday.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with ESMTP id UAA11738; Thu, 14 Mar 1996 20:03:37 -0500 (EST)
Received: by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id UAA29608; Thu, 14 Mar 1996 20:03:37 -0500 (EST)
Received: from Breakaway.Stanford.EDU by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with SMTP id SAA17809; Thu, 14 Mar 1996 18:28:04 -0500 (EST)
Received: from localhost by Breakaway.Stanford.EDU (8.6.10/inc-1.0)
id PAA04836; Thu, 14 Mar 1996 15:27:55 -0800
Message-Id: <199603142327.PAA04836@Breakaway.Stanford.EDU>
Subject: LDAP & X.500: Road Map is UP.
To: ietf-asid@umich.edu, ldap@umich.edu
cc: ns-dirsvc-impl@lists.stanford.edu
Reply-to: hodges@Breakaway.Stanford.EDU
Office: Pine Hall Rm 161; 415-723-2452
Date: Thu, 14 Mar 96 15:27:55 -0800
From: Jeff Hodges <hodges@Breakaway.Stanford.EDU>
X-Mts: smtp
Hi all,
I found it somewhat a struggle as a "newbie" to figger out the X.500 & LDAP
maze and determine what docs to read for what reason and in which order and all
(and still am, actually :)
It was still a problem, even with the help of the excellent Nexor and ISODE web
pages and all. So I've created a modest LDAP & X.500 roadmap to try to help out
others here @ Stanford and elsewhere. It can be found at....
http://www-leland.stanford.edu/group/networking/directory/x500ldapfaq.html
feedback and contributions encouraged.
thanks,
Jeff
From ldap-errors Fri Mar 15 12:31:06 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.4/2.3)
id MAA08585; Fri, 15 Mar 1996 12:31:06 -0500 (EST)
Received: from totalrecall.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.4/2.3)
with ESMTP id MAA08580; Fri, 15 Mar 1996 12:31:05 -0500 (EST)
Received: by totalrecall.rs.itd.umich.edu (8.7.4/2.3)
with X.500 id MAA24762; Fri, 15 Mar 1996 12:31:05 -0500 (EST)
Received: from ncr-sd.SanDiegoCA.ATTGIS.COM by totalrecall.rs.itd.umich.edu (8.7.4/2.3)
with SMTP id MAA24740; Fri, 15 Mar 1996 12:30:59 -0500 (EST)
Received: by ncr-sd.SanDiegoCA.ATTGIS.COM; 15 Mar 96 09:31:14 PST
Received: by sandpiper.sandiegoca.attgis.com with Microsoft Mail
id <3149A922@sandpiper.sandiegoca.attgis.com>; Fri, 15 Mar 96 09:30:10 PST
From: "Rinehart, William" <williamr@microcosm.sandiegoca.attgis.com>
To: ldap <ldap@umich.edu>
Subject: subscribe
Date: Fri, 15 Mar 96 09:29:00 PST
Message-ID: <3149A922@sandpiper.sandiegoca.attgis.com>
Encoding: 4 TEXT
X-Mailer: Microsoft Mail V3.0
subscribe
william.rinehart@sandiegoca.attgis.com
From ldap-errors Thu Mar 21 10:56:53 1996
Return-Path: <ldap-errors>
Received: by terminator.rs.itd.umich.edu (8.7.5/2.3)
id KAA17913; Thu, 21 Mar 1996 10:56:53 -0500 (EST)
Received: from judgmentday.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.7.5/2.3)
with ESMTP id KAA17909; Thu, 21 Mar 1996 10:56:52 -0500 (EST)
Received: by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with X.500 id KAA02396; Thu, 21 Mar 1996 10:56:51 -0500 (EST)
Received: from bnr.ca by judgmentday.rs.itd.umich.edu (8.7.4/2.2)
with SMTP id KAA02386; Thu, 21 Mar 1996 10:56:47 -0500 (EST)
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 21 Mar 1996 10:52:34 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 21 Mar 1996 10:52:26 -0500
X400-Received:
by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Thu, 21 Mar 1996 10:52:26 -0500
X400-Received:
by /PRMD=bnr/ADMD=telecom.canada/C=ca/; Relayed; Thu, 21 Mar 1996 10:52:23 -0500
Date: Thu, 21 Mar 1996 10:52:23 -0500
X400-Originator: /dd.id=1660747/g=peter/i=pw/s=whittaker/@bnr.ca
X400-MTS-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<Pine.HPP.3.91.960321102417.1751]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Questions on ...
From: "peter (p.w.) whittaker" <pww@bnr.ca>
Message-ID: <Pine.HPP.3.91.960321102417.17510f-100000@bwdlh590>
To: ldap%umich.edu@bnr.ca, ic-tech%isode.com@bnr.ca
Subject: Questions on Berkeley db and hash; some on ndbm too....
X-Sender: pww@bwdlh590
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I've recently spent time crawling through the Berkeley db code and
documentation. From the Berkeley documentation - and especially the
USENIX papers - I'd formed a very positive picture of the Berkeley db
and hash work, but the code - and the man page source - sours that
impression.
Given that the IC and UMich use or recommend the use of the Berkeley
code for certain directory services (IC 1993 DSA, UMich slapd), I wish
to solicit your opinions as to the robustness and "readiness" or
"product level-ness" of the Berkeley code. Toward the end I also have a
question or two on other ndbm alternatives.
Background to my concerns about Berkeley db:
--------------------------------------------
I started by reading the papers submitted to USENIX; maybe I should have
started with the code or man pages: the USENIX papers gave the
impression of a powerful db system complete with a transaction control
system. The man pages and code temper this impression some what....
The libtp libraries are part of db.1.85/mpool, which is, according
to the README, not ready for prime time. This comments is echoed in
the code and the man page source as well.
Sections in dbopen.3 that refer to DB_LOCK, DB_SHMEM, and DB-TXN are
commented out; the code itself contains no active references to any
of these macros.
The code available at Berkeley is version 1.85, which has not been
updated since September 1994 (this may coincide with the end of the
BSD project, I don't remember the exact date).
The db DBT structure suffers from the same problem as the ndbm datum
structure: DBT.data is static data. While this is easily worked
around in the same way as ndbm (described above), it doesn't exactly
inspire confidence as to the robustness of db (what I mean is that
db wasn't coded to not do such things, the way, say, gdbm is).
The overall impression is that of a - potentially very good - work in
progress that was interrupted at an unfortunate point: just shy of
being ready for prime time.
One of my responsibilities is recommending/supplying directory products
for use with our group's product. Our customers generally want a
directory they do not have to worry about: install it, set it up,
populate it, forget about. I have written front-end installation,
configuration and population tools that make this about as easy as
possible; the underlying technology, i.e., db, is completely hidden from
the user.
Unfortunately, the Berkeley code leaves me with the impression that the
user will not be able to forget about the Directory, will not be able to
avoid finding out about it, calling our support lines, etc.
That said, both the ISODE Consortium and UMich make use of or recommend
the Berkeley code for use in two of their more important products: the
IC's 1993 DSA and UMich's slapd. I have the impression that UMich's
production directory service is based on slapd using Berkeley db.
So, I've got conflicting information: two technically sound
organizations use or recommend the use of Berkeley db, while the code
itself seems to argue against its use.
One way to reconcile these two views is to emphasize the technically
strong nature of organizations: problems arising from the use of db can
probably be handled very readily by workers at the IC or at UMich.
What it all boils down to:
--------------------------
Can db be used safely in an environment where that level of technical
know-how and support is not immediately at hand? Would a commercial
organization be better off using some other basis for their directory
services, in order to reduce the potential for support calls, customer
complaint, etc?
Thoughts, comments, opinions, on the strength and weaknesses of db?
A final question on db: the slapd documentation says to apply a certain
fix if you have db.1.85 or earlier; this would seem to imply that there
are later versions available, possibly from some source other than
Berkeley. Yes? No? Has someone picked up db and, for love or money,
decided to continue development?
ndbm questions
--------------
The slapd documentation mentions problems with ndbm, mostly related to
re-entrancy. However, steps are taken in the slapd code to handle the
worst of these (ndbm calls that return pointers to static data), and
these same steps are taken for the Berkeley db calls. What are the
real concerns with the use of ndbm in threaded programs?
The IC R3 documentation mentions one important limit of some ndbm
implementations: no datum can be bigger than a disk page (SunOS,
Solaris). Are there others?
Are there other alternatives to ndbm that are widely available (other
than gdbm: the GNU copyright gives many corporate lawyers and contracts
people hives)? I'm especially interested in ndbm for SunOS, Solaris,
HP-UX, OSF/1, and Windows NT. These alternatives should be thread-safe
and should not suffer from the problems found in the bundled ndbms.
Thanks,
pww
Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 Specialist
pww@entrust.com [ http://www.entrust.com ] Nortel Secure Networks
Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C
FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7