** It is recommended that you read or at least skim through ALL of the
** instructions in this file before attempting to build the software.
**
-** The OpenLDAP Quick Start Guide is available at:
-** http://www.openldap.org/faq/index.cgi?file=172
+** A draft of the "OpenLDAP Administrator's Guide", which includes a
+** quick start guide, is available at:
+** http://www.openldap.org/devel/admin/
**
** The OpenLDAP Installation FAQ is available at:
** http://www.openldap.org/faq/index.cgi?file=8
This is an gamma release of OpenLDAP 2.0. It is provided
for testing purposes only. It is not for general use.
- The OpenLDAP Developer's FAQ is available at:
- http://www.openldap.org/faq/index.cgi?file=4
-
Testers should provide feedback regarding this release using
the OpenLDAP Issue Tracking System <http://www.openldap.org/its/>.
Developer's wishing to contribute changes should work with latest
Additional documentation can be found in the doc directory.
doc/devel Developer Information
- doc/drafts LDAP-related IETF drafts
doc/install Installation and Integration
doc/man Raw man(1) pages
doc/rfcs LDAP-related Request for Comments
A draft of the "OpenLDAP Administrator's Guide" is available at:
http://www.openldap.org/devel/admin/
- The OpenLDAP 2.0 Software FAQ is available at:
+ The OpenLDAP Software FAQ is available at:
http://www.openldap.org/faq/index.cgi
Issues, such as bug reports, should be reported using our
our Issue Tracking System <http://www.OpenLDAP.com/its/> or
by sending mail to OpenLDAP-its@OpenLDAP.org. Do not use
- this system for general or software equiries. Please direct
+ this system for general or software enquiries. Please direct
these to the appropriate mailing list.
---
-This is the README file for mail500, a mailer that does X.500 lookups
-via LDAP.
+This is the README file for mail500, a mailer that does directory
+lookups via LDAP. The name is historical and refers to X.500.
If you are planning to run mail500 at your site, there are several
things you will have to tailor in main.c:
similar to the way /bin/mail works. It takes a few required arguments
and then a list of addresses to deliver to. It expects to find the
message to deliver on its standard input. It looks up the addresses in
-X.500 to figure out where to route the mail, and then execs sendmail to
-do the actual delivery. It supports simple aliases, groups, and
+directory to figure out where to route the mail, and then execs sendmail
+to do the actual delivery. It supports simple aliases, groups, and
mailing lists, the details of which are given below.
*** HOW IT WORKS (from the sendmail side): ***
The idea is that you might have a rule like this in your sendmail.cf
file somewhere in rule set 0:
-R$*<@umich.edu>$* $#mail500$@umich.edu$:<$1>
+R$*<@example.com>$* $#mail500$@example.com$:<$1>
-This rule says that any address that ends in @umich.edu will cause
-the mail500 mailer to be called to deliver the mail. You probably
-also want to do something to prevent addresses like terminator!tim@umich.edu
-or tim%terminator.rs.itd.umich.edu@umich.edu from being passed to mail500.
-At U-M, we do this by adding rules like this to rule set 9 where we
-strip off our local names:
+This rule says that any address that ends in @example.com will cause the
+mail500 mailer to be called to deliver the mail. You probably also want
+to do something to prevent addresses like uuhost!user@example.com or
+user%host@example.com from being passed to mail500. This can be done by
+adding rules like this to rule set 9 where we strip off our local names:
-R<@umich.edu>$*:$* $>10<@>$1:$2
-R$+%$+<@umich.edu> $>10$1%$2<@>
-R$+!$+<@umich.edu> $>10$1!$2<@>
+R<@example.com>$*:$* $>10<@>$1:$2
+R$+%$+<@example.com> $>10$1%$2<@>
+R$+!$+<@example.com> $>10$1!$2<@>
See the sample sendmail.cf in this directory for more details.
For sendmail 8.9 (and later) users can use MAILER(mail500) if
*** HOW IT WORKS (from the mail500 side): ***
When mail500 gets invoked with one or more names to which to
-deliver mail, it searches for each name in X.500. Where it searches,
+deliver mail, it searches for each name in LDAP. Where it searches,
and what kind(s) of search(es) it does are compile-time configurable
-by changing the base array in main.c. For example, the configuration
-we use at U-M is like this:
+by changing the base array in main.c. The configuration:
Base base[] =
- { "ou=People, dc=OpenLDAP, dc=org", 0
+ { "ou=People, dc=example, dc=com", 0
"uid=%s", "cn=%s", NULL,
- "ou=System Groups, ou=Groups, dc=OpenLDAP, dc=org", 1
+ "ou=System Groups, ou=Groups, dc=example, dc=com", 1
"(&(cn=%s)(associatedDomain=%h))", NULL, NULL,
- "ou=User Groups, ou=Groups, dc=OpenLDAP, dc=org", 1
+ "ou=User Groups, ou=Groups, dc=example, dc=com", 1
"(&(cn=%s)(associatedDomain=%h))", NULL, NULL,
NULL
};
-which means that in delivering mail to "name" mail500 would do the
+means that in delivering mail to "name" mail500 would do the
the following searches, stopping if it found anything at any step:
- Search (18) [2]: dc=org@dc=OpenLDAP@ou=People
+ Search (18) [2]: dc=com@dc=example@ou=People
Search subtree (uid=name)
- Search (18) [3]: dc=org@dc=OpenLDAP@ou=People
+ Search (18) [3]: dc=com@dc=example@ou=People
Search subtree (cn=name)
- Search (18) [4]: dc=org@dc=OpenLDAP@ou=Groups@ou=System Groups
+ Search (18) [4]: dc=com@dc=example@ou=Groups@ou=System Groups
Search subtree & ((cn=name)(associatedDomain=OpenLDAP.org))
- Search (18) [5]: dc=org@dc=OpenLDAP@ou=Groups@ou=User Groups
- Search subtree & ((cn=name)(associatedDomain=OpenLDAP.org))
+ Search (18) [5]: dc=com@dc=example@ou=Groups@ou=User Groups
+ Search subtree & ((cn=name)(associatedDomain=example.com))
Notice that when specifying a filter %s is replaced by the name,
or user portion of the address while %h is replaced by whatever is
You can also specify whether you want search results that matched
because the entry's RDN matched the search to be given preference
-or not. At U-M, we only give such preference in the mail group
+or not. We only give such preference in the mail group
portion of the searches. Beware with this option: the algorithm
used to decide whether an entry's RDN matched the search is very
simple-minded, and may not always be correct.
for each base. If you want more than that, simply changing the 3 in
the typedef for Base should do the trick.
-*** HOW IT WORKS (from the X.500 side): ***
+*** HOW IT WORKS (from the LDAP side): ***
-In X.500, there are several new attribute types and one new object
+In LDAP, there are several new attribute types and one new object
class defined that mail500 makes use of. At its most basic, for normal
entries mail500 will deliver to the value(s) listed in the
-rfc822Mailbox attribute of the entry. For example, at U-M my entry has
+rfc822Mailbox attribute of the entry. For example, an entry has
the attribute
- mail= tim@terminator.rs.itd.umich.edu
+ mail: user@example.com
-So mail sent to tim@umich.edu will be delivered via mail500 to that
+So mail sent to user@example.com will be delivered via mail500 to that
address. If there were multiple values for the mail attribute, multiple
copies of the mail would be sent.
been defined to handle email groups/mailing lists. To use this, you
will need to add this to your local oidtable.oc:
- # object class for representing rfc 822 mailgroups
+ # object class for representing RFC 822 mailgroups
rfc822MailGroup: umichObjectClass.2 : \
top : \
cn : \
requestsTo: umichAttributeType.31 : DN
The idea was to define a kind of hybrid mail group that could handle
-people who were in X.500 or not. So, for example, members of a group
-can be specified via the member attribute (for X.500 members) or the
-rfc822MailBox attribute (for non-X.500 members). Similarly for the
+people who were in LDAP or not. So, for example, members of a group
+can be specified via the member attribute (for LDAP members) or the
+rfc822MailBox attribute (for non-LDAP members). Similarly for the
errorsTo and rfc822ErrorsTo, and the requestsTo and rfc822RequestsTo
attributes.
do is create an rfc822MailGroup and fill in the errorsTo or
rfc822ErrorsTo attributes (or both). That will cause any errors
encountered when delivering mail to the group to go to the addresses
-listed (or X.500 entry via it's mail attribute).
+listed (or LDAP entry via it's mail attribute).
If you fill in the requestsTo or rfc822RequestsTo (or both) attributes,
mail sent to groupname-request will be sent to the addresses listed
} Base;
Base base[] = {
- {"ou=People, dc=OpenLDAP, dc=org",
+ {"ou=People, dc=example, dc=com",
0, USER,
{"uid=%s", "cn=%s", NULL}},
- {"ou=System Groups, ou=Groups, dc=OpenLDAP, dc=org",
+ {"ou=System Groups, ou=Groups, dc=example, dc=com",
1, 0xff,
{"(&(cn=%s)(associatedDomain=%h))", NULL, NULL}},
- {"ou=User Groups, ou=Groups, dc=OpenLDAP, dc=org",
+ {"ou=User Groups, ou=Groups, dc=example, dc=com",
1, 0xff,
{"(&(cn=%s)(associatedDomain=%h))", NULL, NULL}},
{NULL}
-LDAP rcpt500 mail query server README
+OpenLDAP rcpt500 mail query server README
OVERVIEW
-This is a mail-query server that answers X.500 white pages queries.
+
+This is a mail-query server that answers LDAP white pages queries.
It is designed to be run out of your mail systems alias file, or the
equivalent. It expects to be fed the entire contents (including
headers) of an RFC822 message via standard input. It parses the
The help command returns the contents of the file rcpt500.help. You
can modify the contents as appropriate for your local site.
-The query command performs a series of X.500 searches to try to find
+The query command performs a series of LDAP searches to try to find
a person that matches the object of the query. If more than one
X.500 entry matches, a list is returned. If exactly one is matched,
detailed information is returned. Here is an example message and rcpt500
generated reply:
Query message:
- Mail x500-query@umich.edu
+ Mail ldap-query@example.com
Subject: find tim howes
.
Reply from rcpt500:
- Message-Id: <199209161526.AA12041@umich.edu>
+ Message-Id: <199209161526.AA12041@example.com>
Date: Wed, 16 Sep 1992 11:26:17 -0400
- From: "X.500 Query Program" <X500-Query@umich.edu>
+ From: "LDAP Query Program" <ldap-query@example.com>
Subject: Re: find tim howes
In-Reply-To: Your message of "Wed, 16 Sep 1992 11:26:12 -0400"
- <199209161526.AA26144@terminator.cc.umich.edu>
- To: "Mark Smith" <mcs@terminator.cc.umich.edu>
+ <199209161526.AA26144@terminator.cc.example.com>
+ To: "Mark Smith" <mcs@terminator.cc.example.com>
One exact match was found for 'tim howes':
"Timothy A Howes, Information Technology Division, Faculty and Staff"
tim
If you want to try out rcpt500 yourself before installing it at your site,
-send a message to x500-query@umich.edu (we have a server running
+send a message to ldap-query@umich.edu (we have a server running
there that serves University of Michigan white pages information).
to that will feed the messages to rcpt500. At our site, we run sendmail
so the alias is in /usr/lib/aliases and looks like:
- x500-query: "|/usr/local/etc/rcpt500 -l"
+ ldap-query: "|/usr/local/etc/rcpt500 -l"
The available command line options for rcpt500 are:
-l enable logging of requests via the syslog
LOG_DAEMON facility
-h ldaphost specify LDAP server host to connect to
- -b searchbase specify starting point of X.500 searches
+ -b searchbase specify starting point of LDAP searches
-a don't deference aliases during searches
-s stripcount remove "stripcount" DN components from user
friendly form names that are displayed
-z sizelimit return at most "sizelimit" entries
- -u dapuser DN to bind to X.500 as when searching
+ -u dapuser DN to bind to LDAP as when searching
The search and display behavior is defined in the ldapfilter.conf and
ldaptemplates.conf files.
OpenLDAP-its@OpenLDAP.org
- Additional mailing lists are available. Please see:
+ Mailing lists are available. Please see:
http://www.OpenLDAP.com/lists/
-How to use the University of Michigan X.500 Email Query Service
+How to use the OpenLDAP LDAP Email Query Service
By sending electronic mail to the address:
- x500-query@umich.edu
+ ldap-query@example.com
-you can access the campus X.500 Directory. The Directory contains
+you can access the campus LDAP Directory. The Directory contains
information about all faculty, staff, and students of the University,
including phone numbers, mailing addresses, job titles, email
addresses, and more.
The following command:
.LP
.nf
- ldapdelete "cn=Delete Me, dc=OpenLDAP, dc=org"
+ ldapdelete "cn=Delete Me, dc=example, dc=com"
.fi
.LP
will attempt to delete the entry named with commonName "Delete Me"
-directly below the "dc=OpenLDAP, dc=org" entry. Of
+directly below the "dc=example, dc=com" entry. Of
course it would probably be necessary to supply a \fIbinddn\fP and
\fIpasswd\fP for deletion to be allowed (see the -D and -w options).
.SH DIAGNOSTICS
exists and has the contents:
.LP
.nf
- dn: cn=Modify Me, dc=OpenLDAP, dc=Org
+ dn: cn=Modify Me, dc=example, dc=com
changetype: modify
replace: mail
mail: modme@OpenLDAP.org
.LP
will replace the contents of the "Modify Me" entry's
.I mail
-attribute with the value "modme@OpenLDAP.org", add a
+attribute with the value "modme@example.com", add a
.I title
of "Grand Poobah", and the contents of the file "/tmp/modme.jpeg"
as a
attribute.
The same modifications as above can be performed using the older
.I ldapmodify
-inout format:
+input format:
.LP
.nf
- cn=Modify Me, dc=OpenLDAP, dc=org
- mail=modme@OpenLDAP.org
+ cn=Modify Me, dc=example, dc=com
+ mail=modme@example.com
+title=Grand Poobah
+jpegPhoto=/tmp/modme.jpeg
-description
exists and has the contents:
.LP
.nf
- dn: cn=Barbara Jensen, dc=OpenLDAP, dc=org
+ dn: cn=Barbara Jensen, dc=example, dc=com
objectClass: person
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
title: the world's most famous mythical manager
- mail: bjensen@OpenLDAP.org
+ mail: bjensen@example.com
uid: bjensen
.LP
the command:
exists and has the contents:
.LP
.nf
- dn: cn=Barbara Jensen, dc=OpenLDAP, dc=org
+ dn: cn=Barbara Jensen, dc=example, dc=com
changetype: delete
.LP
the command:
.LP
will remove Babs Jensen's entry.
.SH DIAGNOSTICS
-Exit status is 0 if no errors occur. Errors result in a non-zero exit
-status and a diagnostic message being written to standard error.
+Exit status is zero if no errors occur. Errors result in a non-zero
+exit status and a diagnostic message being written to standard error.
.SH "SEE ALSO"
.BR ldapadd (1),
.BR ldapdelete (1),
exists and has the contents:
.LP
.nf
- cn=Modify Me, dc=OpenLDAP, dc=org
+ cn=Modify Me, dc=example, dc=com
cn=The New Me
.fi
.LP
It should be a string-represented Distringuished Name. E.g.,
.nf
.ft B
- "dc=OpenLDAP, dc=org"
+ "dc=example, dc=com"
.ft
.fi
.LP
#
# default location when adding new entries (DN; "" means no default)
- "dc=OpenLDAP, dc=Org"
+ "dc=example, dc=com"
#
# rules used to define default values for new entries
.LP
.nf
.ft tt
- dn: cn=Barbara J Jensen, dc=Open
- LDAP, dc=org
+ dn: cn=Barbara J Jensen, dc=exam
+ ple, dc=com
.ft
.fi
.LP
.LP
.nf
.ft tt
- dn: cn=Barbara J Jensen, dc=OpenLDAP, dc=Org
+ dn: cn=Barbara J Jensen, dc=example, dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectclass: person
description:< file://tmp/babs
sn: Jensen
- dn: cn=Bjorn J Jensen, dc=OpenLDAP, dc=Org
+ dn: cn=Bjorn J Jensen, dc=example, dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectclass: person
sn: Jensen
- dn: cn=Jennifer J Jensen, dc=OpenLDAP, dc=Org
+ dn: cn=Jennifer J Jensen, dc=example, dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectclass: person
Specify the maximum number of entries to return from a search operation.
The default size limit is 500.
.TP
+.B sasl-realm <realm>
+Specify SASL realm. Default is empty.
+.TP
+.B sasl-secprops <props>
+Cyrus SASL security properties. Default is "noanonymous,noplain".
+.TP
.B srvtab <filename>
Specify the srvtab file in which the kerberos keys necessary for
authenticating clients using kerberos can be found. This option is only
## COPYING RESTRICTIONS APPLY, see COPYRIGHT file
database shell
-suffix "dc=openldap,dc=org"
+suffix "dc=example,dc=com"
search /usr/local/etc/searchexample.sh
slap_tool_init( "slapadd", SLAPADD, argc, argv );
- if( !be->be_entry_open &&
- !be->be_entry_close &&
+ if( !be->be_entry_open ||
+ !be->be_entry_close ||
!be->be_entry_put )
{
fprintf( stderr, "%s: database doesn't support necessary operations.\n",
slap_tool_init( "slapcat", SLAPCAT, argc, argv );
- if( !be->be_entry_open &&
- !be->be_entry_close &&
- !be->be_entry_first &&
- !be->be_entry_next &&
+ if( !be->be_entry_open ||
+ !be->be_entry_close ||
+ !be->be_entry_first ||
+ !be->be_entry_next ||
!be->be_entry_get )
{
fprintf( stderr, "%s: database doesn't support necessary operations.\n",
NULL, ri->ri_authcId, NULL, NULL );
ldrc = ldap_sasl_interactive_bind_s( ri->ri_ldp, ri->ri_bind_dn,
ri->ri_saslmech, NULL, NULL,
- LDAP_SASL_AUTOMATIC, lutil_sasl_interact, defaults );
+ LDAP_SASL_QUIET, lutil_sasl_interact, defaults );
if ( ldrc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY, "Error: LDAP SASL for %s:%d failed: %s\n",
ri->ri_hostname, ri->ri_port, ldap_err2string( ldrc ));
projects / openldap / commitdiff