LDIF (LDAP data interchange format), defined in rfc2849, lines may be folded by inserting a line-separator character and a space, except between bytes of a multi-byte UTF-8 character:
ldapsearch --port 11389 \ --bindDn cn=RootDn \ --bindPassword password \ --baseDn uid=user.0,ou=people,o=training '(&)' description dn: uid=user.0,ou=People,o=training description: trdrrlpmyyvydmyufhiolxmymkukhstjqdjdatbfbjfatanrihdaxffitkmkppuwcmj ihurisjundxbuobkjonekajhqiosmxibbwpxpcctyhahyqbzrnbhchzlzofezmufxvukevmcmwevsqy rhoxtenvqdkywcwryerwucfkudyiaadfmoldcwretzwiqfqdtyuhihdnncxfjyfyxfjqtwwfhkxqtxe pvpejrvwkrwymkfwjupsfksktarwhqkbdlercyuytwiwswwinqeavxzfrpkevdmmbnwxzxoxxjwihyl oznzkbfaveyuxuevnnjmqvmynxhvulrwfeadzvdwfamttqknnzfmtvuqkacmvdisnyzsinvawaxxkbz sielcckfwlifvifssttzekvxcijfdeseruzbyvujrxmpeowfvceevaxowtqaehyynusxtorqokhoqmz abijlebckmsiykcizvfeftyuqzktvkoqxlqvffzqawlrwmzzkcdxaqtfmknbotwonkzbwmimwmxpoam wtcujxuurikkdkjqhkzzkzrptewrqrnnoilkvbuvbxwcpvxjtrloctkqetyfebmpefzklnqibotvxsr waeoclszymenimcwsdybhdyyqovmrwtketcqqrrtixocykthdcbdnvikhlfphodhqmfhyymtevokcll ztabwjqssqlwfvaedsdxjcbzllhbtzvkjfpvdbdsfhtlzwrvubwrbfifldzylieufkfxubituebpmia ryyszorewfnyuaicfqkfdrufdssuuxmkdhttytoibntfrcszcxztdnnuaxqfkobchqkmwihlywfdbub wmzaqrkrwcxmvuxmmbhnkpfuwuasfixsufmqhuvlcmdhikysudclotfcipdkxpijkbpaukmrrbkdskb eeonaeqknszfsnscfcfoixuqivbxudmdfjyutdnqamhhhmolmklldkjanhmykshflpljtmozkvcvdmj psmbojuzp
Use the --dontWrap command-line option to ldapsearch to prevent the lines from being folded:
ldapsearch --port 11389 \
--bindDn cn=RootDn \
--bindPassword password \
--baseDn uid=user.0,ou=people,o=training \
--dontWrap '(&)' description
dn: uid=user.0,ou=People,o=training
description: trdrrlpmyyvydmyufhiolxmymkukhstjqdjdatbfbjf ...
The same thing can be accomplished with the legacy Solaris ldapsearch tool by using the '-T' command line option. The legacy OpenLDAP ldapsearch tool had a '-r' for the same purpose, but that seems to have gone away.
LDAP-compliant servers support an extensible-match filter which provides the necessary
filtering. From RFC4511:
If the dnAttributes field is set to TRUE, the match is additionally applied against all the AttributeValueAssertions in an entry's distinguished name, and it evaluates to TRUE if there is at least one attribute or subtype in the distinguished name for which the filter item evaluates to TRUE. The dnAttributes field is present to alleviate the need for multiple versions of generic matching rules (such as word matching), where one applies to entries and another applies to entries and DN attributes as well.
For example, I added the following entries to a server:
dn: ou=legacy groups,o=training
objectClass: top
objectClass: organizationalUnit
ou: legacy groups
dn: ou=common groups,o=training
objectClass: top
objectClass: organizationalUnit
ou: common groups
dn: ou=groups,o=training
objectClass: top
objectClass: organizationalUnit
ou: groups
dn: cn=a,ou=common groups,o=training
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: uid=user.0,ou=people,o=training
cn: a
dn: cn=b,ou=groups,o=training
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: uid=user.0,ou=people,o=training
cn: b
dn: cn=c,ou=legacy groups,o=training
objectClass: top
objectClass: groupOfUniqueNames
uniqueMember: uid=user.0,ou=people,o=training
cn: c
Examine the filter in the following search after the above entries were added:
ldapsearch --propertiesFilePath ds-setup/11389/ldap-connection.properties \
--baseDN o=training \
--searchScope sub '(|(ou:dn:=groups)(ou:dn:=common groups))' 1.1
dn: ou=common groups,o=training
dn: cn=a,ou=common groups,o=training
dn: ou=groups,o=training
dn: cn=b,ou=groups,o=training
Note that ou=common groups, ou=groups, and their subordinates are returned, but not
ou=legacy groups and subordinates.
This example uses the modern syntax of the ldapsearch command line tool. If the user is
utilizing the legacy OpenLDAP version of ldapsearch, the parameters to the command line tool are
somewhat different, but that does not matter. What matters is the filter.
see also
The ldap-diff utility provides a way to compare the data stored in two directory server
databases. The ldap-diff command-line tool is shipped with the UnboundID Directory Server.
Following is an example of executing the utility in my lab on two servers which replicate
between each other containing 10008 entries:
$ ldap-diff --sourceHost lab.example.com \
--sourcePort 11389 \
--sourceBindDn cn=RootDn \
--sourceBindPasswordFile ./.pwdFile \
--sourceDnsFile /ds/servers/dn.list.txt \
--targetHost lab.example.com \
--targetPort 12389 \
--targetBindDn cn=RootDn \
--targetBindPasswordFile /ds/servers/.pwdFile \
--baseDn dc=example,dc=com -o diff.ldif \
--numConnections 64 \
--numPasses 1 \
--secondsBetweenPass 1
[13:06:08] Starting to read DNs from /ds/servers/dn.list.txt \
(under base DN dc=example,dc=com)
[13:06:08] Starting to dump DNs from server \
ldap://lab.example.com:12389 under base DN \
dc=example,dc=com matching filter (objectclass=*)
[13:06:08] Found 10008 entries at server \
ldap://lab.example.com:11389 that matched the specified criteria
[13:06:08] Found 10008 entries at server \
ldap://lab.example.com:12389 that matched the specified criteria
[13:06:08] Starting pass 1 of 1. Comparing 10008 entries out of a total of 10008
[13:06:09] Completed pass 1 of 1. Compared 10008 entries. \
10008 were identical, 0 were out-of-sync, and 0 no longer exist on either server
[13:06:09] Completed all passes. All 10008\
entries were identical on both servers
characters that are permitted in attribute names
Attribute types are object identifiers, and attribute names are known as “descriptors” (short names to assist humans). The only characters that are permitted in attribute names are ALPHA, DIGIT, and HYPHEN (‘-’). Underscores ‘_’ are not permitted. When an unambiguous descriptor (attribute name) is not available, LDAP clients should use the numeric OID. When descriptors are treated as ambiguous, LDAP servers should treat them as unrecognized.
things to remember
- attribute names are called ‘descriptors’
- only
A-Z,a-z,0-9, and hyphen ‘-’ can be used in a descriptor, and the descriptor must begin with an ALPHA character - the characters in attribute names are not case-sensitive
commonNameis a valid descriptorcommon_nameis not a valid descriptorcommon-nameis a valid descriptor2sexyForMyShoesis not a valid descriptor
references
Alert Handlers
The UnboundID Directory Server provides a mechanism to send alert notifications to Alert Handlers when certain events transpire during Directory Server processing. The server is shipped with useful Alert Handlers such as, but not limited to, an error logging alert handler, JMX alert handler, and SMTP alert handler.
Some examples of administrative alerts are:
access-control-changewhen access control configuration has been changedconfig-changewhen a configuration item has been changedserver-startingwhen the server is beginning the start up cycleserver-shutting-downwhen the server starts the shutdown cyclelow-disk-space-warningwhen the amount of usable disk has dropped below a threshold
and many others.
Custom Alert Handlers
The UnboundID Server SDK makes it possible to create a custom alert handler and make it available to the server. I have seen some environments where IRC (Internet Relay Chat) is used by operations departments to exchange information about operational status, so I decided to write a custom alert handler that transmits alerts to an IRC server.
To create a custom Alert Handler, override the
public void handleAlert(AlertNotification alertNotification) { }
method.
When the Alert Handler is complete, make code (jar file) available to the server and create
the alert handler with the dsconfig command line tool:
$ cp irc-alert-handler.jar ${directoryServerRoot}/lib/extensions
$ dsconfig create-alert-handler \
--handler-name "IRC Alert Handler" \
--type third-party \
--set enabled:true \
--set extension-class:com.unboundid.services.alerts.irc.IrcAlertHandler \
--set extension-argument:hostname=irc.freenode.net \
--set "extension-argument:channel=#slamd" \
--set extension-argument:nick=adm-alerts \
--set extension-argument:port=6667
The dsconfig command above configured the irc-alert-handler to connect to irc.freenode.net on port 6667, use nick "adm-alerts"
and join channel #slamd. Alerts appear in the specified channel.
The screenshot below shows the result of making a configuration change, rebuilding an
index, and shutting down the server. The IRC Alert Handler transmits a message to the IRC server for each administrative alert.
