fixed typos found by RETF in common directory
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:
parent
ec22ae0689
commit
15ceb92a08
@ -1,63 +1,58 @@
|
||||
<?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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>+---------+-------------+
|
||||
@ -65,94 +60,140 @@
|
||||
+---------+-------------+
|
||||
| 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>
|
||||
<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"
|
||||
><secgroup></emphasis></term>
|
||||
<listitem>
|
||||
<para><secgroup> ID of security group.</para>
|
||||
<para>ID of security group.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><ip_proto></emphasis></term>
|
||||
<listitem>
|
||||
<para><ip_proto> IP protocol (icmp, tcp, udp).</para>
|
||||
<para>IP protocol (icmp, tcp, udp).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><from_port></emphasis></term>
|
||||
<listitem>
|
||||
<para><from_port> Port at start of range.</para>
|
||||
<para>Port at start of range.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><to_port></emphasis></term>
|
||||
<listitem>
|
||||
<para><to_port> Port at end of range.</para>
|
||||
<para>Port at end of range.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><cidr></emphasis></term>
|
||||
<listitem>
|
||||
<para><cidr> CIDR for address range.</para>
|
||||
<para>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>
|
||||
</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"
|
||||
><secgroup></emphasis></term>
|
||||
<listitem>
|
||||
<para><secgroup> ID of security group.</para>
|
||||
<para>ID of security group.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><ip_proto></emphasis></term>
|
||||
<listitem>
|
||||
<para><ip_proto> IP protocol (with icmp specified).</para>
|
||||
<para>IP protocol (with icmp specified).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><ICMP_code></emphasis></term>
|
||||
<listitem>
|
||||
<para><ICMP_code> The ICMP code.</para>
|
||||
<para>The ICMP code.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><ICMP_type></emphasis></term>
|
||||
<listitem>
|
||||
<para><ICMP_type> The ICMP type.</para>
|
||||
<para>The ICMP type.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><cidr></emphasis></term>
|
||||
<listitem>
|
||||
<para><cidr> CIDR for the source address range.</para>
|
||||
<para>CIDR for the source address range.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<note>
|
||||
<para>Entering "-1" for both code and type
|
||||
indicates that all ICMP codes and types should
|
||||
be allowed.</para>
|
||||
<para>Entering <literal>-1</literal> for both code and
|
||||
type indicates that all ICMP codes and types are
|
||||
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>
|
||||
<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>
|
||||
<computeroutput>+-------------+-----------+---------+-----------+--------------+
|
||||
| IP Protocol | From Port | To Port | IP Range | Source Group |
|
||||
@ -160,26 +201,45 @@
|
||||
| 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>
|
||||
<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"
|
||||
><secgroup></emphasis></term>
|
||||
<listitem>
|
||||
<para><secgroup> ID of security group.</para>
|
||||
<para>ID of security group.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><ip_proto></emphasis></term>
|
||||
<listitem>
|
||||
<para><ip_proto> IP protocol (icmp, tcp, udp).</para>
|
||||
<para>IP protocol (icmp, tcp, udp).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><from_port></emphasis></term>
|
||||
<listitem>
|
||||
<para><from_port> Port at start of range.</para>
|
||||
<para>Port at start of range.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><to_port></emphasis></term>
|
||||
<listitem>
|
||||
<para><to_port> Port at end of range.</para>
|
||||
<para>Port at end of range.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold"
|
||||
><cidr></emphasis></term>
|
||||
<listitem>
|
||||
<para><cidr> CIDR for address range.</para>
|
||||
<para>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>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<screen><prompt>$</prompt> <userinput>nova secgroup-delete-rule default tcp 80 80 0.0.0.0/0</userinput></screen>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
@ -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>
|
||||
|
@ -4,24 +4,23 @@
|
||||
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
|
||||
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">
|
||||
|
@ -90,8 +90,10 @@
|
||||
>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>
|
||||
<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>
|
||||
@ -100,7 +102,7 @@
|
||||
<para>Cloud config files (starts with
|
||||
<literal>#cloud-config</literal>)</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
</itemizedlist>
|
||||
</simplesect>
|
||||
<simplesect>
|
||||
<title>Run a shell script on boot</title>
|
||||
@ -146,8 +148,8 @@ 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.
|
||||
puppetmaster.example.org and verify its identity by using
|
||||
a certificate.</para>
|
||||
<programlisting>#cloud-config
|
||||
puppet:
|
||||
conf:
|
||||
@ -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>
|
||||
|
Loading…
x
Reference in New Issue
Block a user