Cody Bunch Some Random IT Guy - OpenStack, DevOps, Cloud, Things

Easy Conference Tunneling - OSX, Sidestep, and Cloud Servers

VMworld 2016 is upon us. Or was at the time of this writing. That doesn’t change the message, however. When you are traveling for work, play or otherwise, who knows who else is on the WiFi with you. Who is snooping your traffic, and so on.

In this post, we’ll cover setting up a Cloud server, ssh keys, and sidestep to provide you with traffic tunneling and encryption from where-ever you are.


  • An account with some cloud provider
  • A recent version of OSX

Set up the Cloud Server

THe instructions for this will vary some depending on the provider you use. What you are looking for however, is some flavor of Ubuntu 14.04 or higher. From there, apply this, to provide a basic level of hardening.

You can either copy / paste it in as user data, or run it line by line (or as a script on the remote host).

Set up SSH Keys

First, lets check to see if you have existing ssh keys:

ls -al ~/.ssh

You are looking for one of the following:

Not there? Want a new one for this task? Let’s make one. From the terminal:

ssh-keygen -t rsa -b 4096

When prompted just give it all the default answers (yes yes, passwordless keys are the devil, but, we’re only using this key, for this server, for this conference, right?)

Finally we need to copy the new keys over to your server:


Finally use the key to log in to your cloud server, and disable password logins:


sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_conf

cat /etc/ssh/sshd_conf | grep PasswordAuthentication

sudo service ssh restart

So what we just did was: - Log into the cloud server - Disable password auth - Confirm that we disabled password auth (That is, there is no # in front of the line and that it reads ‘no’) - Restarted SSH to enable the setting


Sidestep is the glue that pulls all of this together. From their site:

When Sidestep detects you connecting to an unprotected wireless network, it automatically encrypts all of your Internet traffic and reroutes it through a secure connection to a server of your choosing, which acts as your Internet proxy. And it does all this in the background so that you don’t even notice it.

So, first things first, download and install this the same as you would other OSX packages. Once installed you will need to configure it.

First, set up the actual proxy host & click test:

Next, set sidestep up to work automagically:


In this post we showed you how to setup a budget tunneling solution for when you are out and about conferencing, or otherwise on a network you do not trust.

Revisiting BGP on Linux w/ Cumulus Topology Converter

A post or two ago, we explored setting up BGP to route between networks using Linux and Cumulus Quagga. As fun as this exercise was, I would not want to have to set it up this way each and every time I needed a lab. To that point, I haven’t actually touched the homelab it was built on since that point. Why? because complicated.

Then enters Scott Lowe, and Technology Short Take #70. At the bottom of the networking section, as if it weren’t the coolest thing on the list, there is this gem:

"This looks neat—I need to try to find time to give it a spin."

So that’s what we’re doing!

Topology converter’s job, is to take a formatted text file that represents the lab you’d like built, and to generate it as a Vagrantfile that can then be spun up with all of the plumbing taken care of for you.

Getting Started

My lab setup is a 2012 15” Retina MacBook, 16bg ram, and the latest Vagrant (1.8.5) & Virtualbox (5.1.4). From there we start with the installation instructions found here.. Additionally, you’ll want to clone the repo: git clone && cd topology_converter

You’ll also want to install the vagrant-cumulus plugin: vagrant plugin install vagrant-cumulus

Remaking our BGP Lab

Now that we’ve got the tools installed, we need to create our topology. Remember, we used this last time:


In the language of topology converter, that looks like this:

graph dc1 {
  "spine01" [function="spine" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "spine02" [function="spine" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "spine03" [function="spine" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "leaf01" [function="leaf" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "leaf02" [function="leaf" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "leaf03" [function="leaf" os="CumulusCommunity/cumulus-vx" version="3.0.1" memory="512" config="./helper_scripts/" mgmt_ip=""]
  "server01" [function="host" os="boxcutter/ubuntu1404" memory="512" ubuntu=True config="./helper_scripts/" mgmt_ip=""]
  "server02" [function="host" os="boxcutter/ubuntu1404" memory="512" ubuntu=True config="./helper_scripts/" mgmt_ip=""]
  "server03" [function="host" os="boxcutter/ubuntu1404" memory="512" ubuntu=True config="./helper_scripts/" mgmt_ip=""]

  "leaf01":"swp40" -- "spine01":"swp1"
  "leaf02":"swp40" -- "spine02":"swp1"
  "leaf03":"swp40" -- "spine03":"swp1"

  "spine01":"swp31" -- "spine02":"swp31"
  "spine02":"swp32" -- "spine03":"swp32"
  "spine03":"swp33" -- "spine01":"swp33"

  "server01":"eth0" -- "leaf01":"swp1"
  "server02":"eth0" -- "leaf02":"swp1"
  "server03":"eth0" -- "leaf03":"swp1"

There are four sections to this file. The first is the node definitions. Spine, leaf, and server. Or, routers, switches, and hosts. Each is given an OS to run and a management IP.

The next three sections define the connections between the nodes. In our case, interface 40 on the switches uplinks to their router. The routers each link to one another, and the hosts to the switches.

Once you have this file saved as (or similar), run the topology converter command (which produces a very verbose bit of output):

$ python ./ ./

          Topology Converter
>> DEVICE: spine02
     code: CumulusCommunity/cumulus-vx
     memory: 512
     function: spine
     config: ./helper_scripts/
     hostname: spine02
     version: 3.0.1
       LINK: swp1
               remote_device: leaf02
               mac: 44:38:39:00:00:04
               network: net2
               remote_interface: swp40
       LINK: swp31
               remote_device: spine01
               mac: 44:38:39:00:00:10
               network: net8
               remote_interface: swp31
       LINK: swp32
               remote_device: spine03
               mac: 44:38:39:00:00:0d
               network: net7
               remote_interface: swp32

Starting the lab

Ok, so what we’ve done so far was install topology converter, write a topology file to represent our lab, and finally, we converted that to a Vagrant file. We have one more pre-flight check to run before we can fire up the lab, and that is to make sure Vagrant recognizes what we’re trying to do:

$ vagrant status
Current machine states:

spine02                   not created (vmware_fusion)
spine03                   not created (vmware_fusion)
spine01                   not created (vmware_fusion)
leaf02                    not created (vmware_fusion)
leaf03                    not created (vmware_fusion)
leaf01                    not created (vmware_fusion)
server01                  not created (vmware_fusion)
server03                  not created (vmware_fusion)
server02                  not created (vmware_fusion)

Looks good, excepting that vmware_fusion bit. Thankfully, that’s an artifact of my local environment, and can be worked around by specifying --provider=virtualbox

So, let’s do that: Warning, this will take a WHILE

vagrant up --provider=virtualbox


$ vagrant status
Current machine states:

spine02                   running (virtualbox)
spine03                   running (virtualbox)
spine01                   running (virtualbox)
leaf02                    running (virtualbox)
leaf03                    running (virtualbox)
leaf01                    running (virtualbox)
server01                  running (virtualbox)
server03                  running (virtualbox)
server02                  running (virtualbox)

Accessing the lab

Ok, to recap one more time, we’ve installed topology converter, written a topology file, converted that to a Vagrant environment, and fired that up within virtualbox. That’s A LOT of work, so if you need a coffee, I understand.

While we’ve done all the work of creating the lab, we haven’t configured anything as yet. While we’ll leave that as an exercise for another post, we will show you how to access a node in said lab. The most straight forward way, is with vagrant ssh [nodename]

vagrant ssh spine02

Welcome to Cumulus VX (TM)

Cumulus VX (TM) is a community supported virtual appliance designed for
experiencing, testing and prototyping Cumulus Networks' latest technology.
For any questions or technical support, visit our community site at:

The registered trademark Linux (R) is used pursuant to a sublicense from LMI,
the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide
vagrant@spine02:~$ sudo su - cumulus


Long post is long. However, in this post, we have used Cumulus Topology converter to create a lab network topology with 3 routers, 3 switches, and 3 hosts that are now waiting for configuration.

Mosh-ing on Ubuntu & OSX

Today? Today was a treat. Instead of staying holed up in the home office, I decided to head out and attempt to people for a few hours. While the results of my peopling varied (Coffee shops are strange) I also encountered less than good network connectivity. That is, if the firewall logs are to be believed, I wasn’t the only one running a torrent or twelve.

Terrible network connections right? SSH is typically robust in the regard. Not this time, apparently. Enter Mosh.

What is Mosh

Mosh, or mobile shell, comes to you from MIT (here). Mosh uses SSH to establish the initial connection and authentication. This lets all your ssh-key files and such keep working. It then launches it’s own udp mosh-server to handle the actual session.

It’s a great little package, and worth looking at a bit more. I’ve been using it instead of SSH for most the boxes I manage for a while now.

Installing and Using Mosh

As with all things, there are two components. That which you install on your laptop, and the bits that run on the box you are managing. This section assumes OSX on the desktop and Ubuntu on the server. That said, if you check the Digital Ocean link in the references section, you’ll see the install covered for other platforms. I’d also recommend adding this to whatever scripts you use to bootstrap a server.

Installing Mosh on OSX

brew install mosh

That’s it!

Oh, you don’t have homebrew installed? While I’d suggest fixing that, you can also download the Mosh package from here, and install like any other OSX package.

Installing Mosh on Ubuntu 14.04

This is also straight forward:

sudo apt-get install -y mosh

Additionally, I added an exception for it in IPTABLES:

sudo iptables -I INPUT 1 -p udp --dport 60000:61000 -j ACCEPT

Logging in

All that setup, phew. Fortunately, from this point forward it works very much like ssh, in that:

ssh bunchc@codybunch.local


mosh bunchc@codybunch.local

If you need to pass port forwarding bits along, it is still straight forward, but a bit less so than standard ssh:

mosh --ssh"ssh -p 9000" bunchc@codybunch.local


Getting started with BGP on Linux with Cumuls Quagga

Before we begin, I’d like to admit something: “I spent a good number of years as a Windows sysadmin.” There, I said it. Now, I’m proud of my time as a Windows guy, so that’s’ not why I bring it up. I mention my time as a Windows admin perhaps to provide a reason why it took me so long to get BGP between some Linux VMs.

What we’re building

The above figure depicts a three node, three router network that we will create in this post. Following these steps:

  1. Install the routers
  2. Configure the routers
  3. Configure the hosts
  4. Test connectivity

Install the Routers

In our setup we start with Ubuntu 14.04 boxes with two interfaces. We assume eth0 is on the network, and eth1 is on the 172.x.100.0/24 network.

First download the 14.04 package from here. In the commands below wget this file from another server in the environment, you can get it there however you like.

Configure the interfaces

On each router, configure your interfaces, substituting network addresses where relevant:

# cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static

auto eth1
iface eth1 inet static

Then, restart the interfaces: sudo service networking restart

Enable routing

sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p

Install Quagga

As root, run the following commands:

apt-get update && apt-get -qq dist-upgrade && reboot
wget http://location/of/the/download/roh-ubuntu1404.tar
tar -xvf roh-ubuntu1404.tar
cd ubuntu1404/
dpkg -i quagga_0.99.23.1-1+cl3u2_trusty_amd64.deb duagga-dbg_0.99.23.1-1+cl3u2_trusty_amd64.deb quagga-doc_0.99.23.1-1+cl3u2_trusty_all.deb

We then need to provide some initial start up configuration for Quagga. We do this by changing the /etc/quagga/daemons file to reflect the services we would like started. In this case, the obligatory Zebra, and BGP:


Start Quagga

Now that Quagga is installed, we need to start said service:

service quagga start

Configure the Routers

with Quagga installed and running on each Quagga host, we can configure the needed bits to get BGP operational. The commands and configuration that follow configure the router from our diagram above. Note, you will want to choose Private AS numbers from here: Private BGP AS Numbers. In the example, these are 64512, 513, and 514 respectively.

# vtysh
conf t

hostname cab1-router
password zebra
enable password zebra
log file /var/log/quagga/bgpd.log
router bgp 64512
 bgp router-id
 neighbor remote-as 64513
 neighbor remote-as 64514
 distance bgp 150 150 150
wr mem

Configure the Hosts

For each host behind out of our Quagga routers, you need to set the interfaces file to an appropriate address and gateway per host:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static

Testing Connectivity

Now that all three routers and all three VMs are configured, we will test connectivity. First between routers, then between VMs:

From router 1: cab1-router# ping PING ( 56(84) bytes of data. 64 bytes from icmp_seq=1 ttl=64 time=0.367 ms ^C --- ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.367/0.367/0.367/0.000 ms cab1-router# ping PING ( 56(84) bytes of data. 64 bytes from icmp_seq=1 ttl=63 time=0.448 ms ^C --- ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.298/0.373/0.448/0.075 ms

From VM3:

[17:03:59] $ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=62 time=0.443 ms
64 bytes from icmp_seq=2 ttl=62 time=0.475 ms
--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.443/0.459/0.475/0.016 ms

[17:10:06] $ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=63 time=0.179 ms
64 bytes from icmp_seq=2 ttl=63 time=0.410 ms
--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.179/0.294/0.410/0.116 ms


In this post we built three L3 networks, and configured BGP routing between them using Quagga on a Ubuntu 14.04 host. We then tested connectivity between these networks.


Make Cloud Great Again - On Crowd Funding


In case y’all missed it, beginning around the OpenStack Austin 2016 summit, I launched a “Make the Cloud Great Again” crowd funding campaign. As I sit here typing this, I’ve dropped all the packages off at the post office, for shipping, and feel it’s important to write some notes for those who might consider their own campaign. That, or to remind myself how difficult this was in case I decide to do it again.


Like most of my more terrible ideas, this one started on Twitter. An snark comment about #MakeTheCloudGreatAgain, as a play on the Trump campaign started it all. I reached out to StitchTek and worked with Mr. Colotti on the trucker hat design. We played with some ideas, and ordered some samples.

The Platform

Indiegogo was the platform of choice. This was due to the flexible nature of funding. Meaning, I didn’t have to hit the entire goal to be able to ship. The platform has some decent tools for promotion and updates, even if the buttons aren’t always where you would expect.


BackerKit basically handles everything after Indiegogo or kickstarter release funds. It’ll handle like surveys, add-ons, additional orders, and more. Where this fit into our process, was surveys and generating shipping labels, as well as communicating tracking information.

Enlisting Help

When the campaign broke the 100% barrier, I enlisted the help of GetFriday, a division of Your Man in India. Basically a per hour assistant. They managed the campaign updates, and everything from the close of the campaign to buying shipping.

Packing and Shipping

The Hats

The rubber met the road here. Lots of hours, trips to Office Max, and then some went into this step. 40+ is a lot of hats.

In Summary

It’s done, over with, finished. The hats have shipped. Would I do it again? Maybe. This was a lot more effort than anticipated, that’s for sure.

Speaker Notes & Slides - BOS VMUG 2016

This last week I had the wonderful opportunity to speak at the Boston VMUG user conference as a part of both a community panel, as well as a talk on “Automation - You’re doing it wrong”. This post then includes the speaker notes for said session in raw form, as well as the similarly raw slides.



Automation - You’re doing it wrong

Automation has been a major topic at IT conferences more or less forever. Be it batch files, PowerShell, VCO (you know, before they renamed it). We’ve even had movements towards automating IT workloads at scale… DevOps, etc. In this talk, we aim, not to cover whatever is the latest and greatest in tactical tools for automation. Rather, our aim is to equip you with the mental models to help resolve some of the underlying issues that prevent IT teams from achieving the goal of having a more automated system, by approaching the problem with a different mindset.

  • Introductions
    • Who is Cody
    • About the space
  • Processes
    • The Credit Union
      • Standard Operating Procedure(s)
      • A Big Project
      • A Small shell script
      • What happened…
      • Lessons learned
    • The Roomba example:
      • “O2O” - Order to Online
      • The Whiteboard
      • Lessons learned
  • People
    • The Credit Union
      • The People
        • The “Mainframe Guy”
        • The “Operator”
        • The “Desktop Guy”
        • The “Web Guy”
  • Stop addressing first order tasks
    • Evolution of Automation
      • Mechanical Turks
      • Task Based
      • “DevOps” / Product Dev
    • Look at the whole system
    • Design an autonomous system
  • Buying Time
    • “If we are engineering processes and solutions that are not automatable, we continue having to staff humans to maintain the system. If we have to staff humans to do the work, we are feeding the machines with the blood, sweat, and tears of human beings. Think The Matrix with less special effects and more pissed off System Administrators” - Joseph Bironas, Google SRE

Updated vSensei Reading List

Apparently, these are useful. With that in mind, here is what I’ve been reading since the first of the year. Unlike the other lists, there isn’t much specific direction in this one.

The importance of being little - This one, spawned a bunch of my more recent twitter borne rants. If nothing else, it is amazing how similar life in the workplace is similar to the life of a preschooler, and unfortunately just as training in most cases.

4 Hour Work Week - This one gets an occasional re-read. If you can get past the Tim Ferrisness of it, there is some good “GO DO THE DAMN THING” advice in there.

Influence - Just wrapped this one up prior to going to a show. It was interesting to spot all the varied techniques in use, in a real setting.

Seeking Wisdom - Excellent read.

Profit First - This one came to me via a podcast recommendation. While I’m not sure I’d recommend it out right, the way it reads is very tele-salesy. The gist of it, is basically set your business up in a similar way to how you would your personal finances post David Ramsey class.

Buddhism Without Beliefs - I’m still processing this one, honestly, and it may get a second listen soon so I can better process the lessons contained within. It gets to the root of things like, ‘why mindfulness’ and ‘why meditation’, along with “meditation isn’t just sitting, it can also be bicycling, etc”.

Debt, the first 5,000 Years - A good little history of money that sheds some light on some of the stupider things we do to each other.

Elon Musk - Quick read on the behind the scenes of some of the most interesting BIG engineering going on today.

Unstoppable - A little preachy, but in a good way. Bill Bill Bill Bill… Bill Nye the Science Guy!

Inside of a Dog - Because being mindful isn’t just for people.

Kubernetes Up And Running - Well, damn this book is good. Accessible, working examples, good overview of k8s. Everything I’d want in a first book on the subject.

Hardware Startup - There was a phase early in the year where I thought I was cool, and would launch a kickstarter for something or other. This was the first book recommended, and while it hasn’t completely disabused me of the notion of a hardware startup, it pointed out HUGE gaps in my knowledge, that I am working to fill.

OpenStack Networking Essentials - One day, I hope to write as well as Denton. He takes and breaks down the complicated subject of the OpenStack Neutron project into the bare essentials of what you need to know. Then explains it in a way that is incredibly accessible. I was an editor of this volume

Troubleshooting OpenStack - Like the Neutron book above, Tony takes and makes a hard subject a bit easier, and lot more understandable. If you use OpenStack, you’ll want this book.

The Wahls Protcol - My wife has MS. I needed to know more. This got me a bit closer.

Docker Clustering on Raspberry Pi

The folks behind Hypriot have made getting Docker up and going on the Raspberry Pi a near on trivial task: Download the image, power it on. They’ve also done the same thing for Docker clustering, here. Which is great, until it isn’t.

That is, their clustering lab has a number of hard requirements around VLAN networking support. If you’ve got a plethora of dumb switches at home, this just wont do!

Have no fear, however, the combination of their image, and their clustering packages seem to be the magical combination.

Hardware bits to have

  • Some number of Raspberry Pi’s (I’ve got 3x rPI 2 for this, I think anything b+ will work)
  • At least one wifi dongle
  • An Ethernet switch

Let’s do this!

This process roughly breaks down like this:

Pull the image down from here. At the time of writing it was “Hector” 0.6.1

Use the Hypriot ‘flash’ script to load your SD card:

flash --hostname Drekkar --ssid WiFi-Iron --password "$DAVE" /path/to/

Do this for each card you have. Once your cards are imaged, plug them in, boot the Pi’s, and find them on the network.

For this next trick, I used ssh and broadcast input in iTerm (TMUX works well too), to issue the following commands across all the nodes in my cluster:

sudo apt-get update && sudo apt-get install hypriot-cluster-lab

The prior commands will take a couple of minutes to complete. Once they do, pick a node to be ‘master’, and direct all input to it (rather than all the nodes). On that node, run the following:

sudo systemctl start cluster-start

Again, this will take a few minutes. Once finished, run the prior command on the rest of your cluster nodes. At this point, fetch a coffee, it’ll be a while.

Cool! You’ve now got a Docker Cluster running on Raspberry PI’s

To read more about what the Hypriot group has going on, and some exercises to do with said cluster, check out their git page here.

#vSensei 2016 Kick-Off

Ok, so I’m a bit late on this one, but here we are. It’s time to open up submissions for the #vSensei program H1 2016.

The form can be found here.

I encourage you to not only sign up, but to encourage others to as well.

Not sure what #vSensei is?

The Program

vSensei or #vSensei is an 1 on 1 mentorship program, currently in it’s second year. The program itself is designed to pair you with some of the best of the best in their respective areas, with the end goal being to help you up your game.

For the first half of 2016, the group of “vSensei” will pair up with you, dig into what makes you tick, what your goals are, and guide you along the way to knocking them out.

Selection Process

Because we have more mentors this time around, we’ll sort of make this up as we go. The gist is: SIGN UP HERE

Once we have your sign-up and close submissions. We’ll have a group think, and then send out emails to those selected.

What you need to bring to the program

  • Be willing to hustle, and hustle hard.
  • Be willing to make changes.
  • Don’t be an asshat
  • Have between 30m - 1h a week

About Us

For H1 2016, we have the following mentors available:

Scott Lowe

Scott Lowe is a blogger, speaker, best-selling author, and IT industry veteran. Currently, he works for VMware, Inc., on the NSX team. He focuses his time and efforts on open source, cloud computing, virtualization, networking, and related data center technologies. Scott regularly shares technical content and insight on his blog at

Edward Haletky

Edward L. Haletky, the President, CEO, and principle consultant for AstroArch Consulting, Inc., graduated from Purdue University in 1988 with a degree in Aeronautical and Astronautical Engineering. Since then, he has worked with programming graphics and other lower-level libraries on various UNIX platforms. When at Hewlett-Packard, Edward worked in the Virtualization, Linux, and High-Performance Technical Computing teams. Edward is very active on the VMware Communities Discussion Forums providing answers to security and configuration questions and is also one of the VMware Communities User Moderators and Guru. In addition, Edward has earned his LPI, RHCE and VCP certifications, and VMware vExpert designation. Edward is a very active analyst, writer, and blogger with in the virtualization space.

Jordan Rinke

CTO for Canada’s largest virtual network provider iTel Networks. One of the original OpenStack for Hyper-V developers. Part of the original Cloud Builders group at Rackspace, deployed the first non-NASA OpenStack Compute cluster. Helped build the first Canadian OpenStack installation. A rare lover of Microsoft, Linux, and Open source. Infrastructure engineer turned developer - with a keen understanding of both in mixed OS environments. His entire career has been about making massive infrastructure go faster. With startup experience and hyperscale experience he has an understanding of bootstrapping a service for dollars a month with a built in ability to scale as money permits, to orchestrating the migration of 5000vms and keeping an e-commerce site online with 20,000 concurrent users.

Trevor Roberts

Trevor Roberts, Jr. is the Senior Technical Marketing Manager for OpenStack at VMware and the lead author of the VMware Press Title, “DevOps for VMware Administrators”. He enjoys speaking to customers and partners about the benefits of using OpenStack with VMware technologies.

Trevor has the CCIE Data Center certification, and he is a VMware Certified Advanced Professional in the Data Center Design and Administration concentrations.

In his spare time, Trevor shares his insights on data center technologies at via the vBrownBag Professional OpenStack and Professional VMware podcasts, and on Twitter (@VMTrooper). His contributions to the IT community have garnered recognition by his designation as a VMware vExpert, Cisco Data Center Champion, and EMC Elect.

Cody Bunch

(That’s me)

Me, I do things. I’ve published a few books, I’ve worked with others to help them get down that path. I’ve spoken at some events, and again, have helped some others down that path. I helped start a podcast, which in turn has helped some folks take that next step. I also want to do more.


Go forth, sign up, spread the message.

So, you want to write a book

So, you want to write a book. Awesome! What follows here then, are the assorted ramblings of someone who has maybe written a few. Specifically, we will be talking about what it takes to get your first technical (and IT specifically) book out. Whilst geared towards first timers, maybe you’ll find some advice in here helpful on a second or third book as well.

Before we start

Take all of this with a grain of salt. Do some additional research, reach out and talk to folks (I’m almost always on twitter, skype, email, etc). Get a mentor (cough vSensei cough) and such. What follows here, are my experiences, across authoring or co-authoring 4 books and tech editing many others.

So you want to write a book?

Excellent! This first part of the post, will dig into a number of the most common questions. How hard is it, will I make money, who will publish me, and so on.

What is your motivation?

This one is huge, and it will come out in your writing. That is, if you are doing this as part of a publish or perish mandate, or ‘to get rich’, well… your writing will reflect this.

Not that it’s particularly bad, mind, just that, given the amount of time and energy you will be pouring into the book, examples, lab environment, diagrams, and other materials…

For me at least, I needed stronger stuff. Love what you do, love what you are writing about, and love the community of supporters, both current and future. Your writing will reflect this and you’ll experience much less fatigue / burn out.

What is the time investment?

This will vary from book to book and contract to contract. It will also vary based on how well you know the material, and a number of other factors.

In the four books I have been a part of, even as a co-author, you can count on it being a second job for the duration of the contract, + 3 months.

Yeah. This includes time spent writing, rewriting, editing, building and testing lab examples, then doing that again, building diagrams, examples, code, and more.

In the coediting sense, this could mean time waiting on getting access to the git repo you are all working from, or because of blocking tasks.

It is important to not underestimate this point. This will be A LOT of work and can(will) cause burnout, both in your personal and professional lives. Be careful not to burn too many bridges here, and discuss it with your family and workplace.

How much money will I make?


tl;dr - It’s not a lot, maybe a few tanks of gas, or if you’re really lucky, enough to refresh the homelab when you’ve finished.

The longer version is, you’ll be paid in royalties that are contingent upon book sales. The average, at the time I am writing this post, is 15%. There are some publishers, like Pragmatic bookshelf that offer as high as 50%.

There is some wiggle room on this point as well. That is, if you are fairly well known, or the book is going to be on a super hot topic, or some combination of the two, you can push for more. The flip side to that, is that you be ready for criticism as well.

There are also advances that are worth noting here. That is, an advance will be used as an incentive to help you meed deadlines, and is a check the publisher will write you, in ‘advance’ of having sold any copies of the book. It’s worth paying attention to the fact that your advance counts against your royalties. That is, you will not see a royalty check until you have sold enough books to meet your advance.

Publisher? Self Published?

This is a personal choice really. Having only worked with publishers, I can’t vote one way or the other.

What does(should) a publisher bring to the table?

Depending on the publisher, you should expect:

  • An acquisition editor
  • A project manager
  • A development editor
  • Technical Editors
  • Marketing Support
  • Sales Channels

So, in order:

Acquisition Editor

This will likely be the first person you meet. They will take your idea, table of contents, and proposal, and give you some first pass feedback. Once that is solidified, they will then shop this proposal around internally at the publisher, as well as with experts in the field. Depending on the feedback received, they will either help you with the contract process, help you refine the proposal, or tell you ‘no’.

Project Manager

This is exactly what it says. Generally you meet your PM after the contract is in place. They will help decide deadlines and coordinate the various reviewers, and other launch activities.

Developmental Editor

Not every one write good. That’s where the developmental editor comes in. They will help you work on grammar, style, formatting, and importantly, helping decide what goes into and doesn’t fit in the book.

Technical Editors

Depending on the publisher and how new the topic area is, they will either supply some technical editors for your project from a pool of industry experts, or ask you to help source some. That, or some combination of both.

The role of the technical editors is to make sure that your writing is factually correct, and that your code examples work, make sense, and illustrate the concepts clearly and concisely.

Because this can take a while, particularly if the examples are broken, or don’t work on the myriad of platforms out there, tech editors generally get your content before everyone else.

Marketing Support

This is where promotions, discount codes, and all of that falls. The specific activities will be dependent on the project and publisher, but my include webinars, interviews, speaking engagements and so forth. Marketing support is also where you will request give-away copies for events.

It is worth noting here, that you are just as responsible for marketing, if not more so, than the publisher. You want it to be big? Get out there and hustle.

Sales Channels

This has changed some in the days of Internet book sales, but the publisher will help coordinate various channels where the book can be sold. Be that academics or book stores, translations, and the like.

What to expect

The process varies some, and what follows is my experience in working with publishers. There are several great posts on self-publishing around.

  • Idea
  • Brainstorming
  • Table of Contents
  • Market Research
  • Proposal
  • Contracting
  • Writing
  • Rewriting
  • Waiting
  • Published


Well, if you didn’t have an idea you wouldn’t be here, right? For me, I generally will chase a few criteria:

Are there books already? Do they cover the material? What about the docs and community? How difficult is $thing? Can I help simplify it?


This sort of happens at the same time as the first part. What would be great to see in a book about $thing, what things should be left out, what approach should we take? Instructional? Story telling? What audience do we want to approach? That is, do we want to dissect packet dumps or introduce them to the idea of a packet?

Keep a notebook, whiteboard, etherpad, goog doc, or something around to record this.

Table of Contents

Now that you have a bunch of things written down. Walk away from it for a while, then come back and try to fit it into a ToC. The ToC in this case, will look much like the outlines you did with roman numerals from highschool writing class. These will correspond to your chapters, and headings. It will also help you wrap your head around how the book should flow.

Market Research

Yes, you should do this part before the ToC. For the most part, it’s an iterative process. Google, Amazon, Google scholar, the communities, vendor documentation, mailing list archives, and such, will all help feed into your understanding of what is out there and where your book fill fit. You will also want to understand addressable market size. Take the VCP for example, there are some thousands of VCP’s out there. If you are writing a study guide for the next version of the exam, that and then some is the addressable market.


Most publishers will either have a web form, or a .doc file, or combination of the two, into which you will put your ToC, as well as the market research and a few variations of elevator pitch about your book into. At this step, if working with a publisher, you will want to find or make a direct connection to an acquisition editor, rather than just deal with an email box.


If they like your proposal, you will start talking contracts at this stage. This is where you will negotiate copyright, royalties, first right of refusal, and deadlines.

While I have no experience in negotiating copyright, the last three points can be flexible, however, much like any negotiating, it can get hairy here. Do not be afraid to stand up for yourself, however.

A note on “first right of refusal”. There is a clause (15 or 16 in most contracts that I’ve worked on), where the publisher demands the first right of refusal for updates, editions, and most importantly, any other works you are considering. It is up to you how you want to handle this point, but it rubbed me the wrong way.


This is the easy part. Really. It’s long, you will waste many a night staying up to meet a deadline, but then, you have a passion for the material, so the words will generally flow.

If they don’t, see the section on self-confidence and motivation.


This is where things get really draining. Rewriting will generally start once you have the first 3 or 4 chapters in to the publisher. At that point the tech editors, and likely some of the other editors will have seen, and made comments or corrections on your manuscript. Basically, while trying to meet one deadline, for possibly the hardest sections of the book, you will now have to address the feedback in a timely fashion.

Feedback can hurt. It can be cutting, and hard to hear. Understand, however, that everyone in this process wants to see your book in the market, and are trying to help you write the best book possible.


So this isn’t exactly waiting, but, once you are done with writing and rewriting, there are a few more steps, where you will have to review proofs before they get sent off to print. You’ll need to be careful errors don’t creep in here, but there is largely nothing you can do to stop the presses at this point.


OH Snap! Your mom found your book on Amazon, with no prompting and called you to congratulate you. How good does that feel? You’re done, mostly. The marketing bits never end, but dammit, when that first physical copy shows up at the house, and you are holding it in your hand… that feels so good. Go celebrate!

Self Confidence & Motivation

You are the expert, and what you are doing is important.

Read that again, and maybe a few more times.

Both self-confidence and motivation are super critical to have along the way. After your fourth or fifth consecutive all-nighter, you will wonder why you ever wanted to do anything. At all. Ever. Depression will set in, or some flavor of imposture syndrome. This will often be coupled with anger and sadness in equal measure.

This is all before the tech and grammar reviews start coming in. That is, when you see your work, that you’ve spent so much time to put out into the world, come back to you marked up like crazy… well, it can be crushing.

Having a good support system in family and friends, and the ability to work with the publisher to step aside for a few days will be critical to helping restore balance.

Do’s and Don’ts *

Here are some things that did not really fit well into the other areas.

  • Do not be afraid to do late stage revision. The publisher wants to get the book to market. Your job, is to get the right book to market.
  • Do use your voice. Yes, technical writing is formal. Yes, you should have proper guideposts in it. That said, there is no need for it to be dry and stilted.
  • Do not take that too far. That is, no F-Bombs, innuendo, and the like.
  • Do not use contractions. Your writing will be much clearer without them.
  • Do listen to your editors


This post isn’t comprehensive, and rambles at times, but should help you get an realistic idea of what all is involved in getting your first (or next) book out there. Ping me on twitter or at bunchc (at) professionalvmware . com if you have any questions, need a tech editor, or any other assistance in getting your idea into the world.

*This one broke me. After spending some time on google: “Style guides and usage books don’t agree. The Chicago Manual of Style and others recommend dos and don’ts. The Associated Press and others recommend do’s and don’ts. Eats, Shoots & Leaves recommends do’s and don’t’s” - Grammar Girl