OpenStack in a backpack – how to create a demo environment for F5 Heat Plugins, part 2
Part 2 – OpenStack installation and testing After “Part 1 – Host environment preparation” you should have your CentOS v7, 64-bit instance up and running. This article will walk you through the OpenStack RDO installation and testing process. Every command requires a Linux root privileges and is issued from the /root/ directory. If you visited the RDO project website, you might have seen the Packstack quickstart installation instructions, recommending you issue a simple packstack --allinone command. Unfortunately, packstack --allinone does not build out OpenStack networking in a way that gives us external access to the guest machines. It doesn’t install the Heat project either. This is why we need to follow a bit more complex route. Install and Set Up OpenStack RDO Install and update the RDO repos: yum install -y https://repos.fedorapeople.org/repos/openstack/openstack-mitaka/rdo-release-mitaka-5.noarch.rpm yum update -y Install the OpenStack RDO Mitaka packages: yum install -y centos-release-openstack-mitaka yum install -y openstack-packstack I strongly recommend that you generate a Packstack answer file first, review it, and correct it if needed, then apply it. It’s less error-prone and it expedites the process of future re-installation (or later installation on a second host). Generate the Packstack answer file: packstack --gen-answer-file=my_answer_file.txt \ --allinone --provision-demo=n --os-neutron-ovs-bridge-mappings=extnet:br-ex \ --os-neutron-ovs-bridge-interfaces=br-ex:ens33 --os-neutron-ml2-type-drivers=vxlan,flat \ --os-neutron-ml2-vni-ranges=100:900 --os-neutron-ml2-tenant-network-types=vxlan \ --os-heat-install=y \ --os-neutron-lbaas-install=y \ --default-password=default NOTE: “ens33” should be replaced with the name of your non-loopback interface. Use “ip addr” to find it. You can remove the --os-neutron-lbaas-install=y \ line if you don’t intend to use your portable OpenStack cloud to play with F5 LbaaS as well. Review the answer file ( my_answer_file.txt ) and correct it if needed. Apply the answer file ( my_answer_file.txt ). packstack --answer-file=my_answer_file.txt Now it’s time to take a long coffee or lunch break, because this part takes a while! Verify that a bridge has been properly created: Your non-loopback interface should be assigned to an OVS bridge.... [root@mitaka network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-ens33 DEVICE=ens33 NAME=ens33 DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=br-ex ONBOOT=yes BOOTPROTO=none .... and the new OVS bridge device should take over the IP settings: [root@mitaka network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-br-ex DEFROUTE=yes UUID=015b449c-4df4-497a-93fd-64764e80b31c ONBOOT=yes IPADDR=10.128.10.3 PREFIX=24 GATEWAY=10.128.10.2 DEVICE=br-ex NAME=br-ex DEVICETYPE=ovs OVSBOOTPROTO=none TYPE=OVSBridge Change a virt type from qemu to kvm, otherwise F5 will not boot: openstack-config --set /etc/nova/nova.conf libvirt virt_type kvm Restart the nova compute service for your changes to take effect. openstack-service restart openstack-nova-compute Mitaka RDO may not take a default DNS forwarder from the /etc/resolv.conf file, so you need to set it manually: openstack-config --set /etc/neutron/dhcp_agent.ini \ DEFAULT dnsmasq_dns_servers 10.128.10.2 openstack-service restart neutron-dhcp-agent In this example, 10.128.10.2 is the closest DNS resolver; that should be your VMware workstation or home router (see part 1). There are couple of CLI authentication methods in OpenStack (e.g. http://docs.openstack.org/developer/python-openstackclient/authentication.html). Let’s use the easiest – but not the most secure – one for the purpose of this exercise, which is setting bash environment variables with username, password, and tenant name. The packstack command has created a flat file containing environment variables that logs you in as the admin user and the admin tenant. You can load those bash environment variables by issuing: source keystonerc_admin Set Up OpenStack Networks Next, we’ll configure our networks in OpenStack Neutron. The “openstack” commands will be issued on behalf of the admin user, until you load different environment variables. It’s a good time to review the keystonerc_admin file, because soon you will have to create such a file for a regular (non-admin) user. Load admin credentials: source keystonerc_admin Configure an external provider network: neutron net-create external_network --provider:network_type flat \ --provider:physical_network extnet --router:external Configure an external provider subnet with an IP address allocation pool that will be used as OpenStack floating IP addresses: neutron subnet-create --name public_subnet --enable_dhcp=False \ --allocation-pool=start=10.128.10.30,end=10.128.10.100 \ --gateway=10.128.10.2 external_network 10.128.10.0/24 \ --dns-nameserver=10.128.10.2 In the example given, 10.128.10.0/24 is my external subnet (the one configured during CentOS installation); 10.128.10.2 is both a default gateway and DNS resolver. Please note that the OpenStack Floating IP address is a completely different concept than an F5 Floating IP address. F5 Floating IP address is an IP that floats between physical or virtual F5 entities in a cluster. OpenStack Floating IP address is a NAT address that is translated from a public IP address to a private (tenant) IP address. In this case, it is defined by --allocation-pool=start=10.128.10.30,end=10.128.10.100 To avoid typos and confusion, let’s make further changes via the CLI and review the results in GUI. In Chrome or Mozilla, enter the IP address you assigned to your CentOS host in your address bar: http://<IP-address> (http://10.128.10.3, in my case). NOTE: IE didn’t work with an OpenStack Horizon (GUI) Mitaka release on my laptop. Set up a User, Project, and VM in OpenStack Next, to make this exercise more realistic, let’s create a non-admin tenant, non-admin user, with non-admin privileges. Create a demo tenant (a.k.a. project): openstack project create demo Create a demo user and assign it to demo tenant: openstack user create --project demo --password default demo Create a keystone environment variable file for demo user that access demo tenant/project: cp keystonerc_admin keystonerc_demo sed -i 's/admin/demo/g' keystonerc_demo source keystonerc_demo Your bash prompt should now look like [root@mitaka ~(keystone_demo)]# , since from now on all the commands will be executed on behalf of the demo user, within the demo tenant/project. In addition, you should be able to log into the OpenStack Horizon dashboard with the demo/default credentials. Create a tenant router. Please double-check that your environment variables are set for demo user. neutron router-create router1 neutron router-gateway-set router1 external_network Create a tenant (internal) management network: neutron net-create management Create a tenant (internal) management subnet and attach it to the router: neutron subnet-create --name management_subnet management 10.0.1.0/24 neutron router-interface-add router1 management_subnet Your network topology should be similar to that shown below (Network-> Network Topology-> Toggle labels): Create an ssh keypair, and store the private key to your pc. You will use this key for a password-less logging to all the guest machines: openstack keypair create default > demo_default.pem Store demo_default.pem to your PC. Please remember to chmod 600 demo_default.pem before using it with ssh -i command. Create an “allow all” security group: openstack security group create allow_all openstack security group rule create --proto icmp \ --src-ip 0.0.0.0/0 --dst-port 0:255 allow_all openstack security group rule create --proto udp \ --src-ip 0.0.0.0/0 --dst-port 1:65535 allow_all openstack security group rule create --proto tcp \ --src-ip 0.0.0.0/0 --dst-port 1:65535 allow_all Again, it’s not the best practice to use such a loose access roles, but the goal of this exercise is to create easy to use demo/test environment. Download and install a Cirros image (12.6MB): curl http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img | \ openstack image create --container-format bare \ --disk-format qcow2 "Cirros image" Check the image status: +------------------+------------------------------------------------------+ | Field | Value | +------------------+------------------------------------------------------+ | checksum | ee1eca47dc88f4879d8a229cc70a07c6 | | container_format | bare | | created_at | 2016-08-29T19:08:58Z | | disk_format | qcow2 | | file | /v2/images/6811814b-9288-48cc-a15a-9496a14c1145/file | | id | 6811814b-9288-48cc-a15a-9496a14c1145 | | min_disk | 0 | | min_ram | 0 | | name | Cirros image | | owner | 65136fae365b4216837110178a7a3d66 | | protected | False | | schema | /v2/schemas/image | | size | 13287936 | | status | active | | tags | | | updated_at | 2016-08-29T19:12:46Z | | virtual_size | None | | visibility | private | +------------------+------------------------------------------------------+ Spinning up your first Guest VM in your OpenStack environment. Here you will use previously created ssh key and allow_all security group. The guest image should be connected to the tenant “management” network. openstack server create --image "Cirros image" --flavor m1.tiny \ --security-group allow_all --key-name default \ --nic net-id=management Cirros1 Now you should be able to access a Cirros1 console: If everything went well, you should be able to log in to the Cirros1 VM with the cirros/subswin:) credentials and you should be able to ping www.f5.com from Cirros1. If your ping works, it looks like Cirros1 has got a way out. Next, let’s create a way in, so we can ssh to the Cirros1 instance from outside. If the console doesn’t react to keystrokes, click the blue bar with “Connected (unencrypted)” first. Create an OpenStack floating IP address: openstack ip floating create external_network Observe a newly create IP address. You will use it in the next step: +-------------+--------------------------------------+ | Field | Value | +-------------+--------------------------------------+ | fixed_ip | None | | id | 5dff365f-3cc8-4d61-8e7e-f964cef3bb8b | | instance_id | None | | ip | 10.128.10.31 | | pool | external_network | +-------------+--------------------------------------+ Now, the newly created “public” IP address may be attached to any Virtual Machine, Cirros1 in this case. Attaching an OpenStack floating IP address creates one-to-one network address translation between public IP address and tenant (private) IP address. Attach the OpenStack floating IP address to your Cirros1: openstack ip floating add 10.128.10.31 Cirros1 Test a way in: ssh from outside to your Cirros1: ssh -i demo_default.pem cirros@10.128.10.31 Or equivalent putty command. Check that you are really on Cirros1: $id uid=1000(cirros) gid=1000(cirros) groups=1000(cirros) If the test was successful, it looks like your basic OpenStack services are up and running. To spare a scarce CPU and memory resources, I’d strongly suggest to hibernate or remove Cirros1 VM. Hibernating: openstack server suspend Cirros1 Removing: openstack server delete Cirros1 Before you boot or shutdown the CentOS host, you should be aware of one CentOS/Mitaka specific issue: your hardware may be too slow to boot an httpd service within the default 90s. This is why I had to change this timeout: sed -i \ 's/^#DefaultTimeoutStartSec=[[:digit:]]\+s/DefaultTimeoutStartSec=270s/g' \ /etc/systemd/system.conf Useful troubleshooting commands: openstack-status , systemctl show httpd.service , systemctl status httpd.service . In the next (and final) article in this series, we’ll install the F5 Heat plugins and onboard the F5 qcow2 image using F5 Heat templates.OpenStack in a backpack - how to create a demo environment for F5 Heat Plugins, part 3
Part 3 – F5 Heat Plugins installation and BIG-IP VE onboarding This article demonstrates how to install the F5 Heat Plugins and onboard a BIG-IP VE image into OpenStack Mitaka using F5 Heat templates. Before you get started, please review the installation instructions for the F5 Heat plugins (https://f5-openstack-heat-plugins.readthedocs.io/en/latest/) to ensure you’re using the latest version. The instructions provided in this article are current at the time of posting. Install the F5 Heat Plugins Run the following commands on the heat service node. Root privileges are required. Install the Python installation tool (pip): yum -y install python-pip Install the F5 Heat plugins. pip install f5-openstack-heat-plugins Make the Heat plugins directory (NOTE: this may already exist). mkdir -p /usr/lib/heat Create a link to the F5 plugins in the Heat plugins directory. ln -s /usr/lib/python2.7/site-packages/f5_heat /usr/lib/heat/f5_heat Restart the Heat engine service: systemctl restart openstack-heat-engine.service Now, you should see the F5 Heat resources in the OpenStack Horizon dashboard, under “Orchestration->Resource Types”: Prepare Your Project to use the F5 Heat Template Next, you’ll use the F5 BIG-IP ‘Image Patch and Upload’ heat template (http://f5-openstack-heat.readthedocs.io/en/latest/templates/supported/ref_images_patch-upload-ve-image.html) to patch your VE image for use in OpenStack and onboard it. ‘Patching’ is modifying the BIG-IP QCOW2 image so it can run within OpenStack and make use of the OpenStack Metadata service, for licensing, setting networking parameters etc. This template requires a bit of preparation, described in the Prerequisites section of the template documentation. In particular, you need to create an OpenStack flavor for the BIG-IP appliance and create an SSH key to use to log in to the BIG-IP. You will also need to provide a link to a Ubuntu image, as the template utilizes an Ubuntu server to extract and patch the image. An appropriate tenant network was already created and tested in the previous article in this series, so no need to do it again. First, log in as the OpenStack admin user to create a new flavor for the BIG-IP and adjust the ‘demo’ user’s permissions. The default OpenStack non-admin privileges do not allow creation of OpenStack Flavors or Heat stacks. Create a new flavor via the command line: sourcekeystonerc_admin openstack flavor create --ram 4096 --disk 20 --vcpus 2 \ --public "F5-small 1 slot" Refer to http://f5-openstack-docs.readthedocs.io/en/latest/guides/openstack_big-ip_flavors.html for additional information regarding BIG-IP VE flavor requirements. Give permission to create Heat stacks to the demo user: openstack role add --project demo --user demo heat_stack_owner You can now switch back to your ‘demo’ user account and import an Ubuntu image to Glance. source keystonerc_demo curl http://uec-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img | \ openstack image create --container-format bare \ --disk-format qcow2 --min-disk 10 "Ubuntu 14.04 LTS" The Heat template requires that the BIG-IP image be hosted in a location accessible to the Heat engine via ‘http’. Assuming that you do not have any other place to host the BIG-IP qcow2 image, we’ll create it one on the Horizon Apache server. Create a new directory to store the image in. mkdir -p /home/openstack/bigipimages/ Add the following lines to /etc/httpd/conf.d/15-horizon_vhost.conf , just before closing </VirtualHost> : Alias /bigipimages "/home/openstack/bigipimages/" <Directory "/home/openstack/bigipimages/"> Options Indexes FollowSymLinks MultiViews AllowOverride None Require all granted <Directory/> Restart the httpd service: systemctl restart httpd.service Download BIGIP-11.6.1.1.0.326.LTM_1SLOT.qcow2.zip from https://downloads.f5.com/ and upload it to /home/openstack/bigipimages/ . Direct link: https://downloads.f5.com/esd/serveDownload.jsp?path=/big-ip/big-ip_v11.x/11.6.1/english/virtual-edition_base-plus-hf1/&sw=BIG-IP&pro=big-ip_v11.x&ver=11.6.1&container=Virtual-Edition_Base-Plus-HF1&file=BIGIP-11.6.1.1.0.326.LTM_1SLOT.qcow2.zip Change the permissions so the file can be seen by Apache: chmod -x+r /home/openstack/bigipimages/*.zip The compressed qcow2 image should now be accessible at: http://<ip_address>/bigipimages/BIGIP-11.6.1.1.0.326.LTM_1SLOT.qcow2.zip Please replace <ip_address> with an IP address of your CentOS host. Launch Your Heat Stack Most of the Heat templates require you to supply some specific configuration parameters (e.g., which networks should be used, what flavor, security group etc). Those parameters are rendered as a questionnaire in the Horizon GUI, right after you specify the source heat template's file or url. Unfortunately, I noticed that Mitaka release doesn't always show external networks in the GUI correctly, while the external network's name can be provided via CLI without any problems. Another disadvantage of Orchestration section in Horizon is that if you make any mistakes or typos, you need to type all the parameters over again. So, the easiest and the most efficient method is to provide Heat parameters in an environment file. Create an environment file – for example, patch_upload_paremeters.yaml – that contains the following parameters: parameters: onboard_image: "Ubuntu 14.04 LTS" flavor: m1.medium # THE FLAVOR YOU CREATED private_network: management f5_image_import_auth_url: http://<ip_address>:5000/v2.0 # YOUR KEYSTONE AUTHENTICATION URL f5_image_import_tenant: admin # THE NAME OF YOUR PROJECT SPACE f5_image_import_user: admin # YOUR USERNAME f5_image_import_password: default # YOUR PASSWORD f5_ve_image_url: http://<ip_address>/bigipimages/BIGIP-11.6.1.1.0.326.LTM_1SLOT.qcow2.zip f5_ve_image_name: BIGIP-11.6.1.1.0.326.qcow2 image_prep_key: default Note: Leading white spaces are significant in the yaml file. Launch the stack: openstack stack create -e patch_upload_paremeters.yaml \ -t https://raw.githubusercontent.com/F5Networks/f5-openstack-heat/master/f5_supported/ve/images/patch_upload_ve_image.yaml \ F5_onboard Please note that we used the GitHub version of the template in the above command (https://raw...). You can also use the download link for the template provided in the documentation. Do not try to use the link for an html-formatted yaml file. You should see your stack being created in Horizon at "Orchestration -> Stacks -> F5_onboard". You can supervise the patching progress by clicking on a Compute instance log: At the end, the stack status should be "Status Create_Complete: Stack CREATE completed successfully". You can check it by clicking on "Orchestration -> Stacks -> F5_onboard -> Overview". If you can't see the stack in your account in Horizon, double-check which user you identified in the environment file; if you specified 'admin', you’ll need to log in as the admin user. Now that you have a BIG-IP image onboarded, you can use it with the F5-supported Heat Templates (http://f5-openstack-heat.readthedocs.io/en/latest/templates/templates_index.html#f5-supported) to deploy BIG-IP VE from any of your OpenStack user accounts. First, make sure the BIG-IP image is visible to all users in your OpenStack environment. source keystonerc_admin openstack image set --public BIGIP-11.6.1.1.0.326 source keystonerc_demo The patched BIG-IP image should be visible in “Compute -> Images” or via the openstack image-list command. As an exercise, you can change the Heat template to include this step. You can now safely delete the onboarding stack. Don’t worry, the BIG-IP image will stick around. openstack stack delete F5_onboard Now, let’s spin up a stand-alone BIG-IP VE with two production interfaces using the F5 BIG-IP VE: Standalone, 3-nic Heat template (http://f5-openstack-heat.readthedocs.io/en/latest/templates/supported/ref_common_f5-ve-standalone-3nic.html) We already have a Management subnet, but we’ll need to add the traffic subnets. Create client and server-side networks: neutron net-create client neutron subnet-create --name client_subnet client 10.0.2.0/24 neutron router-interface-add router1 client_subnet neutron net-create server neutron subnet-create --name server_subnet server 10.0.3.0/24 neutron router-interface-add router1 server_subnet Now your network topology should look as follows: Create a standalone_3_nic_paremeters.yaml environment file that contains: parameters: ve_image: BIGIP-11.6.1.1.0.326 ve_flavor: "F5-small 1 slot" admin_password: admin f5_ve_os_ssh_key: default root_password: default license: <<<your eval license goes here>>> external_network: external_network mgmt_network: management network_1: client network_1_name: client network_2: server network_2_name: server Please remember to insert your evaluation license key. Launch the stack: openstack stack create -e standalone_3_nic_paremeters.yaml \ -t https://raw.githubusercontent.com/F5Networks/f5-openstack-heat/master/f5_supported/ve/standalone/f5_ve_standalone_3_nic.yaml \ F5_standalong_3_nics Now you can find a floating IP address in "Orchestration -> Stacks -> F5_standalon_2nic -> Overview -> Floating IP". You should be able to observe the patching process by running the following command: ssh -i demo_default.pem root@<<floating IP>> tail -f /var/log/messages If the patching process is complete you should see something like this: Sep 14 11:21:05 host-10 notice openstack-init: Completed OpenStack auto-configuration in 167 seconds... You should now be able to log into the BIG-IP configuration utility at the [OpenStack] floating ip address allocated by Neutron. Be sure to use https (e.g., "https://<the_floating_IP>") and give the BIG-IP enough time to fully boot. The VE platform should be properly licensed and basic network configuration should be set up. If everything works fine, you are ready to play with other F5 heat templates, and maybe write your own F5 heat resources. Good starting points would be the GitHub repo (https://github.com/F5Networks/f5-openstack-heat) and the project docs (https://f5-openstack-heat.readthedocs.io/en/latest/). Special thanks to John Gruber, Laurent Boutet, Paul Breaux, Shawn Wormke, Jodie Putrino, and the whole F5 OpenStack PD team.OpenStack in a backpack – how to create a demo environment for F5 Heat Plugins, part 1
Part 1 – Host environment preparation. If you are a Network Engineer, one day you may be asked to roll out F5 ADC in the OpenStack environment. But hey, OpenStack may look new and scary to you, as it was for me. You’ve probably learned on Devcentral (https://devcentral.f5.com/s/wiki/openstack.openstack_heat.ashx) that Heat is a primary OpenStack orchestration service, and that Heat and the F5 Heat Plugins are useful for rolling out and configuring F5 BIG-IP Virtual Edition (VE) on top of the OpenStack environment. Let’s say that you've decided to accustom yourself with Heat and F5 Heat Plugins, but you do not have access to any OpenStack test or development environments, and/or you do not have admin rights to install the F5 Heat Plugins in OpenStack. If so, this series of articles is for you. Please note, that OpenStack is a moving target. By the time I was writing this article, Mitaka was the supported OpenStack release. See https://releases.openstack.org/ for further information. This is what you need to create your small, single-host OpenStack lab environment: Some hardware or virtual machine with >=4 cores, 16G of RAM and Intel VT-x/EPT or AMD-V/RVI support. In my case, it was an old Dell laptop that IT department intended to scrap. ;-) A decent Internet connection. In case of bare metal deployment, you need a home router. In my case it was my old WRT54gl. Ask your F5 Partner or F5 representatives for a couple of VE 45-day evaluation licenses. To sum up, it cost me 0$ to build my own OpenStack lab environment. This is what you will get: Fully functional OpenStack Mitaka environment Heat and F5 Heat Plugins F5 VE as guest machine Direct access to F5 GUI, CLI, Virtual Servers from your laptop or any other devices connected to the home router Possibility to test F5 VE setup from inside or outside of OpenStack Naming convention: [HW] – actions to be done for the bare metal deployment [VMware] – actions to be done for the VMware guest machine deployment no square bracket – do it regardless of whether it’s a physical or VMware deployment. Host Preparation Download and Install the Operating System Check if you have Intel VT-x/EPT or AMD-V/RVI turned on in your bios. Sample screenshot: Download a CentOS v.7 64-bit minimal image: http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1511.iso [HW] Store the CentOS image on a USB stick. The simplest method is to use some other Linux box. dd if=CentOS-6.5-x86_64-bin-DVD1.iso of=/dev/sdb In the above command, /dev/sdb is an USB device; your USB device name will most likely be different. To find out the USB device name, observe /var/log/syslog , or /var/log/messages , while connecting the USB drive to the Linux machine. Further info at:https://wiki.centos.org/HowTos/InstallFromUSBkey [VMware] Create a custom VMware workstation virtual machine. Set everything to default except: Guest Operating system: RedHat Enterprise Linux 7 64-bit. Number of processors: 4 Memory for this Virtual Machine [RAM]: 16384MB (16G) Use Network address translation. You should review and alter the VMware network configuration. Let’s assume that the NAT network is 10.128.10.0/24, where a default route and DNS is set to 10.128.10.2, turn off DHCP. Maximum disk size: 200GB IMPORTANT: Turn on a nested VM support by: Edit virtual machine settings -> Processors -> enable Virtualize Intel VT-x/EPT or AMD-V/RVI NOTE: If you see different GUI options, read this article: https://communities.vmware.com/docs/DOC-8970 For the sake of performance, disable memory page trimming: Install CentOS.Boot the USB drive [HW] or connect the CentoOS .iso image to the VMware guest machine [VMware]. Configure the OS Choose English as the language. Set your local time zone. Correct time will ease troubleshooting. Disable a Security Policy: Network settings: Set your hostname to: mitaka.f5demo.com and configure the network interface: Turn on “Automatically connect to this network when it is available”: Configure IPv4 address, mask, default route and DNS: Disable IPv6: Check if the network interface is switched on: [optional] Disable KDUMP (from the main screen) Open INSTALLATION DESTINATION from the main screen and choose “Partition disk automatically”: Hit “Begin Installation”. Set root password to “default”. You need to hit “DONE” button twice to make CentOS accept the weak password. A user account is not required. CentOS will prompt you to reboot. Permit ssh root login. Uncomment PermitRootLogin yes at /etc/ssh/sshd_config Reboot the ssh service systemctl restart sshd.service Configure the host Now, you should be able to log in to your OpenStack host with an ssh client (e.g., putty or iTerm2), so you can copy/paste the rest of the commands. Generate ssh keyset: ssh-keygen (empty passwords recommended) [HW] By default, the CentOS will suspend on a lid close. To turn this off: In /etc/systemd/logind.conf , set HandleLidSwitch=ignore Further details at http://askubuntu.com/questions/360615/ubuntu-server-13-10-now-goes-to-sleep-when-closing-laptop-lid Turn off Network Manager: systemctl disable NetworkManager systemctl stop NetworkManager Set the hostnames as shown below: [root@mitaka ~]# cat /etc/hosts |grep mitaka 10.128.10.3 mitaka.f5demo.com mitaka and cat /etc/hostname mitaka.f5demo.com Fill in the /etc/sysconfig/network as depicted: # Created by anaconda NETWORKING=yes HOSTNAME=mitaka.f5demo.com GATEWAY=10.128.10.2 Where 10.128.10.2 is a gateway IP address. Switch off selinux: sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config Set English locales: [root@openstack01 ~]# cat /etc/environment LANG=en_US.utf-8 LC_ALL=en_US.utf-8 Update the system: yum update -y Reboot the system: reboot Next, you should be ready to install OpenStack RDO. Stay tuned for instructions in the next installment of OpenStack in a Backpack!
