openstack/openstack-manuals
Code Issues Proposed changes

fixed typos found by RETF in common directory

Browse Source 
Just wrote a script like Topy using the RETF rules provided by
Wikipedia. A first test run on the common directory found some
more typos.

The script is available at the following URL at the moment.

https://gist.github.com/berendt/5ae38f2f1d5bd6b883d3

Also updated to active voice and changed <itemizedlist>
to <variablelist>. Removed "In order to" (useless phrase).

Change-Id: I4ecb1927e8291029db9bc0d743a3061138b974c8
This commit is contained in:
Christian Berendt 2014-05-02 15:13:56 +02:00 committed by Diane Fleming
parent ec22ae0689
commit 15ceb92a08
4 changed files with 244 additions and 184 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

356
doc/common/section_cli_nova_secgroups.xml
View File

@ -1,185 +1,245 @@
<?xml version="1.0" encoding="UTF-8"?>
<section
xmlns="http://docbook.org/ns/docbook"
<section 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"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="nova_cli_security_groups">
<title>Add security group and rules</title>
<para>The following procedure shows you how to add security
groups and add rules to the default security group.</para>
<section xml:id="secgroup_add-delete">
<title>Add or delete a security group</title>
<para>Security groups can be added with <command>nova
secgroup-create</command>.</para>
<para>The following example shows the creation of the
security group <literal>secure1</literal>. After the
group is created, it can be viewed in the security
group list.</para>
<para>
<title>Add security group and rules</title>
<para>The following procedure shows you how to add security groups
and add rules to the default security group.</para>
<section xml:id="secgroup_add-delete">
<title>Add or delete a security group</title>
<para>Use the <command>nova secgroup-create</command> command
to add security groups.</para>
<para>The following example shows how to create the
<literal>secure1</literal> security group:</para>
<screen><prompt>$</prompt> <userinput>nova secgroup-create secure1 "Test security group"</userinput>
<computeroutput>+---------+---------------------+
| Name | Description |
+---------+---------------------+
| secure1 | Test security group |
+---------+---------------------+
</computeroutput>
<prompt>$</prompt> <userinput>nova secgroup-list</userinput>
+---------+---------------------+</computeroutput></screen>
<para>After you create the security group, you can view it in
the security group list:</para>
<screen><prompt>$</prompt> <userinput>nova secgroup-list</userinput>
<computeroutput>+---------+---------------------+
| Name | Description |
+---------+---------------------+
| default | default |
| secure1 | Test security group |
+---------+---------------------+</computeroutput></screen>
</para>
<para>Security groups can be deleted with <command>nova secgroup-delete</command>. The default
security group cannot be deleted. The default security group contains these initial
settings:<itemizedlist>
<listitem>
<para>All the traffic originated by the instances (outbound traffic) is
allowed</para>
</listitem>
<listitem>
<para>All the traffic destined to instances
(inbound traffic) is denied</para>
</listitem>
<listitem>
<para>All the instances inside the group are allowed to talk to each
other</para>
</listitem>
</itemizedlist>
<note>
<para>You can add extra rules into the default security group for handling the egress
traffic. Rules are ingress only at this time.</para>
</note>
</para>
<para>In the following example, the group
<literal>secure1</literal> is deleted. When you
view the security group list, it no longer
appears.</para>
<para>
<screen><prompt>$</prompt> <userinput>nova secgroup-delete secure1</userinput>
<para>Use the <command>nova secgroup-delete</command> command
to delete security groups. You cannot delete the default
security group. The default security group has these
initial settings:</para>
<itemizedlist>
<listitem>
<para>All the traffic originated by the instances
(outbound traffic) is allowed</para>
</listitem>
<listitem>
<para>All the traffic destined to instances (inbound
traffic) is denied</para>
</listitem>
<listitem>
<para>All the instances inside the group are allowed
to talk to each other</para>
</listitem>
</itemizedlist>
<note>
<para>You can add extra rules into the default security
group for handling the egress traffic. Rules are
ingress only at this time.</para>
</note>
<para>The following example deletes the
<literal>secure1</literal> group. When you view the
security group list, it no longer appears:</para>
<screen><prompt>$</prompt> <userinput>nova secgroup-delete secure1</userinput>
<prompt>$</prompt> <userinput>nova secgroup-list</userinput>
<computeroutput>+---------+-------------+
| Name | Description |
+---------+-------------+
| default | default |
+---------+-------------+</computeroutput></screen>
</para>
</section>
<section xml:id="secgroup_rules">
<title>Modify security group rules</title>
<para>The security group rules control the incoming traffic that is allowed to the instances
in the group, while all outbound traffic is automatically allowed. <note>
<para>It is not possible to change the default outbound behaviour.</para>
</note>Every security group rule is a policy which allows you to specify inbound
connections that are allowed to access the instance, by source address, destination
port and IP protocol,(TCP, UDP or ICMP). Currently, ipv6 and other protocols cannot
be managed with the security rules, making them permitted by default. To manage
such, you can deploy a firewall in front of your OpenStack cloud to control other
types of traffic. The command requires the following arguments for both TCP and UDP
rules : <itemizedlist>
<listitem>
<para>&lt;secgroup&gt; ID of security group.</para>
</listitem>
<listitem>
<para>&lt;ip_proto&gt; IP protocol (icmp, tcp, udp).</para>
</listitem>
<listitem>
<para>&lt;from_port&gt; Port at start of range.</para>
</listitem>
<listitem>
<para>&lt;to_port&gt; Port at end of range.</para>
</listitem>
<listitem>
<para>&lt;cidr&gt; CIDR for address range.</para>
</listitem>
</itemizedlist></para>
<para>For ICMP rules, instead of specifying a begin and end port, you specify the
allowed ICMP code and ICMP type: <itemizedlist>
<listitem>
<para>&lt;secgroup&gt; ID of security group.</para>
</listitem>
<listitem>
<para>&lt;ip_proto&gt; IP protocol (with icmp specified).</para>
</listitem>
<listitem>
<para>&lt;ICMP_code&gt; The ICMP code.</para>
</listitem>
<listitem>
<para>&lt;ICMP_type&gt; The ICMP type.</para>
</listitem>
<listitem>
<para>&lt;cidr&gt; CIDR for the source address range.</para>
</listitem>
</itemizedlist>
<note>
<para>Entering "-1" for both code and type
indicates that all ICMP codes and types should
be allowed.</para>
</note>
</para>
<para>
<note>
<title>The CIDR notation</title>
<para>That notation allows you to specify a base IP address and a suffix that
designates the number of significant bits in the IP address used to identify
the network. For example, by specifying a 88.170.60.32/27, you specify
88.170.60.32 as the <emphasis role="bold">base IP</emphasis> and 27 as the
<emphasis role="bold">suffix</emphasis>. Since you use an IPV4 format,
there are only 5 bits available for the host part (32 minus 27). The
0.0.0.0/0 notation means you allow the entire IPV4 range, meaning allowing
all addresses.</para>
</note></para>
<para>For example, in order to allow any IP address to
access a web server running on one of your instances
inside the default security
group:<screen><prompt>$</prompt> <userinput>nova secgroup-add-rule default tcp 80 80 0.0.0.0/0</userinput>
</section>
<section xml:id="secgroup_rules">
<title>Modify security group rules</title>
<para>The security group rules control the incoming traffic
that can access the instances in the group, while all
outbound traffic is automatically allowed. <note>
<para>You cannot change the default outbound
behavior.</para>
</note>Every security group rule is a policy that allows
you to specify inbound connections that can access the
instance by source address, destination port, and IP
protocol (TCP, UDP or ICMP). Currently, you cannot manage
ipv6 and other protocols through the security rules,
making them permitted by default. To manage such
protocols, you can deploy a firewall in front of your
OpenStack cloud to control other types of traffic. The
command requires the following arguments for both TCP and
UDP rules:</para>
<variablelist wordsize="10">
<varlistentry>
<term><emphasis role="bold"
>&lt;secgroup&gt;</emphasis></term>
<listitem>
<para>ID of security group.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;ip_proto&gt;</emphasis></term>
<listitem>
<para>IP protocol (icmp, tcp, udp).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;from_port&gt;</emphasis></term>
<listitem>
<para>Port at start of range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;to_port&gt;</emphasis></term>
<listitem>
<para>Port at end of range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;cidr&gt;</emphasis></term>
<listitem>
<para>CIDR for address range.</para>
</listitem>
</varlistentry>
</variablelist>
<para>For ICMP rules, instead of specifying a begin and end
port, you specify the allowed ICMP code and ICMP
type:</para>
<variablelist wordsize="10">
<varlistentry>
<term><emphasis role="bold"
>&lt;secgroup&gt;</emphasis></term>
<listitem>
<para>ID of security group.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;ip_proto&gt;</emphasis></term>
<listitem>
<para>IP protocol (with icmp specified).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;ICMP_code&gt;</emphasis></term>
<listitem>
<para>The ICMP code.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;ICMP_type&gt;</emphasis></term>
<listitem>
<para>The ICMP type.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;cidr&gt;</emphasis></term>
<listitem>
<para>CIDR for the source address range.</para>
</listitem>
</varlistentry>
</variablelist>
<note>
<para>Entering <literal>-1</literal> for both code and
type indicates that all ICMP codes and types are
allowed.</para>
</note>
<note>
<title>The CIDR notation</title>
<para>That notation allows you to specify a base IP
address and a suffix that designates the number of
significant bits in the IP address used to identify
the network. For example, by specifying a
<literal>88.170.60.32/27</literal>, you specify
<literal>88.170.60.32</literal> as the <emphasis
role="bold">base IP</emphasis> and
<literal>27</literal> as the <emphasis role="bold"
>suffix</emphasis>. Because you use an IPV4
format, only 5 bits are available for the host part
(32 minus 27). The <literal>0.0.0.0/0</literal>
notation means you allow the entire IPV4 range, which
allows all addresses.</para>
</note>
<para>For example, to allow any IP address to access a web
server running on one of your instances inside the default
security group:</para>
<screen><prompt>$</prompt> <userinput>nova secgroup-add-rule default tcp 80 80 0.0.0.0/0</userinput>
<computeroutput>+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+</computeroutput></screen>
</para>
<para>In order to allow any IP address to ping an instance
inside the default security group (Code 0, Type 8 for
the ECHO
request.):<screen><prompt>$</prompt> <userinput>nova secgroup-add-rule default icmp 0 8 0.0.0.0/0</userinput>
<para>To allow any IP address to ping an instance inside the
default security group (Code 0, Type 8 for the ECHO
request):</para>
<screen><prompt>$</prompt> <userinput>nova secgroup-add-rule default icmp 0 8 0.0.0.0/0</userinput>
<computeroutput>+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp | 0 | 8 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+</computeroutput></screen>
</para>
<para>
<screen><prompt>$</prompt> <userinput>nova secgroup-list-rules default</userinput>
<screen><prompt>$</prompt> <userinput>nova secgroup-list-rules default</userinput>
<computeroutput>+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
| icmp | 0 | 8 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+</computeroutput></screen>
</para>
<para>In order to delete a rule, you need to specify the exact same arguments you used
to create it:<itemizedlist>
<listitem>
<para>&lt;secgroup&gt; ID of security group.</para>
</listitem>
<listitem>
<para>&lt;ip_proto&gt; IP protocol (icmp, tcp, udp).</para>
</listitem>
<listitem>
<para>&lt;from_port&gt; Port at start of range.</para>
</listitem>
<listitem>
<para>&lt;to_port&gt; Port at end of range.</para>
</listitem>
<listitem>
<para>&lt;cidr&gt; CIDR for address range.</para>
</listitem>
</itemizedlist><screen><prompt>$</prompt> <userinput>nova secgroup-delete-rule default tcp 80 80 0.0.0.0/0</userinput></screen>
</para>
</section>
<para>To delete a rule, you must specify exactly the same
arguments that you used to create it:</para>
<variablelist wordsize="10">
<varlistentry>
<term><emphasis role="bold"
>&lt;secgroup&gt;</emphasis></term>
<listitem>
<para>ID of security group.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;ip_proto&gt;</emphasis></term>
<listitem>
<para>IP protocol (icmp, tcp, udp).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;from_port&gt;</emphasis></term>
<listitem>
<para>Port at start of range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;to_port&gt;</emphasis></term>
<listitem>
<para>Port at end of range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold"
>&lt;cidr&gt;</emphasis></term>
<listitem>
<para>CIDR for address range.</para>
</listitem>
</varlistentry>
</variablelist>
<screen><prompt>$</prompt> <userinput>nova secgroup-delete-rule default tcp 80 80 0.0.0.0/0</userinput></screen>
</section>
</section>

4
doc/common/section_dashboard_sessions.xml
View File

@ -123,7 +123,7 @@ CACHES = {
<para><screen><prompt>mysql></prompt> <userinput>CREATE DATABASE dash;</userinput></screen></para>
</step>
<step>
<para>Create a MySQL user for the newly-created dash
<para>Create a MySQL user for the newly created dash
database that has full control of the
database. Replace <replaceable>DASH_DBPASS</replaceable> with
a password for the new user:</para>
@ -158,7 +158,7 @@ DATABASES = {
<para>After configuring the <filename>local_settings</filename>
as shown, you can run the <command>manage.py
syncdb</command> command to populate this
newly-created database.</para>
newly created database.</para>
<screen><prompt>$</prompt> <userinput>/usr/share/openstack-dashboard/manage.py syncdb</userinput></screen>
<para>Note on openSUSE the path is <filename>/srv/www/openstack-dashboard/manage.py</filename>.
</para>

27
doc/common/section_keystone-external-auth.xml
View File

@ -4,25 +4,24 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0">
<?dbhtml stop-chunking?>
<title>External authentication with the Identity
Service</title>
<para>When the Identity Service runs in <literal>apache-httpd</literal>,
you can use external authentication methods that differ from
the authentication provided by the identity store back-end.
For example, you can use an SQL identity back-end together with
<title>External authentication with Identity</title>
<para>When Identity runs in <literal>apache-httpd</literal>, you
can use external authentication methods that differ from the
authentication provided by the identity store back end. For
example, you can use an SQL identity back end together with
X.509 authentication, Kerberos, and so on instead of using the
user name and password combination.</para>
<section xml:id="keystone-httpd-auth">
<title>Use HTTPD authentication</title>
<para>Web servers, like Apache HTTP, support many methods of
authentication. The Identity Service can allow the web
server to perform the authentication. The web server then
passes the authenticated user to the Identity Service by
using the <literal>REMOTE_USER</literal> environment variable.
This user must already exist in the Identity Service
back-end so as to get a token from the controller. To use
this method, the Identity Service should run on
<literal>apache-httpd</literal>.</para>
authentication. Identity can allow the web server to
perform the authentication. The web server then passes the
authenticated user to Identity by using the
<literal>REMOTE_USER</literal> environment variable.
This user must already exist in the Identity back end to
get a token from the controller. To use this method,
Identity should run on
<literal>apache-httpd</literal>.</para>
</section>
<section xml:id="keystone-x509-auth">
<title>Use X.509</title>

41
doc/common/section_user-data.xml
View File

@ -90,17 +90,19 @@
>Ubuntu community documentation</link> for details
about how to use <package>cloud-init</package>. Some basic
examples are provided here.</para>
<para><package>cloud-init</package> supports several different
input formats for user data. Two commonly used formats are:<itemizedlist>
<listitem>
<para>Shell scripts (starts with
<literal>#!</literal>)</para>
</listitem>
<listitem>
<para>Cloud config files (starts with
<literal>#cloud-config</literal>)</para>
</listitem>
</itemizedlist></para>
<para><package>cloud-init</package> supports several input
formats for user data. Two commonly used formats
are:</para>
<itemizedlist>
<listitem>
<para>Shell scripts (starts with
<literal>#!</literal>)</para>
</listitem>
<listitem>
<para>Cloud config files (starts with
<literal>#cloud-config</literal>)</para>
</listitem>
</itemizedlist>
</simplesect>
<simplesect>
<title>Run a shell script on boot</title>
@ -137,7 +139,7 @@ adduser --disabled-password --gecos "" clouduser</programlisting>
hostname: mynode
fqdn: mynode.example.com
manage_etc_hosts: true</programlisting>
</para>
</para>
</simplesect>
<simplesect>
<title>Example: Configure instances with Puppet</title>
@ -146,9 +148,9 @@ manage_etc_hosts: true</programlisting>
xlink:href="http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-puppet.txt"
>doc/examples/cloud-config-puppet.txt</link>, would
configure the instance to contact a Puppet server at
puppetmaster.example.org and verify its identity using a
certificate.
<programlisting>#cloud-config
puppetmaster.example.org and verify its identity by using
a certificate.</para>
<programlisting>#cloud-config
puppet:
conf:
agent:
@ -166,7 +168,7 @@ puppet:
SIb3DQEBBQUAA4GBAH/rxlUIjwNb3n7TXJcDJ6MMHUlwjr03BDJXKb34Ulndkpaf
+GAlzPXWa7bO908M9I8RnPfvtKnteLbvgTK+h+zX1XCty+S2EQWk29i2AdoqOTxb
hppiGMp0tT5Havu4aceCXiy2crVcudj3NFciy8X66SoECemW9UYDCb9T5D0d
-----END CERTIFICATE-----</programlisting></para>
-----END CERTIFICATE-----</programlisting>
</simplesect>
<simplesect>
<title>Example: Configure instances with Chef</title>
@ -177,8 +179,8 @@ puppet:
intended for use in an Ubuntu image, adds the Chef apt
repository, installs Chef, connects to a Chef server at
<literal>https://chefserver.example.com:4000</literal>,
and installs
Apache:<programlisting>#cloud-config
and installs Apache:</para>
<programlisting>#cloud-config
apt_sources:
- source: "deb http://apt.opscode.com/ $RELEASE-0.10 main"
key: |
@ -230,7 +232,6 @@ chef:
apache:
prefork:
maxclients: 100
keepalive: "off"</programlisting></para>
keepalive: "off"</programlisting>
</simplesect>
</section>