Author: paul
Date: 2006-01-29 00:47:56 +0100 (Sun, 29 Jan 2006)
New Revision: 1092
Log:
r6831@frost: paul | 2006-01-28 17:35:24 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/renamed-nodes.txt
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/renamed-nodes.txt
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/renamed-nodes.txt
trunk/refman-5.1/sql-syntax.xml
trunk/refman-common/titles.en.ent
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6830
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6831
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-4.1/database-administration.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -14430,8 +14430,27 @@
<listitem>
<para>
- MySQL usernames can be up to 16 characters long. Operating
- system usernames might have a different maximum length. For
+ MySQL usernames can be up to a maximum of 16 characters
+ long. This limit is hard-coded in the MySQL servers and
+ clients, and trying to circumvent it by modifying the
+ definitions of the tables in the <literal>mysql</literal>
+ database <emphasis>does not work</emphasis>.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: <emphasis>You should
+ never alter any of the tables in the
+ <literal>mysql</literal> database in any manner whatsoever
+ except by means of the procedure prescribed by MySQL AB that
+ is described in
+ <xref linkend="mysql-fix-privilege-tables"/>. Attempting to
+ redefine MySQL's system tables in any other fashion results
+ in undefined (and unsupported!) behavior</emphasis>.
+ </para>
+
+ <para>
+ Operating system usernames are completely unrelated to MySQL
+ usernames and may even be of a different maximum length. For
example, Unix usernames typically are limited to eight
characters.
</para>
@@ -14492,10 +14511,9 @@
privileges that are described in
<xref linkend="default-privileges"/>, which also discusses how
to assign passwords to them. Thereafter, you normally set up,
- modify, and remove MySQL accounts using the
- <literal>GRANT</literal> and <literal>REVOKE</literal>
- statements. See <xref linkend="grant"/>, and
- <xref linkend="revoke"/>.
+ modify, and remove MySQL accounts using statements such as
+ <literal>GRANT</literal> and <literal>REVOKE</literal>. See
+ <xref linkend="account-management-sql"/>.
</para>
<para>
@@ -14525,9 +14543,9 @@
<para>
The preceding commands include the password value on the command
line, which can be a security risk. See
- <xref linkend="password-security"/>. To avoid this, specify the
- <option>--password</option> or <option>-p</option> option
- without any following password value:
+ <xref linkend="password-security"/>. To avoid this problem,
+ specify the <option>--password</option> or <option>-p</option>
+ option without any following password value:
</para>
<programlisting>
@@ -14536,16 +14554,16 @@
</programlisting>
<para>
- Then the client program prints a prompt and waits for you to
- enter the password. (In these examples,
- <replaceable>db_name</replaceable> is <emphasis>not</emphasis>
- interpreted as a password, because it is separated from the
- preceding password option by a space.)
+ When the password option has no password value, the client
+ program prints a prompt and waits for you to enter the password.
+ (In these examples, <replaceable>db_name</replaceable> is
+ <emphasis>not</emphasis> interpreted as a password because it is
+ separated from the preceding password option by a space.)
</para>
<para>
- On some systems, the library call that MySQL uses to prompt for
- a password automatically limits the password to eight
+ On some systems, the library routine that MySQL uses to prompt
+ for a password automatically limits the password to eight
characters. That is a problem with the system library, not with
MySQL. Internally, MySQL does not have any limit for the length
of the password. To work around the problem, change your MySQL
@@ -14607,7 +14625,9 @@
<listitem>
<para>
- By manipulating the MySQL grant tables directly
+ By manipulating the MySQL grant tables directly with
+ statements such as <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, or <literal>DELETE</literal>
</para>
</listitem>
@@ -14616,8 +14636,8 @@
<para>
The preferred method is to use <literal>GRANT</literal>
statements, because they are more concise and less error-prone.
- <literal>GRANT</literal> is available as of MySQL 3.22.11; its
- syntax is described in <xref linkend="grant"/>.
+ <literal>GRANT</literal> is described in
+ <xref linkend="grant"/>.
</para>
<para>
@@ -14922,9 +14942,9 @@
for the <literal>bankaccount</literal>,
<literal>expenses</literal>, and <literal>customer</literal>
databases, but only when accessed from the proper hosts. As
- usual when you modify the grant tables directly, you tell the
- server to reload them with <literal>FLUSH PRIVILEGES</literal>
- so that the privilege changes take effect.
+ usual when you modify the grant tables directly, you must tell
+ the server to reload them with <literal>FLUSH
+ PRIVILEGES</literal> so that the privilege changes take effect.
</para>
<para>
@@ -15256,10 +15276,10 @@
</programlisting>
<para>
- Only users such as <literal>root</literal> with update access to
- the <literal>mysql</literal> database can change the password
- for other users. If you are not connected as an anonymous user,
- you can change your own password by omitting the
+ Only users such as <literal>root</literal> that have update
+ access to the <literal>mysql</literal> database can change the
+ password for other users. If you are not connected as an
+ anonymous user, you can change your own password by omitting the
<literal>FOR</literal> clause:
</para>
@@ -15318,15 +15338,14 @@
</itemizedlist>
<para>
- When you assign an account a password using <literal>SET
- PASSWORD</literal>, <literal>INSERT</literal>, or
+ When you assign an account a non-empty password using
+ <literal>SET PASSWORD</literal>, <literal>INSERT</literal>, or
<literal>UPDATE</literal>, you must use the
- <literal>PASSWORD()</literal> function to encrypt it. (The only
- exception is that you need not use <literal>PASSWORD()</literal>
- if the password is empty.) <literal>PASSWORD()</literal> is
- necessary because the <literal>user</literal> table stores
- passwords in encrypted form, not as plaintext. If you forget
- that fact, you are likely to set passwords like this:
+ <literal>PASSWORD()</literal> function to encrypt it.
+ <literal>PASSWORD()</literal> is necessary because the
+ <literal>user</literal> table stores passwords in encrypted
+ form, not as plaintext. If you forget that fact, you are likely
+ to set passwords like this:
</para>
<programlisting>
@@ -15367,7 +15386,7 @@
</programlisting>
<para>
- If you set passwords using the <literal>GRANT ... IDENTIFIED
+ If you assign passwords using the <literal>GRANT ... IDENTIFIED
BY</literal> statement or the <command>mysqladmin
password</command> command, they both take care of encrypting
the password for you. The <literal>PASSWORD()</literal> function
@@ -15395,7 +15414,7 @@
<para>
On an administrative level, you should never grant access to the
- <literal>mysql.user</literal> table to any non-administrative
+ <literal>user</literal> grant table to any non-administrative
accounts. Passwords in the <literal>user</literal> table are
stored in encrypted form, but in versions of MySQL earlier than
4.1, knowing the encrypted password for an account makes it
@@ -15643,44 +15662,48 @@
<para>
If you need more information about SSL, X509, or encryption,
- use your favorite Internet search engine to search for
+ use your favorite Internet search engine to search for the
keywords in which you are interested.
</para>
</section>
- <section id="secure-requirements">
+ <section id="secure-using-openssl">
- <title>&title-secure-requirements;</title>
+ <title>&title-secure-using-openssl;</title>
<para>
To use SSL connections between the MySQL server and client
- programs, your system must be able to support OpenSSL and your
- version of MySQL must be 4.0.0 or newer.
+ programs, your system must support OpenSSL and your version of
+ MySQL must be 4.0.0 or newer.
</para>
<para>
- To get secure connections to work with MySQL, you must do the
- following:
+ To get secure connections to work with MySQL and OpenSSL, you
+ must do the following:
</para>
<orderedlist>
<listitem>
<para>
- Install the OpenSSL library. We have tested MySQL with
- OpenSSL 0.9.6. If you need OpenSSL, visit
- <ulink url="http://www.openssl.org"/>.
+ Install the OpenSSL library if it has not already been
+ installed. We have tested MySQL with OpenSSL 0.9.6. If you
+ need OpenSSL, visit <ulink url="http://www.openssl.org"/>.
</para>
</listitem>
<listitem>
<para>
- When you configure MySQL, run the
+ When you configure MySQL, invoke the
<command>configure</command> script with the
<option>--with-vio</option> and
- <option>--with-openssl</option> options.
+ <option>--with-openssl</option> options:
</para>
+
+<programlisting>
+shell> <userinput>./configure --with-vio --with-openssl</userinput>
+</programlisting>
</listitem>
<listitem>
@@ -16172,8 +16195,8 @@
</orderedlist>
<para>
- You should now have an ODBC connection to MySQL, encrypted
- using SSH.
+ At this point, you should have an ODBC connection to MySQL,
+ encrypted using SSH.
</para>
</section>
@@ -17083,8 +17106,8 @@
<command>myisamchk</command> operations that affect indexes can
cause <literal>FULLTEXT</literal> indexes to be rebuilt with
full-text parameters that are incompatible with the values used
- by the MySQL server. To avoid this, read the instructions in
- <xref linkend="myisamchk-general-options"/>.
+ by the MySQL server. To avoid this problem, read the
+ instructions in <xref linkend="myisamchk-general-options"/>.
</para>
<para>
@@ -17886,8 +17909,8 @@
<para>
Because we have not had any unexpectedly crashed tables
(tables that become corrupted for reasons other than hardware
- trouble) for a couple of years (this is really true), once a
- week is more than enough for us.
+ trouble) for several years, once a week is more than
+ sufficient for us.
</para>
<para>
Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-4.1/renamed-nodes.txt 2006-01-28 23:47:56 UTC (rev 1092)
@@ -110,3 +110,4 @@
server-side-scripts server-side-overview
upgrading-grant-tables mysql-fix-privilege-tables
secure-grant grant
+secure-requirements secure-using-openssl
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-4.1/sql-syntax.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -10852,7 +10852,8 @@
<literal>mysql.user</literal> table, and attempting to do so
results in unpredictable behavior which may even make it
impossible for users to log in to the MySQL server</emphasis>.
- You should never attempt to alter the grant tables in any way
+ You should never alter any of the tables in the
+ <literal>mysql</literal> database in any manner whatsoever
except by means of the procedure prescribed by MySQL AB that
is described in <xref linkend="mysql-fix-privilege-tables"/>.
</para>
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.0/database-administration.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -15393,9 +15393,9 @@
when you specify a password using the
<literal>GRANT</literal> or (beginning with MySQL 5.0.2)
<literal>CREATE USER</literal> statements, or the
- <command>mysqladmin password</command> command. Each of those
- automatically uses <literal>PASSWORD()</literal> to encrypt
- the password. See <xref linkend="passwords"/>, and
+ <command>mysqladmin password</command> command. Each of
+ those automatically uses <literal>PASSWORD()</literal> to
+ encrypt the password. See <xref linkend="passwords"/>, and
<xref linkend="create-user"/>.
</para>
</listitem>
@@ -16553,10 +16553,11 @@
<emphasis role="bold">Note</emphasis>: <emphasis>You should
never alter any of the tables in the
<literal>mysql</literal> database in any manner whatsoever
- except by running the scripts supplied expressly for this
- purpose with the MySQL distribution. Attempting to redefine
- MySQL's system tables in any other fashion results in
- undefined (and unsupported!) behavior</emphasis>.
+ except by means of the procedure prescribed by MySQL AB that
+ is described in
+ <xref linkend="mysql-fix-privilege-tables"/>. Attempting to
+ redefine MySQL's system tables in any other fashion results
+ in undefined (and unsupported!) behavior</emphasis>.
</para>
<para>
@@ -16608,10 +16609,9 @@
privileges that are described in
<xref linkend="default-privileges"/>, which also discusses how
to assign passwords to them. Thereafter, you normally set up,
- modify, and remove MySQL accounts using the
- <literal>GRANT</literal> and <literal>REVOKE</literal>
- statements. See <xref linkend="grant"/>, and
- <xref linkend="revoke"/>.
+ modify, and remove MySQL accounts using statements such as
+ <literal>GRANT</literal> and <literal>REVOKE</literal>. See
+ <xref linkend="account-management-sql"/>.
</para>
<para>
@@ -16641,9 +16641,9 @@
<para>
The preceding commands include the password value on the command
line, which can be a security risk. See
- <xref linkend="password-security"/>. To avoid this, specify the
- <option>--password</option> or <option>-p</option> option
- without any following password value:
+ <xref linkend="password-security"/>. To avoid this problem,
+ specify the <option>--password</option> or <option>-p</option>
+ option without any following password value:
</para>
<programlisting>
@@ -16652,11 +16652,11 @@
</programlisting>
<para>
- Then the client program prints a prompt and waits for you to
- enter the password. (In these examples,
- <replaceable>db_name</replaceable> is <emphasis>not</emphasis>
- interpreted as a password, because it is separated from the
- preceding password option by a space.)
+ When the password option has no password value, the client
+ program prints a prompt and waits for you to enter the password.
+ (In these examples, <replaceable>db_name</replaceable> is
+ <emphasis>not</emphasis> interpreted as a password because it is
+ separated from the preceding password option by a space.)
</para>
<remark role="todo">
@@ -16664,8 +16664,8 @@
</remark>
<para>
- On some systems, the library call that MySQL uses to prompt for
- a password automatically limits the password to eight
+ On some systems, the library routine that MySQL uses to prompt
+ for a password automatically limits the password to eight
characters. That is a problem with the system library, not with
MySQL. Internally, MySQL doesn't have any limit for the length
of the password. To work around the problem, change your MySQL
@@ -16721,23 +16721,27 @@
<listitem>
<para>
- By using <literal>GRANT</literal> statements
+ By using statements intended for creating accounts, such as
+ <literal>CREATE USER</literal> or <literal>GRANT</literal>
</para>
</listitem>
<listitem>
<para>
- By manipulating the MySQL grant tables directly
+ By manipulating the MySQL grant tables directly with
+ statements such as <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, or <literal>DELETE</literal>
</para>
</listitem>
</itemizedlist>
<para>
- The preferred method is to use <literal>GRANT</literal>
- statements, because they are more concise and less error-prone.
- <literal>GRANT</literal> is available as of MySQL 3.22.11; its
- syntax is described in <xref linkend="grant"/>.
+ The preferred method is to use account-creation statements
+ because they are more concise and less error-prone.
+ <literal>CREATE USER</literal> and <literal>GRANT</literal> are
+ described in <xref linkend="create-user"/>, and
+ <xref linkend="grant"/>.
</para>
<para>
@@ -16910,9 +16914,12 @@
<para>
The <literal>'Y'</literal> values enable privileges for the
- accounts. For the <literal>admin</literal> account, you may also
- employ the more readable extended <literal>INSERT</literal>
- syntax using <literal>SET</literal>.
+ accounts. Depending on your MySQL version, you may have to use a
+ different number of <literal>'Y'</literal> values in the first
+ two <literal>INSERT</literal> statements. For the
+ <literal>admin</literal> account, you may also employ the more
+ readable extended <literal>INSERT</literal> syntax using
+ <literal>SET</literal>.
</para>
<para>
@@ -17038,9 +17045,9 @@
for the <literal>bankaccount</literal>,
<literal>expenses</literal>, and <literal>customer</literal>
databases, but only when accessed from the proper hosts. As
- usual when you modify the grant tables directly, you tell the
- server to reload them with <literal>FLUSH PRIVILEGES</literal>
- so that the privilege changes take effect.
+ usual when you modify the grant tables directly, you must tell
+ the server to reload them with <literal>FLUSH
+ PRIVILEGES</literal> so that the privilege changes take effect.
</para>
<para>
@@ -17396,10 +17403,10 @@
</programlisting>
<para>
- Only users such as <literal>root</literal> with update access to
- the <literal>mysql</literal> database can change the password
- for other users. If you are not connected as an anonymous user,
- you can change your own password by omitting the
+ Only users such as <literal>root</literal> that have update
+ access to the <literal>mysql</literal> database can change the
+ password for other users. If you are not connected as an
+ anonymous user, you can change your own password by omitting the
<literal>FOR</literal> clause:
</para>
@@ -17458,15 +17465,14 @@
</itemizedlist>
<para>
- When you assign an account a password using <literal>SET
- PASSWORD</literal>, <literal>INSERT</literal>, or
+ When you assign an account a non-empty password using
+ <literal>SET PASSWORD</literal>, <literal>INSERT</literal>, or
<literal>UPDATE</literal>, you must use the
- <literal>PASSWORD()</literal> function to encrypt it. (The only
- exception is that you need not use <literal>PASSWORD()</literal>
- if the password is empty.) <literal>PASSWORD()</literal> is
- necessary because the <literal>user</literal> table stores
- passwords in encrypted form, not as plaintext. If you forget
- that fact, you are likely to set passwords like this:
+ <literal>PASSWORD()</literal> function to encrypt it.
+ <literal>PASSWORD()</literal> is necessary because the
+ <literal>user</literal> table stores passwords in encrypted
+ form, not as plaintext. If you forget that fact, you are likely
+ to set passwords like this:
</para>
<programlisting>
@@ -17509,7 +17515,7 @@
</programlisting>
<para>
- If you set passwords using the <literal>GRANT ... IDENTIFIED
+ If you assign passwords using the <literal>GRANT ... IDENTIFIED
BY</literal> statement or the <command>mysqladmin
password</command> command, they both take care of encrypting
the password for you. In these cases, using
@@ -17537,7 +17543,7 @@
<para>
On an administrative level, you should never grant access to the
- <literal>mysql.user</literal> table to any non-administrative
+ <literal>user</literal> grant table to any non-administrative
accounts.
</para>
@@ -17786,46 +17792,49 @@
<para>
If you need more information about SSL, X509, or encryption,
- use your favorite Internet search engine to search for
+ use your favorite Internet search engine to search for the
keywords in which you are interested.
</para>
</section>
- <section id="secure-requirements">
+ <section id="secure-using-openssl">
- <title>&title-secure-requirements;</title>
+ <title>&title-secure-using-openssl;</title>
<para>
To use SSL connections between the MySQL server and client
- programs, your system must be able to support OpenSSL. If
- you're using a MySQL version with built-in yaSSL support (as
- of version 5.0.10), don't read this section, but rather
- <xref linkend="secure-using-yassl"/>.
+ programs, your system must support either OpenSSL or (as of
+ MySQL 5.0.10) yaSSL. This section covers OpenSSL. To use
+ yaSSL, read <xref linkend="secure-using-yassl"/>, instead.
</para>
<para>
- To get secure connections to work with MySQL, you must do the
- following:
+ To get secure connections to work with MySQL and OpenSSL, you
+ must do the following:
</para>
<orderedlist>
<listitem>
<para>
- Install the OpenSSL library. We have tested MySQL with
- OpenSSL 0.9.6. If you need OpenSSL, visit
- <ulink url="http://www.openssl.org"/>.
+ Install the OpenSSL library if it has not already been
+ installed. We have tested MySQL with OpenSSL 0.9.6. If you
+ need OpenSSL, visit <ulink url="http://www.openssl.org"/>.
</para>
</listitem>
<listitem>
<para>
- When you configure MySQL, run the
+ When you configure MySQL, invoke the
<command>configure</command> script with the
<option>--with-vio</option> and
- <option>--with-openssl</option> options.
+ <option>--with-openssl</option> options:
</para>
+
+<programlisting>
+shell> <userinput>./configure --with-vio --with-openssl</userinput>
+</programlisting>
</listitem>
<listitem>
@@ -17881,7 +17890,7 @@
Using MySQL's built-in yaSSL support makes it easier to use
secure connections. You don't have to install OpenSSL and
perform the other steps described in
- <xref linkend="secure-requirements"/>. Also, both MySQL and
+ <xref linkend="secure-using-openssl"/>. Also, both MySQL and
yaSSL employ the same licensing model.
</para>
@@ -17918,12 +17927,12 @@
</itemizedlist>
<para>
- If you want to enable yaSSL when building MySQL from source,
- you should configure MySQL like this:
+ To enable yaSSL when building MySQL from source, you should
+ configure MySQL like this:
</para>
<programlisting>
-./configure --with-yassl=yes
+shell> <userinput>./configure --with-yassl</userinput>
</programlisting>
<para>
@@ -17935,6 +17944,12 @@
see Bug #13164.
</para>
+ <remark role="todo">
+ [pd] This is actually general info, not something
+ yaSSL-specific. Eventually we should move it to a more general
+ section.
+ </remark>
+
<para>
To start the MySQL server with yaSSL support, use the same
options as with OpenSSL support and identify the certificates
@@ -18449,8 +18464,8 @@
</orderedlist>
<para>
- You should have an ODBC connection to MySQL, encrypted using
- SSH.
+ At this point, you should have an ODBC connection to MySQL,
+ encrypted using SSH.
</para>
</section>
@@ -19332,8 +19347,8 @@
<command>myisamchk</command> operations that affect indexes can
cause <literal>FULLTEXT</literal> indexes to be rebuilt with
full-text parameters that are incompatible with the values used
- by the MySQL server. To avoid this, read the instructions in
- <xref linkend="myisamchk-general-options"/>.
+ by the MySQL server. To avoid this problem, read the
+ instructions in <xref linkend="myisamchk-general-options"/>.
</para>
<para>
@@ -20107,8 +20122,8 @@
<para>
Because we have not had any unexpectedly crashed tables
(tables that become corrupted for reasons other than hardware
- trouble) for a couple of years (this is really true), once a
- week is more than enough for us.
+ trouble) for several years, once a week is more than
+ sufficient for us.
</para>
<para>
Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.0/renamed-nodes.txt 2006-01-28 23:47:56 UTC (rev 1092)
@@ -409,3 +409,4 @@
instance-manager-command-line-options instance-manager-command-options
upgrading-grant-tables mysql-fix-privilege-tables
secure-grant grant
+secure-requirements secure-using-openssl
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.0/sql-syntax.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -11966,10 +11966,10 @@
by altering the <literal>mysql.user</literal> table, and
attempting to do so results in unpredictable behavior which
may even make it impossible for users to log in to the MySQL
- server</emphasis>. You should never attempt to alter the grant
- tables in any way except by means of the procedure prescribed
- by MySQL AB that is described in
- <xref linkend="mysql-fix-privilege-tables"/>.
+ server</emphasis>. You should never alter any of the tables in
+ the <literal>mysql</literal> database in any manner whatsoever
+ except by means of the procedure prescribed by MySQL AB that
+ is described in <xref linkend="mysql-fix-privilege-tables"/>.
</para>
<para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.1/database-administration.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -16567,10 +16567,11 @@
<emphasis role="bold">Note</emphasis>: <emphasis>You should
never alter any of the tables in the
<literal>mysql</literal> database in any manner whatsoever
- except by running the scripts supplied expressly for this
- purpose with the MySQL distribution. Attempting to redefine
- MySQL's system tables in any other fashion results in
- undefined (and unsupported!) behavior</emphasis>.
+ except by means of the procedure prescribed by MySQL AB that
+ is described in
+ <xref linkend="mysql-fix-privilege-tables"/>. Attempting to
+ redefine MySQL's system tables in any other fashion results
+ in undefined (and unsupported!) behavior</emphasis>.
</para>
<para>
@@ -16622,10 +16623,9 @@
privileges that are described in
<xref linkend="default-privileges"/>, which also discusses how
to assign passwords to them. Thereafter, you normally set up,
- modify, and remove MySQL accounts using the
- <literal>GRANT</literal> and <literal>REVOKE</literal>
- statements. See <xref linkend="grant"/>, and
- <xref linkend="revoke"/>.
+ modify, and remove MySQL accounts using statements such as
+ <literal>GRANT</literal> and <literal>REVOKE</literal>. See
+ <xref linkend="account-management-sql"/>.
</para>
<para>
@@ -16655,9 +16655,9 @@
<para>
The preceding commands include the password value on the command
line, which can be a security risk. See
- <xref linkend="password-security"/>. To avoid this, specify the
- <option>--password</option> or <option>-p</option> option
- without any following password value:
+ <xref linkend="password-security"/>. To avoid this problem,
+ specify the <option>--password</option> or <option>-p</option>
+ option without any following password value:
</para>
<programlisting>
@@ -16666,11 +16666,11 @@
</programlisting>
<para>
- Then the client program prints a prompt and waits for you to
- enter the password. (In these examples,
- <replaceable>db_name</replaceable> is <emphasis>not</emphasis>
- interpreted as a password, because it is separated from the
- preceding password option by a space.)
+ When the password option has no password value, the client
+ program prints a prompt and waits for you to enter the password.
+ (In these examples, <replaceable>db_name</replaceable> is
+ <emphasis>not</emphasis> interpreted as a password because it is
+ separated from the preceding password option by a space.)
</para>
<remark role="todo">
@@ -16678,8 +16678,8 @@
</remark>
<para>
- On some systems, the library call that MySQL uses to prompt for
- a password automatically limits the password to eight
+ On some systems, the library routine that MySQL uses to prompt
+ for a password automatically limits the password to eight
characters. That is a problem with the system library, not with
MySQL. Internally, MySQL doesn't have any limit for the length
of the password. To work around the problem, change your MySQL
@@ -16735,23 +16735,27 @@
<listitem>
<para>
- By using <literal>GRANT</literal> statements
+ By using statements intended for creating accounts, such as
+ <literal>CREATE USER</literal> or <literal>GRANT</literal>
</para>
</listitem>
<listitem>
<para>
- By manipulating the MySQL grant tables directly
+ By manipulating the MySQL grant tables directly with
+ statements such as <literal>INSERT</literal>,
+ <literal>UPDATE</literal>, or <literal>DELETE</literal>
</para>
</listitem>
</itemizedlist>
<para>
- The preferred method is to use <literal>GRANT</literal>
- statements, because they are more concise and less error-prone.
- <literal>GRANT</literal> is available as of MySQL 3.22.11; its
- syntax is described in <xref linkend="grant"/>.
+ The preferred method is to use account-creation statements
+ because they are more concise and less error-prone.
+ <literal>CREATE USER</literal> and <literal>GRANT</literal> are
+ described in <xref linkend="create-user"/>, and
+ <xref linkend="grant"/>.
</para>
<para>
@@ -16924,9 +16928,12 @@
<para>
The <literal>'Y'</literal> values enable privileges for the
- accounts. For the <literal>admin</literal> account, you may also
- employ the more readable extended <literal>INSERT</literal>
- syntax using <literal>SET</literal>.
+ accounts. Depending on your MySQL version, you may have to use a
+ different number of <literal>'Y'</literal> values in the first
+ two <literal>INSERT</literal> statements. For the
+ <literal>admin</literal> account, you may also employ the more
+ readable extended <literal>INSERT</literal> syntax using
+ <literal>SET</literal>.
</para>
<para>
@@ -17052,9 +17059,9 @@
for the <literal>bankaccount</literal>,
<literal>expenses</literal>, and <literal>customer</literal>
databases, but only when accessed from the proper hosts. As
- usual when you modify the grant tables directly, you tell the
- server to reload them with <literal>FLUSH PRIVILEGES</literal>
- so that the privilege changes take effect.
+ usual when you modify the grant tables directly, you must tell
+ the server to reload them with <literal>FLUSH
+ PRIVILEGES</literal> so that the privilege changes take effect.
</para>
<para>
@@ -17405,10 +17412,10 @@
</programlisting>
<para>
- Only users such as <literal>root</literal> with update access to
- the <literal>mysql</literal> database can change the password
- for other users. If you are not connected as an anonymous user,
- you can change your own password by omitting the
+ Only users such as <literal>root</literal> that have update
+ access to the <literal>mysql</literal> database can change the
+ password for other users. If you are not connected as an
+ anonymous user, you can change your own password by omitting the
<literal>FOR</literal> clause:
</para>
@@ -17467,15 +17474,14 @@
</itemizedlist>
<para>
- When you assign an account a password using <literal>SET
- PASSWORD</literal>, <literal>INSERT</literal>, or
+ When you assign an account a non-empty password using
+ <literal>SET PASSWORD</literal>, <literal>INSERT</literal>, or
<literal>UPDATE</literal>, you must use the
- <literal>PASSWORD()</literal> function to encrypt it. (The only
- exception is that you need not use <literal>PASSWORD()</literal>
- if the password is empty.) <literal>PASSWORD()</literal> is
- necessary because the <literal>user</literal> table stores
- passwords in encrypted form, not as plaintext. If you forget
- that fact, you are likely to set passwords like this:
+ <literal>PASSWORD()</literal> function to encrypt it.
+ <literal>PASSWORD()</literal> is necessary because the
+ <literal>user</literal> table stores passwords in encrypted
+ form, not as plaintext. If you forget that fact, you are likely
+ to set passwords like this:
</para>
<programlisting>
@@ -17518,7 +17524,7 @@
</programlisting>
<para>
- If you set passwords using the <literal>GRANT ... IDENTIFIED
+ If you assign passwords using the <literal>GRANT ... IDENTIFIED
BY</literal> statement or the <command>mysqladmin
password</command> command, they both take care of encrypting
the password for you. In these cases, using
@@ -17546,7 +17552,7 @@
<para>
On an administrative level, you should never grant access to the
- <literal>mysql.user</literal> table to any non-administrative
+ <literal>user</literal> grant table to any non-administrative
accounts.
</para>
@@ -17795,46 +17801,49 @@
<para>
If you need more information about SSL, X509, or encryption,
- use your favorite Internet search engine to search for
+ use your favorite Internet search engine to search for the
keywords in which you are interested.
</para>
</section>
- <section id="secure-requirements">
+ <section id="secure-using-openssl">
- <title>&title-secure-requirements;</title>
+ <title>&title-secure-using-openssl;</title>
<para>
To use SSL connections between the MySQL server and client
- programs, your system must be able to support OpenSSL. If
- you're using a MySQL version with built-in yaSSL support,
- don't read this section, but rather
- <xref linkend="secure-using-yassl"/>.
+ programs, your system must support either OpenSSL or yaSSL.
+ This section covers OpenSSL. To use yaSSL, read
+ <xref linkend="secure-using-yassl"/>, instead.
</para>
<para>
- To get secure connections to work with MySQL, you must do the
- following:
+ To get secure connections to work with MySQL and OpenSSL, you
+ must do the following:
</para>
<orderedlist>
<listitem>
<para>
- Install the OpenSSL library. We have tested MySQL with
- OpenSSL 0.9.6. If you need OpenSSL, visit
- <ulink url="http://www.openssl.org"/>.
+ Install the OpenSSL library if it has not already been
+ installed. We have tested MySQL with OpenSSL 0.9.6. If you
+ need OpenSSL, visit <ulink url="http://www.openssl.org"/>.
</para>
</listitem>
<listitem>
<para>
- When you configure MySQL, run the
+ When you configure MySQL, invoke the
<command>configure</command> script with the
<option>--with-vio</option> and
- <option>--with-openssl</option> options.
+ <option>--with-openssl</option> options:
</para>
+
+<programlisting>
+shell> <userinput>./configure --with-vio --with-openssl</userinput>
+</programlisting>
</listitem>
<listitem>
@@ -17890,7 +17899,7 @@
Using MySQL's built-in yaSSL support makes it easier to use
secure connections. You don't have to install OpenSSL and
perform the other steps described in
- <xref linkend="secure-requirements"/>. Also, both MySQL and
+ <xref linkend="secure-using-openssl"/>. Also, both MySQL and
yaSSL employ the same licensing model.
</para>
@@ -17927,12 +17936,12 @@
</itemizedlist>
<para>
- If you want to enable yaSSL when building MySQL from source,
- you should configure MySQL like this:
+ To enable yaSSL when building MySQL from source, you should
+ configure MySQL like this:
</para>
<programlisting>
-./configure --with-yassl=yes
+shell> <userinput>./configure --with-yassl</userinput>
</programlisting>
<para>
@@ -17944,6 +17953,12 @@
see Bug #13164.
</para>
+ <remark role="todo">
+ [pd] This is actually general info, not something
+ yaSSL-specific. Eventually we should move it to a more general
+ section.
+ </remark>
+
<para>
To start the MySQL server with yaSSL support, use the same
options as with OpenSSL support and identify the certificates
@@ -18458,8 +18473,8 @@
</orderedlist>
<para>
- You should have an ODBC connection to MySQL, encrypted using
- SSH.
+ At this point, you should have an ODBC connection to MySQL,
+ encrypted using SSH.
</para>
</section>
@@ -19341,8 +19356,8 @@
<command>myisamchk</command> operations that affect indexes can
cause <literal>FULLTEXT</literal> indexes to be rebuilt with
full-text parameters that are incompatible with the values used
- by the MySQL server. To avoid this, read the instructions in
- <xref linkend="myisamchk-general-options"/>.
+ by the MySQL server. To avoid this problem, read the
+ instructions in <xref linkend="myisamchk-general-options"/>.
</para>
<para>
@@ -20116,8 +20131,8 @@
<para>
Because we have not had any unexpectedly crashed tables
(tables that become corrupted for reasons other than hardware
- trouble) for a couple of years (this is really true), once a
- week is more than enough for us.
+ trouble) for several years, once a week is more than
+ sufficient for us.
</para>
<para>
Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.1/renamed-nodes.txt 2006-01-28 23:47:56 UTC (rev 1092)
@@ -113,3 +113,4 @@
upgrading-grant-tables mysql-fix-privilege-tables
silent-column-changes ../../5.0/en/silent-column-changes
secure-grant grant
+secure-requirements secure-using-openssl
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-5.1/sql-syntax.xml 2006-01-28 23:47:56 UTC (rev 1092)
@@ -12443,10 +12443,10 @@
by altering the <literal>mysql.user</literal> table, and
attempting to do so results in unpredictable behavior which
may even make it impossible for users to log in to the MySQL
- server</emphasis>. You should never attempt to alter the grant
- tables in any way except by means of the procedure prescribed
- by MySQL AB that is described in
- <xref linkend="mysql-fix-privilege-tables"/>.
+ server</emphasis>. You should never alter any of the tables in
+ the <literal>mysql</literal> database in any manner whatsoever
+ except by means of the procedure prescribed by MySQL AB that
+ is described in <xref linkend="mysql-fix-privilege-tables"/>.
</para>
<para>
Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent 2006-01-28 23:47:07 UTC (rev 1091)
+++ trunk/refman-common/titles.en.ent 2006-01-28 23:47:56 UTC (rev 1092)
@@ -1477,8 +1477,8 @@
<!ENTITY title-secure-basics "Basic SSL Concepts">
<!ENTITY title-secure-connections "Using Secure Connections">
<!ENTITY title-secure-create-certs "Setting Up SSL Certificates for MySQL">
-<!ENTITY title-secure-requirements "Requirements (OpenSSL)">
-<!ENTITY title-secure-using-yassl "Using yaSSL">
+<!ENTITY title-secure-using-openssl "Using SSL Connections with OpenSSL">
+<!ENTITY title-secure-using-yassl "Using SSL Connections with yaSSL">
<!ENTITY title-security "General Security Issues">
<!ENTITY title-security-against-attack "Making MySQL Secure Against Attackers">
<!ENTITY title-security-guidelines "General Security Guidelines">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1092 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 29 Jan |
