Just another WordPress site
Up until recently in tripleo booting, from a cinder volume was confined to virtual instances, but now thanks to some recent work in ironic, baremetal instances can also be booted backed by a cinder volume.
Below I’ll go through the process of how to take a CentOS cloud image, prepare and load it into a cinder volume so that it can be used to back the root partition of a baremetal instance.
Continue reading “Booting baremetal from a Cinder Volume in TripleO”
If your anything like me you’ll have various ssh port forwarding tunnels set up to gain access to hosts on a private network through a jumphost or behind a firewall for which you don’t have a VPN. Every time I need to access to another port I add another configuration (or command line parameter) to my ssh tunnel.
Recently I hit a need for 1 tunnel too many. I started looking for a easier way and after a brief investigation into the possibilities with iptables I found the problem was already solved, I found sshuttle.
Continue reading ““sshuttle” where have you been all my life”
To get familiar with docker I took a look to see what it would take to build and/or run various containers, it was surprisingly easy (all commands below were run as root)
Install/start and enable docker
yum install docker-io
systemctl start docker
systemctl enable docker
The instructions below go through creating 2 docker images (the first is based on busybox and the second is fedora), if you would just like to use one that has already been created you can download it from the docker registry and then just start using it.
docker pull fedora
docker images
docker run -t -i fedora:20 /bin/bash
If all you want to do is run this pre-built fedora image you can stop here.
On the other hand if you would like to get your hands dirty and create your own images then …
Continue reading “Playing with docker on Fedora 20”
I recently had to install pidora on my Raspberry Pi in headless mode over ssh, I couldn’t find it documented anywhere so here is what I had to do. These instructions were carried out on a Fedora 18 laptop on the same local network as the Pi.
The main problem with running in headless mode is that you can’t navigate through the firstboot application, and can’t resize the file system. If running with a keyboard and monitor attached you wouldn’t need to follow the process below.
1. Download the image from http://pidora.ca/
2. insert your sd card and find its device name, I usually do this by tailing /var/log/messages when I insert the card
3. after checking for family photos on the card, unzip and write the image to the sdcard, Note: the device name of your sd card may differ from mine
$ unzip pidora-18-r1c.zip
Archive: pidora-18-r1c.zip
inflating: pidora-18-r1c.img
extracting: pidora-18-r1c.img.md5sum
$ sudo dd if=pidora-18-r1c.img of=/dev/mmcblk0
3494306+0 records in
3494306+0 records out
1789084672 bytes (1.8 GB) copied, 1025.63 s, 1.7 MB/s
4. put the sd card into the Pi, connect it to the network and power it up.
5. Find the ipaddress of the Pi, there are a number of ways todo this, I just checked the dhcp leases on my local dhcp server
6. After waiting a minute or 2 ssh to the Pi with the username “root” and password “raspberrypi”, (the -X is important, we’ll need it in a minute)
$ ssh root@192.168.1.112 -X
7. You should see that firstboot has started, run ps to find its PID’s and kill it, we’ll need to run it again in the next step…
[root@raspi ~]# ps -ef | grep -i firstboot
root 134 1 10 14:47 ? 00:00:12 python /usr/sbin/firstboot
root 233 134 1 14:47 ? 00:00:01 python /usr/sbin/firstboot
root 667 645 0 14:49 pts/0 00:00:00 grep –color=auto -i firstboot
[root@raspi ~]# kill 134 233
8. Now we can start it again, because we passed in -X to our ssh client, firstboot should be tunnelled over ssh to the local X server, if you don’t have a local X server running your going to have to start one (e.g. on windows maybe cygwin does this ?)
[root@raspi ~]# firstboot
run through the dialogue, after a reboot your done, You now have Fedora 18 running on your Raspberry Pi.
EDIT : I just stumbled across alternate instructions
Looking for a Fedora 18 qcow2 image to use on openstack? I’ve put one here. Cloud init is configured to set the ssh public key for the user “fedora” who has full sudo access.
Simply download the file and use glance add
$ glance -d add name="Fedora 18" disk_format=qcow2 container_format=bare is_public=true < f18-x86_64-openstack-sda.qcow2
If you’d prefer to build your own one, I’ve included the kickstart file simply download it and run the commands
$ yum install -y appliance-tools qemu-img # I did this on Fedora 17
$ appliance-creator --name f18-x86_64-openstack --format qcow2 --config=f18-x86_64-openstack.ks
$ qemu-img convert -f qcow2 -c -O qcow2 f18-x86_64-openstack/f18-x86_64-openstack-sda.qcow2 f18-x86_64-openstack-sda.qcow2
The details above are a slightly altered version of a Fedora 17 image provided by Daniel Berrange http://berrange.fedorapeople.org/images/
Installing and deploying OpenStack is a tricky business and its not uncommon for people to get bogged down at the early stages, the task gets even more difficult when you try to do more then an all in one installation.
In order to help people with this task I have been working on a tool that is capable of installing openstack in a distributed environment using some of the most common configurations. Packstack can be used to transform Fedora 17/18, RHEL 6 or CentOS 6 servers into a functional Openstack Folsom deployment. The tool ssh’s onto each server and apply’s puppet manifests to set openstack up. Below I give a brief outline of how todo this on Fedora 17
I’ll be installing openstack on 2 servers
s1 : keystone, glance, nova controller, cinder, swift proxy
s2 : nova compute, swift storage
I often find myself trying to figure out what role and tenants certain users have on a keystone server and this for me usually comes down to running combinations of
keystone user-list
keystone tenant-list
keystone user-role-list
As an alternative I’ve put together a small script that list the relationship between users/tenants and roles in a table format
In my last post I demonstrated how to use the openstack nova client to control rackspace servers from the command line.
It is also possible to control your rackspace cloud files using the openstack swift client, the first thing we need to do is install the package (again these examples are using fedora 17)
> yum install openstack-swift
Next we need to create the file ~/rackspacerc_cloudfiles, this file will be used to setup our environment anytime we want to use swift, it should look something like this
Continue reading “rackspace cloud files from the command line”
With rackspaces providing its compute service based on OpenStack, its possible to control your servers using the openstack nova client and its fairly simple to do.
You start by installing the openstack-novaclient (these examples are done on fedora 17). For now python-setuptools is needed here as a dependency.
> sudo yum install python-setuptools python-novaclient
Create the file ~/rackspacerc, this file will be used to setup our environment anytime we want to use nova, it should look something like this
export OS_USERNAME=username
export OS_PASSWORD=passwd
export OS_AUTH_URL=https://identity.api.rackspacecloud.com/v2.0/
export OS_REGION_NAME=DFW
export OS_TENANT_NAME=1234567
export NOVA_SERVICE_NAME=cloudServersOpenStack
A word about some of these settings and where to get their values
Continue reading “rackspace cloud servers from the command line”
Hello,
this is my second attempt at creating a blog, the first one failed before the number of entries even reached the double digits.
Bye for now,
Derek.