802.1x Authentication on Wired Ethernet on Raspbian

Wed Mar 18 2015 12:11:00 GMT-0400 (EDT)

I pulled out my Raspberry Pi again to tinker with at work and needed to connect to the Internet to perform updates. Our wired network in the office uses 802.1X authentication for all connections. Here's how I was able to get it configured:

sudo vi /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=0
network={
    key_mgmt=IEEE8021X
    identity="alex.cline"
    password="supersecretpassword"
    eap=PEAP
    eapol_flags=0
    phase1="peaplabel=1"
    phase2="auth=MSCHAPV2"
}
sudo vi /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-driver wired
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
sudo wpa_supplicant -i eth0 -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired &
# Wait until you see a message stating that authentication was successful.
sudo dhclient -nw eth0
fg CTRL^c

Obviously, there are a ton of options for 802.1X authentication, but these are the ones that worked for me.


My Impressions of the 2015 Subaru WRX and STI

Thu Jan 16 2014 11:54:27 GMT-0500 (EST)

I've followed the developments of the new 2015 Subaru WRX and WRX STI since August 2013 when I was seriously considering purchasing a new car. At the time I was weighing the pros and cons of a 2014 BRZ vs a 2014 WRX or STI. After learning that the 2015 WRX would be debuted at the LA Auto Show, I decided to hold off until all the news was out about the new model.

Now that the new WRX and STI have both been revealed, there are a lot of mixed feelings surrounding the two models. From the lack of a hatch, to the CVT in the WRX, to the EJ25 in the STI many people are expressing a whole range of emotions about the revelations.

The WRX has an all new frame and body to distinguish it from the current and past Subaru Impreza line. Improvements have been made to the handling characteristics of the car to make it more responsive and to decrease body roll. The automatic now has a Continuously Variable Transmission which has several different sport modes. Lastly, the WRX has Subaru's FA20DIT engine which is the same as the one in the Forester XT.

The WRX STI has had a face-lift, but not much has changed mechanically from the outgoing model. The steering ratio has been lowered to 13:1 which means faster, more responsive cornering. The suspension has been tuned to further increase handling and decrease body roll. The STI keeps the EJ257 engine from the 2014 model as well as the manual transmission and Driver Controlled Center Differential components.

I think it's safe to say that there are a lot of people who are disappointed about the reveal of these two cars -- there is something for everyone to hate. In reality, there are very good reasons for what has been changed, though I think Subaru of America has been unsuccessful in marketing the changes correctly. What follows are my opinions about why Subaru revealed the cars they revealed.


The New Body Style: Opinions of the new body style are subjective just like any car's styling. There will always be people saying a car looks ugly or that it looks too much like another car. (gasp! Cars kinda look like other cars!) When looking at the styling of the WRX, you can definitely see similarities with the Impreza, but enough differences to qualify them as distinct cars. This is likely because panelling is cheaper when two cars share similarly sized and shaped pieces.

Sedan-Only Body: A very vocal group of people have expressed disdain over the the new models only being available as a sedan. Subaru's explanation is that after development resources were divided up between the new WRX/STI, the Levorg, the Hybrid XV and the fully electric Tribeca replacement, there wasn't enough to work on a WRX/STI hatch. Many people have attributed this to Subaru being cheap and not wanting to spend money, but I think this is a calculated investment in gradual improvement of the platform. They're working on creating a solid, well-performing base with the sedan and will release a WRX hatch in a few years.

The Upgraded Suspension: A common consensus is that the 2014 WRX and STI suffered from a poor factory suspension. Subaru improved the suspension and handling in the new model to directly address this shortfall. I don't think anyone is questioning the value-add of the improvements made.

The FA20DIT: The FA20 is the engine released in the BRZ and is the same turbocharged engine in the FXT. This new engine has proven to be a high quality platform to build upon and Subaru is smart to release it in the WRX.

Direct Injection Turbocharged(DIT) engines do have an issue with carbon build-up in the intake valves. Whether Subaru has a fix for this is yet to be seen -- they may be working on this before releasing the engine (as a 2.5L) into the STI.

The EJ25: This engine is Subaru's bread and butter. With 25 years of development behind it, it is a known powerhouse that has a huge fanbase and lots of aftermarket support. People who buy an STI are likely to want to install aftermarket parts and if Subaru used the new FA or FB engines, they would be waiting for shops to R&D, test and release parts.

The EJ25 engine has historically had issues with leaky head gaskets and ringland failures. It is yet to be seen if Subaru has fixed these issues in the new STI or if they're relying on performance enthusiasts to tune safely.

CVT: This is really a no-brainer for Subaru. Their lowest-end Legacy has a traditional automatic gearbox and it's not well received compared to the CVT in other trim levels. Putting a traditional automatic in the WRX wouldn't be a smart decision since the CVT is a known quantity. People who want an automatic WRX will have good fun with the CVT.

The Interior: No one is really complaining about the new interiors for these cars. Subarus are not known for their luxurious, padded interiors and the new ones are a great improvement over the outgoing models. Impressions of the design of the seats and the amenities are subjective as well.


It's important to realize that the 2015 WRX and 2015 STI are gradual improvements to the line, not drastic overhauls of the outgoing model year. Each improves on the 2014 models in their own way for their own reasons.

The 2015 WRX STI is the loved powerhouse that it has always been. If the powertrain of the car aren't broke, Subaru doesn't have to fix it. Many people were hoping for a new engine or gearbox, but that's not what this car is -- it's a nicer looking body for the beast within. Subaru will sell a lot of STIs to people who like the new body and want to tune -- they've stated that existing aftermarket parts will work in the new car. The Launch Edition is meant for tuning enthusiasts who want the rally heritage with the new styling.

The 2015 WRX has received more updates, but it does so because it's the testing platform for the flagship STI. The new FA engine is in the FXT, but it hasn't had long-term high-performance testing that can be generated by a WRX. The engine also doesn't have the catalog of aftermarket performance parts required by tuning enthusiasts. In the next two years, aftermarket manufacturers will be working hard to create parts for the new platform which will eventually end up in the STI.

Subaru of America has a tough sell -- they need to distinguish the 2015 WRX and STI from each other as well as the outgoing 2014 models. This becomes problematic when you need to make every press release and piece of marketing material say 'NEW NEW NEW!' without giving away your long term plans and turning away thrifty buyers. The Peanut Gallery should soon realize that improvements to both cars are incremental in their own ways.

If you want to get a rally-bred sports car with an engine with a 25 year track record, and all the new amenities, get the STI. Tune the car to your heart's content with all the existing performance parts available for the platform.

If you want to get a great, sporty daily driver with good performance and fuel economy, get the WRX. You'll be driving the engine that is the next evolution of the Boxer.

I'm getting a WRX.


Thanks for the Tunes TurnTable.fm!

Mon Dec 02 2013 07:29:56 GMT-0500 (EST)

TurnTable.fm Trance Out!

Today is the last day for TurnTable.fm -- the audience-powered music streaming service is shutting down today.

The TurnTable team announced the end of the tt.fm era two weeks ago in a blog post. The TurnTable team is going to focus on the TurnTable Live service.

I don't think I'll be attending any TurnTable Live events. I don't really attend many in-person concerts and I think doing live shows over the Internet won't be as popular as TurnTable.fm was.

You can get a t-shirt commemorating the tt.fm service here: https://cottonbureau.com/products/turntablefm


Node.js Proxying Requests Using Express

Thu Oct 10 2013 08:32:56 GMT-0400 (EDT)

I'm constantly amazed at how powerful node.js is -- here's an example of the power behind streams.

I'm writing a web-app using the sails.js MVC framework. Sails is built on express for providing HTTP responses to requests. Part of the application will request an image from a server and serve it to the user (essentially acting as a proxy).

Here's the the code needed to get this to work:

var request = require('request');

module.exports = {
  showImage: function(req, res){
    request('http://example.com/image.png').pipe(res);
  }
};

An example of the simplicity of streams for data handling.


Long Live Lime!

Sat Sep 21 2013 10:10:53 GMT-0400 (EDT)

I found a box of original (the real kind) at a K-Mart. One of the last ones in the world!

20130921-135652.jpg


Setting up the mysql_ Plugin in Munin

Fri Jul 12 2013 09:36:38 GMT-0400 (EDT)

After spending a few days trying to get the mysql_ plugin working in my munin installation, I've decided to write up the process. It include some pointers about troubleshooting and diagnosing problems with the plugin.

Once you have munin and mysql working:

# Save this to /etc/munin/plugin-conf.d/mysql_
[mysql_*]
  env.mysqlconnection DBI:mysql:mysql;host=127.0.0.1;port=3306
  env.mysqluser munin
  env.mysqlpassword 5uperS3cr3tPassw0rd

Next, create a new user in mysql:

mysql> CREATE USER munin@127.0.0.1 IDENTIFIED BY '5uperS3cr3tPassw0rd';
mysql> GRANT SUPER,PROCESS ON *.* TO munin@127.0.0.1;
mysql> GRANT SELECT ON mysql.* TO munin@127.0.0.1;
mysql> FLUSH PRIVILEGES;

You may need to install some perl dependencies:

yum install -y perl-Cache-Cache

Now, test that your new user is able to connect to the db thorough munin. You should not see any mysql errors printed here.

munin-node-configure --suggest 2>&1 | grep mysql

Next, install the suggested mysql plugins:

(munin-node-configure --shell 2>&1 | grep mysql | /bin/bash); service munin-node restart

Finally, you can confirm that the plugin is setup and working properly by testing it by running munin-run and telnet:

munin-run mysql_connections
  max_connections.value 151
  Max_used_connections.value 3
  Aborted_clients.value 2
  Aborted_connects.value 1
  Threads_connected.value 3
  Connections.value 36
telnet localhost 4949
  Trying 1.2.3.4...
  Connected to localhost.
  Escape character is '^]'.
  # munin node at localhost
  fetch mysql_connections
  max_connections.value 151
  Max_used_connections.value 3
  Aborted_clients.value 2
  Aborted_connects.value 1
  Threads_connected.value 3
  Connections.value 38
  .
  quit
  Connection closed by foreign host.

I was getting errors mentioning "# Bad exit" while using telnet; running munin-run showed the actual error messages.


Automatically Adding Keys to Systems without Automatic Key Management

Wed Jul 03 2013 10:31:29 GMT-0400 (EDT)

I've been using this snippet on some of my systems for a while. It's useful for when I want to automatically have ssh-agent started and the user's keys loaded when I login. When this runs in .bash_profile, I don't have to do the ssh-agent /bin/bash && ssh-add dance.

TZ='America/New_York'; export TZ

SSH_ENV="$HOME/.ssh/environment"

function start_agent {
     echo "Initialising new SSH agent..."
     /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
     echo succeeded
     chmod 600 "${SSH_ENV}"
     . "${SSH_ENV}" > /dev/null
     /usr/bin/ssh-add;
}

# Source SSH settings, if applicable

if [ -f "${SSH_ENV}" ]; then
     . "${SSH_ENV}" > /dev/null
     #ps ${SSH_AGENT_PID} doesn't work under cywgin
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
         start_agent;
     }
else
     start_agent;
fi

This snippet was borrowed from Mark Hershberger's blog.


Convert a UPC to an Amazon Standard Identification Number (ASIN)

Thu Jun 27 2013 19:57:15 GMT-0400 (EDT)

I've been working on a project that needed the ability to convert a UPC to an Amazon Standard Identification Number, or ASIN. There don't seem to be any simple services to do this -- I needed an Amazon Associates account just to make the request to look it up.

I have created UPCtoASIN.com. It's a simple web service for converting a 12-digit UPC (or 13-digit EAN) to an ASIN number.

For example, the ASIN for the UPC 012569828490 is B000I5XOVY. This can be looked up using this URL: http://upctoasin.com/012569828490

It's written in Node.js and the source code is available on GitHub.


Dirtree Puppet Module Released!

Tue May 14 2013 08:49:31 GMT-0400 (EDT)

My second Puppet module has just been released on the Forge. It's called dirtree and you can download it from the Puppet Forge project page or check out the source code in the repo on GitHub.

The reason I created this module was so I could ensure an entire directory path was created by puppet. For example, if I wanted to create the folder /opt/foobar/fizzbuzz, I'd have to use the following Puppet manifest:

file { ['/opt', '/opt/foobar', '/opt/foobar/fizzbuzz']:
  ensure => present,
}

If any of those directories were declared in another manifest, it would throw an error about the conflict. With the dirtree module I can ensure the entire tree is created like so:

$dirtree = dirtree('/opt/foobar/fizzbuzz')
ensure_resource('file', $dirtree, {'ensure' => 'present'})

As of the 4.1.0 release of puppetlabs-stdlib, ensure_resource accepts an array of resources and will check to see if they already exist and create them if they don't. This will be a really great improvement for the DRYness of manifests that have to create directory structures.

Feel free to fork the repo on GitHub and contribute back to the project!


Purging Exported Resources for Inactive Nodes in Puppet

Tue Apr 30 2013 06:31:06 GMT-0400 (EDT)

Puppet's Exported Resources are a wonderful feature of the tool. In my environment, I'm using them to collect Munin configuration files for the Munin master server.

Each munin client gets the class munin-node with the following partial configuration:

class munin_node {
  @@file { "/etc/munin/munin.conf.d/${::fqdn}.node":
    content => "[Example.com;${::fqdn}]
  address ${::ipaddress}
  use_node_name yes",
    tag     => 'munin-node',
  }
}

Then, the munin master node collects all the munin configuration files.

node 'munin-master' {
  File <<| tag == 'munin-node' |>>
}

This is a really useful feature of puppet and it makes adding new nodes to Munin incredibly easy. It also makes it difficult to remove nodes from Munin that may have been shutdown permanently.

When I retire a system, I don't want it to show up in Munin anymore, but because Puppet will collect resources for all the nodes its ever known about even if they've stopped reporting, removing the file by hand will cause it to be recreated by puppet. There is an easy fix for this though -- deactivating and cleaning the node on the puppet master.

puppet node deactivate someoldnode.example.com
puppet node clean someoldnode.example.com
rm /etc/munin/munin.conf.d/someoldnode.example.com.node

The first two commands will effectively retire an old node from Puppet. The first will deactivate it (and stop the master from collecting resources for it) and the second will clean its certificate. The last one is obviously to remove the file created by the collected exported resource.