Create initial repository on github

The full summary of all posts for API Rackspace challenge can be found here:
Rackspace api-challenge summary

This is in regards to the Rackspace API-challenge. More info can be found at Rackspace api-challenge summary.

All my steps to create my repository are listed below.

Install Git Shell for windows

mkdir api-challenge
git init

Create next a README.md file

git commit
git add README.md
git commit -m 'init'
git remote add origin git@github.com:rtomaszewski/api-challenge.git

git push -u origin master
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of know
n hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Troubleshooting base on https://help.github.com/articles/error-permission-denied-publickey

 
ssh -vT git@github.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
....
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /c/Users/rado4752/.ssh/github_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

ssh-add -l
The agent has no identities.

I had to add and register my public ssh key github_rsa on github. After adding it using the webgui https://github.com/settings/ssh this test went fine.

 
ssh -vT git@github.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Applying options for github.com
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /c/Users/rado4752/.ssh/github_rsa type 1
...
Hi rtomaszewski! You've successfully authenticated, but GitHub does not provide
shell access.
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.5 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 1

git remote add origin git@github.com:rtomaszewski/api-challenge
fatal: remote origin already exists.

git remote -v
origin  git@github.com:rtomaszewski/api-challenge (fetch)
origin  git@github.com:rtomaszewski/api-challenge (push)

git push -u origin master
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of know hosts.
ERROR: Repository not found.
Fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

git remote rm origin
git remote add origin git@github.com:rtomaszewski/api-challenge.git
git remote -v
origin  git@github.com:rtomaszewski/api-challenge.git (fetch)
origin  git@github.com:rtomaszewski/api-challenge.git (push)

As there is not repository with the name api-challenge I created it under my github account.

 
git push -u origin master

After all this trouble i could navigate to my newly created repository under https://github.com/rtomaszewski/api-challenge

At the end got to http://challenge.cldsrvr.com/register and register your repo.

Practical online github course

There are many modern distributed versioning systems and github is one of them. This link is going to take you to a simple online but practical course where you can practice the basic git commands.

Learning by doing: http://try.github.com/ (http://www.codeschool.com/courses/try-git)

Commands reference:

 
$ git init
$ git status
$ git add octocat.txt
$ git status
$ git commit -m "Add cute octocat story"
$ git add '*.txt'
$ git commit -m 'Add all the octocat txt files'
$ git log
$ git remote add origin git@github.com:rtomaszewski/try_git.git
$ git push -u origin master
$ git pull origin master
$ git diff HEAD
$ git add octofamily/octodog.txt
$ git diff --staged
$ git reset octofamily/octodog.txt
$ git checkout -- octocat.txt
$ git branch clean_up
$ git checkout clean_up
$ git rm '*.txt'
$ git commit -m "Remove all the cats"
$ git checkout master
$ git merge clean_up
$ git branch -d clean_up
$ git push

My git recipes

1. To download the repository to your local host

$ git clone https://github.com/rtomaszewski/#repo.git#


Or you can upload a public SSH key to your github account as described here https://help.github.com/articles/generating-ssh-keys and then clone using SSH method.



$ git clone git@github.com:rtomaszewski/#repo.git#



2. To commit and upload the source back to repository

$ cd #repo#
$ git add new-file.py
$ git commit new-file.py -m 'init'
$ git push origin master



3. To update your local repository with the master

$ cd #repo#
$ git pull
$ git pull origin master



4. List config settings

$ cd #repo#
$ git config -l 



5. Rename a file

$ cd #repo#
$ git mv README README.md
$ git commit -m "renamed"
$ git push origin master

References

1. http://stackoverflow.com/questions/5989893/github-how-to-checkout-my-own-repository
2. http://superuser.com/questions/199507/how-do-i-ensure-git-doesnt-ask-me-for-my-github-username-and-password
3. https://help.github.com/articles/set-up-git#password-caching

How to create a Cloud Server using Rackspace API

Problem description

How to create a cloud server using cloud API.

Solution

A small script available at gitub [1] that uses available cloud API to login to the Rackspace cloud infrastructure. After login it issues necessary create request and creates a new cloud server. At the end prints the result on stdout.

Demonstration

• Standard output

# python rackspace_cloudserver.py -u user -k key run
creating new cloud server with a name: cstest1343077883
{
 "server": {
  "status": "BUILD", 
  "hostId": "50a21504e046275fa53877dc937ceab6", 
  "name": "cstest1343077883", 
  "adminPass": "KnB1Cu7t4cstest1343077883", 
  "metadata": {}, 
  "imageId": 112, 
  "progress": 0, 
  "flavorId": 1, 
  "id": 10196007, 
  "addresses": {
   "public": [
    "5.79.1.17"
   ], 
   "private": [
    "10.178.4.241"
   ]
  }
 }
}

• Verbose output 

# python rackspace_cloudserver.py -u user -k key -v run
debug[ 1]: user:  key: key;
debug[ 1]: http request
  lon.auth.api.rackspacecloud.com GET /v1.0
  headers: 
    X-Auth-Key: 391....aebe1
    X-Auth-User: user
debug[ 1]: http response
  204 No Content
  headers
    content-length: 0
    x-server-management-url: https://lon.servers.api.rackspacecloud.com/v1.0/10001641
    x-storage-token: 7e901...67a
    vary: X-Auth-Token,X-Auth-Key,X-Storage-User,X-Storage-Pass
    x-cdn-management-url: https://cdn3.clouddrive.com/v1/MossoCloudFS_c99f3ebf-f27d-4933-94b7-9e9ebf2bc7cd
    server: Apache/2.2.3 (Red Hat)
    connection: Keep-Alive
    cache-control: s-maxage=85050
    date: Mon, 23 Jul 2012 20:59:40 GMT
    x-storage-url: https://storage101.lon3.clouddrive.com/v1/MossoCloudFS_c99f3ebf-f27d-4933-94b7-9e9ebf2bc7cd
    x-auth-token: 7e90....1bc67a
    content-type: text/xml
debug[ 1]: read 0 from the server:
creating new cloud server with a name: cstest1343077180
debug[ 1]: http request
  lon.servers.api.rackspacecloud.com POST /v1.0/10001641/servers
  headers: 
    Content-Type: application/json
    X-Auth-Token: 7e901...bc67a
body:
   {"server": {"flavorId": 1, "name": "cstest1343077180", "imageId": 112}}
debug[ 1]: http response
  202 Accepted
  headers
    content-length: 272
    x-varnish: 1662239131
    age: 0
    vary: Accept, Accept-Encoding, X-Auth-Token
    server: Apache-Coyote/1.1
    connection: keep-alive
    via: 1.1 varnish
    cache-control: no-cache
    date: Mon, 23 Jul 2012 20:59:45 GMT
    content-type: application/json
debug[ 1]: read 272 from the server:
{
 "server": {
  "status": "BUILD", 
  "hostId": "155a42778c64cf881c41ae5dc8a8bd0c", 
  "name": "cstest1343077180", 
  "adminPass": "4KUt5u3oXcstest1343077180", 
  "metadata": {}, 
  "imageId": 112, 
  "progress": 0, 
  "flavorId": 1, 
  "id": 10195995, 
  "addresses": {
   "public": [
    "5.79.1.129"
   ], 
   "private": [
    "10.178.18.97"
   ]
  }
 }
}

References
[1]  https://github.com/rtomaszewski/experiments/blob/master/rackspace_cloudserver.py  

Hacking the UDP protocol - how to sent data using the UDP source port of UDP packets

Security has become one of the major concerns in current system architectures. The emerging new cloud technologies like Openstack ( IaaS cloud offering) try to address it in a better way in every new software release. When implementing and integrating bigger infrastructure solution we could say that the difficulty is proportional to the number of technologies that are involved to create a final solution.

One of the most important technology that works as a glue between the components is of course a network infrastructure and the supported protocol stack like TCP/IP that allows application to communicate. As our history of Internet proves a network layer has been since ever a fascination of many hackers. And as we know when it comes to programming and deciding what your program should do the sky is the limit.

As part of my network and security fascination i decided to conduct a small research project to confirm one of my ideas.

Research project description

How to transmit data using the UDP as transport protocols but without relaying on the UDP payload functionality.

Proposed solution description

The ideas is to use the available UDP headers to encode and to encapsulate the the data payload. In my example I decided to use the UDP source port value to store there my payload [1]

The UDP source port is a 16 bit length variable. That means that for a multi byte stream of data to transfer we have to implement effective way to divide it into chunks and sent them separately in many UDP datagrams. On the server site we have to de-encapsulate it and build up the original stream.

Examples and prove of concept (POC)
The client is a simple shell using the hping [2] to sent our specially designed UDP packets.

The server has been written in C to allow it an access to all functions of a network socket. The server has to implement the necessary logic to assemble the original data as well.

The example code can be found on github under the udptx project link [4]

Results presentation

For the below DemoA and DemoB illustrations we are going to use
 a) One Debian base Rackspace Cloud Server (RCS) [3].
 b) Locally hosted VM (in VMware Workstation) on my PC at home.

On any of the below mentioned machines we work on I assume you have already the necessary programs installed like hping2 (you can use the hping3 as well) and the compiler to compile the  server.c code.

This is only an example what you may need to install if you use Debian or Ubuntu base RCS.

debian-leny:~# aptitude install git-core #to check out our source code from github
debian-leny:~# aptitude install gcc
debian-leny:~# uname -a
debian-leny:~# aptitude install linux-headers-2.6.26-2-xen-amd64
debian-leny:~# aptitude install libc6-dev
debian-leny:~# aptitude install hping2

To check out the code and to compile the server code you can do:

debian-leny:~# git clone git://github.com/rtomaszewski/udptx.git
debian-leny:~# cd udptx
debian-leny:~/udptx# gcc -o server server.c

# after a successful compilation the code should look like this
debian-leny:~/udptx# ls -la server
-rwxr-xr-x 1 root root 11862 2012-01-05 22:15 server

debian-leny:~/udptx# ldd server
        linux-vdso.so.1 =>  (0x00007fff6bbff000)
        libc.so.6 => /lib/libc.so.6 (0x00007f95f19c3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f95f1d16000)

DemoA - using the loop back interface on the RCS

Open first SSH session to the RCS server and start the server.

ssh 31.222.171.250
debian-leny:~/udptx# cd udptx
debian-leny:~/udptx# ./server

If the server starts successfully the output will look like this.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket

On the second SSH session on the RCS server let's run the client. The client requires 2 options: the ip of a host where the data should be sent and a string parameter representing the data we want to sent. In our example we use the loopback address and we try to sent a 3 character string "az;".

ssh  31.222.171.xyz
debian-leny:~/udptx# cd udptx

debian-leny:~/udptx# ./client.sh 127.0.0.1 'az;'
DEBUG: Output interface address: 219.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C BC A6 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 26 19 15 B3 00 08 C6 0F

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 191.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 11 B3 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 2F DD 15 B3 00 08 BC 4B

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 28.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C A9 27 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 17 41 15 B3 00 08 D4 E7

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 209.127.0.0
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 7F DE 00 00 40 11 00 00 7F 00 00 01 7F 00 00 01 00 35 15 B3 00 08 EB F3

--- 127.0.0.1 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

If the data were sent successfully to the server we should see there the following output.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket
received from ip: 127.0.0.1 port: hex 0x2619 dec 9753
received from ip: 127.0.0.1 port: hex 0x2fdd dec 12253
received from ip: 127.0.0.1 port: hex 0x1741 dec 5953
received from ip: 127.0.0.1 port: hex 0x35 dec 53
Received 3 characters:
msg[0]=char a hex 0x61 dec 97
msg[1]=char z hex 0x7a dec 122
msg[2]=char ; hex 0x3b dec 59

A tcpdump file with captured session between the client and sever can be found here udptx.lo.pcap.

debian-leny:~/udptx# tcpdump -s0 -nn -i lo -w /tmp/udptx.lo.pcap
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
4 packets captured
8 packets received by filter
0 packets dropped by kernel

DemoB - test over the Internet

The assumptions here are the same as before with the exception that the client is run from a local VM and it connects over the Internet to our Rackspace Cloud Server.

This time the output from the client is a little different than before.

root@ubuntuserver:~/udptx# uname  -a
Linux ubuntuserver 2.6.38-11-server #50-Ubuntu SMP Mon Sep 12 21:34:27 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntuserver:~/udptx# ip addr
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:0c:29:93:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.6/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::20c:29ff:fe93:eeff/64 scope link
       valid_lft forever preferred_lft forever

root@ubuntuserver:~/udptx# ls -la /usr/sbin/hping2
lrwxrwxrwx 1 root root 6 2012-01-05 23:28 /usr/sbin/hping2 -> hping3

root@ubuntuserver:~/udptx# tracepath  31.222.171.250

 1 :  192.168.0.6                                           0.207ms pmtu 1500
 1:  10.95.xyz.xyz                                           10.674ms
 1:  10.95.52.1                                           13.559ms
 2:  80.3.177.253                                         13.320ms
 3:  195.182.179.85                                       14.875ms asymm  5
 4:  212.43.163.117                                       13.964ms
 5:  212.43.162.218                                       12.821ms
 6:  213.105.159.34                                       18.455ms
 7:  62.253.184.2                                         26.880ms
 8:  195.66.224.116                                       15.280ms asymm  7
 9:  92.52.76.246                                         31.758ms asymm  8
10:  92.52.77.107                                         50.107ms asymm  9
11:  31.222.171.250                                       15.384ms reached
     Resume: pmtu 1500 hops 11 back 55

root@ubuntuserver:~/udptx# ./client.sh 31.222.171.250 'az;'
DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 81 DF 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 26 19 15 B3 00 08 37 8B
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 1F E2 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 2F DD 15 B3 00 08 2D C7 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

DEBUG: Output interface address: 0.0.0.0
DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 9F 7F 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 17 41 15 B3 00 08 46 63 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms
DEBUG: Output interface address: 0.0.0.0

DEBUG: if lo: The address doesn't match
DEBUG: if eth0: OK
using eth0, addr: 192.168.0.6, MTU: 1500
DEBUG: pcap_open_live(eth0, 99999, 0, 1, 0x628220)
DEBUG: dltype is 1
HPING 31.222.171.250 (eth0 31.222.171.250): udp mode set, 28 headers + 0 data bytes
45 00 00 1C 8C BC 00 00 40 11 00 00 C0 A8 00 06 1F DE AB FA 00 35 15 B3 00 08 5D 6F 
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL

--- 31.222.171.250 hping statistic ---
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

The outputs from the server has changed as well.

debian-leny:~/udptx# ./server
created a UPD socket on port 5555
listening on our UPD socket
received from ip: 80.194.5.191 port: hex 0x2619 dec 9753
received from ip: 80.194.5.191 port: hex 0x2fdd dec 12253
received from ip: 80.194.5.191 port: hex 0x1741 dec 5953
received from ip: 80.194.5.191 port: hex 0x35 dec 53
Received 3 characters:
msg[0]=char a hex 0x61 dec 97
msg[1]=char z hex 0x7a dec 122
msg[2]=char ; hex 0x3b dec 59

A new tcpdump file with the captured session between the client and sever can be found here udptx.eth.pcap

debian-leny:~/udptx# tcpdump -s0 -nn -i eth0 -w /tmp/udptx.eth.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19 packets captured
20 packets received by filter
0 packets dropped by kernel

Summary and further work

The presented code shows that it is possible to sent and receive data without relaying on the UDP payload mechanism. Of course the code is very simple and doesn't implement all the necessary protocol features to make it useful on a bigger scale. To name only a few missing key points that would have to be implemented:
 - packet lost
 - packet duplication
 - packets reordering

To better understand the limitation of our code and learn more about protocol implementation issues it is highly recommend to read at least the official RFC documents about for UDP and TCP protocols [5].

References

[1] http://www.networksorcery.com/enp/protocol/udp.htm
[2] http://www.hping.org/

[3]
http://www.rackspace.com/cloud/cloud_hosting_products/servers/
http://www.rackspace.com/cloud/cloud_hosting_faq/
http://www.rackspace.com/knowledge_center/node/1875

[4]  https://github.com/rtomaszewski/udptx
[5] http://www.diigo.com/user/rtomaszewski/rfc