From 15ceb92a08a6c33db527a8ba028b901598f3fc08 Mon Sep 17 00:00:00 2001 From: Christian Berendt Date: Fri, 2 May 2014 15:13:56 +0200 Subject: [PATCH] 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 to . Removed "In order to" (useless phrase). Change-Id: I4ecb1927e8291029db9bc0d743a3061138b974c8 --- doc/common/section_cli_nova_secgroups.xml | 356 ++++++++++-------- doc/common/section_dashboard_sessions.xml | 4 +- doc/common/section_keystone-external-auth.xml | 27 +- doc/common/section_user-data.xml | 41 +- 4 files changed, 244 insertions(+), 184 deletions(-) diff --git a/doc/common/section_cli_nova_secgroups.xml b/doc/common/section_cli_nova_secgroups.xml index 30544e534a..56675bff4e 100644 --- a/doc/common/section_cli_nova_secgroups.xml +++ b/doc/common/section_cli_nova_secgroups.xml @@ -1,185 +1,245 @@ -
- Add security group and rules - The following procedure shows you how to add security - groups and add rules to the default security group. -
- Add or delete a security group - Security groups can be added with nova - secgroup-create. - The following example shows the creation of the - security group secure1. After the - group is created, it can be viewed in the security - group list. - + Add security group and rules + The following procedure shows you how to add security groups + and add rules to the default security group. +
+ Add or delete a security group + Use the nova secgroup-create command + to add security groups. + The following example shows how to create the + secure1 security group: $ nova secgroup-create secure1 "Test security group" +---------+---------------------+ | Name | Description | +---------+---------------------+ | secure1 | Test security group | -+---------+---------------------+ - -$ nova secgroup-list ++---------+---------------------+ + After you create the security group, you can view it in + the security group list: + $ nova secgroup-list +---------+---------------------+ | Name | Description | +---------+---------------------+ | default | default | | secure1 | Test security group | +---------+---------------------+ - -Security groups can be deleted with nova secgroup-delete. The default - security group cannot be deleted. The default security group contains these initial - settings: - - All the traffic originated by the instances (outbound traffic) is - allowed - - - All the traffic destined to instances - (inbound traffic) is denied - - - All the instances inside the group are allowed to talk to each - other - - - - You can add extra rules into the default security group for handling the egress - traffic. Rules are ingress only at this time. - - - In the following example, the group - secure1 is deleted. When you - view the security group list, it no longer - appears. - - $ nova secgroup-delete secure1 + Use the nova secgroup-delete command + to delete security groups. You cannot delete the default + security group. The default security group has these + initial settings: + + + All the traffic originated by the instances + (outbound traffic) is allowed + + + All the traffic destined to instances (inbound + traffic) is denied + + + All the instances inside the group are allowed + to talk to each other + + + + You can add extra rules into the default security + group for handling the egress traffic. Rules are + ingress only at this time. + + The following example deletes the + secure1 group. When you view the + security group list, it no longer appears: + $ nova secgroup-delete secure1 $ nova secgroup-list +---------+-------------+ | Name | Description | +---------+-------------+ | default | default | +---------+-------------+ - -
-
- Modify security group rules - The security group rules control the incoming traffic that is allowed to the instances - in the group, while all outbound traffic is automatically allowed. - It is not possible to change the default outbound behaviour. - 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 : - - <secgroup> ID of security group. - - - <ip_proto> IP protocol (icmp, tcp, udp). - - - <from_port> Port at start of range. - - - <to_port> Port at end of range. - - - <cidr> CIDR for address range. - - - For ICMP rules, instead of specifying a begin and end port, you specify the - allowed ICMP code and ICMP type: - - <secgroup> ID of security group. - - - <ip_proto> IP protocol (with icmp specified). - - - <ICMP_code> The ICMP code. - - - <ICMP_type> The ICMP type. - - - <cidr> CIDR for the source address range. - - - - Entering "-1" for both code and type - indicates that all ICMP codes and types should - be allowed. - - - - - The CIDR notation - 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 base IP and 27 as the - suffix. 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. - - - 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:$ nova secgroup-add-rule default tcp 80 80 0.0.0.0/0 +
+
+ Modify security group rules + The security group rules control the incoming traffic + that can access the instances in the group, while all + outbound traffic is automatically allowed. + You cannot change the default outbound + behavior. + 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: + + + <secgroup> + + ID of security group. + + + + <ip_proto> + + IP protocol (icmp, tcp, udp). + + + + <from_port> + + Port at start of range. + + + + <to_port> + + Port at end of range. + + + + <cidr> + + CIDR for address range. + + + + For ICMP rules, instead of specifying a begin and end + port, you specify the allowed ICMP code and ICMP + type: + + + <secgroup> + + ID of security group. + + + + <ip_proto> + + IP protocol (with icmp specified). + + + + <ICMP_code> + + The ICMP code. + + + + <ICMP_type> + + The ICMP type. + + + + <cidr> + + CIDR for the source address range. + + + + + Entering -1 for both code and + type indicates that all ICMP codes and types are + allowed. + + + The CIDR notation + 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 base IP and + 27 as the suffix. Because you use an IPV4 + format, only 5 bits are available for the host part + (32 minus 27). The 0.0.0.0/0 + notation means you allow the entire IPV4 range, which + allows all addresses. + + For example, to allow any IP address to access a web + server running on one of your instances inside the default + security group: + $ nova secgroup-add-rule default tcp 80 80 0.0.0.0/0 +-------------+-----------+---------+-----------+--------------+ | IP Protocol | From Port | To Port | IP Range | Source Group | +-------------+-----------+---------+-----------+--------------+ | tcp | 80 | 80 | 0.0.0.0/0 | | +-------------+-----------+---------+-----------+--------------+ - - In order to allow any IP address to ping an instance - inside the default security group (Code 0, Type 8 for - the ECHO - request.):$ nova secgroup-add-rule default icmp 0 8 0.0.0.0/0 + To allow any IP address to ping an instance inside the + default security group (Code 0, Type 8 for the ECHO + request): + $ nova secgroup-add-rule default icmp 0 8 0.0.0.0/0 +-------------+-----------+---------+-----------+--------------+ | IP Protocol | From Port | To Port | IP Range | Source Group | +-------------+-----------+---------+-----------+--------------+ | icmp | 0 | 8 | 0.0.0.0/0 | | +-------------+-----------+---------+-----------+--------------+ - - - $ nova secgroup-list-rules default + $ nova secgroup-list-rules default +-------------+-----------+---------+-----------+--------------+ | 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 | | +-------------+-----------+---------+-----------+--------------+ - - In order to delete a rule, you need to specify the exact same arguments you used - to create it: - - <secgroup> ID of security group. - - - <ip_proto> IP protocol (icmp, tcp, udp). - - - <from_port> Port at start of range. - - - <to_port> Port at end of range. - - - <cidr> CIDR for address range. - - $ nova secgroup-delete-rule default tcp 80 80 0.0.0.0/0 - -
- + To delete a rule, you must specify exactly the same + arguments that you used to create it: + + + <secgroup> + + ID of security group. + + + + <ip_proto> + + IP protocol (icmp, tcp, udp). + + + + <from_port> + + Port at start of range. + + + + <to_port> + + Port at end of range. + + + + <cidr> + + CIDR for address range. + + + + $ nova secgroup-delete-rule default tcp 80 80 0.0.0.0/0 +
diff --git a/doc/common/section_dashboard_sessions.xml b/doc/common/section_dashboard_sessions.xml index b94c6b23eb..f0e2cca2e1 100644 --- a/doc/common/section_dashboard_sessions.xml +++ b/doc/common/section_dashboard_sessions.xml @@ -123,7 +123,7 @@ CACHES = { mysql> CREATE DATABASE dash; - Create a MySQL user for the newly-created dash + Create a MySQL user for the newly created dash database that has full control of the database. Replace DASH_DBPASS with a password for the new user: @@ -158,7 +158,7 @@ DATABASES = { After configuring the local_settings as shown, you can run the manage.py syncdb command to populate this - newly-created database. + newly created database. $ /usr/share/openstack-dashboard/manage.py syncdb Note on openSUSE the path is /srv/www/openstack-dashboard/manage.py. diff --git a/doc/common/section_keystone-external-auth.xml b/doc/common/section_keystone-external-auth.xml index 5785bb35c9..d1ebbd7162 100644 --- a/doc/common/section_keystone-external-auth.xml +++ b/doc/common/section_keystone-external-auth.xml @@ -4,25 +4,24 @@ xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0"> - External authentication with the Identity - Service - When the Identity Service runs in apache-httpd, - 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 + External authentication with Identity + When Identity runs in apache-httpd, 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.
Use HTTPD authentication 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 REMOTE_USER 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 - apache-httpd. + authentication. Identity can allow the web server to + perform the authentication. The web server then passes the + authenticated user to Identity by using the + REMOTE_USER 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 + apache-httpd.
Use X.509 diff --git a/doc/common/section_user-data.xml b/doc/common/section_user-data.xml index d952c37da0..143f21aa95 100644 --- a/doc/common/section_user-data.xml +++ b/doc/common/section_user-data.xml @@ -90,17 +90,19 @@ >Ubuntu community documentation for details about how to use cloud-init. Some basic examples are provided here. - cloud-init supports several different - input formats for user data. Two commonly used formats are: - - Shell scripts (starts with - #!) - - - Cloud config files (starts with - #cloud-config) - - + cloud-init supports several input + formats for user data. Two commonly used formats + are: + + + Shell scripts (starts with + #!) + + + Cloud config files (starts with + #cloud-config) + + Run a shell script on boot @@ -137,7 +139,7 @@ adduser --disabled-password --gecos "" clouduser hostname: mynode fqdn: mynode.example.com manage_etc_hosts: true - + Example: Configure instances with Puppet @@ -146,9 +148,9 @@ manage_etc_hosts: true 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, would configure the instance to contact a Puppet server at - puppetmaster.example.org and verify its identity using a - certificate. - #cloud-config + puppetmaster.example.org and verify its identity by using + a certificate. + #cloud-config puppet: conf: agent: @@ -166,7 +168,7 @@ puppet: SIb3DQEBBQUAA4GBAH/rxlUIjwNb3n7TXJcDJ6MMHUlwjr03BDJXKb34Ulndkpaf +GAlzPXWa7bO908M9I8RnPfvtKnteLbvgTK+h+zX1XCty+S2EQWk29i2AdoqOTxb hppiGMp0tT5Havu4aceCXiy2crVcudj3NFciy8X66SoECemW9UYDCb9T5D0d - -----END CERTIFICATE----- + -----END CERTIFICATE----- Example: Configure instances with Chef @@ -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 https://chefserver.example.com:4000, - and installs - Apache:#cloud-config + and installs Apache: + #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" - + keepalive: "off"