[install] Fix environment structure
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
parent
e8e239d73a
commit
677d910899
|
|
@ -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.**
|
||||
|
|
@ -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.**
|
||||
|
|
@ -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/>`__.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue