Creating functional ssh key-pair on RDO Mitaka via Chrome Advanced REST Client

May 2, 2016

The problem here is that REST API POST request creating ssh-keypair to access nova servers  doesn’t write to disk rsa private key  and only upload public one to nova. Closing Chrome Client results loosing rsa private key. To prevent failure to write to disk private key , save response-export.json as shown bellow. Working via CLI ( invoking curl ) allows to upload rsa public key to Nova and create rsa private key as file :-

#!/bin/bash -x
 curl -g -i -X POST \
 http://192.169.142.127:8774/v2/052b16e56537467d8161266b52a43b54/os-keypairs \
 -H "User-Agent: python-novaclient" \
 -H "Content-Type: application/json" -H "Accept: application/json" \
 -H "X-Auth-Token: 2ae281359a8f4b249d5e8cf36c4233c0" -d  \
 '{"keypair": {"name": "oskey2"}}' |  tail -1 >output.json ;
 echo "Genegating rsa privare key for server access as file";
 echo "-----BEGIN RSA PRIVATE KEY-----" >  oskey2.pem ;
 sed 's/\\n/\
 /g' <  output.json | grep -v "keypair" | grep -v "user_id" >>oskey2.pem ;
 chmod 600 oskey2.pem

To start ( keystone api v3 environment ) obtain project’s scoped token via request

[root@ip-192-169-142-127 ~(keystone_admin)]# curl -i  -H “Content-Type: application/json” -d ‘ { “auth”:
{ “identity”:
{ “methods”: [“password”], “password”:
{ “user”:
{ “name”: “admin”, “domain”:
{ “id”: “default” }, “password”: “7049f834927e4468” }
}
},
“scope”:
{ “project”:
{ “name”: “demo”, “domain”:
{ “id”: “default” }
}
}
}
}’  http://192.169.142.127:5000/v3/auth/tokens ; echo

HTTP/1.1 201 Created
Date: Mon, 02 May 2016 10:41:25 GMT
Server: Apache/2.4.6 (CentOS)
X-Subject-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  &lt;= token value
Vary: X-Auth-Token
x-openstack-request-id: req-bed4f407-8cbd-4d43-acd5-7450d028bc45
Content-Length: 5791
Connection: close

Content-Type: application/json

*******************************************************************************
The run script extracting from response-export.json the rsa private key
*******************************************************************************

#!/bin/bash -x
echo “Genegating privare key for server access”
echo “—–BEGIN RSA PRIVATE KEY—–” > $1.pem
sed ‘s/\\n/\
/g’ <  response-export.json | grep -v “keypair” | grep -v “user_id” >> $1.pem
chmod 600 $1.pem

like :-

# ./filter.sh oskeymitakaV3

***********************************
Shell command [ 1 ]  :-
***********************************

sed ‘s/\\n/\
/g’ <  response-export.json

will replace ‘\n’ by Carriage Return in  response-export.json.

Now login to dashboard and verify that rsa public key gets uploaded

Relaunch Chrome Advanced Rest Client and launch server with
“key_name” : “oskeymitakaV3”

******************************************************************************
Login to server using rsa private key  oskeymitakaV3.pem
******************************************************************************

[boris@fedora23wks json]$ ssh -i oskeymitakaV3.pem ubuntu@192.169.142.169

The authenticity of host ‘192.169.142.169 (192.169.142.169)’ can’t be established.
ECDSA key fingerprint is SHA256:khfhZEHHwz7T18oIlKMCKWKY9b6ctsS8XMW5ZpVlRa8.
ECDSA key fingerprint is MD5:25:98:50:9f:b3:37:f3:a1:ed:95:5d:44:f4:03:13:14.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.169.142.169’ (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-21-generic x86_64)
* Documentation:  https://help.ubuntu.com/
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
0 packages can be updated.
0 updates are security updates.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
To run a command as administrator (user “root”), use “sudo “.
See “man sudo_root” for details.
ubuntu@ubuntuxenialdevs:~$

Advertisements

Creating Servers via REST API on RDO Mitaka && Keystone API V3

April 29, 2016

As usual ssh-kepair for particular tenant is supposed to be created sourcing tenant’s credentials and afterwards it works for particular tenant. By some reasons upgrade keystone api version to v3 breaks this schema in regards of REST API POST requests issued for servers creation. I am not sure either following bellow is workaround or it is supposed to work this way.

Assign admin role user admin on project demo via openstack client

[root@ip-192-169-142-127 ~(keystone_admin)]# openstack project list| \
grep demo > list2

[root@ip-192-169-142-127 ~(keystone_admin)]#openstack user list| \
grep admin >> list2

[root@ip-192-169-142-127 ~(keystone_admin)]# openstack role list|\
grep admin >> list2

[root@ip-192-169-142-127 ~(keystone_admin)]# cat list2
| 052b16e56537467d8161266b52a43b54 | demo |
| b6f2f511caa44f4e94ce5b2a5809dc50 | admin |
| f40413a0de92494680ed8b812f2bf266 | admin |

[root@ip-192-169-142-127 ~(keystone_admin)]# openstack role add \
–project \
052b16e56537467d8161266b52a43b54 \
–user b6f2f511caa44f4e94ce5b2a5809dc50 \
f40413a0de92494680ed8b812f2bf266

*********************************************************************
Run to obtain token scoped “demo”
*********************************************************************

# . keystonerc_admin
# curl -i -H “Content-Type: application/json” -d \
‘ { “auth”:
{ “identity”:
{ “methods”: [“password”], “password”:
{ “user”:
{ “name”: “admin”, “domain”:
{ “id”: “default” }, “password”: “7049f834927e4468” }
}
},
“scope”:
{ “project”:
{ “name”: “demo”, “domain”:
{ “id”: “default” }
}
}
}
}’ http://192.169.142.127:5000/v3/auth/tokens ; echo

Screenshot from 2016-04-28 19-47-00

Created ssh keypair “oskeydemoV3” sourcing keystonerc_admin

Screenshot from 2016-04-28 19-50-02

Admin Console shows

Screenshot from 2016-04-28 20-28-57

***************************************************************************************
Submit “oskeydemoV3” as value for key_name into Chrome REST Client environment &amp;&amp; issue POST request to create the server , “key_name” will be accepted ( vs case when ssh-keypair was created by tenant demo )
*************************************************************************************

Screenshot from 2016-04-28 19-52-24

Now log into dashboard as demo

Screenshot from 2016-04-28 19-56-25

Verify that created keypair “oskeydemoV3” allows log into server

Screenshot from 2016-04-28 19-58-56


Creating Servers via REST API on RDO Mitaka via Chrome Advanced REST Client

April 21, 2016

In posting bellow we are going to demonstrate Chrome Advanced REST Client successfully issuing REST API POST requests for creating RDO Mitaka Servers (VMs) as well as getting information about servers via GET requests. All required HTTP Headers are configured in GUI environment as well as body request field for servers creation.

Version of keystone API installed v2.0

Following [ 1 ] to authenticate access to OpenStack Services, you are supposed first of all to issue an authentication request to get authentication token. If the request succeeds, the server returns an authentication token.

Source keystonerc_demo on Controller or on Compute node. It doesn’t
matter. Then run this cURL command to request a token:

curl -s -X POST http://192.169.142.54:5000/v2.0/tokens \
-H “Content-Type: application/json” \
-d ‘{“auth”: {“tenantName”: “‘”$OS_TENANT_NAME”‘”, “passwordCredentials”: {“username”: “‘”$OS_USERNAME”‘”, “password”: “‘”$OS_PASSWORD”‘”}}}’ \
| python -m json.tool

to get authentication token and scroll down to the bottom :-

“token”: {
“audit_ids”: [
“ce1JojlRSiO6TmMTDW3QNQ”
],
“expires”: “2016-04-21T18:26:28Z”,
“id”: “0cfb3ec7a10c4f549a3dc138cf8a270a”, &lt;== X-Auth-Token
“issued_at”: “2016-04-21T17:26:28.246724Z”,
“tenant”: {
“description”: “default tenant”,
“enabled”: true,
“id”: “1578b57cfd8d43278098c5266f64e49f”, &lt;=== Demo tenant’s id
“name”: “demo”
}
},
“user”: {
“id”: “8e1e992eee474c3ab7a08ffde678e35b”,
“name”: “demo”,
“roles”: [
{
“name”: “heat_stack_owner”
},
{
“name”: “_member_”
}
],
“roles_links”: [],
“username”: “demo”
}
}
}

********************************************************************************************
Original request to obtain token might be issued via Chrome Advanced REST Client as well
********************************************************************************************

Scrolling down shows up token been returned and demo’s tenant id

Required output

{

access“: 

{

token“: 

{
issued_at“: 2016-04-21T21:56:52.668252Z
expires“: 2016-04-21T22:56:52Z
id“: dd119ea14e97416b834ca72aab7f8b5a

tenant“: 

{
description“: default tenant
enabled“: true
id“: 1578b57cfd8d43278098c5266f64e49f
name“: demo
}

*****************************************************************************
Next create ssh-keypair via CLI or dashboard for particular tenant :-
*****************************************************************************
nova keypair-add oskeymitaka0417 &gt; oskeymitaka0417.pem
chmod 600 *.pem

******************************************************************************************
Following bellow is a couple of samples REST API POST requests starting servers as they usually are issued and described.
******************************************************************************************

curl -g -i -X POST http://192.169.142.54:8774/v2/1578b57cfd8d43278098c5266f64e49f/servers -H “User-Agent: python-novaclient” -H “Content-Type: application/json” -H “Accept: application/json” -H “X-Auth-Token: 0cfb3ec7a10c4f549a3dc138cf8a270a” -d ‘{“server”: {“name”: “CirrOSDevs03”, “key_name” : “oskeymitaka0417”, “imageRef”: “2e148cd0-7dac-49a7-8a79-2efddbd83852”, “flavorRef”: “1”, “max_count”: 1, “min_count”: 1, “networks”: [{“uuid”: “e7c90970-c304-4f51-9d65-4be42318487c”}], “security_groups”: [{“name”: “default”}]}}’

curl -g -i -X POST http://192.169.142. 54:8774/v2/1578b57cfd8d43278098c5266f64e49f/servers -H “User-Agent: python-novaclient” -H “Content-Type: application/json” -H “Accept: application/json” -H “X-Auth-Token: 0cfb3ec7a10c4f549a3dc138cf8a270a” -d ‘{“server”: {“name”: “VF23Devs03”, “key_name” : “oskeymitaka0417”, “imageRef”: “5b00b1a8-30d1-4e9d-bf7d-5f1abed5173b”, “flavorRef”: “2”, “max_count”: 1, “min_count”: 1, “networks”: [{“uuid”: “e7c90970-c304-4f51-9d65-4be42318487c”}], “security_groups”: [{“name”: “default”}]}}’

**********************************************************************************
We are going to initiate REST API POST requests creating servers been
issued  via Chrome Advanced REST Client
**********************************************************************************

[root@ip-192-169-142-54 ~(keystone_demo)]# glance image-list

+————————————–+———————–+
| ID                                   | Name                  |
+————————————–+———————–+
| 28b590fa-05c8-4706-893a-54efc4ca8cd6 | cirros                |
| 9c78c3da-b25b-4b26-9d24-514185e99c00 | Ubuntu1510Cloud-image |
| a050a122-a1dc-40d0-883f-25617e452d90 | VF23Cloud-image       |
+————————————–+———————–+

[root@ip-192-169-142-54 ~(keystone_demo)]# neutron net-list
+————————————–+————–+—————————————-+
| id                                   | name         | subnets                                |
+————————————–+————–+—————————————-+
| 43daa7c3-4e04-4661-8e78-6634b06d63f3 | public       | 71e0197b-fe9a-4643-b25f-65424d169492   |
|                                      |              | 192.169.142.0/24                       |
| 292a2f21-70af-48ef-b100-c0639a8ffb22 | demo_network | d7aa6f0f-33ba-430d-a409-bd673bed7060   |
|                                      |              | 50.0.0.0/24                            |
+————————————–+————–+—————————————-+

First required Headers were created in corresponding fields and
following fragment was placed in Raw Payload area of Chrome Client

{“server”:
{“name”: “VF23Devs03”,
“key_name” : “oskeymitaka0420”,
“imageRef” : “a050a122-a1dc-40d0-883f-25617e452d90“,
“flavorRef”: “2”,
“max_count”: 1,
“min_count”: 1,
“networks”: [{“uuid”: “292a2f21-70af-48ef-b100-c0639a8ffb22“}],
“security_groups”: [{“name”: “default”}]
}
}

Launching Fedora 23 Server :-

Next Ubuntu 15.10 Server (VM) will be created via changing  image-id in  Advanced RESTful Client GUI environment

Make sure that servers have been created and are currently up and running

***************************************************************************************
Now launch Chrome REST Client again for servers verification via GET request
***************************************************************************************