openstack/openstack-manuals
Code Issues Proposed changes

Merge "Fix broken URLs"

Browse Source
This commit is contained in:
Jenkins 2013-10-01 09:40:19 +00:00 committed by Gerrit Code Review
commit ff20a50aa2
18 changed files with 90 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/admin-guide-cloud/ch_compute.xml
View File

@ -392,7 +392,7 @@
configuration are discussed in the <link
xlink:href="http://docs.openstack.org/user-guide/content/index.html">
<citetitle>OpenStack End User
Guide</citetitle></link>. </para>
Guide</citetitle></link>.</para>
<para>Volumes do not provide concurrent access from
multiple instances. For that you need either a
traditional network file system like NFS or CIFS
@ -413,7 +413,7 @@
>RESTful API</link> that allows users to query VM
image metadata and retrieve the actual image with HTTP
requests. You can also use the <link
xlink:href="http://docs.openstack.org/cli/quick-start/content/glance_client.html"
xlink:href="http://docs.openstack.org/user-guide/content/cli_manage_images.html"
>glance command-line tool</link>, or the <link
xlink:href="http://docs.openstack.org/developer/python-glanceclient/"
>Python API</link> to accomplish the same
@ -489,13 +489,14 @@
</para>
<para>Full details for <application>nova</application>
and other CLI tools are provided in the <link
xlink:href="http://docs.openstack.org/cli/quick-start/content/index.html"
>OpenStack CLI Guide</link>. What follows is
xlink:href="http://docs.openstack.org/user-guide/content/index.html"
><citetitle>OpenStack End User Guide</citetitle></link>. What follows is
the minimal introduction required to follow the
CLI example in this chapter. In the case of a
conflict the <link
xlink:href="http://docs.openstack.org/cli/quick-start/content/index.html"
>OpenStack CLI Guide</link> should be
conflict the
<link
xlink:href="http://docs.openstack.org/user-guide/content/index.html"
><citetitle>OpenStack End User Guide</citetitle></link> should be
considered authoritative (and a bug filed against
this section).</para>
<para>To function, the
@ -684,7 +685,7 @@ header: Date: Thu, 13 Sep 2012 20:27:36 GMT
>php-opencloud</link> is a PHP SDK
that should work with most
OpenStack-based cloud deployments and
the Rackspace public cloud. </para>
the Rackspace public cloud.</para>
</listitem>
</itemizedlist>
</para>
@ -836,9 +837,10 @@ header: Date: Thu, 13 Sep 2012 20:27:36 GMT
>nova-network</systemitem> for networking between
VMs or use the Networking service (neutron) for
networking. To configure Compute networking options
with Neutron, see <link
xlink:href="http://docs.openstack.org/trunk/openstack-network/admin/content/"
>Network Administration Guide</link>.</para>
with Neutron, see the <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html"
>networking chapter</link> of the
<citetitle>Cloud Administrator Guide</citetitle>.</para>
<para>For each VM instance, Compute assigns to it a
private IP address. (Currently, Compute with
<systemitem class="service"
@ -1714,7 +1716,7 @@ net.bridge.bridge-nf-call-ip6tables=0</programlisting>
received by the API server and relayed to the
originating user. Database entries are queried,
added, or removed as necessary throughout the
process. </para>
process.</para>
</simplesect>
<simplesect>
<title>Compute worker</title>
@ -2020,10 +2022,10 @@ local0.error @@172.20.1.43:1024</programlisting></para>
<xi:include href="section_rootwrap.xml"/>
<section xml:id="section_live-migration-usage">
<title>Migration</title>
<!--<para>Before starting migrations, review the <link linkend="configuring-migrations"
>Configuring Migrations</link> section.</para>-->
<para>Before starting migrations, review the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations"
>Configuring Migrations</link> section in the
<citetitle>Configuration Reference Guide</citetitle>.</para>
<para>Migration provides a scheme to migrate running
instances from one OpenStack Compute server to another
OpenStack Compute server.</para>
@ -2424,7 +2426,7 @@ find / -gid 120 -exec chgrp nova {} \;</programlisting>
command was invoked, so the files for the
instances remain on the compute node.</para>
<para>The plan is to perform the following tasks, in
that exact order. </para>
that exact order.</para>
<para><emphasis role="underline">Any extra step would
be dangerous at this stage</emphasis> :</para>
<para>
@ -2442,12 +2444,12 @@ find / -gid 120 -exec chgrp nova {} \;</programlisting>
<listitem>
<para>Restart the instances. In other
words, go from a shutdown to running
state. </para>
state.</para>
</listitem>
<listitem>
<para>After the restart, you can reattach
the volumes to their respective
instances. </para>
instances.</para>
</listitem>
<listitem>
<para>That step, which is not a mandatory

8
doc/common/ch_getstart.xml
View File

@ -91,7 +91,7 @@
xlink:href="http://docs.openstack.org/developer/glance/"
>Glance</link></td>
<td>Provides a registry of virtual machine images. Compute
Service uses it to provision instances. </td>
Service uses it to provision instances.</td>
</tr>
<tr>
<td><link
@ -269,8 +269,8 @@
is generally only used when you run in multi-host mode
with <systemitem class="service">nova-network</systemitem>
installations. For details, see <link
xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/metadata-service.html"
>Metadata service</link>.</para>
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html"
>Metadata service</link> in the <citetitle>Cloud Administrator Guide</citetitle>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
@ -345,7 +345,7 @@
either type can be run against a single <systemitem
class="service">nova-consoleauth</systemitem> service in
a cluster configuration. For information, see <link
xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/about-nova-consoleauth.html"
xlink:href="http://docs.openstack.org/trunk/config-reference/content/about-nova-consoleauth.html"
>About nova-consoleauth</link>.</para>
</listitem>
<listitem>

7
doc/common/section_about-dashboard.xml
View File

@ -29,13 +29,14 @@
<para>After you install the dashboard, you can complete the following tasks:</para>
<itemizedlist>
<listitem>
<para>To customize your dashboard, see <link xlink:href="http://docs.openstack.org/grizzly/openstack-compute/install/apt/content/dashboard-custom-brand.html">How To Custom Brand The OpenStack Dashboard (Horizon)</link>.
<para>To customize your dashboard, see <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/dashboard-custom-brand.html"
>Customize the dashboard section</link>.
</para>
</listitem>
<listitem>
<para>To set up session storage for the dashboard,
see <link xlink:href="http://docs.openstack.org/grizzly/openstack-compute/install/apt/content/dashboard-sessions.html"
>OpenStack Dashboard Session Storage</link>.</para>
see <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/dashboard-sessions.html"
>Set up session storage for the dashboard section</link>.</para>
</listitem>
<listitem>
<para>To deploy the

2
doc/common/section_compute-configure-vnc.xml
View File

@ -115,7 +115,7 @@
<xi:include href="../common/tables/nova-vnc.xml"/>
<note>
<para>To support <link
xlink:href="../openstack-compute/admin/content/configuring-migrations.html"
xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations"
>live migration</link>, you cannot specify a specific IP
address for <literal>vncserver_listen</literal>, because
that IP address does not exist on the destination

4
doc/common/section_nova_cli_evacuate.xml
View File

@ -42,8 +42,8 @@
<para>To preserve the user disk data on the evacuated
server, deploy OpenStack Compute with shared
filesystem. To configure your system, see <link
xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-migrations.html"
>Configure migrations guide</link>. In this
xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#section_configuring-compute-migrations"
>Configure migrations section</link>. In this
example, the password remains unchanged.</para>
<screen><prompt>$</prompt> <userinput>nova evacuate <replaceable>evacuated_server_name</replaceable> <replaceable>host_b</replaceable> --on-shared-storage</userinput> </screen>
</step>

6
doc/common/section_xen-install.xml
View File

@ -76,10 +76,10 @@
<listitem>
<para>For resize and migrate functionality, please
perform the changes described in the <link
xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-resize.html#xenserver-resize"
xlink:href="http://docs.openstack.org/trunk/config-reference/content/configuring-openstack-compute-basics.html#xenserver-resize"
> Configuring Resize</link> section of the
OpenStack Compute Administration
Manual.</para>
<citetitle>OpenStack Configuration Reference</citetitle>.
</para>
</listitem>
<listitem>
<para>Install the VIF isolation rules to help

2
doc/high-availability-guide/aa-network.txt
View File

@ -20,7 +20,7 @@ highly available.
Since the Grizzly release, OpenStack Networking service has a scheduler which
allows to run multiple agents accross nodes. Also, the DHCP agent can be natively
highly available. Please follow the http://docs.openstack.org/trunk/openstack-network/admin/content/app_demo_multi_dhcp_agents.html[OpenStack Networking guide] for
highly available. Please follow the http://docs.openstack.org/trunk/config-reference/content/app_demo_multi_dhcp_agents.html[OpenStack Configuration Reference] for
further details.
==== Running Neutron L3 Agent

2
doc/high-availability-guide/ap-cinder-api.txt
View File

@ -8,7 +8,7 @@ Making the Cinder API service highly available in active / passive mode involves
* managing Cinder API daemon with the Pacemaker cluster manager,
* configuring OpenStack services to use this IP address.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-compute/install/apt/content/osfolubuntu-cinder.html[documentation] for installing Cinder service.
NOTE: Here is the http://docs.openstack.org/trunk/install-guide/install/apt/content/cinder-install.html[documentation] for installing Cinder service.
===== Adding Cinder API resource to Pacemaker

2
doc/high-availability-guide/ap-glance-api.txt
View File

@ -8,7 +8,7 @@ Making the OpenStack Image API service highly available in active / passive mode
* managing OpenStack Image API daemon with the Pacemaker cluster manager,
* configuring OpenStack services to use this IP address.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-compute/install/apt/content/install-glance.html[documentation] for installing OpenStack Image API service.
NOTE: Here is the http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-image.html[documentation] for installing OpenStack Image API service.
===== Adding OpenStack Image API resource to Pacemaker

2
doc/high-availability-guide/ap-keystone.txt
View File

@ -8,7 +8,7 @@ Making the OpenStack Identity service highly available in active / passive mode
* managing OpenStack Identity daemon with the Pacemaker cluster manager,
* configuring OpenStack services to use this IP address.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ch_installing-openstack-identity-service.html[documentation] for installing OpenStack Identity service.
NOTE: Here is the http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-identity-service.html[documentation] for installing OpenStack Identity service.
===== Adding OpenStack Identity resource to Pacemaker

6
doc/high-availability-guide/ap-network-controller.txt
View File

@ -13,7 +13,7 @@ The Neutron L3 agent provides L3/NAT forwarding to ensure external network acces
for VMs on tenant networks. High Availability for the L3 agent is achieved by
adopting Pacemaker.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_l3_agent.html[documentation] for installing Neutron L3 Agent.
NOTE: Here is the http://docs.openstack.org/trunk/config-reference/content/section_adv_cfg_l3_agent.html[documentation] for installing Neutron L3 Agent.
===== Adding Neutron L3 Agent resource to Pacemaker
@ -55,7 +55,7 @@ Neutron DHCP agent distributes IP addresses to the VMs with dnsmasq (by
default). High Availability for the DHCP agent is achieved by adopting
Pacemaker.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-network/admin/content/adv_cfg_dhcp_agent.html[documentation] for installing Neutron DHCP Agent.
NOTE: Here is the http://docs.openstack.org/trunk/config-reference/content/section_adv_cfg_dhcp_agent.html[documentation] for installing Neutron DHCP Agent.
===== Adding Neutron DHCP Agent resource to Pacemaker
@ -95,7 +95,7 @@ Neutron Metadata agent allows Nova API Metadata to be reachable by VMs on tenant
networks. High Availability for the Metadata agent is achieved by adopting
Pacemaker.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-network/admin/content/metadata_agent_options.html[documentation] for installing Neutron Metadata Agent.
NOTE: Here is the http://docs.openstack.org/trunk/config-reference/content/networking-options-metadata.html[documentation] for installing Neutron Metadata Agent.
===== Adding Neutron Metadata Agent resource to Pacemaker

2
doc/high-availability-guide/ap-neutron-server.txt
View File

@ -8,7 +8,7 @@ Making the OpenStack Networking Server service highly available in active / pass
* managing OpenStack Networking API Server daemon with the Pacemaker cluster manager,
* configuring OpenStack services to use this IP address.
NOTE: Here is the http://docs.openstack.org/trunk/openstack-network/admin/content/index.html[documentation] for installing OpenStack Networking service.
NOTE: Here is the http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_installing-openstack-networking.html[documentation] for installing OpenStack Networking service.
===== Adding OpenStack Networking Server resource to Pacemaker

2
doc/security-guide/ch014_best-practices-for-operator-mode-access.xml
View File

@ -122,7 +122,7 @@
<section xml:id="ch014_best-practices-for-operator-mode-access-idp80496">
<title>References</title>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/section_cli_overview.html">command line clients overview</link></para>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/cli/quick-start/content/cli_openrc.html">OpenStack RC file</link></para>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/cli_openrc.html">Download and source the OpenStack RC file</link></para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp82336">

2
doc/security-guide/ch024_authentication.xml
View File

@ -59,7 +59,7 @@
</section>
<section xml:id="ch024_authentication-idp261600">
<title>Service Authorization</title>
<para>As described in the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/index.html"><citetitle>OpenStack Compute Administration Guide</citetitle></link>, cloud administrators must define a user for each service, with a role of Admin. This service user account provides the service with the authorization to authenticate users.</para>
<para>As described in the <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/index.html"><citetitle>OpenStack Cloud Administrator Guide</citetitle></link>, cloud administrators must define a user for each service, with a role of Admin. This service user account provides the service with the authorization to authenticate users.</para>
<para>The Nova and Swift services can be configured to use either the "tempAuth" file or Keystone to store authentication information. The "tempAuth" solution MUST NOT be deployed in a production environment since it stores passwords in plain text.</para>
<para>Keystone supports client authentication for SSL which may be enabled. SSL client authentication provides an additional authentication factor, in addition to the username / password, that provides greater reliability on user identification. It reduces the risk of unauthorized access when usernames and passwords may be compromised.  However, there is additional administrative overhead and cost to issue certificates to users that may not be feasible in every deployment.</para>
<para>NOTE: We recommend using client authentication using SSL for the authentication of services to Keystone.</para>

2
doc/security-guide/ch026_compute.xml
View File

@ -68,7 +68,7 @@
</section>
<section xml:id="ch026_compute-idp86912">
<title>References</title>
<para><link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/spice-console.html">SPICE Console</link></para>
<para><link xlink:href="http://docs.openstack.org/trunk/config-reference/content/spice-console.html">SPICE Console</link></para>
<para><link xlink:href="https://bugzilla.redhat.com/show_bug.cgi?id=913607">Red Hat bug 913607</link></para>
<para><link xlink:href="http://openstack.redhat.com/forum/discussion/67/resolved-spice-support-in-rdo-grizzly/p1">SPICE support in RDO Grizzly</link></para>
</section>

15
doc/security-guide/ch034_tenant-secure-networking-best-practices.xml
View File

@ -8,7 +8,20 @@
</section>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp46080">
<title>Networking Resource Policy Engine</title>
<para>A policy engine and its configuration file, <emphasis>policy.json</emphasis>, within OpenStack Networking provides a method to provide finer grained authorization of users on tenant networking methods and objects. It is important that cloud architects and operators evaluate their design and use cases in providing users and tenants the ability to create, update, and destroy available network resources as it has a tangible effect on tenant network availability, network security, and overall OpenStack security. For a more detail explanation of OpenStack Networking policy definition, please refer to the <link xlink:href="http://docs.openstack.org/trunk/openstack-network/admin/content/ch_auth.html">Authentication and Authorization chapter</link> in the <citetitle>OpenStack Networking Administration Guide</citetitle>.</para>
<para>A policy engine and its configuration file,
<filename>policy.json</filename>, within OpenStack Networking
provides a method to provide finer grained authorization of
users on tenant networking methods and objects. It is important
that cloud architects and operators evaluate their design and
use cases in providing users and tenants the ability to create,
update, and destroy available network resources as it has a
tangible effect on tenant network availability, network
security, and overall OpenStack security. For a more detailed
explanation of OpenStack Networking policy definition, please
refer to the <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_auth.html">Authentication
and authorization section</link> in the <citetitle>OpenStack
Cloud Administrator Guide</citetitle>.</para>
<address>It is important to review the default networking resource policy and modify the policy appropriately for your security posture.</address>
<para>If your deployment of OpenStack provides multiple external access points into different security domains it is important that you limit the tenant's ability to attach multiple vNICs to multiple external access points -- this would bridge these security domains and could lead to unforseen security compromise. It is possible mitigate this risk by utilizing the host aggregates functionality provided by OpenStack Compute or through splitting the tenant VMs into multiple tenant projects with different virtual network configurations.</para>
</section>

33
doc/security-guide/ch055_security-services-for-instances.xml
View File

@ -27,7 +27,22 @@
<section xml:id="ch055_security-services-for-instances-idp128240">
<title>Scheduling Instances to Nodes</title>
<para>Before an instance is created, a host for the image instantiation must be selected. This selection is performed by the <systemitem class="service">nova-scheduler</systemitem> which determines how to dispatch compute and volume requests.</para>
<para>The default nova scheduler in Grizzly is the Filter Scheduler, although other schedulers exist (see the section <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/other-schedulers.html">Other Schedulers</link> in the <citetitle>OpenStack Compute Administration Guide</citetitle>). The filter scheduler works in collaboration with 'filters' to decide where an instance should be started. This process of host selection allows administrators to fulfil many different security requirements. Depending on the cloud deployment type for example, one could choose to have tenant instances reside on the same hosts whenever possible if data isolation was a primary concern, conversely one could attempt to have instances for a tenant reside on as many different hosts as possible for availability or fault tolerance reasons. The following diagram demonstrates how the filter scheduler works:</para>
<para>The default nova scheduler in Grizzly is the Filter
Scheduler, although other schedulers exist (see the section
<link
xlink:href="http://docs.openstack.org/trunk/config-reference/content/section_compute-scheduler.html">Scheduling</link>
in the <citetitle>OpenStack Configuration
Reference</citetitle>). The filter scheduler works in
collaboration with 'filters' to decide where an instance should
be started. This process of host selection allows administrators
to fulfil many different security requirements. Depending on the
cloud deployment type for example, one could choose to have
tenant instances reside on the same hosts whenever possible if
data isolation was a primary concern, conversely one could
attempt to have instances for a tenant reside on as many
different hosts as possible for availability or fault tolerance
reasons. The following diagram demonstrates how the filter
scheduler works:</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="400" contentwidth="550" fileref="static/filteringWorkflow1.png" format="PNG" scalefit="1"/>
</imageobject>
@ -36,12 +51,20 @@
</imageobject>
</inlinemediaobject></para>
<para>The use of scheduler filters may be used to segregate customers, data, or even discard machines of the cloud that cannot be attested as secure. This generally applies to all OpenStack projects offering a scheduler. When building a cloud, you may choose to implement scheduling filters for a variety of security-related purposes.</para>
<para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/scheduler-filters.html">Scheduler Filters</link> section of the <citetitle>OpenStack Compute Administration Guide</citetitle></para>
<para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/filter-scheduler.html">Filter Scheduler</link> section of the <citetitle>OpenStack Configuration Reference</citetitle>.</para>
<para><emphasis role="bold">Tenant Driven Whole Host Reservation</emphasis></para>
<para>There currently exists a <link xlink:href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation">blueprint for whole host reservation</link> - This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.</para>
<section xml:id="ch055_security-services-for-instances-idp140080">
<title>Host Aggregates</title>
<para>While not a filter in themselves, host aggregates allow administrators to assign key-value pairs to groups of machines. This allows cloud administrators, not users, to partition up their compute host resources. Each node can have multiple aggregates (see the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/host-aggregates.html">Host Aggregates</link> section of the <citetitle>OpenStack Compute Administration Guide</citetitle> for more information on creating and managing aggregates).</para>
<para>While not a filter in themselves, host aggregates allow
administrators to assign key-value pairs to groups of
machines. This allows cloud administrators, not users, to
partition up their compute host resources. Each node can have
multiple aggregates (see the <link
xlink:href="http://docs.openstack.org/trunk/config-reference/content/host-aggregates.html">Host
Aggregates</link> section of the <citetitle>OpenStack
Configuration Reference</citetitle> for more information on
creating and managing aggregates).</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp142048">
<title>AggregateMultiTenancyIsolation</title>
@ -77,10 +100,10 @@ wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep OK
</screen>
<para>The second option is to use the <link xlink:href="http://docs.openstack.org/trunk/openstack-compute/admin/content/creating-custom-images.html">OpenStack guide for building images</link>. In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the <link xlink:href="http://iase.disa.mil/stigs/os/unix/red_hat.html">RHEL6 STIG</link>.</para>
<para>The second option is to use the <link xlink:href="http://docs.openstack.org/trunk/image-guide/content/"><citetitle>OpenStack Virtual Maschine Image Guide</citetitle></link>. In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the <link xlink:href="http://iase.disa.mil/stigs/os/unix/red_hat.html">RHEL6 STIG</link>.</para>
<para>The final option is to use an automated image builder. The following example uses the Oz image builder. The OpenStack community has recently created a newer tool worth investigating: disk-image-builder. We have not evaluated this tool from a security perspective.</para>
<para>Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section <emphasis>AC-19(d) in</emphasis> Oz.</para>
<screen> 
<screen>
&lt;template&gt;
&lt;name&gt;centos64&lt;/name&gt;
&lt;os&gt;

8
doc/training-guide/module001-ch011-block-storage.xml
View File

@ -54,10 +54,8 @@
will be on the persistent volume and thus state will be maintained
even if the instance it shutdown. Details of this configuration
are discussed in the<link
xlink:href="http://docs.openstack.org/cli/quick-start/content/"
/><link
xlink:href="http://docs.openstack.org/cli/quick-start/content/"
>OpenStack Clients Guide</link>.</para>
xlink:href="http://docs.openstack.org/user-guide/content/"
>OpenStack End User Guide</link>.</para>
<para>Volumes do not provide concurrent access from multiple
instances. For that you need either a traditional network
filesystem like NFS or CIFS or a cluster filesystem such as
@ -248,4 +246,4 @@
volume.</para>
</listitem>
</itemizedlist>
</chapter>
</chapter>