rtyler
/
brokenco.de
1
0
Fork 0
Code Pull Requests Releases Activity

Add my two most recent posts

This commit is contained in:
R. Tyler Croy 2012-06-14 22:02:08 -07:00
parent 4bedef7601
commit 0962b1811c
2 changed files with 190 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

136
_posts/2012-06-10-outside-in-to-ops.markdown Normal file
View File

@ -0,0 +1,136 @@
---
layout: post
title: Outside-in for Operations
tags:
- bdd
- cucumber
- ops
---
I have been thinking a lot about "outside-in" developement for operations as of
late, primarily focusing on how [Cucumber](http://cukes.info) might fit into
the equation.
[cucumber-puppet](http://blog.nistu.de/2012/06/09/cucumber-puppet-end-of-life/)
reached its "end-of-life" recently as the developer can no longer provide the
tender love and code (TLC) that the project requires. I don't particularly like
the way cucumber-puppet works but at the same time, I've been faced with more
and more questions about how to bridge into, or out of,
[rspec-puppet](http://rspec-puppet.com/).
As a development tool rspec-puppet is quite handy, but at the end of the day,
Puppet manifests should be run in an actual Puppet environment on real or
virtualized hardware before they get shipped off to the production site.
What does that look like?
Before you answer that, I think it is important to answer "who are the
stake-holders?" for the work that operations is doing?
### Developers as Stake Holders
Let's say I'm developing an application called "PentaGram", this is a simple
Rails application that will help Satan worshippers upload evil photos and share
them with their fellow demonic friends.
To host PentaGram, I'm going to need a web server, an Oracle database (this
application is evil, after all) and memcached. I think for now I'll just break
up my Cucumber `.feature` files into machine types (web, db, cache).
For this post, i'll focus on `featurees/apphost.feature`:
Feature: Serve the PentaGram web application
In order to serve up the PentaGram to millions of devil worshippers
As a developer
Web hosts should be configured to run the application
I think this makes sense as an 'introduction' to the feature, I need web hosts
to serve my web application.
Feature: Serve the PentaGram web application
...
Scenario: Provision a fresh web host
Given an empty host
And the host is of type "pentagram-app"
When I provision the host
Then it should be running a web server
And it should be responding to web requests
Alright, I'm not supremeley thrilled with this approach, one such example is
that "pentagram-app" is a Puppet module, and I'm not very comfortable with that
leaky of an abstraction. So I'm going to reword it to: `And the host is a
PentaGram app host` and start to define a vocabulary between my stake-holders
instead of letting Puppet module names leak upwards into Cucumber.
The more I think about it, I'm not sure "developers" or even product-owners are the stake
holders to address with these features. As a developer, I care very little
about the operational details, so long as PentaGram works!
Operations is its own compelling stake-holder, but that presents a complication
of making "outside-in" features such as these too leaky in terms of
abstractions and not very descriptive.
### Operations as Stake Holders
That web host you provisioned above is nice and fancy and all that, but as far as I
am concerned (being a fellow Ops engineer), there's a lot more to an app host
than just running the web server.
Feature: Serve the PentaGram web application
...
Scenario: Add app hosts into the load balancer
Given a load balancer with a pool for app hosts
And an empty PentaGram app host
When I provision the host
Then it should be added to the load balancer
And it should be receiving requests from the load balancer
I'm reasonably pleased with this, I'm going to pretend writing all these step
definitions is going to be rather easy to write, and forge ahead writing out
more Scenarios.
Scenario: Create the appropriate firewall rules
Given an empty PengtaGram app host
When I provision the host
Then traffic should be allowed to port 80
And traffic should be allowed to port 443
Scenario: Nagios checks for app hosts
Given a Nagios server
And an empty PentaGram app host
When I provision the host
Then Nagios HTTP checks should be added for the host
And Nagios HTTPs checks should be added for the host
---
At this point I've not written any step definitions or Ruby code to run these
Cucumber features, but I *think* this enumerates what I want out of a PentaGram
app host.
I know the following things are needed for an app host, just by reading
`apphost.feature`:
* A web server should be running (but how do we know it's not "It Works!"
coming from Apache instead of the PentaGram app?)
* The app host should be added to the load balancer's app-host pool when it is
provisioned
* The app host should port 80 and 443 open, ostensibly because Apache is
listening on those ports (we didn't say that it should be though! should we?)
* When the app host comes online, it should have Nagios checks added for its
service running on port 80 and port 443 (again, this doesn't verify the
PentaGram app is actually running there).
---
I am not sure if this is the best approach, or even an approach that doesn't
suck, this entire blog post has been me riffing on what outside-in might look
like for Operations.
In my next post on the subject, I should have some example code available with
fleshed out step definitions and some valid/passing scenarios.

54
_posts/2012-06-13-ssh-as-a-hidden-service.markdown Normal file
View File

@ -0,0 +1,54 @@
---
layout: post
title: SSH as a Hidden Service with Tor
tags:
- tor
- ssh
- security
---
For quite some time I've been using [Tor](https://www.torproject.org) for a
number of things, but my most recent use revolves around a lesser-known feature
Tor provides: [Hidden Services](https://www.torproject.org/docs/hidden-services.html.en).
With fewer and fewer IPv4 addresses running around, especially among
residential consumer lines, it has become increasingly difficult to "play a
part" in the internet without gnarly port forwarding hacks combined with
dynamic DNS.
Hidden Services offer a way to bypass a lot of those hacks altogether, but it
comes at a cost of some latency. Basically you need to connect both ends of the
connection, the SSH server and SSH client, to the Tor network and let it handle
discovery and routing for you.
<center><img alt="Fancy diagram!"
src="http://agentdero.cachefly.net/unethicalblogger.com/images/tor-hidden-service.png"/></center>
1. Set up a Hidden Service [by following these instructions](https://www.torproject.org/docs/tor-hidden-service)
1. Store your `.onion` hostname on your "client" computer
1. Run Tor on your "client" computer
1. Add the following entry to you `~/.ssh/config`:
Host *.onion
ProxyCommand /usr/bin/nc -xlocalhost:9050 -X5 %h %p
1. Run SSH to your `.onion` hostname: `ssh username@shallots.onion`
1. Profit? Probably not, but who cares, you can now access all of your machines on
*any* network from *anywhere* around the globe!
---
It's worth noting again that latency will be sticking point, so I probably
wouldn't use this for developing in a remote `tmux` session, but I would use it
for using SFTP to transfer files to and from the server (for example).
Addtionally, [with the instructions
above](https://www.torproject.org/docs/tor-hidden-service) it's trivial to set
up hidden web servers, hidden jabber servers, etc.
Use responsibly!