Some companies may deploy OpenStack clouds but without the Horizon Dashboard interface, and therefore you may wish to deploy your own horizon instance, either on a hosted VM of the OpenStack infrastructure, or why not on your own computer? Well this is possible.
However, your concern is that http might be insecure... especially if hosted on a VM or machine accessible from the Internet. So you want an SSL connection.
The issue is that SSL certificates can cost some money, but for personal usage, self-signed certificates will do the Job for no costs, and easy-rsa will make their management easy :-)
Note: even though you will run your own Horizon instance, you will not have extra privileges, it will just add your favorite "life easy-making GUI" on top of OpenStack :-)
Requirements:
On Centos/RHEL 6.x x86_64:
# Apache with SSL and wsgi support
sudo yum install httpd mod_ssl mod_wsgi
# EPEL repos
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# GIT to retrieve sources
sudo yum install git git-review
sudo yum install python-virtualenv
# cryptography requirements
sudo yum install gcc libffi-devel python-devel openssl-devel
On Ubuntu:
# Apache with SSL and wsgi support
sudo apt-get install apache2 libapache2-mod-wsgi
# GIT to retreieve sources
sudo apt-get install git git-review
sudo apt-get install python-virtualenv
# cryptography requirements
sudo apt-get install build-essential libssl-dev libffi-dev python-dev
Create an "horizon" user:
On Centos/RHEL:
useradd -d /home/horizon -m -g apache horizon
On Ubuntu:
useradd -d /home/horizon -m -s /bin/bash -g www-data horizon
sudo permissions for the horizon user:
If you want to be able to "sudo" from the horizon user (for convenience):
sudo su -c "echo 'horizon ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/horizon_user"
sudo chmod 0440 /etc/sudoers.d/horizon_user
The server will run under the "apache" or "www-data" user (depending on the distribution), so there is no risk of privilege escalation due to this sudo permission.
If after deployment you want to remove the horizon user's sudo permissions to feel reassured, just type:
sudo rm -f /etc/sudoers.d/horizon_user
switch to the horizon user:
Generate your SSL certificates:
Centos/RHEL:
sudo yum install easy-rsa
cp -r /usr/share/easy-rsa/2.0 ~/easy-rsa
On Ubuntu:
sudo apt-get install easy-rsa
cp -r /usr/share/easy-rsa ~/easy-rsa
NOTE: depending on your Ubuntu version, you might not find the easy-rsa package.
This package has been recently striped out of OpenVPN, so if you do not have an easy-rsa package, you can install OpenVPN and copy the easy-rsa script (and uninstall OpenVPN if you do not want to keep it):
sudo apt-get install openvpn libpkcs11-helper1 liblzo2-2
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 ~/easy-rsa
cp ~/easy-rsa/openssl-1.0.0.cnf ~/easy-rsa/openssl.cnf
# If you do not want to use or keep OpenVPN, you can now remove it:
sudo apt-get purge openvpn
Generate the certificates:
Edit the vars file in your ~/easy-rsa directory and adapt all the export KEY_* variables to your liking (especially: KEYSIZE, KEYCOUNTRY, KEYPROVINCE, KEYCITY, KEYORG, KEYEMAIL, KEY_OU), and then source this file:
and initialize certificates:
Create your own CA:
Create your server's certificate:
./build-key-server My_Server_Name
Hit the "enter" key when prompted for a password.
This creates a password-less private key which is usually considered bad practice but we do it this way here for convenience because your server will not enter passwords to use the certificate, requiring a password for a server key is also bad practice because most users of such certificates will use the clear-text password in a configuration file in order to use the certificate automatically in init scripts.
Hit the "y" key when prompted to Sign the certificate, and when prompted to commit.
In the keys subdirectory you will now see something like this:
-rw-r--r--. 1 horizon apache 5625 Apr 2 14:35 01.pem
-rw-r--r--. 1 horizon apache 1809 Apr 2 14:32 ca.crt
-rw-------. 1 horizon apache 1704 Apr 2 14:32 ca.key
-rw-r--r--. 1 horizon apache 152 Apr 2 14:35 index.txt
-rw-r--r--. 1 horizon apache 21 Apr 2 14:35 index.txt.attr
-rw-r--r--. 1 horizon apache 0 Apr 2 14:31 index.txt.old
-rw-r--r--. 1 horizon apache 5625 Apr 2 14:35 My_Server_Name.crt
-rw-r--r--. 1 horizon apache 1102 Apr 2 14:35 My_Server_Name.csr
-rw-------. 1 horizon apache 1708 Apr 2 14:35 My_Server_Name.key
-rw-r--r--. 1 horizon apache 3 Apr 2 14:35 serial
-rw-r--r--. 1 horizon apache 3 Apr 2 14:31 serial.old
apache will need read access to MyServerName.key:
chmod g+rx keys
chmod g+r keys/My_Server_Name.key
NOTE:
These are Self-signed certificates usually made for testing or pre-deployement, so since your browser isn't able to verify the identity of your website when accessing your server, it will display a "This Connection Is Untrusted" alert page saying it is an untrusted site. This is normal. To avoid this message you will have to bypass the warning, or import the ca.crt file in your browser (the later works only if when prompted for the server name by the ./build-key-server command, you give the server the same hostname as the FQDN you use to access it, otherwise you will get a "Certificate is only valid for (site name)" warning instead).
Get the Horizon source:
Clone horizon sources:
git clone git://git.openstack.org/openstack/horizon.git
You will now see an horizon directory (under you own "horizon" user's /home/horizon directory if you created one previously).
change to this new horizon directory:
Horizon needs python dependencies which may not be provided in the proper version by your OS's packaging system, so the best is to use a virtual environment to install the python packages without any conflicts with your distribution's packages:
virtualenv --no-site-packages .venv
source .venv/bin/activate
pip install -Ur requirements.txt
If some packages fail to compile with errors like this one (It "sometimes" may happen when your language's locales is not strictly limited to ASCII):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 126: ordinal not in range(128)
then try the last command again but prefixed with LC_ALL=C:
LC_ALL=C pip install -Ur requirements.txt
Configure your local_settings:
cd openstack_dashboard/local/
cp local_settings.py.example local_settings.py
And edit local_settings.py with your favorite editor and set DEBUG = False, then configure OPENSTACK_API_VERSIONS, OPENSTACK_HOST and uncomment:
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True
With DEBUG = False, you need to set ALLOWED_HOSTS to a list of strings representing the host/domain names used to access your horizon site. If you have not registered any hostname yet, you will have to set the server's IP (as a string) in the list in order to be able to access Horizon via it's IP in your browser. See ALLOWED_HOSTS for detailed information.
You also have to edit SECRET_KEY.
If you use SECRET_KEY = secret_key.generate_or_read_from_file(os.path.join(LOCAL_PATH, '.secret_key_store')) the apache (or www-data) user will need write access to this file (.secret_key_store) because this file is created the first time you launch Horizon. Instead you can set SECRET_KEY to a string (e.g.: SECRET_KET = 'a unique sentence no one can guess') SECRET_KEY is used to provide cryptographic signing, and should be set to a unique, unpredictable value. Running Horizon with a known SECRET_KEY defeats many of Horizon’s security protections, and can lead to privilege escalation and remote code execution vulnerabilities. Horizon will now refuse to start if SECRET_KEY is not set.
If you use Self-signed certificates uncomment:
OPENSTACK_SSL_NO_VERIFY = True
Otherwise, uncomment:
OPENSTACK_SSL_CACERT = '/path/to/cacert.pem'
and set the path to the CA provided by your Certificate Authority
Get the apache configuration script:
If the Web deployment configuration script isn't yet merged (see Change I6397ba01: Created a makewebconf command.) you can cherry-pick it:
git checkout -b web-conf-generation-script
git fetch https://review.openstack.org/openstack/horizon refs/changes/68/82468/6 && git cherry-pick FETCH_HEAD
This patch adds a django_admin management command allowing to create a wsgi file with virtual environment detection, and an apache configuration file. We will use this command.
Go back the ~/horizon directory (where the manage.py file is located):
Activate your virtual environment if not already done (In a bash shell, your prompt is usually prefixed by "(.venv)" if it's activated, but if typing echo $VIRTUAL_ENV returns nothing, it means you have to source it):
source .venv/bin/activate
Create the wsgi file:
We use the Web deployment configuration script:
python manage.py make_web_conf --wsgi
Collect static files:
We gather all the static files which apache will have to serve (they will be placed in the directory defined by STATIC_ROOT in the local_settings.py file):
python manage.py collectstatic
Compile .pyc files:
If apache does not have write access it won't be able to write .pyc files during code execution, and this drastically slows down python's performances.
Instead of relying on the code execution to compile the bytecode .pyc files, we create (compile) them manually:
Give apache some permissions:
We Give apache read access to files, execution permission on directories, and write permission to static files directory:
sudo chmod -R g+r ~/
find ~/ -type d -exec sudo chmod g+x {} \;
find ~/horizon/static -type d -exec chmod g+w {} \;
Create your apache configuration file:
We use the Web deployment configuration script again:
python manage.py make_web_conf --apache --ssl \
--sslcert=/home/horizon/easy-rsa/keys/My_Server_Name.crt \
--sslkey=/home/horizon/easy-rsa/keys/My_Server_Name.key \
--mail=your.email@youdomain.com > horizon.conf
And move this configuration file to your apache conf directory:
Centos/RHEL Apache configuration file:
sudo mv horizon.conf /etc/httpd/conf.d/
sudo chown root:root /etc/httpd/conf.d/horizon.conf
edit /etc/httpd/conf/httpd.conf and replace:
by:
NameVirtualHost *:443
WSGISocketPrefix /var/run/wsgi
To start Apache:
To restart Apache:
sudo service httpd restart
Logs are available in /var/log/httpd/openstack_dashboard-error.log and /var/log/httpd/openstack_dashboard-access.log.
Ubuntu Apache configuration file:
sudo mv horizon.conf /etc/apache2/sites-available/horizon
sudo chown root:root /etc/apache2/sites-available/horizon
sudo a2ensite horizon
sudo a2ensite ssl
To start Apache:
sudo service apache2 start
To restart Apache:
sudo service apache2 reload
Logs are available in /var/log/apache2/openstack_dashboard-error.log and /var/log/apache2/openstack_dashboard-access.log.
Notes about unscoped tokens:
Some cloud companies do not let you log in with an unscoped token and horizon logs will tell you your login failed even though you entered the proper password.
If this is the case, you may need to modify your .venv/lib/python2.7/site-packages/openstack_auth/backend.py (or .venv/lib/python2.6/site-packages/openstack_auth/backend.py) file like this:
change the try block line 134:
try:
client = keystone_client.Client(
tenant_id=project.id,
token=unscoped_auth_ref.auth_token,
auth_url=auth_url,
insecure=insecure,
cacert=ca_cert,
debug=settings.DEBUG)
to:
try:
client = keystone_client.Client(
tenant_id=project.id,
#token=unscoped_auth_ref.auth_token,
user_domain_name=user_domain_name,
username=username,
password=password,
auth_url=auth_url,
insecure=insecure,
debug=settings.DEBUG)
Keep up to date:
Once Horizon deployed, staying up to date is easy:
git checkout master
git remote update && git pull --ff-only origin master
source .venv/bin/activate
pip install -Ur requirements.txt # you might need to redo the unscoped tokens change
find . -name "*.pyc" -delete
python -m compileall .
python manage.py collectstatic
chmod -R g+r ~/horizon
find ~/horizon -type d -exec chmod g+x {} \;
find ~/horizon/static -type d -exec chmod g+w {} \;
And restart apache.
Centos/RHEL:
Ubuntu:
sudo service apache2 reload
Enjoy your Horizon GUI, and feel free to review the Change I6397ba01: Created a makewebconf command. patch, or to add suggestions to the Web deployment configuration script Blueprint.
Cloud computing, however, was created to accommodate a different class of applications, such as MongoDB and Hadoop. Cloud platforms like OpenStack are designed to be used with applications that have a distributed architecture where application components are distributed across multiple physical or virtual servers. These applications are generally designed to grow by scaling out across multiple servers so as demand increases, resources can be expanded by adding more application instances and re-balancing workloads across those instances. Another design principle behind cloud platforms such as OpenStack is that given the distributed nature of these applications, ownership for resiliency belongs to the applications and not the underlying infrastructure. This approach is often misunderstood by folks in the VMware space as a shortcoming and immaturity in the OpenStack platform; “lacking” features such as vSphere HA are seen as a potential warning sign that OpenStack is not ready for production usage.
However, this is a misunderstanding about the differing design principles of legacy and cloud. Distributed applications that run on cloud platforms (what the industry often term as “cloud native” applications) have lowered the barrier for building resiliency, both in terms of cost and of usability. By moving application resiliency up the stack, cloud platforms remove the need for shared-everything architecture based decisions such as the use of shared storage. This promotes the use of commodity as an option for running a cloud platform and creates an architecture that enables rapid scaling out the infrastructure. It is also an architecture that is best suited for next-generation large scale application environments where failure is expected and needs to be designed at multiple layers, not simply at the infrastructure layer.
I look forward to hitting the road and continuing the work I’ve been doing as an official OpenStack Ambassador and a VMware vExpert educating technologists on the value and power of vSphere with OpenStack. More importantly, I am excited to meet as many folks as I can in the VMware and OpenStack communities. As always, I invite you all to engage with me and help me make what I present useful to as many people as possible.
Welcome to the Short Stack, our weekly feature where we search for the most intriguing OpenStack links to share with you. These links may come fromtraditional publications or company blogs, but if it's about OpenStack, we'll find the best links we can to share with you every week. If you like what you see, please consider subscribing. Here we go with this week's links:
OpenStack's Icehouse release will be available on April 17th. 
