NAME
slapd-tcl - Tcl backend to slapd
SYNOPSIS
/etc/openldap/slapd.confDESCRIPTION
The Tcl backend to ssllaappdd(8) works by embedding a TTccll(3tcl) interpreter into ssllaappdd(8). Any tcl database section of the configuration file ssllaappdd..ccoonnff(5) must then specify what Tcl script to use. This backend is experimental. WWAARRNNIINNGG TThhiiss bbaacckkeenndd''ss ccaalllliinngg ccoonnvveennttiioonnss hhaavvee cchhaannggeedd ssiinnccee OOppeennLLDDAAPP 22..00.. Previously, the 2nd argument to the procs was a message ID. Now theyare an "operation ID" string. Also, proc abandon now gets a new aabbaann-
ddoonniidd argument. CCOONNFFIIGGUURRAATTIIOONN These ssllaappdd..ccoonnff options apply to the TCL backend database. That is, they must follow a "database tcl" line and come before any subsequent "backend" or "database" lines. Other database options are described in the ssllaappdd..ccoonnff(5) manual page. ssccrriippttppaatthh <> The full path to the tcl script used for this database. sseeaarrcchh < > aadddd < > ddeelleettee < > mmooddiiffyy < > bbiinndd < > uunnbbiinndd < > mmooddrrddnn < > ccoommppaarree < > aabbaannddoonn < > The procs for each ldap function. They refer to the tcl procs in the `scriptpath' script that handles them. ttccllrreeaallmm < > This is one of the biggest pluses of using the tcl backend. The realm lets you group several databases to the same interpreter. This basically means they share the same global variables and proc space. So global variables, as well as all the procs, are callable between databases. If no tclrealm is specified, it is put into the "default" realm. VVaarriiaabblleess ppaasssseedd ttoo tthhee pprrooccss aabbaannddoonn {{ aaccttiioonn ooppiidd ssuuffffiixx aabbaannddoonniidd }} action - Always equal to ABANDON.
opid - The opid of this ldap operation.
suffix - List of suffix(es) associated with the
call. Each one is an entry in a tcl formatted list (surrounded by {}'s).abandonid - The opid of the operation to abandon.
aadddd {{ aaccttiioonn ooppiidd ssuuffffiixx eennttrryy }}action - Always equal to ADD.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
entry - Full entry to add. Each "type: val" is
an element in a tcl formatted list. bbiinndd {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn mmeetthhoodd ccrreeddlleenn ccrreedd }}action - Always equal to BIND.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN being bound to.
method - One of the ldap authentication methods.
credlen - Length of cred.
cred - Credentials being used to authenticate,
according to RFC. If this value is empty, then it should be considered an anonymous bind (??) ccoommppaarree {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn aavvaattyyppee aavvaavvaalluuee }}action - Always equal to COMPARE.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN for compare.
avatype - Type for comparison.
avavalue - Value to compare.
ddeelleettee {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn }}action - Always equal to DELETE.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN to delete.
mmooddiiffyy {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn mmooddss }}action - Always equal to MODIFY.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN to modify.
mods - Tcl list of modifications.
The list is formatted in this way: { { {op: type} {type: val} } { {op: type} {type: val} {type: val} } ... } Newlines are not present in the actual var, they are present here for clarification. "op" is the type of modification (ADD, DELETE, REPLACE). mmooddrrddnn {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn nneewwrrddnn ddeelleetteeoollddrrddnn }}action - Always equal to MODRDN.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN whose RDN is being renamed.
newrdn - New RDN.
deleteoldrdn - Boolean stating whether or not the
old RDN should be removed after being renamed.sseeaarrcchh {{ aaccttiioonn ooppiidd ssuuffffiixx bbaassee ssccooppee ddeerreeff ssiizzeelliimmiitt ttiimmeelliimmiitt ffiill-
tteerrssttrr aattttrrssoonnllyy aattttrrlliisstt }}action - Always equal to SEARCH.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
base - Base for this search.
scope - Scope of search, ( 0 | 1 | 2 ).
deref - Alias dereferencing ( 0 | 1 | 2 | 3 ).
sizelimit - Maximum number of entries to return.
timelimit - Time limit for search.
filterstr - Filter string as sent by the requester.
attrsonly - Boolean for whether to list only the
attributes, and not values as well.attrlist - Tcl list if to retrieve.
uunnbbiinndd {{ aaccttiioonn ooppiidd ssuuffffiixx ddnn }}action - Always equal to UNBIND.
opid - The opid of this ldap operation.
suffix - List of suffix(es), as above.
dn - DN to unbind.
An opid (operation ID) is a "connection ID/message ID" string identify-
ing an operation. Return Method and Syntax There are only 2 return types. All procs must return a result to show status of the operation. The result is in this form: { RESULT {code:} {matched: } {info: } {} } This is best accomplished with this type of tcl code lappend retval "RESULT" lappend retval "code: 0" lappend retval "" return $retval
The final empty string (item in list) is necessary to point to the end of list. The `code', `matched', and `info' values are not necessary, and default values are given if not specified. The `code' value is usually an LDAP error in decimal notation from ldap.h. The `info', may be sent back to the client, depending on the function. In the bind proc, LDAP uses the value of `code' to indicate whether or not the authentication is acceptable. The other type of return is for searches. It is similar format to theshell backend return (as is most of the syntax here). Its format fol-
lows: {dn: o=Company, c=US} {attr: val} {objectclass: val} {} {dn: o=CompanyB, c=US} {attr: val} {objectclass: val} {} Again, newlines are for visual purposes here. Also note the {} marking the end of the entry (same effect as a newline in ldif format). Here is some example code again, showing a full search proc example.# Note that `args' lets you lump all possible args
# into one var, used here for simplicity of example
proc ldap:search { args } {# ...perform some operations...
lappend retval "dn: $rdn,$base"
lappend retval "objectclass: $objcl"
lappend retval "sn: $rdn"
lappend retval "mail: $email"
lappend retval ""# Now setup the result
lappend retval "RESULT" lappend retval "code: 0" lappend retval ""return $retval
}NOTE: Newlines in the return value is acceptable in search entries
(i.e. when returning base64 encoded binary entries). BBuuiillttiinn CCoommmmaannddss aanndd VVaarriiaabblleess llddaapp::ddeebbuugg <> Allows you to send debug messages through OpenLDAP's native debugging system, this is sent as a LDAPDEBUGANY and will be logged. Useful for debugging scripts or logging bind failures. FILES /etc/openldap/slapd.conf default slapd configuration file SEE ALSO
ssllaappdd..ccoonnff(5), ssllaappdd(8), TTccll(3tcl).OpenLDAP 2.2.19 2004/11/26 SLAPD-TCL(5)