openstack/openstack-manuals
Code Issues Proposed changes

[install] Fix environment structure

Browse Source 
Address various structure and consistency issues with
environment content.

This patch only addresses the critical structure and
consistency problems that impact usability. A future
patch should address the larger, but less obvious problems
that mostly appeared during the RST conversion.

Change-Id: Iae586b4cc8943abedca3c09820d0fb5370b5a858
Implements: blueprint installguide-liberty
This commit is contained in:
Matthew Kassawara 2015-10-05 13:39:48 -05:00
parent e8e239d73a
commit 677d910899
9 changed files with 368 additions and 328 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
doc/install-guide/source/environment-networking-compute.rst Normal file
View File

@ -0,0 +1,85 @@
Compute node
~~~~~~~~~~~~
Configure network interfaces
----------------------------
#. Configure the first interface as the management interface:
IP address: 10.0.0.31
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
.. note::
Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on.
#. The public interface uses a special configuration without an IP
address assigned to it. Configure the second interface as the public
interface:
Replace ``INTERFACE_NAME`` with the actual interface name. For example,
*eth1* or *ens224*.
.. only:: ubuntu or debian
a. Edit the :file:`/etc/network/interfaces` file to contain the following:
.. code-block:: ini
# The public network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
.. only:: rdo
a. Edit the :file:`/etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME` file
to contain the following:
Do not change the ``HWADDR`` and ``UUID`` keys.
.. code-block:: ini
DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"
.. only:: obs
a. Edit the :file:`/etc/sysconfig/network/ifcfg-INTERFACE_NAME` file to
contain the following:
.. code-block:: ini
STARTMODE='auto'
BOOTPROTO='static'
#. Reboot the system to activate the changes.
Configure name resolution
-------------------------
#. Set the hostname of the node to ``compute1``.
#. Edit the :file:`/etc/hosts` file to contain the following:
.. code-block:: ini
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
.. warning::
Some distributions add an extraneous entry in the :file:`/etc/hosts`
file that resolves the actual hostname to another loopback IP
address such as ``127.0.1.1``. You must comment out or remove this
entry to prevent name resolution problems. **Do not remove the
127.0.0.1 entry.**

81
doc/install-guide/source/environment-networking-controller.rst Normal file
View File

@ -0,0 +1,81 @@
Controller node
~~~~~~~~~~~~~~~
Configure network interfaces
----------------------------
#. Configure the first interface as the management interface:
IP address: 10.0.0.11
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
#. The public interface uses a special configuration without an IP
address assigned to it. Configure the second interface as the public
interface:
Replace ``INTERFACE_NAME`` with the actual interface name. For example,
*eth1* or *ens224*.
.. only:: ubuntu or debian
a. Edit the :file:`/etc/network/interfaces` file to contain the following:
.. code-block:: ini
# The public network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
.. only:: rdo
a. Edit the :file:`/etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME` file
to contain the following:
Do not change the ``HWADDR`` and ``UUID`` keys.
.. code-block:: ini
DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"
.. only:: obs
a. Edit the :file:`/etc/sysconfig/network/ifcfg-INTERFACE_NAME` file to
contain the following:
.. code-block:: ini
STARTMODE='auto'
BOOTPROTO='static'
#. Reboot the system to activate the changes.
Configure name resolution
-------------------------
#. Set the hostname of the node to ``controller``.
#. Edit the :file:`/etc/hosts` file to contain the following:
.. code-block:: ini
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
.. warning::
Some distributions add an extraneous entry in the :file:`/etc/hosts`
file that resolves the actual hostname to another loopback IP
address such as ``127.0.1.1``. You must comment out or remove this
entry to prevent name resolution problems. **Do not remove the
127.0.0.1 entry.**

84
doc/install-guide/source/environment-networking-verify.rst Normal file
View File

@ -0,0 +1,84 @@
Verify connectivity
-------------------
We recommend that you verify network connectivity to the Internet and
among the nodes before proceeding further.
#. From the *controller* node, test access to the Internet:
.. code-block:: console
# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms
--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
#. From the *controller* node, test access to the management interface on the
*compute* node:
.. code-block:: console
# ping -c 4 compute1
PING compute1 (10.0.0.31) 56(84) bytes of data.
64 bytes from compute1 (10.0.0.31): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=4 ttl=64 time=0.202 ms
--- compute1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
#. From the *compute* node, test access to the Internet:
.. code-block:: console
# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms
--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
#. From the *compute* node, test access to the management interface on the
*controller* node:
.. code-block:: console
# ping -c 4 controller
PING controller (10.0.0.11) 56(84) bytes of data.
64 bytes from controller (10.0.0.11): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from controller (10.0.0.11): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from controller (10.0.0.11): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from controller (10.0.0.11): icmp_seq=4 ttl=64 time=0.202 ms
--- controller ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
.. note::
.. only:: rdo or obs
Your distribution enables a restrictive :term:`firewall` by
default. During the installation process, certain steps will
fail unless you alter or disable the firewall. For more
information about securing your environment, refer to the
`OpenStack Security Guide <http://docs.openstack.org/sec/>`__.
.. only:: ubuntu or debian
Your distribution does not enable a restrictive :term:`firewall`
by default. For more information about securing your environment,
refer to the
`OpenStack Security Guide <http://docs.openstack.org/sec/>`__.

210
doc/install-guide/source/environment-networking.rst
View File

@ -1,4 +1,4 @@
Host Networking
Host networking
~~~~~~~~~~~~~~~
.. only:: ubuntu
@ -100,207 +100,6 @@ the controller node.
connectivity. We recommend using a local terminal session for these
procedures.
Controller node
---------------
Configure networking
~~~~~~~~~~~~~~~~~~~~
#. Configure the first interface as the management interface:
IP address: 10.0.0.11
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
#. Reboot the system to activate the changes.
|
Configure name resolution
~~~~~~~~~~~~~~~~~~~~~~~~~
#. Set the hostname of the node to ``controller``.
#. Edit the :file:`/etc/hosts` file to contain the following:
.. code-block:: ini
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
.. warning::
Some distributions add an extraneous entry in the :file:`/etc/hosts`
file that resolves the actual hostname to another loopback IP
address such as ``127.0.1.1``. You must comment out or remove this
entry to prevent name resolution problems. **Do not remove the
127.0.0.1 entry.**
|
Compute node
------------
Configure networking
~~~~~~~~~~~~~~~~~~~~
#. Configure the first interface as the management interface:
IP address: 10.0.0.31
Network mask: 255.255.255.0 (or /24)
Default gateway: 10.0.0.1
.. note::
Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on.
#. The public interface uses a special configuration without an IP
address assigned to it. Configure the second interface as the public
interface:
Replace ``INTERFACE_NAME`` with the actual interface name. For example,
*eth1* or *ens224*.
.. only:: ubuntu or debian
a. Edit the :file:`/etc/network/interfaces` file to contain the following:
.. code-block:: ini
# The public network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down
.. only:: rdo
a. Edit the :file:`/etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME` file
to contain the following:
Do not change the ``HWADDR`` and ``UUID`` keys.
.. code-block:: ini
DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"
.. only:: obs
a. Edit the :file:`/etc/sysconfig/network/ifcfg-INTERFACE_NAME` file to
contain the following:
.. code-block:: ini
STARTMODE='auto'
BOOTPROTO='static'
#. Reboot the system to activate the changes.
|
Configure name resolution
~~~~~~~~~~~~~~~~~~~~~~~~~
#. Set the hostname of the node to ``compute1``.
#. Edit the :file:`/etc/hosts` file to contain the following:
.. code-block:: ini
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
.. warning::
Some distributions add an extraneous entry in the :file:`/etc/hosts`
file that resolves the actual hostname to another loopback IP
address such as ``127.0.1.1``. You must comment out or remove this
entry to prevent name resolution problems. **Do not remove the
127.0.0.1 entry.**
|
Verify connectivity
-------------------
We recommend that you verify network connectivity to the Internet and
among the nodes before proceeding further.
#. From the *controller* node, test access to the Internet:
.. code-block:: console
# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms
--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
#. From the *controller* node, test access to the management interface on the
*compute* node:
.. code-block:: console
# ping -c 4 compute1
PING compute1 (10.0.0.31) 56(84) bytes of data.
64 bytes from compute1 (10.0.0.31): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from compute1 (10.0.0.31): icmp_seq=4 ttl=64 time=0.202 ms
--- compute1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
#. From the *compute* node, test access to the Internet:
.. code-block:: console
# ping -c 4 openstack.org
PING openstack.org (174.143.194.225) 56(84) bytes of data.
64 bytes from 174.143.194.225: icmp_seq=1 ttl=54 time=18.3 ms
64 bytes from 174.143.194.225: icmp_seq=2 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=3 ttl=54 time=17.5 ms
64 bytes from 174.143.194.225: icmp_seq=4 ttl=54 time=17.4 ms
--- openstack.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 17.489/17.715/18.346/0.364 ms
#. From the *compute* node, test access to the management interface on the
*controller* node:
.. code-block:: console
# ping -c 4 controller
PING controller (10.0.0.11) 56(84) bytes of data.
64 bytes from controller (10.0.0.11): icmp_seq=1 ttl=64 time=0.263 ms
64 bytes from controller (10.0.0.11): icmp_seq=2 ttl=64 time=0.202 ms
64 bytes from controller (10.0.0.11): icmp_seq=3 ttl=64 time=0.203 ms
64 bytes from controller (10.0.0.11): icmp_seq=4 ttl=64 time=0.202 ms
--- controller ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.202/0.217/0.263/0.030 ms
.. note::
.. only:: rdo or obs
@ -317,3 +116,10 @@ among the nodes before proceeding further.
by default. For more information about securing your environment,
refer to the
`OpenStack Security Guide <http://docs.openstack.org/sec/>`__.
.. toctree::
:maxdepth: 1
environment-networking-controller.rst
environment-networking-compute.rst
environment-networking-verify.rst

17
doc/install-guide/source/environment-ntp-controller.rst
View File

@ -3,8 +3,10 @@
Controller node
~~~~~~~~~~~~~~~
Install the NTP service
-----------------------
Install and configure components
--------------------------------
Install the packages:
.. only:: ubuntu or debian
@ -36,18 +38,13 @@ Install the NTP service
# zypper refresh
# zypper install chrony
|
Configure the NTP service
-------------------------
By default, the controller node synchronizes the time via a pool of
public servers. However, you can optionally configure alternative servers such
as those provided by your organization.
.. only:: ubuntu or debian
#. Edit the :file:`/etc/chrony/chrony.conf` file and add, change, or remove the
#. Edit the ``/etc/chrony/chrony.conf`` file and add, change, or remove the
following keys as necessary for your environment:
.. code:: ini
@ -66,7 +63,7 @@ as those provided by your organization.
.. only:: rdo or obs
#. Edit the :file:`/etc/chrony.conf` file and add, change, or remove the
#. Edit the ``/etc/chrony.conf`` file and add, change, or remove the
following keys as necessary for your environment:
.. code:: ini
@ -78,7 +75,7 @@ as those provided by your organization.
``server`` keys.
#. To enable other nodes to connect to the chrony daemon on the controller,
add the following key to :file:`/etc/chrony.conf`:
add the following key to the ``/etc/chrony.conf`` file:
.. code:: ini

15
doc/install-guide/source/environment-ntp-other.rst
View File

@ -3,8 +3,10 @@
Other nodes
~~~~~~~~~~~
Install the NTP service
-----------------------
Install and configure components
--------------------------------
Install the packages:
.. only:: ubuntu or debian
@ -36,17 +38,12 @@ Install the NTP service
# zypper refresh
# zypper install chrony
|
Configure the NTP service
-------------------------
Configure the network and compute nodes to reference the controller
node.
.. only:: ubuntu or debian
1. Edit the :file:`/etc/chrony/chrony.conf` and comment out or remove all
1. Edit the ``/etc/chrony/chrony.conf`` file and comment out or remove all
but one ``server`` key. Change it to reference the controller node:
.. code:: ini
@ -61,7 +58,7 @@ node.
.. only:: rdo or obs
1. Edit the :file:`/etc/chrony.conf` and comment out or remove all but one
1. Edit the ``/etc/chrony.conf`` file and comment out or remove all but one
``server`` key. Change it to reference the controller node:
.. code:: ini

4
doc/install-guide/source/environment-ntp.rst
View File

@ -3,8 +3,8 @@
.. _environment-ntp:
Configure Network Time Protocol (NTP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Network Time Protocol (NTP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
You should install Chrony, an implementation of :term:`NTP`, to properly
synchronize services among nodes. We recommend that you configure the

86
doc/install-guide/source/environment-security.rst Normal file
View File

@ -0,0 +1,86 @@
Security
~~~~~~~~
OpenStack services support various security methods including password,
policy, and encryption. Additionally, supporting services including the
database server and message broker support at least password security.
To ease the installation process, this guide only covers password
security where applicable. You can create secure passwords manually,
generate them using a tool such as
`pwgen <http://sourceforge.net/projects/pwgen/>`__, or by running the
following command:
.. code-block:: console
$ openssl rand -hex 10
For OpenStack services, this guide uses ``SERVICE_PASS`` to reference
service account passwords and ``SERVICE_DBPASS`` to reference database
passwords.
The following table provides a list of services that require passwords
and their associated references in the guide:
.. list-table:: **Passwords**
:widths: 50 60
:header-rows: 1
* - Password name
- Description
* - Database password (no variable used)
- Root password for the database
* - ``ADMIN_PASS``
- Password of user ``admin``
* - ``CEILOMETER_DBPASS``
- Database password for the Telemetry service
* - ``CEILOMETER_PASS``
- Password of Telemetry service user ``ceilometer``
* - ``CINDER_DBPASS``
- Database password for the Block Storage service
* - ``CINDER_PASS``
- Password of Block Storage service user ``cinder``
* - ``DASH_DBPASS``
- Database password for the dashboard
* - ``DEMO_PASS``
- Password of user ``demo``
* - ``GLANCE_DBPASS``
- Database password for Image service
* - ``GLANCE_PASS``
- Password of Image service user ``glance``
* - ``HEAT_DBPASS``
- Database password for the Orchestration service
* - ``HEAT_DOMAIN_PASS``
- Password of Orchestration domain
* - ``HEAT_PASS``
- Password of Orchestration service user ``heat``
* - ``KEYSTONE_DBPASS``
- Database password of Identity service
* - ``NEUTRON_DBPASS``
- Database password for the Networking service
* - ``NEUTRON_PASS``
- Password of Networking service user ``neutron``
* - ``NOVA_DBPASS``
- Database password for Compute service
* - ``NOVA_PASS``
- Password of Compute service user ``nova``
* - ``RABBIT_PASS``
- Password of user guest of RabbitMQ
* - ``SWIFT_PASS``
- Password of Object Storage service user ``swift``
OpenStack and supporting services require administrative privileges
during installation and operation. In some cases, services perform
modifications to the host that can interfere with deployment automation
tools such as Ansible, Chef, and Puppet. For example, some OpenStack
services add a root wrapper to ``sudo`` that can interfere with security
policies. See the `Cloud Administrator Guide <http://docs.openstack.org/
admin-guide-cloud/compute-root-wrap-reference.html>`__
for more information.
Also, the Networking service assumes default values for kernel network
parameters and modifies firewall rules. To avoid most issues during your
initial installation, we recommend using a stock deployment of a supported
distribution on your hosts. However, if you choose to automate deployment
of your hosts, review the configuration and policies applied to them before
proceeding further.

114
doc/install-guide/source/environment.rst
View File

@ -18,7 +18,7 @@ Although most environments include Identity, Image service, Compute, at least
one networking service, and the dashboard, the Object Storage service can
operate independently. If your use case only involves Object Storage, you can
skip to :ref:`swift` after configuring the appropriate nodes for it. However,
the dashboard requires at least the Image service and Compute.
the dashboard requires at least the Image service, Compute, and Networking.
You must use an account with administrative privileges to configure each node.
Either run the commands as the ``root`` user or configure the ``sudo``
@ -30,9 +30,6 @@ utility.
when the service uses SysV Init scripts instead of native systemd files. This
warning can be ignored.
Before you begin
~~~~~~~~~~~~~~~~
For best performance, we recommend that your environment meets or exceeds
the hardware requirements in :ref:`figure-hwreqs`. However, OpenStack does
not require a significant amount of resources and the following minimum
@ -51,9 +48,9 @@ A single disk partition on each node works for most basic installations.
However, you should consider :term:`Logical Volume Manager (LVM)` for
installations with optional services such as Block Storage.
Many users build their test environment on a
:term:`virtual machine (VM)`. The primary benefits of VMs include
the following:
For first-time installation and testing purposes, many users elect to build
each host as a :term:`virtual machine (VM)`. The primary benefits of VMs
include the following:
- One physical server can support multiple nodes, each with almost any
number of network interfaces.
@ -68,110 +65,17 @@ of nested VMs.
.. note::
If you choose to install on VMs, make sure your hypervisor permits
:term:`promiscuous mode` and disables MAC address filtering on the
:term:`external network`.
If you choose to install on VMs, make sure your hypervisor provides
a way to disable MAC address filtering on the ``public`` network
interface.
For more information about system requirements, see the `OpenStack
Operations Guide <http://docs.openstack.org/ops/>`_.
Security
~~~~~~~~
OpenStack services support various security methods including password,
policy, and encryption. Additionally, supporting services including the
database server and message broker support at least password security.
To ease the installation process, this guide only covers password
security where applicable. You can create secure passwords manually,
generate them using a tool such as
`pwgen <http://sourceforge.net/projects/pwgen/>`__, or by running the
following command:
.. code-block:: console
$ openssl rand -hex 10
For OpenStack services, this guide uses ``SERVICE_PASS`` to reference
service account passwords and ``SERVICE_DBPASS`` to reference database
passwords.
The following table provides a list of services that require passwords
and their associated references in the guide:
.. list-table:: **Passwords**
:widths: 50 60
:header-rows: 1
* - Password name
- Description
* - Database password (no variable used)
- Root password for the database
* - ``ADMIN_PASS``
- Password of user ``admin``
* - ``CEILOMETER_DBPASS``
- Database password for the Telemetry service
* - ``CEILOMETER_PASS``
- Password of Telemetry service user ``ceilometer``
* - ``CINDER_DBPASS``
- Database password for the Block Storage service
* - ``CINDER_PASS``
- Password of Block Storage service user ``cinder``
* - ``DASH_DBPASS``
- Database password for the dashboard
* - ``DEMO_PASS``
- Password of user ``demo``
* - ``GLANCE_DBPASS``
- Database password for Image service
* - ``GLANCE_PASS``
- Password of Image service user ``glance``
* - ``HEAT_DBPASS``
- Database password for the Orchestration service
* - ``HEAT_DOMAIN_PASS``
- Password of Orchestration domain
* - ``HEAT_PASS``
- Password of Orchestration service user ``heat``
* - ``KEYSTONE_DBPASS``
- Database password of Identity service
* - ``NEUTRON_DBPASS``
- Database password for the Networking service
* - ``NEUTRON_PASS``
- Password of Networking service user ``neutron``
* - ``NOVA_DBPASS``
- Database password for Compute service
* - ``NOVA_PASS``
- Password of Compute service user ``nova``
* - ``RABBIT_PASS``
- Password of user guest of RabbitMQ
* - ``SWIFT_PASS``
- Password of Object Storage service user ``swift``
|
OpenStack and supporting services require administrative privileges
during installation and operation. In some cases, services perform
modifications to the host that can interfere with deployment automation
tools such as Ansible, Chef, and Puppet. For example, some OpenStack
services add a root wrapper to ``sudo`` that can interfere with security
policies. See the `Cloud Administrator Guide <http://docs.openstack.org/
admin-guide-cloud/compute-root-wrap-reference.html>`__
for more information.
Also, the Networking service assumes default values for kernel network
parameters and modifies firewall rules. To avoid most issues during your
initial installation, we recommend using a stock deployment of a supported
distribution on your hosts. However, if you choose to automate deployment
of your hosts, review the configuration and policies applied to them before
proceeding further.
Host networking, NTP, OpenStack service dependencies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. toctree::
:maxdepth: 2
:maxdepth: 1
environment-security.rst
environment-networking.rst
environment-ntp.rst
environment-dependencies.rst