openstack/openstack-manuals
Code Issues Proposed changes

Remove deprecated auth from docs

Browse Source 
fixes bug 1034143

This patch removes various sections and updates some wording to
remove deprecated auth from the documentation and state that
OpenStack Identity is the choice now.

Patch Set 2 fixes minor sentence problem in
doc/src/docbkx/openstack-compute-admin/computeconfigure.xml.

Change-Id: I5c109666812b6a96514887bef1fedcfa68abf1ff
This commit is contained in:
Tom Fifield
2012-08-29 19:10:24 +10:00
committed by annegentle
parent 351c1f03e2
commit 5dffc3192a
8 changed files with 17 additions and 283 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
doc/src/docbkx/common/ch_identity_mgmt.xml
View File

@@ -214,43 +214,12 @@ keystone-manage export_legacy_catalog \
<?dbhtml stop-chunking?>
<title>Migrating from Legacy Authentication</title>
<para>
Migration of users, projects (aka tenants), roles and EC2
credentials is supported for the Diablo and Essex releases of
Nova. To migrate your auth data from Compute, use the following
steps:
A different type of authentication was used in OpenStack releases
prior to Diablo, after which it was deprecated. It has been
removed entirely in Folsom. If you are still using 'legacy
authentication' and need to upgrade, please refer to the
<link xlink:href="http://docs.openstack.org/essex/openstack-compute/admin/content/migrating-from-nova-auth.html">Essex Documentation</link>.
</para>
<section xml:id="step-1-export-your-data-from-nova">
<title>Step 1: Export your data from Compute</title>
<para> Use the following command to export your data from
Compute (nova): </para>
<screen>
nova-manage export auth &gt; /path/to/dump
</screen>
<para>
It is important to redirect the output to a file so it can be
imported in a later step.
</para>
</section>
<section xml:id="step-2-db_sync-your-new-empty-database-1">
<title>Step 2: db_sync your new, empty database</title>
<para>
Run the following command to configure the most recent schema in
your new installation:
</para>
<screen>
keystone-manage db_sync
</screen>
</section>
<section xml:id="step-3-import-your-data-to-keystone">
<title>Step 3: Import your data to Keystone</title>
<para>
To import your Compute auth data from a dump file created with
<command>nova-manage</command>, run this command:
</para>
<screen>
<prompt>$</prompt> <userinput>keystone-manage import_nova_auth <replaceable>[dump_file, e.g. /path/to/dump]</replaceable></userinput>
</screen>
</section>
</section>
<section xml:id="initializing-keystone">
<title>Initializing Keystone</title>
@@ -750,7 +719,7 @@ keystone role-get role=19d1d3344873464d819c45f521ff9890
example:
</para>
<screen>
keystone role add-user-role \
keystone add-user-role \
3a751f78ef4c412b827540b829e2d7dd \
03c84b51574841ba9a0d8db7882ac645 \
20601a7f1d94447daa4dff438cb1c209

15
doc/src/docbkx/common/getstart.xml
View File

@@ -205,8 +205,7 @@ xml:id="ch_getting-started-with-openstack">
in Object (Swift)</para>
</listitem>
<listitem>
<para>All the services (<emphasis>will
eventually</emphasis>) authenticate with Identity
<para>All the services authenticate with Identity
(Keystone)</para>
</listitem>
</itemizedlist>
@@ -324,9 +323,8 @@ xml:id="ch_getting-started-with-openstack">
users to perform administrative actions). It also
initiates most of the orchestration activities (such as
running an instance) as well as enforces some policy
(mostly quota checks). In the Essex release, nova-api has
been modularized, allowing for implementers to run only
specific APIs.</para>
(mostly quota checks). Nova-api is modularized, allowing
for implementers to run only specific APIs.</para>
</listitem>
<listitem>
<para>The <code>nova-compute</code> process is primarily a
@@ -384,10 +382,9 @@ xml:id="ch_getting-started-with-openstack">
</itemizedlist>
<para>During the last two releases, Nova has augmented its
console services. Console services allow end users to access
their virtual instance's console through a proxy. This
involves a pair of new daemons (nova-console and
<para>Nova also provides cosole services to allow end users to
access their virtual instance's console through a proxy. This
involves a pair of daemons (nova-console and
nova-consoleauth).</para>
<para>Nova interacts with all of the usual suspects: Keystone

3
doc/src/docbkx/openstack-compute-admin/computeadmin.xml
View File

@@ -210,7 +210,8 @@ usage: nova [--debug] [--os_username OS_USERNAME] [--os_password OS_PASSWORD]
<command>nova-manage project list</command></para>
<para>Run without arguments to see a list of available command categories: nova-manage</para>
<para>You can also run with a category argument such as user to see a list of all commands in that category: nova-manage user</para>
<para>You can also run with a category argument such as user to see
a list of all commands in that category: nova-manage service</para>
</simplesect> <simplesect><title>Using the euca2ools commands</title>
<para>For a command-line interface to EC2 API calls, use
the euca2ools command line tool. It is documented at

6
doc/src/docbkx/openstack-compute-admin/computeconfigure.xml
View File

@@ -590,10 +590,8 @@ xenapi_remap_vbd_dev=true
<title>Configuring Authentication and Authorization</title>
<para>There are different methods of authentication for the
OpenStack Compute project, including no authentication,
keystone, or deprecated (which uses nova-manage commands to
create users). With additional configuration, you can use the
OpenStack Identity Service, code-named Keystone. Refer to
OpenStack Compute project, including no authentication. The preferred
system is the OpenStack Identity Service, code-named Keystone. Refer to
<xref linkend="ch-identity-mgmt-config"/> for additional information. </para>
<para>To customize authorization settings for Compute, see these
configuration settings in <filename>nova.conf</filename>.</para>

187
doc/src/docbkx/openstack-compute-admin/computeidentity.xml
View File

@@ -1,187 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="ch_configuring-authentication">
<title>Identity Service and Authentication </title>
<para></para>
<section xml:id="configuring-authentication-authorization">
<title>Configuring Authentication and Authorization </title>
<para>There are different methods of authentication for the OpenStack Compute project and the
default setting is now to use the OpenStack Identity Service, code-named Keystone. For
the older, deprecated auth system, you set the --use_deprecated-auth Configuration
option. For no auth, use the default paste.ini that is included in the etch directory. </para>
<para>OpenStack Compute uses an implementation of an authentication system structured like
having an Active Directory or other federated LDAP user store that backends to an
identity manager or other SAML Policy Controller that then maps to groups. Credentials
for API calls are stored in the project zip file when using the deprecated auth system.
Certificate authority is also customized in nova.conf for the deprecated auth system. </para>
<para>If you see errors such as "EC2ResponseError: 403 Forbidden" it is likely you are
trying to use euca commands without the auth system properly configured. Either install
and configure the Identity Service, use the deprecated auth setting, or change out the
default paste.ini file to use no auth.</para>
<table rules="all">
<caption>Description of nova.conf configuration options for Authentication</caption>
<thead>
<tr>
<td>Configuration option</td>
<td>Default</td>
<td>Description</td>
</tr>
</thead><tbody>
<tr>
<td>auth_driver</td>
<td>default:'nova.auth.dbdriver.DbDriver'</td>
<td><para>String value; Name of the driver for authentication</para><itemizedlist>
<listitem>
<para>nova.auth.dbdriver.DbDriver - Default setting, uses Identity
Service (Keystone).</para>
</listitem>
<listitem>
<para>nova.auth.ldapdriver.FakeLdapDriver - create a replacement
for this driver supporting other backends by creating another
class that exposes the same public methods.</para>
</listitem>
</itemizedlist></td>
</tr>
<tr>
<td>use_deprecated_auth</td>
<td>default:'false'</td>
<td><para>True or false; Sets the auth system to use the zip file provided with the project files to store all credentials</para></td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Description of nova.conf Configuration options for customizing roles in deprecated
auth</caption>
<thead>
<tr>
<td>Configuration option</td>
<td>Default</td>
<td>Description</td>
</tr>
</thead><tbody>
<tr>
<td>allowed_roles</td>
<td>default: 'cloudadmin,itsec,sysadmin,netadmin,developer') </td>
<td>Comma separated list; Allowed roles for project</td>
</tr>
<tr>
<td>global_roles</td>
<td>default: 'cloudadmin,itsec') </td>
<td>Comma separated list; Roles that apply to all projects</td>
</tr>
<tr>
<td>superuser_roles</td>
<td>default: 'cloudadmin') </td>
<td>Comma separated list; Roles that ignore authorization checking completely</td>
</tr>
</tbody>
</table>
<table rules="all">
<caption>Description of nova.conf Configuration options for credentials in deprecated
auth</caption>
<thead>
<tr>
<td>Configuration option</td>
<td>Default</td>
<td>Description</td>
</tr>
</thead><tbody>
<tr>
<td>credentials_template</td>
<td>default: '') </td>
<td>Directory; Template for creating users' RC file</td>
</tr>
<tr>
<td>credential_rc_file</td>
<td>default: '%src') </td>
<td>File name; File name of rc in credentials zip</td>
</tr>
<tr>
<td>credential_cert_file</td>
<td>default: 'cert.pem') </td>
<td>File name; File name of certificate in credentials zip</td>
</tr>
<tr>
<td>credential_key_file</td>
<td>default: 'pk.pem') </td>
<td>File name; File name of rc in credentials zip</td>
</tr>
<tr>
<td>vpn_client_template</td>
<td>default: 'nova/cloudpipe/client/ovpn.template') </td>
<td>Directory; Refers to where the template lives for creating users vpn file</td>
</tr>
<tr>
<td>credential_vpn_file</td>
<td>default: 'nova-vpn.conf') </td>
<td>File name; Filename of certificate in credentials.zip</td>
</tr>
</tbody></table>
<table rules="all">
<caption>Description of nova.conf Configuration options for CA (Certificate
Authority)</caption>
<thead>
<tr>
<td>Configuration option</td>
<td>Default</td>
<td>Description</td>
</tr>
</thead><tbody>
<tr>
<td>keys_path</td>
<td>default: '$state_path/keys') </td>
<td>Directory; Where Nova keeps the keys</td>
</tr>
<tr>
<td>ca_file</td>
<td>default: 'cacert.pem') </td>
<td>File name; File name of root CA</td>
</tr>
<tr>
<td>crl_file</td>
<td>default: 'crl.pem') </td>
<td>File name; File name of Certificate Revocation List</td>
</tr>
<tr>
<td>key_file</td>
<td>default: 'private/cakey.pem') </td>
<td>File name; File name of private key</td>
</tr>
<tr>
<td>use_project_ca</td>
<td>default: 'false') </td>
<td>True or false; Indicates whether to use a CA for each project; false means CA is not used for each project</td>
</tr>
<tr>
<td>project_cert_subject</td>
<td>default: '/C=US/ST=California/L=MountainView/O=AnsoLabs/OU=NovaDev/CN=proje ct-ca-%s-%s') </td>
<td>String; Subject for certificate for projects, %s for project, timestamp </td>
</tr>
<tr>
<td>user_cert_subject</td>
<td>default: '/C=US/ST=California/L=MountainView/O=AnsoLabs/OU=NovaDev/CN=%s-%s-%s') </td>
<td>String; Subject for certificate for users, %s for project, users, timestamp </td>
</tr>
<tr>
<td>vpn_cert_subject</td>
<td>default: '/C=US/ST=California/L=MountainView/O=AnsoLabs/OU=NovaDev/CN=project-vpn-%s-%s') </td>
<td>String; Subject for certificate for vpns, %s for project, timestamp </td>
</tr>
</tbody></table>
</section>
</chapter>

2
doc/src/docbkx/openstack-compute-admin/tables/auth-nova-conf.xml
View File

@@ -15,7 +15,7 @@
<tr>
<td> auth_strategy=noauth </td>
<td> (StrOpt) The strategy to use for authentication.
Supports noauth, keystone, and deprecated. </td>
Supports noauth or keystone. </td>
</tr>
<tr>
<td> auth_token_ttl=3600 </td>

1
doc/src/docbkx/openstack-install/ch_installcomputeimage.xml
View File

@@ -23,7 +23,6 @@
<xi:include href="compute-verifying-install.xml" />
<xi:include href="configure-creds.xml" />
<xi:include href="installing-additional-compute-nodes.xml" />
<!--<xi:include href="nova-manage-initial-user-project.xml" />-->
<!--<xi:include href="enable-access-security-group.xml" />-->
</chapter>

43
doc/src/docbkx/openstack-install/nova-manage-initial-user-project.xml
View File

@@ -1,43 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xml:id="setting-up-openstack-compute-environment-on-the-compute-node"
xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
<title>Setting Up OpenStack Compute Environment on the Compute Node</title>
<para>
These are the commands you run to ensure the database schema is current, and
then set up a user and project, if you are using built-in auth with the
<code>--use_deprecated_auth</code> flag rather than the Identity Service. We'll walk through these to offer a validation step and show that the cloud is accepting commands.
</para>
<para>
<literallayout class="monospaced">sudo nova-manage user admin &lt;user_name>
nova-manage project create &lt;project_name> &lt;user_name>
nova-manage network create &lt;network-label> --bridge=&lt;bridgename> &lt;IP-range-of-network-CIDR> &lt;number-of-networks-to-define-for-project> &lt;addresses-in-each-network> </literallayout>
</para>
<para>Here is an example of what this looks like with real values
entered and values returned: </para>
<literallayout class="monospaced">$ sudo nova-manage user admin dub
export EC2_ACCESS_KEY=a42e03c9-656d-4c11-a660-80ed374a4cfb
export EC2_SECRET_KEY=a00a3a32-726a-4e1e-b0c8-24e7df55c959
$ sudo nova-manage project create dubproject dub
$ sudo nova-manage network create novanet --bridge_interface=br100 192.168.100.0/24 1 256</literallayout>
<para>For this example, the number of IPs is /24 which will be compatible with the ‘fixed-range’
set in nova.conf. Currently, there can only be one network, and this set up would use the
max IPs available in a /24. You can choose values that let you use any valid amount that you
would like. </para>
<para>The nova-manage service assumes that the first IP address is
your network (like 192.168.11.0), that the 2nd IP is your
gateway (192.168.11.1), and that the broadcast is the very
last IP in the range you defined (192.168.11.255). If this is
not the case you will need to manually edit the sql db
‘networks’ table.o. </para>
<para>When you run the nova-manage network create command, entries are made
in the ‘networks’ and ‘fixed_ips’ table. However, one of the networks listed in the
‘networks’ table needs to be marked as bridge in order for the code to know that a
bridge exists. The network in the Nova networks table is marked as bridged
automatically for Flat Manager.</para>
</section>