OpenStack Project (Mitaki) Cloud Environment setup - Part-1

OpenStack Project

The OpenStack project is an open source cloud computing platform that supports all types of cloud environments. The project aims for simple implementation, massive scalability, and a rich set of features. Cloud computing experts from around the world contribute to the project.
OpenStack provides an Infrastructure-as-a-Service (IaaS) solution through a variety of complemental services. Each service offers an Application Programming Interface (API) that facilitates this integration.
This guide covers step-by-step deployment of the following major OpenStack services using a functional example architecture suitable for new users of OpenStack with sufficient Linux experience:

Example architecture

The example architecture requires at least two nodes (hosts) to launch a basic virtual machine or instance. Optional services such as Block Storage and Object Storage require additional nodes.
This example architecture differs from a minimal production architecture as follows:

• Networking agents reside on the controller node instead of one or more dedicated network nodes.
• Overlay (tunnel) traffic for self-service networks traverses the management network instead of a dedicated network.

For more information on production architectures, see the Architecture Design Guide, Operations Guide, and Networking Guide.

Networking Option 1: Provider networks

The provider networks option deploys the OpenStack Networking service in the simplest way possible with primarily layer-2 (bridging/switching) services and VLAN segmentation of networks. Essentially, it bridges virtual networks to physical networks and relies on physical network infrastructure for layer-3 (routing) services. Additionally, a DHCP service provides IP address information to instances. 

Note

This option lacks support for self-service (private) networks, layer-3 (routing) services, and advanced services such as LBaaS and FWaaS. Consider the self-service networks option if you desire these features.

  

Networking Option 2: Self-service networks

The self-service networks option augments the provider networks option with layer-3 (routing) services that enable self-service networks using overlay segmentation methods such as VXLAN. Essentially, it routes virtual networks to physical networks using NAT. Additionally, this option provides the foundation for advanced services such as LBaaS and FWaaS. Environment

For best performance, we recommend that your environment meets or exceeds the hardware requirements in Hardware requirements.

The following minimum requirements should support a proof-of-concept environment with core services and several CirrOS instances:

• Controller Node: 1 processor, 4 GB memory, and 5 GB storage
• Compute Node: 1 processor, 2 GB memory, and 10 GB storage

As the number of OpenStack services and virtual machines increase, so do the hardware requirements for the best performance. If performance degrades after enabling additional services or virtual machines, consider adding hardware resources to your environment.

To minimize clutter and provide more resources for OpenStack, we recommend a minimal installation of your Linux distribution. Also, you must install a 64-bit version of your distribution on each node.

  

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, or by running the following command:

$ 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:

Passwords
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 Administrator Guide 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

After installing the operating system on each node for the architecture that you choose to deploy, you must configure the network interfaces. We recommend that you disable any automated network management tools and manually edit the appropriate configuration files for your distribution. For more information on how to configure networking on your distribution, see the documentation .
All nodes require Internet access for administrative purposes such as package installation, security updates, DNS, and NTP. In most cases, nodes should obtain internet access through the management network interface. To highlight the importance of network separation, the example architectures use private address space for the management network and assume that the physical network infrastructure provides Internet access via NAT or other method. The example architectures use routable IP address space for the provider (external) network and assume that the physical network infrastructure provides direct Internet access.
In the provider networks architecture, all instances attach directly to the provider network. In the self-service (private) networks architecture, instances can attach to a self-service or provider network. Self-service networks can reside entirely within OpenStack or provide some level of external network access using NAT through the provider network.

The example architectures assume use of the following networks:

·         Management on 10.0.0.0/24 with gateway 10.0.0.1

This network requires a gateway to provide Internet access to all nodes for administrative purposes such as package installation, security updates, DNS, and NTP.

·         Provider on 203.0.113.0/24 with gateway 203.0.113.1

This network requires a gateway to provide Internet access to instances in your OpenStack environment.

You can modify these ranges and gateways to work with your particular network infrastructure.
Network interface names vary by distribution. Traditionally, interfaces use “eth” followed by a sequential number. To cover all variations, this guide simply refers to the first interface as the interface with the lowest number and the second interface as the interface with the highest number.
Unless you intend to use the exact configuration provided in this example architecture, you must modify the networks in this procedure to match your environment. Also, each node must resolve the other nodes by name in addition to IP address. For example, the controller name must resolve to 10.0.0.11, the IP address of the management interface on the controller node.

Warning

Reconfiguring network interfaces will interrupt network connectivity. We recommend using a local terminal session for these procedures.

Note

Your distribution enables a restrictive 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.

• Controller node
• Compute node
• Block storage node (Optional)
• Object storage nodes (Optional)
• Verify connectivity

Controller node

Configure network interfaces

1.    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

2.    The provider interface uses a special configuration without an IP address assigned to it. Configure the second interface as the provider interface:

Replace INTERFACE_NAME with the actual interface name. For example, eth1 or ens224.

o    Edit the /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME file to contain the following:

Do not change the HWADDR and UUID keys.

DEVICE=INTERFACE_NAME

TYPE=Ethernet

ONBOOT="yes"

BOOTPROTO="none"

3.    Reboot the system to activate the changes.

Configure name resolution

1.    Set the hostname of the node to controller.

2.    Edit the /etc/hosts file to contain the following:

# controller

10.0.0.11       controller

# compute1

10.0.0.31       compute1

# block1

10.0.0.41       block1

# object1

10.0.0.51       object1

# object2

10.0.0.52       object2

Warning

Some distributions add an extraneous entry in the /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.

Note

To reduce complexity of this guide, we add host entries for optional services regardless of whether you choose to deploy them.

  

Compute node

Configure network interfaces

1.    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.

2.    The provider interface uses a special configuration without an IP address assigned to it. Configure the second interface as the provider interface:

Replace INTERFACE_NAME with the actual interface name. For example, eth1 or ens224.

o    Edit the /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME file to contain the following:

Do not change the HWADDR and UUID keys.

DEVICE=INTERFACE_NAME

TYPE=Ethernet

ONBOOT="yes"

BOOTPROTO="none"

3.    Reboot the system to activate the changes.

Configure name resolution

1.    Set the hostname of the node to compute1.

2.    Edit the /etc/hosts file to contain the following:

# controller

10.0.0.11       controller

# compute1

10.0.0.31       compute1

# block1

10.0.0.41       block1

# object1

10.0.0.51       object1

# object2

10.0.0.52       object2

Warning

Some distributions add an extraneous entry in the /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.

Note

To reduce complexity of this guide, we add host entries for optional services regardless of whether you choose to deploy them.

Block storage node (Optional)

If you want to deploy the Block Storage service, configure one additional storage node.

Configure network interfaces

• Configure the management interface:
• IP address: 10.0.0.41
• Network mask: 255.255.255.0 (or /24)
• Default gateway: 10.0.0.1

Configure name resolution

1.    Set the hostname of the node to block1.

2.    Edit the /etc/hosts file to contain the following:

# controller

10.0.0.11       controller

# compute1

10.0.0.31       compute1

# block1

10.0.0.41       block1

# object1

10.0.0.51       object1

# object2

10.0.0.52       object2

Warning

Some distributions add an extraneous entry in the /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.

Note

To reduce complexity of this guide, we add host entries for optional services regardless of whether you choose to deploy them.

3.    Reboot the system to activate the changes.

Verify connectivity

We recommend that you verify network connectivity to the Internet and among the nodes before proceeding further.

1.    From the controller node, test access to the Internet:

# 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

2.    From the controller node, test access to the management interface on the compute node:

# 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

3.    From the compute node, test access to the Internet:

# 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

4.    From the compute node, test access to the management interface on the controller node:

# 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

Your distribution enables a restrictive 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.

 

Network Time Protocol (NTP)

You should install Chrony, an implementation of NTP, to properly synchronize services among nodes. We recommend that you configure the controller node to reference more accurate (lower stratum) servers and other nodes to reference the controller node.

 Controller node

Perform these steps on the controller node.

Install and configure components

1.    Install the packages:

# yum install chrony

2.    Edit the /etc/chrony.conf file and add, change, or remove the following keys as necessary for your environment:

server NTP_SERVER iburst

Replace NTP_SERVER with the hostname or IP address of a suitable more accurate (lower stratum) NTP server. The configuration supports multiple server keys.

Note

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.

3.    To enable other nodes to connect to the chrony daemon on the controller, add the following key to the /etc/chrony.conf file:

allow 10.0.0.0/24

If necessary, replace 10.0.0.0/24 with a description of your subnet.

4.    Start the NTP service and configure it to start when the system boots:

# systemctl enable chronyd.service

# systemctl start chronyd.service

 

Other nodes

Other nodes reference the controller node for clock synchronization. Perform these steps on all other nodes.

Install and configure components

1.    Install the packages:

# yum install chrony

2.    Edit the /etc/chrony.conf file and comment out or remove all but one server key. Change it to reference the controller node:

server controller iburst

3.    Start the NTP service and configure it to start when the system boots:

# systemctl enable chronyd.service

# systemctl start chronyd.service

 

Verify operation

We recommend that you verify NTP synchronization before proceeding further. Some nodes, particularly those that reference the controller node, can take several minutes to synchronize.

1.    Run this command on the controller node:

# chronyc sources

  210 Number of sources = 2

  MS Name/IP address         Stratum Poll Reach LastRx Last sample

  =========================================================================

  ^- 192.0.2.11                    2   7    12   137  -2814us[-3000us] +/-   43ms

  ^* 192.0.2.12                    2   6   177    46    +17us[  -23us] +/-   68ms

Contents in the Name/IP address column should indicate the hostname or IP address of one or more NTP servers. Contents in the S column should indicate * for the server to which the NTP service is currently synchronized.

2.    Run the same command on all other nodes:

# chronyc sources

  210 Number of sources = 1

  MS Name/IP address         Stratum Poll Reach LastRx Last sample

  =========================================================================

  ^* controller                    3    9   377   421    +15us[  -87us] +/-   15ms

Contents in the Name/IP address column should indicate the hostname of the controller node.

OpenStack packages

Distributions release OpenStack packages as part of the distribution or using other methods because of differing release schedules. Perform these procedures on all nodes. 

Warning

Your hosts must contain the latest versions of base installation packages available for your distribution before proceeding further.

Note

Disable or remove any automatic update services because they can impact your OpenStack environment.

Prerequisites

Warning

We recommend disabling EPEL when using RDO packages due to updates in EPEL breaking backwards compatibility. Or, preferably pin package versions using the yum-versionlock plugin.

Note

CentOS does not require the following steps.

1.    On RHEL, register your system with Red Hat Subscription Management, using your Customer Portal user name and password:

# subscription-manager register --username="USERNAME" --password="PASSWORD"

2.    Find entitlement pools containing the channels for your RHEL system:

# subscription-manager list --available

3.    Use the pool identifiers found in the previous step to attach your RHEL entitlements:

# subscription-manager attach --pool="POOLID"

4.    Enable required repositories:

# subscription-manager repos --enable=rhel-7-server-optional-rpms \

  --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms

Enable the OpenStack repository

·         On CentOS, the extras repository provides the RPM that enables the OpenStack repository. CentOS includes the extras repository by default, so you can simply install the package to enable the OpenStack repository.

# yum install centos-release-openstack-mitaka

·         On RHEL, download and install the RDO repository RPM to enable the OpenStack repository.

# yum install https://rdoproject.org/repos/rdo-release.rpm

Finalize the installation

1.    Upgrade the packages on your host:

2.     # yum upgrade 

Note

If the upgrade process includes a new kernel, reboot your host to activate it.

3.    Install the OpenStack client:

# yum install python-openstackclient

3.    RHEL and CentOS enable SELinux by default. Install the openstack-selinux package to automatically manage security policies for OpenStack services:

# yum install openstack-selinux

NoSQL database

The Telemetry service uses a NoSQL database to store information. The database typically runs on the controller node. The procedures in this guide use MongoDB. 

Note

The installation of the NoSQL database server is only necessary when installing the Telemetry service as documented in Telemetry service.

Install and configure components

1.    Install the MongoDB packages:

# yum install mongodb-server mongodb

2.    Edit the /etc/mongod.conf file and complete the following actions:

o    Configure the bind_ip key to use the management interface IP address of the controller node.

bind_ip = 10.0.0.11

o    By default, MongoDB creates several 1 GB journal files in the /var/lib/mongodb/journal directory. If you want to reduce the size of each journal file to 128 MB and limit total journal space consumption to 512 MB, assert the smallfiles key:

smallfiles = true

You can also disable journaling. For more information, see the MongoDB manual.

Finalize installation

·         Start the MongoDB service and configure it to start when the system boots:

# systemctl enable mongod.service

# systemctl start mongod.service

Message queue

OpenStack uses a message queue to coordinate operations and status information among services. The message queue service typically runs on the controller node. OpenStack supports several message queue services including RabbitMQ, Qpid, and ZeroMQ. However, most distributions that package OpenStack support a particular message queue service. This guide implements the RabbitMQ message queue service because most distributions support it. If you prefer to implement a different message queue service, consult the documentation associated with it.

Install and configure components

1.    Install the package:

# yum install rabbitmq-server

2.    Start the message queue service and configure it to start when the system boots:

# systemctl enable rabbitmq-server.service

# systemctl start rabbitmq-server.service

3.    Add the openstack user:

# rabbitmqctl add_user openstack RABBIT_PASS

Creating user "openstack" ...

...done.

Replace RABBIT_PASS with a suitable password.

4.    Permit configuration, write, and read access for the openstack user:

# rabbitmqctl set_permissions openstack ".*" ".*" ".*"

Setting permissions for user "openstack" in vhost "/" ...

...done.

Memcached

The Identity service authentication mechanism for services uses Memcached to cache tokens. The memcached service typically runs on the controller node. For production deployments, we recommend enabling a combination of firewalling, authentication, and encryption to secure it.

Install and configure components

1.    Install the packages:

# yum install memcached python-memcached

Finalize installation

·         Start the Memcached service and configure it to start when the system boots:

# systemctl enable memcached.service

# systemctl start memcached.service

Identity service overview

The OpenStack Identity service provides a single point of integration for managing authentication, authorization, and service catalog services. Other OpenStack services use the Identity service as a common unified API. Additionally, services that provide information about users but that are not included in OpenStack (such as LDAP services) can be integrated into a pre-existing infrastructure.
In order to benefit from the Identity service, other OpenStack services need to collaborate with it. When an OpenStack service receives a request from a user, it checks with the Identity service whether the user is authorized to make the request.
The Identity service contains these components:

Server

A centralized server provides authentication and authorization services using a RESTful interface.

Drivers

Drivers or a service back end are integrated to the centralized server. They are used for accessing identity information in repositories external to OpenStack, and may already exist in the infrastructure where OpenStack is deployed (for example, SQL databases or LDAP servers).

Modules

Middleware modules run in the address space of the OpenStack component that is using the Identity service. These modules intercept service requests, extract user credentials, and send them to the centralized server for authorization. The integration between the middleware modules and OpenStack components uses the Python Web Server Gateway Interface.

When installing OpenStack Identity service, you must register each service in your OpenStack installation. Identity service can then track which OpenStack services are installed, and where they are located on the network.

Install and configure

This section describes how to install and configure the OpenStack Identity service, code-named keystone, on the controller node. For performance, this configuration deploys Fernet tokens and the Apache HTTP server to handle requests.

Prerequisites

Before you configure the OpenStack Identity service, you must create a database and an administration token.

1.    To create the database, complete the following actions:

o    Use the database access client to connect to the database server as the root user:

$ mysql -u root -p

o    Create the keystone database:

CREATE DATABASE keystone;

o    Grant proper access to the keystone database:

GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' \

  IDENTIFIED BY 'KEYSTONE_DBPASS';

GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' \

  IDENTIFIED BY 'KEYSTONE_DBPASS';

Replace KEYSTONE_DBPASS with a suitable password.

o    Exit the database access client.

2.    Generate a random value to use as the administration token during initial configuration:

$ openssl rand -hex 10

Install and configure components

Note

Default configuration files vary by distribution. You might need to add these sections and options rather than modifying existing sections and options. Also, an ellipsis (...) in the configuration snippets indicates potential default configuration options that you should retain.

Note

This guide uses the Apache HTTP server with mod_wsgi to serve Identity service requests on ports 5000 and 35357. By default, the keystone service still listens on these ports. Therefore, this guide manually disables the keystone service.

1.    Run the following command to install the packages:

# yum install openstack-keystone httpd mod_wsgi

3.    Edit the /etc/keystone/keystone.conf file and complete the following actions:

o    In the [DEFAULT] section, define the value of the initial administration token:

[DEFAULT]

...

admin_token = ADMIN_TOKEN

Replace ADMIN_TOKEN with the random value that you generated in a previous step.

o    In the [database] section, configure database access:

[database]

...

connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone

Replace KEYSTONE_DBPASS with the password you chose for the database.

o    In the [token] section, configure the Fernet token provider:

[token]

...

provider = fernet

4.    Populate the Identity service database:

# su -s /bin/sh -c "keystone-manage db_sync" keystone 

Note

Ignore any deprecation messages in this output.

5.    Initialize Fernet keys:

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone

Configure the Apache HTTP server

1.    Edit the /etc/httpd/conf/httpd.conf file and configure the ServerName option to reference the controller node:

ServerName controller

2.    Create the /etc/httpd/conf.d/wsgi-keystone.conf file with the following content:

Listen 5000

Listen 35357

<VirtualHost *:5000>

    WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}

    WSGIProcessGroup keystone-public

    WSGIScriptAlias / /usr/bin/keystone-wsgi-public

    WSGIApplicationGroup %{GLOBAL}

    WSGIPassAuthorization On

    ErrorLogFormat "%{cu}t %M"

    ErrorLog /var/log/httpd/keystone-error.log

    CustomLog /var/log/httpd/keystone-access.log combined

    <Directory /usr/bin>

        Require all granted

    </Directory>

</VirtualHost>

<VirtualHost *:35357>

    WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone group=keystone display-name=%{GROUP}

    WSGIProcessGroup keystone-admin

    WSGIScriptAlias / /usr/bin/keystone-wsgi-admin

    WSGIApplicationGroup %{GLOBAL}

    WSGIPassAuthorization On

    ErrorLogFormat "%{cu}t %M"

    ErrorLog /var/log/httpd/keystone-error.log

    CustomLog /var/log/httpd/keystone-access.log combined

    <Directory /usr/bin>

        Require all granted

    </Directory>

</VirtualHost>

Finalize the installation

·         Start the Apache HTTP service and configure it to start when the system boots:

# systemctl enable httpd.service

# systemctl start httpd.service

Create the service entity and API endpoints

The Identity service provides a catalog of services and their locations. Each service that you add to your OpenStack environment requires a service entity and several API endpoints in the catalog.

Prerequisites

By default, the Identity service database contains no information to support conventional authentication and catalog services. You must use a temporary authentication token that you created in the section called Install and configure to initialize the service entity and API endpoint for the Identity service.
You must pass the value of the authentication token to the openstack command with the --os-token parameter or set the OS_TOKEN environment variable. Similarly, you must also pass the value of the Identity service URL to the openstack command with the --os-url parameter or set the OS_URL environment variable. This guide uses environment variables to reduce command length.

Warning

For security reasons, do not use the temporary authentication token for longer than necessary to initialize the Identity service.

1.    Configure the authentication token:

$ export OS_TOKEN=ADMIN_TOKEN

Replace ADMIN_TOKEN with the authentication token that you generated in the section called Install and configure. For example:

$ export OS_TOKEN=294a4c8a8a475f9b9836

2.    Configure the endpoint URL:

$ export OS_URL=http://controller:35357/v3

3.    Configure the Identity API version:

$ export OS_IDENTITY_API_VERSION=3

Create the service entity and API endpoints

1.    The Identity service manages a catalog of services in your OpenStack environment. Services use this catalog to determine the other services available in your environment.

Create the service entity for the Identity service:

$ openstack service create \

  --name keystone --description "OpenStack Identity" identity

+-------------+----------------------------------+

| Field       | Value                            |

+-------------+----------------------------------+

| description | OpenStack Identity               |

| enabled     | True                             |

| id          | 4ddaae90388b4ebc9d252ec2252d8d10 |

| name        | keystone                         |

| type        | identity                         |

+-------------+----------------------------------+

Note

OpenStack generates IDs dynamically, so you will see different values in the example command output.

2.    The Identity service manages a catalog of API endpoints associated with the services in your OpenStack environment. Services use this catalog to determine how to communicate with other services in your environment.

OpenStack uses three API endpoint variants for each service: admin, internal, and public. The admin API endpoint allows modifying users and tenants by default, while the public and internal APIs do not allow these operations. In a production environment, the variants might reside on separate networks that service different types of users for security reasons. For instance, the public API network might be visible from the Internet so customers can manage their clouds. The admin API network might be restricted to operators within the organization that manages cloud infrastructure. The internal API network might be restricted to the hosts that contain OpenStack services. Also, OpenStack supports multiple regions for scalability. For simplicity, this guide uses the management network for all endpoint variations and the default RegionOne region.

Create the Identity service API endpoints:

$ openstack endpoint create --region RegionOne \

  identity public http://controller:5000/v3

+--------------+----------------------------------+

| Field        | Value                            |

+--------------+----------------------------------+

| enabled      | True                             |

| id           | 30fff543e7dc4b7d9a0fb13791b78bf4 |

| interface    | public                           |

| region       | RegionOne                        |

| region_id    | RegionOne                        |

| service_id   | 8c8c0927262a45ad9066cfe70d46892c |

| service_name | keystone                         |

| service_type | identity                         |

| url          | http://controller:5000/v3        |

+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \

  identity internal http://controller:5000/v3

+--------------+----------------------------------+

| Field        | Value                            |

+--------------+----------------------------------+

| enabled      | True                             |

| id           | 57cfa543e7dc4b712c0ab137911bc4fe |

| interface    | internal                         |

| region       | RegionOne                        |

| region_id    | RegionOne                        |

| service_id   | 6f8de927262ac12f6066cfe70d99ac51 |

| service_name | keystone                         |

| service_type | identity                         |

| url          | http://controller:5000/v3        |

+--------------+----------------------------------+

$ openstack endpoint create --region RegionOne \

  identity admin http://controller:35357/v3

+--------------+----------------------------------+

| Field        | Value                            |

+--------------+----------------------------------+

| enabled      | True                             |

| id           | 78c3dfa3e7dc44c98ab1b1379122ecb1 |

| interface    | admin                            |

| region       | RegionOne                        |

| region_id    | RegionOne                        |

| service_id   | 34ab3d27262ac449cba6cfe704dbc11f |

| service_name | keystone                         |

| service_type | identity                         |

| url          | http://controller:35357/v3       |

+--------------+----------------------------------+

Note

Each service that you add to your OpenStack environment requires one or more service entities and three API endpoint variants in the Identity service.

Create a domain, projects, users, and roles

The Identity service provides authentication services for each OpenStack service. The authentication service uses a combination of domains, projects (tenants), users, and roles.

1.    Create the default domain:

$ openstack domain create --description "Default Domain" default

+-------------+----------------------------------+

| Field       | Value                            |

+-------------+----------------------------------+

| description | Default Domain                   |

| enabled     | True                             |

| id          | e0353a670a9e496da891347c589539e9 |

| name        | default                          |

+-------------+----------------------------------+

2.    Create an administrative project, user, and role for administrative operations in your environment:

o    Create the admin project:

$ openstack project create --domain default \

  --description "Admin Project" admin

+-------------+----------------------------------+

| Field       | Value                            |

+-------------+----------------------------------+

| description | Admin Project                    |

| domain_id   | e0353a670a9e496da891347c589539e9 |

| enabled     | True                             |

| id          | 343d245e850143a096806dfaefa9afdc |

| is_domain   | False                            |

| name        | admin                            |

| parent_id   | None                             |

+-------------+----------------------------------+ 

Note

OpenStack generates IDs dynamically, so you will see different values in the example command output.

o    Create the admin user:

$ openstack user create --domain default \

  --password-prompt admin

User Password:

Repeat User Password:

+-----------+----------------------------------+

| Field     | Value                            |

+-----------+----------------------------------+

| domain_id | e0353a670a9e496da891347c589539e9 |

| enabled   | True                             |

| id        | ac3377633149401296f6c0d92d79dc16 |

| name      | admin                            |

+-----------+----------------------------------+

o    Create the admin role:

$ openstack role create admin

+-----------+----------------------------------+

| Field     | Value                            |

+-----------+----------------------------------+

| domain_id | None                             |

| id        | cd2cb9a39e874ea69e5d4b896eb16128 |

| name      | admin                            |

+-----------+----------------------------------+

o    Add the admin role to the admin project and user:

$ openstack role add --project admin --user admin admin 

Note

This command provides no output.

Note

Any roles that you create must map to roles specified in the policy.json file in the configuration file directory of each OpenStack service. The default policy for most services grants administrative access to the admin role. For more information, see the Operations Guide - Managing Projects and Users.

3.    This guide uses a service project that contains a unique user for each service that you add to your environment. Create the service project:

$ openstack project create --domain default \

  --description "Service Project" service

+-------------+----------------------------------+

| Field       | Value                            |

+-------------+----------------------------------+

| description | Service Project                  |

| domain_id   | e0353a670a9e496da891347c589539e9 |

| enabled     | True                             |

| id          | 894cdfa366d34e9d835d3de01e752262 |

| is_domain   | False                            |

| name        | service                          |

| parent_id   | None                             |

+-------------+----------------------------------+

4.    Regular (non-admin) tasks should use an unprivileged project and user. As an example, this guide creates the demo project and user.

o    Create the demo project:

$ openstack project create --domain default \

  --description "Demo Project" demo

+-------------+----------------------------------+

| Field       | Value                            |

+-------------+----------------------------------+

| description | Demo Project                     |

| domain_id   | e0353a670a9e496da891347c589539e9 |

| enabled     | True                             |

| id          | ed0b60bf607743088218b0a533d5943f |

| is_domain   | False                            |

| name        | demo                             |

| parent_id   | None                             |

+-------------+----------------------------------+ 

Note

Do not repeat this step when creating additional users for this project.

o    Create the demo user:

$ openstack user create --domain default \

  --password-prompt demo

User Password:

Repeat User Password:

+-----------+----------------------------------+

| Field     | Value                            |

+-----------+----------------------------------+

| domain_id | e0353a670a9e496da891347c589539e9 |

| enabled   | True                             |

| id        | 58126687cbcc4888bfa9ab73a2256f27 |

| name      | demo                             |

+-----------+----------------------------------+

o    Create the user role:

$ openstack role create user

+-----------+----------------------------------+

| Field     | Value                            |

+-----------+----------------------------------+

| domain_id | None                             |

| id        | 997ce8d05fc143ac97d83fdfb5998552 |

| name      | user                             |

+-----------+----------------------------------+

o    Add the user role to the demo project and user:

$ openstack role add --project demo --user demo user 

Note

This command provides no output.

Note

You can repeat this procedure to create additional projects and users.

Verify operation

Verify operation of the Identity service before installing other services.

Note

Perform these commands on the controller node.

1.    For security reasons, disable the temporary authentication token mechanism:

Edit the /etc/keystone/keystone-paste.ini file and remove admin_token_auth from the [pipeline:public_api], [pipeline:admin_api], and [pipeline:api_v3] sections.

2.    Unset the temporary OS_TOKEN and OS_URL environment variables:

$ unset OS_TOKEN OS_URL

3.    As the admin user, request an authentication token:

$ openstack --os-auth-url http://controller:35357/v3 \

  --os-project-domain-name default --os-user-domain-name default \

  --os-project-name admin --os-username admin token issue

Password:

+------------+---------------------------------------------------------+

| Field      | Value                                                           |

+------------+---------------------------------------------------------+

| expires    | 2016-02-12T20:14:07.056119Z                                     |

| id         | gAAAAABWvi7_B8kKQD9wdXac8MoZiQldmjEO643d-e_j-XXq9AmIegIbA7UHGPv |

|            | atnN21qtOMjCFWX7BReJEQnVOAj3nclRQgAYRsfSU_MrsuWb4EDtnjU7HEpoBb4 |

|            | o6ozsA_NmFWEpLeKy0uNn_WeKbAhYygrsmQGA49dclHVnz-OMVLiyM9ws       |

| project_id | 343d245e850143a096806dfaefa9afdc                                |

| user_id    | ac3377633149401296f6c0d92d79dc16                                |

+------------+---------------------------------------------------------+

Note

This command uses the password for the admin user.

4.    As the demo user, request an authentication token:

$ openstack --os-auth-url http://controller:5000/v3 \

  --os-project-domain-name default --os-user-domain-name default \

  --os-project-name demo --os-username demo token issue

Password:

+------------+---------------------------------------------------------+

| Field      | Value                                                           |

+------------+---------------------------------------------------------+

| expires    | 2016-02-12T20:15:39.014479Z                                     |

| id         | gAAAAABWvi9bsh7vkiby5BpCCnc-JkbGhm9wH3fabS_cY7uabOubesi-Me6IGWW |

|            | yQqNegDDZ5jw7grI26vvgy1J5nCVwZ_zFRqPiz_qhbq29mgbQLglbkq6FQvzBRQ |

|            | JcOzq3uwhzNxszJWmzGC7rJE_H0A_a3UFhqv8M4zMRYSbS2YF0MyFmp_U       |

| project_id | ed0b60bf607743088218b0a533d5943f                                |

| user_id    | 58126687cbcc4888bfa9ab73a2256f27                                |

+------------+--------------------------------------------------------+ 

Note

This command uses the password for the demo user and API port 5000 which only allows regular (non-admin) access to the Identity service API.

Create OpenStack client environment scripts

The previous section used a combination of environment variables and command options to interact with the Identity service via the openstack client. To increase efficiency of client operations, OpenStack supports simple client environment scripts also known as OpenRC files. These scripts typically contain common options for all clients, but also support unique options. For more information, see the OpenStack End User Guide.

Creating the scripts

Create client environment scripts for the admin and demo projects and users. Future portions of this guide reference these scripts to load appropriate credentials for client operations.

1.    Edit the admin-openrc file and add the following content:

export OS_PROJECT_DOMAIN_NAME=default

export OS_USER_DOMAIN_NAME=default

export OS_PROJECT_NAME=admin

export OS_USERNAME=admin

export OS_PASSWORD=ADMIN_PASS

export OS_AUTH_URL=http://controller:35357/v3

export OS_IDENTITY_API_VERSION=3

export OS_IMAGE_API_VERSION=2

Replace ADMIN_PASS with the password you chose for the admin user in the Identity service.

2.    Edit the demo-openrc file and add the following content:

export OS_PROJECT_DOMAIN_NAME=default

export OS_USER_DOMAIN_NAME=default

export OS_PROJECT_NAME=demo

export OS_USERNAME=demo

export OS_PASSWORD=DEMO_PASS

export OS_AUTH_URL=http://controller:5000/v3

export OS_IDENTITY_API_VERSION=3

export OS_IMAGE_API_VERSION=2

Replace DEMO_PASS with the password you chose for the demo user in the Identity service.

Using the scripts

To run clients as a specific project and user, you can simply load the associated client environment script prior to running them. For example:

1.    Load the admin-openrc file to populate environment variables with the location of the Identity service and the admin project and user credentials:

$ . admin-openrc

2.    Request an authentication token:

$ openstack token issue

+------------+---------------------------------------------------------+

| Field      | Value                                                           |

+------------+---------------------------------------------------------+

| expires    | 2016-02-12T20:44:35.659723Z                                     |

| id         | gAAAAABWvjYj-Zjfg8WXFaQnUd1DMYTBVrKw4h3fIagi5NoEmh21U72SrRv2trl |

|            | JWFYhLi2_uPR31Igf6A8mH2Rw9kv_bxNo1jbLNPLGzW_u5FC7InFqx0yYtTwa1e |

|            | eq2b0f6-18KZyQhs7F3teAta143kJEWuNEYET-y7u29y0be1_64KYkM7E       |

| project_id | 343d245e850143a096806dfaefa9afdc                                |

| user_id    | ac3377633149401296f6c0d92d79dc16                                |

+------------+---------------------------------------------------------+

cont... part-2

How to Install Git on CentOS/RHEL 7/6/5 & Fedora 23/22

Git is a free and open source distributed version control system . It is designed to handle a small to very large projects with speed and efficiency. To read more details and changes about Git 2.9.1 read

Git release notes. If you are using a Git repository for your development, then you must required a git client on your system and you need to install git client on your workstation system

This tutorial will help you to install git core 2.9.1 on CentOS/RHEL 7/6/5 operating systems using source code. For beginners visit Git console (http://try.github.io/levels/1/challenges/1) on your browser and learn Git uses and command line tips.

Step 1 – Install Required Packages

Before installing Git from source code, make sure you have already installed required packages on your  system. If not use following command to install required packages.

# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel

# yum install gcc perl-ExtUtils-MakeMaker

Step 2 – Download and Install Git

Download latest Git source code from kernel git or simply use following command to download Git 2.9.1.

# cd /usr/src

# wget https://www.kernel.org/pub/software/scm/git/git-2.9.1.tar.gz

# tar xzf git-2.9.1.tar.gz

After downloading and extracting Git source code, Use following command to compile source code.

# cd git-2.9.1

# make prefix=/usr/local/git all

# make prefix=/usr/local/git install

Step 3 – Setup Environment

After installation of git client. Now you must need to set binary in system environment.

So edit /etc/bashrc file and add below content to it

# export PATH=$PATH:/usr/local/git/bin

Now execute below command to reload configuration in current environment.

# source /etc/bashrc

After completing above steps. Let’s use following command to check current git version.

# git --version

If it is showing older version then grep and remove it

# rpm -qa | grep git

git-1.8.3.1-6.el7_2.1.x86_64

# rpm -e --nodeps git-1.8.3.1-6.el7_2.1.x86_64

check for newer version

# git --version

git version 2.9.1

Setting up User Identity:

# git config --global user.name "John Doe"

# git config --global user.email peterdrucker@sample.com

# git config --global color.ui true

# git config --global color.status auto

# git config --global color.branch auto

# git config --global core.editor vim

# git config --global merge.tool vimdiff

# git config –list

Git – Life Cycle:

Step 4 – Create user and base repository

Create New user:

# groupadd devs

# useradd -G devs -d /home/sameer -m -s  /bin/bash sameer

# password sameer

Create a Base repository:

# pwd

/home/sameer

#  mkdir project.git

# cd project.git/

# ls

# git --bare init

Initialized empty Git repository in /home/sameer/project.git/

# ls

branches  config  description  HEAD  hooks  info  objects  refs

Step 5 – Configure git client on your local windows machine

Download and install git client and install

Open git gui  and select - > create new repository or Open existing repository.

Generate private/public keys for the SSH server

Generate key with secure phrase @ 4096 encryption

Install the new private ssh key on the remote server

private ssh key, remote server, authorized_keys

Install the new private ssh key into git client

Open -> Remote -> select Add then enter Name, location of remote server

(Location: ssh://username@192.168.1.7:22/home/user/repo/project.git)

Push your first commit to create the master remote-> push ->master

Done...

* Note: 

error: bash: git-receive-pack: command not found

fatal: Could not read from remote repository.

Adding this to my .bashrc via PATH=$PATH:/new/path/here worked for me

vi /home/user/.bashrc

PATH=$PATH:/usr/local/git/bin

source /etc/bashrc

Note:

You can easily restrict the git user to only doing Git activities with a limited shell tool called git-shell that comes with Git. If you set this as your git user’s login shell, then the git user can’t have normal shell access to your server. To use this, specify git-shell instead of bash or csh for your user’s login shell. To do so, you must first add git-shell to /etc/shells if it’s not already there:

# cat /etc/shells   # see if `git-shell` is already in there.  If not...

# which git-shell   # make sure git-shell is installed on your system.

# sudo vim /etc/shells  # and add the path to git-shell from last command

Now you can edit the shell for a user using chsh <username>:

# sudo chsh git  # and enter the path to git-shell, usually: /usr/bin/git-shell

Now, the git user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this:

# ssh git@gitserver

fatal: Interactive git shell is not enabled.

hint: ~/git-shell-commands should exist and have read and execute access.

Connection to gitserver closed.

Now Git network commands will still work just fine but the users won’t be able to get a shell. As the output states, you can also set up a directory in the git user’s home directory that customizes the git-shell command a bit. For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that. Run git help shell for more information on customizing the shell.

Git usage and example:

To create a new git repository, create a folder and apply this command
# git init

To create a working copy to a local repository
# git clone /path/to/repository

To creat a working copy from remote repository
# git clone username@host:/path/to/repository

Workflow:
local repository consists of three trees maintained by git.
1. Working directory  (holds actual files)
2. Index   (staging area)
3. HEAD  (points to last commit)

Add and commit:
add changes to the index using
# git add <filename>
# git add *

To commit changes to HEAD
# git commit -m "commit message"

To connect repository to remote server
# git remote add origin <server>

To send changes to remote repository
# git push origin master

To create a local branch and swith to it
# git checkout -b <branch>

To switch back to master branch
# git checkout master

To delete the branch
# git branch -d <branch>

To push branch to remote repository
# git push origin <branch>

To fetch and merge remote changes to local repository
# git pull

To merge another branch into active branch
# git merge <branch>

Mark them as merged with before merging changes
# git add filename

To preview changes and differences 
# git diff <source_branch>  <target_branch>

To create a new tags for software releases with commit id
# git tag 1.0.0 1b2e1d63ff

To see only the commits of a certain author
# git log --author=bob

To see a very compressed log where each commit is one line
# git log --pretty=oneline

To see an ASCII art tree of all the branches
# git log --graph --oneline --decorate --all

To see whichfiles have changed
# git log --name-status

To replace changes in your working repository
# git checkout --<filename>

To drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it
# git fetch origin
# git reset --hard origin/master