So, at work we had a lot of customers that were asking for new ipv4’s all of the time, and it’s a little known thing to the mainstream that it is actually possible to configure SSL just fine without the addition of a new IP, or the implementation of SNI (Server Name Indication).

Here is how I configured a basic apache2 server without the need for additional IP’s or SNI. The trick is to use ports. This works for Debian, Ubuntu and also CentOS, RHEL and Fedora but you will want to replace apt-get with yum for the latter 3 distributions.

(for security purposes, I removed the real private and public network IP of my servers to prevent attacks. It does however not affect the clarity of this tutorial providing that you bear in mind you need to replace your load balancer private IP in the apache2 virtualhost configuration. )

1. Step 1, Install apache2 and enable SSL

apt-get update
apt-get install apache2
a2enmod ssl
service apache2 restart

2. Step 2 Create Self Signed Certificates (optional step), you can use some SSL certificates you purchased instead, place them in /etc/apache2/ssl/your.website.com.crt and /etc/apache2/ssl/yourwebsite.com.key for organisational reasons.

mkdir /etc/apache2/ssl

mkdir -p /var/www/shop.example.com/html

 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

The prompt looks like this; answer the contact and country details, this can generally be anything but be sure to include your FQDN ( fully qualified domain name ) that you want SSL to run with. I will be configured shop.example.com

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Your Company
Organizational Unit Name (eg, section) []:Department of Catz
Common Name (e.g. server FQDN or YOUR name) []:shop.example.com
Email Address []:[email protected]

3. Step 3 Configure Apache2 with your primary IP address using SSL being sure to ensure that you specify an SSLCertificateFile and SSLCertificateKeyFile. You generated the CertficateFile and KeyFile in step 2, but the below directive is an example of how I configured a HTML website for use with SSL

<VirtualHost 134.213.1.1:443>

ServerName shop.example.com

DocumentRoot /var/www/shop.example.com/html
CustomLog /var/www/shop.example.com/access.log combined
ErrorLog /var/www/shop.example.com/error.log
DirectoryIndex index.html

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/secure.website.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/secure.website.com.key

</VirtualHost>

You now have a functioning SSL website with self signed certificate running on a primary IP. If you want to add a load balancer without an additional IP address then keep reading, because that’s the next part.

4. Create a Load Balancer in the Rackspace Control Panel.
Important things to notice here is that.
a) Configure sensible name for load balancer representing TLD I want to host
b) Configure Port 443 for the incoming connections to the Load Balancer
c) Configure Port 543 for the outgoing connections to your cloud server

Once your configuration looks like this you should be almost ready.

5. Configure Apache2 for use with a Rackspace Load Balancer

Previously, in step 3, you configured SSL on apache2 for a single IP address which was publicly accessible. Because the server is now behind a load balancer we need to tell the apache2 webserver to listen on a local private ip address, 10.0.0.1, we also need to tell apache2 webserver to expect connections from the load balancer on port 543. So we need to modify the apache configuration for apache2 to listen on port and to bind to the correct IP now load balancer is sending requests thru the private network instead than to it’s public IP. This is the magic of using a load balancer, you don’t need separate IP’s on the apache2 , the load balancer has an IP already, and you can simply identify the SSL configurations in virtualhosts by binding to ports as opposed to IP’s to provide that isolation necessary for secure SSL. It’s simple to do:

Listen 543
<VirtualHost 10.0.0.1:543>
#ServerName localhost
ServerName shop.example.com

DocumentRoot /var/www/shop.example.com/html
CustomLog /var/www/shop.example.com/access.log combined
ErrorLog /var/www/shop.example.com/error.log
DirectoryIndex index.html

SSLEngine on

SSLCertificateFile /etc/apache2/ssl/shop.example.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/shop.example.com.key

</VirtualHost>

As you can see we added a new IP for the VirtualHost, this is the private IP of the Rackspace Server:

All Rackspace cloud Servers have two networks, a public network IP like we configured earlier as 134.213.1.1. And a private network IP 10.0.0.1 for internal communications between things like the load balancer and this cloud server.

Also you can see we added a Listen 543, this tells Apache2 to listen to connections on this port so that the load balancer can connect to apache2 to send data.

5. Restart apache2 and chmod your directories with the right user and group permissions like you would on any apache2 server

chmod -R www-data:www-data /var/www/shop.example.com/html
service apache2 restart

So, I had a few customers this week that were having problems going thru the setup of Rackspace Cloud Backup on their Linux System. There is some documentation on Rackspace Knowledge Center about this but it is essentially really really really simple to install. Here are the steps for Debian Systems,:

1. Update your aptitude packages, then make sure python-apt is installed

sudo apt-get update

sudo apt-get install python-apt

2. Download the cloud backup installer

wget 'http://agentrepo.drivesrvr.com/debian/cloudbackup-updater-latest.deb'

3. Install the cloud backup installer

sudo dpkg -i cloudbackup-updater-latest.deb
apt-get install -f

4. Ensure cloudbackup-updater is installed by running

cloudbackup-updater -v

If you get any kind of response at all (other than command not found), it installed OK.

5. Configure the cloudbackup driverclient

sudo /usr/local/bin/driveclient --configure -u yourmycloudusername -k yourmycloudapikeyhere

6. Start the cloud backup driver client daemon service

sudo service driveclient start

 

Ironically, it’s easier for Redhat based systems (Fedora, Redhat and CentOS)
1. Download the cloudbackup updater RPM

sudo rpm -Uvh 'http://agentrepo.drivesrvr.com/redhat/cloudbackup-updater-latest.rpm'

2. Check updater is installed

sudo cloudbackup-updater -v

3. Configure with your mycloud user and API , Key, in this case you will be prompted to type in your mycloud username and API key details, you find this in “Account settings” of your mycloud control panel

sudo /usr/local/bin/driveclient --configure

4. Start the driveclient cloud backup service

sudo service driveclient start

A lot of customers complain of not being able to login to the remote administration console because of their latest java 7 or java 8.

I found, thanks to a colleague friend of mine that this can be remedied by installing the latest version of Java 7 revision 80. Here is what I did.

After installing Java 7 , r80, You will have to go into the JAVA configuration and set the security settings to “Medium” for it to work though.

See: https://www.java.com/en/download/help/jcp_security.xml

If you are running Java 7, r79 or earlier, or Java 8 you will need to uninstall java, and then reinstall it again. Being sure to restart the browser you are using. I tested using firefox.

1. Uninstall JAVA from your System Preferences or Control Panel, depending on your OS and confirm that it is missing from the browsers addons/plugins.
2. Reinstall Java SE Runtime Environment 7u80 at http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html
3. Set JAVA security settings to medium in the JAVA control Panel.
4. Browse to your mycloud console window, and accept any security warnings you get.

I have tested this on my machine and I can confirm that this does work.

Best wishes,
Adam

Note to self 10060 is caused by an iptables problem, not a MySQL grant problem!!!

Will update this article in coming week.

We had a customer which was getting an error 10060 when trying to connect to MySQL Server. Obviously 10060 error code is explaining that MySQL doesn’t think the remote is allowed, so closes the connection.

The user only has to do a few things to make sure they are allowed, which is basically make sure the right MySQL grants are added on the mysql server they are trying to access remotely. Please note that the section ‘5F398fDKof$%‘ denotes the password, and somemysqluser denotes the username and the 10.2.1.1 denotes the ip address. you will need to replace the ip address with the remote machine you want to access your mysql server, and replace the username with the user you want to connect with. Please, use a different password than ‘5F398fDKof$%‘ as well, to ensure your installation is as secure as it possibly can be.

So, something like this, will be great:

GRANT ALL PRIVILEGES ON DB_NAME.* TO 'somemysqluser'@'10.2.1.1' IDENTIFIED BY '5F398fDKof$%';

So, at work yesterday it was suggested to me that I should setup SSH with keys as to avoid the pain caused by attempts to continually use credentials for specific servers I run.

Doing this might seem daunting to the uninitiated, so here is how I did it between my box and the server I wanted to login with an SSH key instead of regular password. Please note there are some security implications from using SSH keys as opposed to password.

Step 1:  Generate your pair of keys. (2 keys will be made, one for the remote server, and one for your own machine).

ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/adam/.ssh/id_dsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/adam/.ssh/id_dsa.
Your public key has been saved in /home/adam/.ssh/id_dsa.pub.
The key fingerprint is:
1d:ab:23:29:9f:d6:7c:3c:39:ab:2b:2c:8f:2f:4d:26 adam@mylocal

Step 2:  your keys are stored, by default in your ‘users’ .ssh folder or ~

cd ~.ssh; ls -l

-rw-------    1 adam     adam          526 Nov  3 01:21 id_dsa
-rw-r--r--    1 adam     adam          330 Nov  3 01:21 id_dsa.pub

Step 3: Observe your beautiful keys.

— id_dsa is your private key. Keep this on the machine you want to login FROM. Do not share the key otherwise it will allow other people to login to your machine. very bad.

— id_dsa.pub is your public key. This can be added to the system you want to login to authorized_keys2 file.

Step 4: Place the public key on the remote server. I simply used scp from the terminal to copy the public key file to the remote server I want to login to.

scp id_dsa.pub [email protected]:./id_dsa.pub

If it works you’ll see a status bar show 100% , 607bytes, Kb/s 0:00 and the time taken to transfer the file

Step 5: Login to the remote server and make public key ready to be used. It is very important these commands are written in this order.

# switch to home dir and make sure .ssh folder exists
cd ~; mkdir .ssh;
cd .ssh

# make sure that the key file is there
touch authorized_keys2

# add key to authorize_keys2 file

cat ../id_dsa.pub >> authorized_keys2
rm ../id_dsa.pub

Step 6:  Ensure correct permissions on the filesystem for ‘secret’ file

chmod 600 authorized_keys2

Step 7: Login using your new ssh keypair

ssh -2 -v [email protected]
debug1: Trying private key: /Users/adam/.ssh/id_rsa
debug1: Offering DSA public key: /Users/adam/.ssh/id_dsa

Job done!

 

At work we have recently had a lot of customers asking us about how to configure their SSL certificate files for their webserver. This may seem intimidating to many persons, especially those without any technical experience, however it really need not be so frustrating. There are only just a few things that need to be done to make sure that your website can use HTTPS SSL (or the secure hypertext transfer protocol (https) using the secure sockets layer (SSL). This tutorial should be good for most debian, centos, and redhat operating systems, or nearly any linux distribution, but you may need to install nano;

# for debian or ubuntu

apt-get install nano

 

# for centos or Redhat

yum install nano

You will have likely been sent two files by your registrar or SSL provider which are
the CRT and KEY file. Each file you have been sent looks a bit like the following, you cannot do this tutorial without these two files:

yourdomainname.com.crt

—–BEGIN CERTIFICATE REQUEST—–
MIICJDCCAY0CAQAwgagxGzAZBgNVBAoTElRoZSBTYW1wbGUgQ29tcGFueTEUMBIG
A1UECxMLTWFpbCBTZXJ2ZXIxJDAiBgkqhkiG9w0BCQEWFXBvc3RtYXN0ZXJAc2Ft
cGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UECBMITmV3IFlvcmsx
CzAJBgNVBAYTAlVTMRgwFgYDVQQDEw9tYWlsLnNhbXBsZS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAPJhc++WxcBaoDbJpzFbDg42NcOz/ELVFMU4FlPa
yUzUO+xXkdFRMPKo54d4Pf1w575Jhlu9lE+kJ8QN2st6JFySbc9QjPwVwl9D2+I3
SSf2kVTu+2Ur5izCPbVAfU0rPZxxK8ELoOkA1uwwjFz6EFuVvnHwlguonWKDtmYW
u7KTAgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FLWaQsUVIQzWr58HtDinH1JfeCheMA0GCSqGSIb3DQEBBAUAA4GBAAbe0jrGEQ3i
tyVfy5Lg4/f69rKvDGs+uhZJ9ZRx7Dl92Qq2osE7XrLB1bANmcoEv/ORLZOjWZEY
NjMvuz60O7R8GKBrvb/YhAwWhIIt2LJqPkpAEWS0kY0AkoQcfZ7h6oC35+eJ7okg
Uu3WuE57RgcNt7/ftr0sG1jUyRwMLvhv
—–END CERTIFICATE REQUEST—–

yourdomainname.com.key

—–BEGIN CERTIFICATE REQUEST—–
LKSDIJUCJCdsjdicx933FKJ£DKCJDIDKFJVKSIdjjhan3FGdf1wbGUgQ29tcGFueTEUMBIG
A1UECxMLTWFpbCBTZXJ2ZXIxJDAiBgkqhkiG9w0BCQEWFXBvc3RtYXN0ZXJAc2Ft
cGxlLmNvbTETMBEGA1UEBxMKTWV0cm9wb2xpczERMA8GA1UECBMITmV3IFlvcmsx
CzAJBgNVBAYTAlVTMRgwFgYDVQQDEw9tYWlsLnNhbXBsZS5jb20wgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAPJhc++WxcBaoDbJpzFbDg42NcOz/ELVFMU4FlPa
yUzUO+xXkdFRMPKo54d4Pf1w575Jhlu9lE+kJ8QN2st6JFySbc9QjPwVwl9D2+I3
SSf2kVTu+2Ur5izCPbVAfU0rPZxxK8ELoOkA1uwwjFz6EFuVvnHwlguonWKDtmYW
u7KTAgMBAAGgOzA5BgkqhkiG9w0BCQ4xLDAqMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FLWaQsUVIQzWr58HtDinH1JfeCheMA0GCSqGSIb3DQEBBAUAA4GBAAbe0jrGEQ3i
tyVfy5Lg4/f69rKvDGs+uhZJ9ZRx7Dl92Qq2osE7XrLB1bANmcoEv/ORLZOjWZEY
NjMvuz60O7R8GKBrvb/YhAwWhIIt2LJqPkpAEWS0kY0AkoQcfZ7h6oC35+eJ7okg
Uu3WuE57RgcNt7/ftr0sG1jUyRwMLvhv
—–END CERTIFICATE REQUEST—–

(DO NOT USE THE ABOVE CERTIFICATES (THEY WILL NOT WORK) USE THE ONES YOU ARE PROVIDED)

Step 1: Copy the CRT text into the clipboard (including the —–BEGIN CERTIFICATE REQUEST—– and the —–END CERTIFICATE REQUEST—–) but nothing above the begin certificate line and nothing below the end certificate line. This is very important. 

Step 2: Open a new file for the CRT

mkdir -p /etc/httpd/conf/ssl.crt/
nano /etc/httpd/conf/ssl.crt/yourdomain.com.crt

Step 3: Paste in the CRT certificate text you were given.
Step 4: Press CTRL+O to write out the file.

Step 5: Copy the KEY text into the clipboard in the same way you did for the CRT.

Step 6: Open a new file for the key file

mkdir /p /etc/httpd/conf/ssl.key/

nano /etc/httpd/conf/ssl.key/yourdomain.com.key

Step 7: Paste the KEY certificate text.
Step 8: Press CTRL+O to write out the file.

It is safe for you to replace yourdomain.com with your own domain name, but make sure that you specify it the same in the apache2 configuration later on. This is the file we will refer to in the webserver configuration to let it use https and ssl and if you refer to the wrong file or a non existent file it won’t work!

Step 9: Edit your apache 2 webserver configuration.

(Normally this is in /etc/apache2/httpd.conf or /etc/httpd/httpd.conf , but it could be in a different place like /etc/httpd/sites-enabled or /etc/apache2/sites-enabled or /etc/apache2/conf.d and my have a different name to httpd.conf.)

<VirtualHost 1.1.1.1:443>
ServerName www.yourdomain.com
DocumentRoot /var/www/html/mydomain.com

SSLEngine ON
SSLCertificateFile /etc/httpd/conf/ssl.crt/domain.com.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/domain.com.key

ErrorLog logs/ssl.domain.com.error_log
CustomLog logs/ssl.domain.com.access_log combined
</VirtualHost>

It’s important to get all of this correct. So lets go thru what each one of these lines does.

VirtualHost tells apache2 where to listen. If you don’t know what to put here you can use:
<VirtualHost *:443> which will work for most configurations, but it will listen on every single IP address attached to that machine. The 443 signifies that it is the HTTPS. HTTP traffic for instance runs on port 80.

ServerName is the website name your using so if your website is https://www.google.com , for instance then you want to put ServerName www.google.com.

DocumentRoot is the location of your website on the disk, the physical location of all the files, be they html, php, images etc, DocumentRoot is the way the webserver knows where to look when serving that website hostname. For me I use /var/www/html but if you don’t know it’s best to ask your provider or technical contact what your DocumentRoot here should be.

SSLEngine ON does exactly what it says on the tin. It enables apache2’s SSL HTTPS functionality.

SSLCertificateFile tells where apache2 is instructed to look for the CRT file you were given by your webhost. Make sure you specify it in the same location you placed it.

SSLCertificateKeyFile tells where apache2 is instructed to look for the KEY file you were given by your webhost. Make sure you specify it in the same location you placed it.

ErrorLog and CustomLog give the location on the hardisk to place the logs for the access to this website.

Step 10: Enable the SSL module for apache2 by running

a2enmod ssl

Step 11: Restart Apache2 so that the configurations changes are loaded

/etc/init.d/apache2 restart

Step 11B: If Step 11 fails to complete then use

service apache2 restart

That is it , you should be done configuring your apache2 SSL configuration. It’s not that hard is it? Admittedly I’ve done this before a few times myself, and I am sure that after you have done the same it will be second nature.

Best wishes,
Adam

 

 

Customer Service: importance of fast AND accurate information

So, the other day it occurred to me that working in customer service isn’t all that easy, for instance in my case I am working in a new unfamiliar environment and supporting a new and unfamiliar infrastructure with which I have limited knowledge of. So providing both quick and accurate information has been difficult, and getting the right balance for any new starter is naturally important.

Ensuring efficiency accuracy and speed in a support environment

It may sound like an impossibility to be fast and accurate but giving this some thought it occurs to me that it is not so difficult. In fact, one of the reasons why I started this blog was to enable me to store some of my experiences, so I don’t have to. And as time goes by, in the case of coming across new problems which will begin to seem familiar, having my own personal knowledge base could make a big difference to my efficiency, accuracy and speed.

Think Ahead, create your own knowledge base – record information accurately and in advance of the time you need it:

It’s things like this kind of thinking ahead which is probably worth the most to businesses. It increases the functional ability of the individuals they employ, and so means that the employer gets more for their money. Most important of all it makes the employee’s life a little bit easier by planning ahead, and I believe this is key to any successful business or technician.

Being proactive (but not over the top!)

Being proactive is obviously a very important trait in any employee. The company benefits from individuals which take responsibility and ownership of problems, which allows the business to concentrate on more pressing organizational problems and solutions than the perhaps less business-critical itinerary of service technicians and so on. But it is possible to over do it, “chill Winston” as the all wise Lock Stock and Two Smoking Barrels quote goes. It is possible to be too uptight and intense about mistakes or potential difficulties one encounters, so always remember to:

Take it easy.

Make sure that you have enough winding down time in the evening. Be it futurama, family guy or the simpsons, you need to look after you, because you are the most important thing to any business. Without you the business doesn’t exist, so, that means sometimes taking time off, as opposed to always taking time on. By all means show up early to show your dedication, and if you enjoy that kind of thing then keep on doing it.

Balance

The point here is to make sure that there is enough time for all the things that make an employee hard working, calm, well rested, excited and balancing all of these traits is quite easy when you know what your trying to do. Which brings on potentially the most important thing.

Set Goals

Many people do not set goals, however, if a company or a person has not set objectives then it can be very difficult to understand what kind of attitude or action is required in order to achieve them. Think of it like a boat with an engine, it may be the finest engine of the land, and have the most expensive and well thought out parts, all the best attributes of a good employee, but if the boat has no direction, no navigator, captain or crew, then that boat cannot get to where it needs to go, and it’s only because nobody knows where it is going! So, no matter how vague the goals you set are, it’s always good to set a few rough goals in my estimations, because then at least you know which way to sail, and even without the meanest and bestest engine, a simple sail with a direction may get you quite a lot further!

Determination

Which brings me on to the last thing. You have to want to be successful, but also you have to be determined to try and make that success. You already have a direction, and some tools to help you like planning, and record keeping, you already think ahead and consider the most efficient and cost effective solutions, but without that determination to keep it going, even when it fails, you will find it very difficult to provide THE best customer service you can. By being determined, you will be able to benefit from your experience, and when the going is difficult, you won’t give up or drop out. This is probably the most important thing of all because it gains the respect of your fellow employee’s and builds confidence. My motto is don’t give up! Nothing is more important than showing how seriously you take things, except for the times where you just need to relax and take a chill pill. Believe me, in customer service if you do not know how to do both of these very well, you will not last long!

My first few weeks at working in cloud, particularly openstack were challenging. There were quite a few tools ,and interpreters that I had to get used to using and debugging to properly use software, and as always, the compiler or interpreters messages aren’t usually helpful. It’s worth noting that before we start, some of the messages from python applications can be unhelpful and appear to be dependency issues but in one case it was because of an extra character lurking in my .supernova configuration, thanks to a colleague of mine who pointed this out yesterday.

One of the important things to get a handle on was the installation and configuration of my supernova and nova openstack for use with the Rackspace UK API. Here is some of the ‘arguments’ we had at the commandline.

There is some pretty helpful information listed at: https://developer.rackspace.com/blog/supernova-managing-openstack-environments-made-easy/

but I decided that after all the problems I had, specific to my Mac OS X Yosemite 10.10.4 that some sort of additional documentation on getting started was necessary, if not for other people, but my own personal record! I list quite a few of the common mishaps I ran into when installing.

# I had lots of problems so I started from scratch

pip freeze |  xargs pip uninstall -y

git clone https://github.com/major/supernova
# install latest supernova from github (optional)
sudo python setup.py install

After doing this and running a ‘supernova’ command from the commandline I am quickly informed that

ERROR (AuthSystemNotFound): AuthSystemNotFound: ‘rackspace’

We should make sure that the novaclient and supernova are installed and note that the supernova application is merely a wrapper for the the nova openstack api connector.

pip install supernova rackspace-novaclient

I also got a bit crazy and started trying to install different versions of novaclient noting that there were some possible compatibility problems between supernova and nova due to differences in the packages. I also resorted to running a ‘brew install python’ after getting fed up, but I won’t need to cover this here because brew is fairly simple

pip install -U python-novaclient==2.11.1

This didn’t bring me much luck and I was sitll encountering the AuthSystemNotFound error. So I started to try and dig deeper into what was going on, and what packages were available and/or might be missing.

pip search rackspace

pip search rackspace | grep auth

rackspace-auth-openstack                       – Rackspace Auth Plugin for OpenStack Clients.
rackspace-auth-neutronclientext                – Rackspace Auth Plugin for OpenStack Neutron Clients.
rackspace-glanceclient                         – Metapackage to install python-glanceclient and Rackspace auth package

Confirming my suspicions that a plugin was not installed by pip when I ran pip install supernova rackspace-novaclient. So I ran

pip install rackspace-auth-openstack
supernova lon image-list
__ Error Output ______________________________________________________________
ERROR: No module named auth_plugin

Which certainly meant progress, now a different error, “auth_plugin”. So I re-ran an install of rackspace-novaclient

pip install rackspace-novaclient

 

paying special attention to these particular entries:

Successfully installed os-diskconfig-python-novaclient-ext-0.1.2 os-networksv2-python-novaclient-ext-0.25 os-virtual-interfacesv2-python-novaclient-ext-0.19 rackspace-novaclient-1.4 rax-default-network-flags-python-novaclient-ext-0.3.1 rax-scheduled-images-python-novaclient-ext-0.3.1

It looked like the two were missing some dependencies that were causing this particular cryptic error above with auth_plugin.

I found then when running a supernova lon image-list I was presented with a new difficulty:

supernova lon image-list

__ Error Output ______________________________________________________________
ERROR: cannot import name cliutils

This was probably the least cryptic error because simply searching for cliutils with pip was easy enough, and then i installed that package:

pip search cliutils
cliutils     – A collection of utilities easing the creation of command line scripts

pip install cliutils

for special measure I also installed a package called ‘rack’ and upgraded supernova once more from pip repository. I do not know if these steps are necessary but if your still having trouble running supernova you can always try them:

pip install rack

pip install supernova –upgrade

Which gives the friendly and expected output:

supernova customer image-list
[SUPERNOVA] Running nova against customer…
+————————————–+————————————————————–+——–+————————————–+
| ID                                   | Name                                                         | Status | Server                               |
+————————————–+————————————————————–+——–+————————————–+
| 8785022e-a29c-4e31-9d9c-213b87c63e2a | Arch 2015.7 (PVHVM)                                          | ACTIVE |                                      |
| 6e44a225-85f4-4d53-858b-a3022939845b | CentOS 5 (PV)                                                |
……. etc

Please note IMPORTANTLY that to properly query the Rackspace Openstack API thru supernova nova wrapper you will require a properly formatted .supernova config file. This actually takes some time to get to grips with. Your supernova file should , usually be in your user context home, ie cd ~

.supernova config template

[myopenstackconfig] OS_AUTH_URL=https://identity.api.rackspacecloud.com/v2.0/
OS_AUTH_SYSTEM=rackspace
OS_COMPUTE_API_VERSION=1.1
NOVA_RAX_AUTH=1
OS_REGION_NAME=LON
NOVA_SERVICE_NAME=cloudServersOpenStack
OS_PASSWORD=yourrackspaceAPIkeygoeshere
OS_USERNAME=yourrackspacemycloudusernamegoeshere
OS_TENANT_NAME=yourrackspaceaccountnumbergoeshere

If you don’t like the idea of using plaintext in your config file you could use supernova-keyring your .supernova config file must look like this:

[myopenstackconfig] OS_AUTH_URL=https://identity.api.rackspacecloud.com/v2.0/
OS_AUTH_SYSTEM=rackspace
OS_COMPUTE_API_VERSION=1.1
NOVA_RAX_AUTH=1
OS_REGION_NAME=LON
NOVA_SERVICE_NAME=cloudServersOpenStack
OS_PASSWORD=USE_KEYRING[‘UKRackspaceAccountAPIKey’] OS_USERNAME=USE_KEYRING[‘UKRackspaceAccountUser’] OS_TENANT_NAME=USE_KEYRING[‘UKRackspaceAccountDDI’]

at the shell you will have to set the variables for the ‘keyring’ do that like this and you will be prompted to type in your account API Key, and username and DDI (which is the 6 or 7 digit number your account is in the url address when using mycloud) the details there:

Type this at the commandline

# something like myusername
supernova-keyring -s global RackspaceAccountUser
# something like 80aa1af9a6Bc459076834592ab324a

supernova-keyring -s global RackspaceAccountAPIKey

# something like 1004345
supernova-keyring -s global RackspaceAccountDDI

Here are some critically important and helpful links for supernova guides , tutorials, examples and so on, the developer “Major Harden” is a great guy and I am sure if you have issues further to what I had he will be able to help you further over at GitHub.

Supernova Developers’ website and documentation https://major.io/2012/06/05/supernova-manage-multiple-openstack-nova-environments-with-ease/
Latest github for cloning on Github https://github.com/major/supernova
1 Hour Presentation on Supernova https://www.youtube.com/watch?v=BZGhoCYZKEM

What fun! Hello I am Adam, Linux Administrator and Cloud Infrastructure peon. I don’t really have much time but here is my asserted attempt at making something useful of myself and recording the things I experience from day to day.

One tries, anyway.