mirror of https://github.com/OpenIdentityPlatform/OpenDJ.git
opendj3/src/main/docbkx/admin-guide/chap-admin-tools.xml
@@ -114,9 +114,9 @@ <term>Schema</term> <listitem> <para>The Manage Schema window lets you browse and modify the rules that define how data is stored in the directory. You can modify the schema while the server is running, and the changes you make take effect immediately.</para> that define how data is stored in the directory. You can add new schema definitions such as new attribute types and new object classes while the server is running, and the changes you make take effect immediately.</para> </listitem> </varlistentry> <varlistentry> @@ -170,8 +170,9 @@ JVM.</para> <itemizedlist> <para>Setup, upgrade, and uninstall tools are located in the OpenDJ directory. Find the additional command-line tools for your platform.</para> <para>Setup, upgrade, and uninstall tools are located in the directory where you unpacked OpenDJ, such as <filename>/path/to/OpenDJ</filename>. Find the additional command-line tools for your platform.</para> <listitem> <para>(UNIX) In OpenDJ/bin.</para> </listitem> @@ -183,6 +184,10 @@ <para>The following list uses the UNIX names for the tools. On Windows all command-line tools have the extension .bat.</para> <!-- TODO: Add olinks for all tools at least to the reference documentation and perhaps also to the Admin Guide chapters that show how the tools are used. For example, the ldap* tools could have links into chap-ldap-operations. --> <variablelist> <varlistentry> <term>backup</term> opendj3/src/main/docbkx/admin-guide/chap-ldap-operations.xml
@@ -83,7 +83,16 @@ certificate. Finally, you can specify a list of attributes to return. If you do not specify attributes, then the search returns all user attributes for the entry.</para> <itemizedlist> <para>Review the following examples in this section to get a sense of how searches work.</para> <listitem><para><xref linkend="simple-filter-search"/></para></listitem> <listitem><para><xref linkend="complex-filter-search"/></para></listitem> <listitem><para><xref linkend="operational-attrs-search"/></para></listitem> <listitem><para><xref linkend="attr-desc-list-search"/></para></listitem> </itemizedlist> <example xml:id="simple-filter-search"> <title>Search: Simple Filter</title> @@ -170,6 +179,11 @@ sn: Jensen </screen> <para>Complex filters can use both "and" syntax, <literal>(&(<replaceable>filtercomp</replaceable>)(<replaceable>filtercomp</replaceable>))</literal>, and "or" syntax, <literal>(|(<replaceable>filtercomp</replaceable>)(<replaceable>filtercomp</replaceable>))</literal>.</para> </example> <example xml:id="operational-attrs-search"> @@ -224,12 +238,12 @@ <para>In this example, Kirsten Vaughan checks whether the hashed password value matches the stored value on <literal>authPassword</literal>.</para> <screen>$ ldapcompare <screen>$ <userinput>ldapcompare --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery 'authPassword:MD5$dFHgpDxXUT8=$qlC4xMXvmVlusJLz9/WJ5Q==' uid=kvaughan,ou=people,dc=example,dc=com uid=kvaughan,ou=people,dc=example,dc=com</userinput> Comparing type authPassword with value MD5$dFHgpDxXUT8=$qlC4xMXvmVlusJLz9/WJ5Q== in entry uid=kvaughan,ou=people,dc=example,dc=com @@ -513,8 +527,11 @@ <para>Sam Carter is changing her last name to Jensen, and changing her login from <literal>scarter</literal> to <literal>sjensen</literal>. The following example renames and changes Sam Carter's entry accordingly.</para> The following example renames and changes Sam Carter's entry accordingly. Notice the boolean field, <literal>deleteoldrdn: 1</literal>, which indicates that the previous RDN, <literal>uid: scarter</literal>, should be removed. (Setting <literal>deleteoldrdn: 0</literal> instead would preserve <literal>uid: scarter</literal> on the entry.)</para> <screen>$ cat /path/to/scarter-sjensen.ldif dn: uid=scarter,ou=people,dc=example,dc=com @@ -573,7 +590,11 @@ employee under <literal>ou=Employees,dc=example,dc=com</literal> under <literal>ou=People,dc=example,dc=com</literal> as well, finally removing the empty <literal>ou=Employees,dc=example,dc=com</literal> container.</para> container. Here, <literal>deleteoldrdn: 1</literal> indicates that the old RDN, <literal>ou: Customers</literal>, should be removed from the entry. For employees, <literal>deleteoldrdn: 0</literal> indicates that old RDNs, in this case <literal>uid</literal> attribute values, should be preserved.</para> <screen>$ cat move-customers.ldif dn: ou=Customers,dc=example,dc=com opendj3/src/main/docbkx/admin-guide/chap-server-process.xml
@@ -153,8 +153,25 @@ few entries in a transaction log. Generally OpenDJ returns to service quickly.</para> <para>You can find Berkeley Java Edition database recovery messages in the database log file, such as <filename>/path/to/OpenDJ/db/userRoot/je.info.0</filename>. The following shows two example messages from that log, the first written at the beginning of the recovery process, the second written at the end of the process.</para> <screen>111104 10:23:48:967 CONFIG [/path/to/OpenDJ/db/userRoot]Recovery underway, found end of log ... 111104 10:23:49:015 CONFIG [/path/to/OpenDJ/db/userRoot]Recovery finished: Recovery Info ...</screen> <para>What can take some time during server startup is preloading database content into memory when the server starts. Objects cached in memory do not survive a crash.</para> survive a crash. By default, OpenDJ does not cache objects in memory before starting to accept client requests. You can however set a <literal>preload-time-limit</literal> for the database cache of your backend if you do want to load objects into the database cache before OpenDJ begins accepting client connections.</para> <!-- TODO: Add olink to preload-time-limit in config ref. --> </section> </chapter>
