Solving Off-The-Wall Stumpers

Solving Off-The-Wall Stumpers

Here is an example of a High Level Help Desk interaction with a client. This client is US based company with internal software development and operations team.

It’s a good example of what we can bring to the table for ongoing support and escalations as a valuable resource to them. Sometimes we answer random ‘What do you recommend?’ questions, and other times quick off the wall ‘Stumpers’ for their dev team.

(In the dialog below, italics represents the thought process and feedback of one of our senior Linux Engineers)

One of the Client’s developers contacted me via Slack chat, but I was in a meeting at the time and looks like he was also busy with other tasks. Still, I was able to resolve it in under 90 minutes from start to finish.

Client Dev [11:45 AM]
Hi! Could I perhaps get your help debugging Vagrant?

Richard Clark [12:10 PM]
Sure – What’s up ?

Client Dev [12:20 PM]

So, I’m using this project:

Stop doing whatever else I was working on, Google Vagrant, install vagrant, get a test box running on local, investigate drawing on all the stuff I know.
 I have used vagrant a bit in the past, about 3 years ago.  Too fat, I use Docker and Kubernetes (which makes docker not suck) now.

In the past, I was able to run the webserver on my host machine and have it communicate with  postgres running on the vagrant VM.

But now, I can no longer even ping the machine from host. I can still log in. Port forwarding/IP config hasn’t changed.

The only change is that, on this new machine, I’m running Vagrant 1.8.5
Downgrading is not a desirable option, since that would also require me to downgrade VirtualBox, which would require me to downgrade my Linux kernel, which could cascade to all sorts of other unpleasantness.

Richard Clark [12:24 PM]
What is your host os, (guessing Linux from last statement?) and, to confirm, you are launching the vagrant PostgreSQL instance from under your host os ? (or from jump server, etc.) ?

Client Dev [12:26 PM]
Yes, my host OS is arch. Postgres is on the vagrant VM

Richard Clark [12:28 PM]
vagrant vm on your host machine though right – not vagrant vm on some other box ?

Client Dev [12:28 PM]
Yes, on my host machine

At this point, I have figured out / remembered that there is a Vagrantfile in a ruby like format that configures how the vagrant boxes, so let’s get his one for PostgreSQL

Richard Clark [12:28 PM]
can you paste in your vagrantfile for Postgres instance

Client Dev [12:29 PM]

Client Dev [12:29 PM]
added a Ruby snippet: Vagrantfile


Richard Clark [12:33 PM]
can you paste in `ip a` from your host, and `ip a` from inside the postgres vm (mentioned you can still vagrant ssh into it right?)

Client Dev  [12:34 PM]
Yes, I can `vagrant ssh`. One moment

Wait, what do you mean by `ip a`?

Ahh, gotcha

Client Dev [12:35 PM]
added a Plain Text snippet: `ip address` Host

Richard Clark [12:35 PM]
Also paste in a sudo netstat -pnlt from arch

Client Dev [12:36 PM]
added a Plain Text snippet:  `ip address` postgres

Client Dev [12:39 PM]
added a Plain Text snippet: netstat Arch

I have now figured out the problem, and the quick solution. From the Vagrantfile posted in, there is a private network trying to be setup.  Again, I don’t know exactly how it gets setup, or all the various options, but it is there in mostly english like words in the config file, and if I was going to develop Vagrant, I would use similar kinds of words.

Richard Clark [12:41 PM]
What does the app (myproj_portal) have for its postgresql URL / Connection string ?

My guess is that this new machine does not have the private network setup that used to exist on the old machine.  It’s fine, you probably don’t need it, but you will need to change the myproj_portal DB connection to be psql://username:password@localhost:15432 from whatever it is now.  (I am assuming that you are running the myproj_portal code native on arch)..

I am just guessing at the url format, not sure what language is in use for myproj_portal
I didn’t want to wait for his reply, and then edit it. It would have been better to say ‘something like psql://……’ instead.
We are familiar with writing code in many languages to connect to many databases because we have all done software engineering as well as ops setup and management.

Client Dev [12:46 PM]
Yes, that’s right.

Richard Clark [12:46 PM]
You can’t ping it because the only thing that is working now is the NAT interface provided by VirtualBox, setup by stock Vagrant.. (the address inside the postgres box)

Again, while I might not be a Vagrant pro at this point in time, I do know all the parts that it uses, so I know how Virtualbox wires the plumbing (ops level knowledge).  It could have been LXC (docker), KVM, OpenVZ, Xen, etc.. just as well, and whatever flavor of the month is wrapping them.

Client Dev [12:47 PM]`jdbc:postgresql://postgres/myproj`

Erm, did I get you the right URL? The don’t look so similar…

Richard Clark [12:48 PM]
If you want the old functionality, you would need to get a private network setup with, I am guessing, on the arch. I can work that out, but it’s been a bit since I have used Vagrant so my vagrant-foo will take a bit to figure it out.

Not familar with Arch, but it is just another distro, some quick proper google searching will quickly narrow down what I actually need. It is not just googling – it is knowing what to google for 

Client Dev [12:49 PM]
I don’t recall setting anything up like that on the old machine.

And that is why we use management tools like SaltStack to deploy and actually document what / how a client uses their systems, and why we use things like Docker and Kubernetes to get to a developers laptop, a setup that is a close to production as possible. This above is exactly why developers will use the phrase ‘Works for me’ — They have done something, that they forgot, that makes their instance work, but no other instance anywhere else work.

Richard Clark [12:49 PM]
Need to change URL to `jdbc:postgresql://localhost:15432/myproj`

Client Dev [12:49 PM]
Thanks! I’ll try that out

This is in my /etc/hosts, by the way: `      postgres                postgres`

Richard Clark [12:50 PM]
No problem.. As for the private network missing – not sure how it got on old one, but it is not something stock vagrant / virtualbox would setup IIRC.

You could change the /etc/hosts to be `` postgres\   and keep the word ‘postgres’ in your connection string, but would still need to add `:15432`

Hm, now we could change your vagrant file, since it doesn’t look like you have a local PostgreSQL running.

Client Dev [12:52 PM]
I don’t even have it installed

Richard Clark [12:52 PM]
Change ` “forwarded_port”, guest: 5432, host: 15432` to ` “forwarded_port”, guest: 5432, host: 5432`, and change the /etc/hosts (as mentioned), and then you can probably keep your jdbc url (edited)

..just remember that if you ever do PostgreSQL into arch, it and this vagrant container will be fighting over 5432..

Client Dev [12:53 PM]
Okay! 5432 is default for Postgres, then?

Richard Clark [12:53 PM]

Client Dev [12:53 PM]
I’ll try that out.

Richard Clark [12:53 PM]

Client Dev [12:53 PM]
Thanks so much! You saved me a lot of time

Richard Clark [12:53 PM]
No problem… That’s what I am here for 

Categories: War Stories

By Richard Clark

November 12, 2016

Richard Clark
Author: Richard Clark

VP Engineering


Props to DevOps Panel Meetup