cleaning up whitespaces
Removing more whitespaces found by the new validation method. https://review.openstack.org/#/c/40414/ is workable after merging this change. Patchset fixes missing periods. Change-Id: I95b866cc3dfdd7fd71afb98f9b4f78a3e484504a
This commit is contained in:
Christian Berendt
annegentle
parent
2387fc040f
commit
588d397e8f
@ -461,7 +461,7 @@
|
||||
installations that need to support euca2ools. The
|
||||
euca2ools tools talk to nova-objectore in “S3 language”
|
||||
and <systemitem class="service">nova-objectstore</systemitem> translates S3 requests into glance
|
||||
requests </para>
|
||||
requests.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The <code>euca2ools</code> client is not an
|
||||
|
||||
@ -4,13 +4,15 @@
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="troubleshooting-openstack-compute">
|
||||
<title>Troubleshooting OpenStack Compute</title>
|
||||
<para>Common problems for Compute typically involve misconfigured networking or credentials that are not sourced properly in the environment. Also, most flat networking configurations do not enable ping or ssh from a compute node to the instances running on that node. Another common problem is trying to run 32-bit images on a 64-bit compute node. This section offers more information about how to troubleshoot Compute.</para>
|
||||
<section xml:id="log-files-for-openstack-compute"><title>Log files for OpenStack Compute</title><para>Log files are stored in /var/log/nova and there is a log file for each service, for example
|
||||
nova-compute.log. You can format the log strings using options for the nova.log
|
||||
module. The options used to set format strings are: logging_context_format_string
|
||||
and logging_default_format_string. If the log level is set to debug, you can also
|
||||
specify logging_debug_format_suffix to append extra formatting. For information
|
||||
about what variables are available for the formatter see:
|
||||
http://docs.python.org/library/logging.html#formatter </para>
|
||||
<section xml:id="log-files-for-openstack-compute"><title>Log files for OpenStack Compute</title><para>Log files are stored in /var/log/nova and there is a log file for each
|
||||
service, for example nova-compute.log. You can format the log
|
||||
strings using options for the nova.log module. The options used to
|
||||
set format strings are: logging_context_format_string and
|
||||
logging_default_format_string. If the log level is set to debug, you
|
||||
can also specify logging_debug_format_suffix to append extra
|
||||
formatting. For information about what variables are available for
|
||||
the formatter see:
|
||||
http://docs.python.org/library/logging.html#formatter.</para>
|
||||
<para>You have two options for logging for OpenStack Compute based on configuration
|
||||
settings. In nova.conf, include the logfile option to enable logging. Alternatively
|
||||
you can set use_syslog=1, and then the nova daemon logs to syslog.</para></section>
|
||||
|
||||
@ -1198,7 +1198,8 @@ firewall_driver=nova.virt.xenapi.firewall.Dom0IptablesFirewallDriver</programlis
|
||||
the network interfce on the VM running the
|
||||
OpenStack services.</para>
|
||||
<para>With VLAN networking and the XenAPI driver, the
|
||||
following things happen when you start a VM: <itemizedlist>
|
||||
following things happen when you start a VM:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>First the XenServer network is
|
||||
attached to the appropriate physical
|
||||
@ -1224,7 +1225,8 @@ firewall_driver=nova.virt.xenapi.firewall.Dom0IptablesFirewallDriver</programlis
|
||||
</para>
|
||||
<para>To help understand VLAN networking with the
|
||||
XenAPI further, here are some important things to
|
||||
note: <itemizedlist>
|
||||
note:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>A physical interface (PIF)
|
||||
identified either by (A) the
|
||||
@ -1365,7 +1367,6 @@ fixed_ip_disassociate_timeout=1209600</programlisting></para>
|
||||
<section xml:id="cloudpipe-per-project-vpns">
|
||||
<title>Cloudpipe — Per Project Vpns</title>
|
||||
|
||||
|
||||
<para>Cloudpipe is a method for connecting end users to
|
||||
their project instances in VLAN networking mode.</para>
|
||||
<para>The support code for cloudpipe implements admin
|
||||
@ -1378,13 +1379,11 @@ fixed_ip_disassociate_timeout=1209600</programlisting></para>
|
||||
project without exposing those machines to the public
|
||||
internet.</para>
|
||||
<para>The cloudpipe image is basically just a Linux
|
||||
|
||||
instance with openvpn installed. It needs a simple
|
||||
script to grab user data from the metadata server, b64
|
||||
decode it into a zip file, and run the autorun.sh
|
||||
script from inside the zip. The autorun script will
|
||||
configure and run openvpn to run using the data from
|
||||
|
||||
nova.</para>
|
||||
<para>It is also useful to have a cron script that will
|
||||
periodically re download the metadata and copy the new
|
||||
@ -1724,7 +1723,6 @@ ALLOW -1:-1 from 0.0.0.0/0
|
||||
updated crl, it will block revoked users from
|
||||
connecting to the vpn.</para>
|
||||
<para>The user data for cloudpipe isn't currently
|
||||
|
||||
updated when certs are revoked, so it is necessary
|
||||
to restart the cloudpipe instance if a user's
|
||||
credentials are revoked.</para>
|
||||
|
||||
@ -158,7 +158,7 @@
|
||||
<prompt>$</prompt> <userinput>/etc/init.d/idmapd restart</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Set the 'execute/search' bit on your shared directory </para>
|
||||
<para>Set the 'execute/search' bit on your shared directory.</para>
|
||||
<para>On both compute nodes, make sure to enable the
|
||||
'execute/search' bit to allow qemu to be able to use the images
|
||||
within the directories. On all hosts, execute the
|
||||
|
||||
@ -40,7 +40,7 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<para>This example will convert a raw image file named centos63.dsk to a qcow2 image file </para>
|
||||
<para>This example will convert a raw image file named centos63.dsk to a qcow2 image file.</para>
|
||||
<para>
|
||||
<screen><prompt>$</prompt> <userinput>qemu-img convert -f raw -O qcow2 centos64.dsk centos64.qcow2</userinput></screen>
|
||||
</para>
|
||||
|
||||
@ -441,7 +441,7 @@ neutron router-interface-add router1 <subnet2-uuid></computeroutput></scre
|
||||
network in the provider</para>
|
||||
<para>A router can also be connected to an “external
|
||||
network”, allowing that router to act as a NAT gateway
|
||||
for external connectivity. </para>
|
||||
for external connectivity.</para>
|
||||
<screen><computeroutput>neutron router-gateway-set router1 <ext-net-id> </computeroutput></screen>
|
||||
<para>Viewing routers:</para>
|
||||
<para>List all routers:
|
||||
|
||||
@ -420,12 +420,11 @@ catalog.$Region.network.internalURL = http://10.211.55.17:9696
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="nova_with_neutron_example">
|
||||
<title> Example nova.conf Values (for nova-compute and nova-api)</title>
|
||||
<para>The following code provides example <filename>nova.conf</filename>
|
||||
values, for a cloud controller node running OpenStack Compute and
|
||||
<title>Example nova.conf (for <systemitem class="service">nova-compute</systemitem> and <systemitem class="service">nova-api</systemitem>)</title>
|
||||
<para>Example values for the above settings, assuming a
|
||||
cloud controller node running OpenStack Compute and
|
||||
OpenStack Networking with an IP address of 192.168.1.2
|
||||
and vif-plugging using the LibvirtHybridOVSBridgeDriver.
|
||||
</para>
|
||||
and vif-plugging using the LibvirtHybridOVSBridgeDriver.</para>
|
||||
<screen><computeroutput>network_api_class=nova.network.neutronv2.api.API
|
||||
neutron_url=http://192.168.1.2:9696
|
||||
neutron_auth_strategy=keystone
|
||||
|
||||
@ -104,7 +104,7 @@
|
||||
<para>At this point we know that the node has booted with the correct kernel and underlying components. There are many paths for hardening a given operating system deployment. The specifics on these steps are outside of the scope of this book. We recommend following the guidance from a hardening guide specific to your operating system. For example, the security technical implementation guides (STIG, http://iase.disa.mil/stigs/) and the NSA guides (http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/) are useful starting places.</para>
|
||||
<para>The nature of the nodes makes additional hardening possible. We recommend the following additional steps for production nodes:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>Use a read-only file system where possible. Ensure that writeable file systems do not permit execution. This can be handled through the mount options provided in <literal> /etc/fstab </literal>.</para>
|
||||
<para>Use a read-only file system where possible. Ensure that writeable file systems do not permit execution. This can be handled through the mount options provided in <literal>/etc/fstab</literal>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Use a mandatory access control policy to contain the instances, the node services, and any other critical processes and data on the node. See the discussions on sVirt / SELinux and AppArmor below.</para>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user