I had just lost the RAID array that hosts my ESXi data store. I didn’t yet know that’s what had happened, but with some investigation, some embarrassment, and a bit of swearing, I would find out that an oversight on my part three years ago would lead to this happening. Continue reading How I Relearned the Consequences of Improper Monitoring
This past June when I was in North Carolina at Cisco’s CPOC lab, I learned that there was a chance–albeit a slim one, but a chance nonetheless–that a position would be opening up on the CPOC team in the fall. By that point I had been to CPOC three times and knew many of the engineers who worked there. I spoke to them to get their feedback, met with the newly-hired manager of the team, and just generally did all the things I thought I should be doing to take advantage of my time being face to face with these folks.
Then I flew home, subscribed to the “new jobs at Cisco mailing list” and waited.
And then, one day, it was posted: CPOC Technical Projects Systems Engineer. I immediately sent a message to my wife who responded as only she knows how:
Five short interviews later I was offered the job!
This brings me to change #1: As of this month (January), I am no longer a Systems Engineer with Cisco Systems Canada. I am now a Systems Engineer on the CPOC team reporting to a manager in the US.
Beyond the basic level of excitement I have about joining this team, I’m even more excited because I’m being hired for a role that isn’t quite the typical CPOC engineer role. My role is part of an initiative to help field sales teams (which up until today, would’ve included myself) sell various Cisco enterprise networking solutions, the first of which is Cisco Intelligent WAN. My role in this initiative is to provide technical expertise in helping field SEs conduct proof of value (POV) exercises with their customers through a combination of remote support and direct hands-on engagement at customer locations (as the situation warrants).
This is a new initiative at Cisco and involves a lot of people at different levels and in different parts of the company. I’m really excited to get back to a more technical, hands-on role, to feed my field experience back into this initiative to make it successful and valuable to the field teams, and to be involved in an initiative this big from the ground floor.
Now, you may have noticed that I said above that I am reporting to a manager in the US. Well, that’s because the CPOC lab is in RTP, North Carolina and that’s where the team is based.
That brings me to change #2: My wife and I (and the cats, can’t forget the cats 😼) will be moving from Calgary to the Raleigh/Durham area in the coming weeks.
Something else we did when I was at CPOC in June was to make sure my wife came down over the weekend so she could (finally!) see the area and understand why I loved going down there so much. It took her no time at all to get it. Now that we’re looking at moving, she understands the area a bit and has a feeling for what we’ll be stepping into.
She grew up and has lived her whole life in Calgary and I grew up not far from Calgary and have been here for about 15 years. We’re very excited for this change! We’re excited for a different climate, we’re excited to explore, and we’re excited to be close(r) to the ocean.
So there we go! Not a long list, but a very impactful one, for sure. Thank you to everyone for your support, small and large, over the past few and upcoming weeks! Bring on the BBQ!
I haven’t ever written a “year in review” type of post before. Sure, I do a post to summarize how the blog has done over the year but I’ve never done a personal look back. Last night–New Years Eve–I was thinking about everything that I was involved in during 2016 and I realized “I should write this down! I was involved in or a participant of some amazing things last year!”
So here we go. In an effort to show a more personal side and not just my geeky side, here is my personal 2016 year in review. Continue reading My Personal Look Back on 2016
Happy New Year! I just realized the other day that this blog turned 5 years old in 2016. It’s been a lot of fun and has paid me back for my time in terms of building my brand and being a means to explore and learn new topics. I have plans to put more focus on my writing in 2017 and reduce the friction between starting with a blank page and hitting that “Publish” button.
Anyways! Here’s a look back at 2016 on packetmischief.ca. Continue reading 2016 End of Year Blog Statistics
I recently decided it would be fun to upgrade the hardware on my main OpenBSD machine at home (because, you know, geek). These Intel NUC machines are pretty interesting. They are pretty powerful, support a decent amount of RAM, certain models support internal storage, and they are very low power and low noise. Perfect for a machine that is a shell/email/development box.
So… I’m a little embarrased to admit this but I only very recently found out that there are significant differences in how Virtual Port Channels (vPC) behave on the Nexus 5k vs the Nexus 7k when it comes to forming routing adjacencies over the vPC.
I’ve read the vPC Best Practice whitepaper and have often referred
others to it and also referred back to it myself from time to time. What I failed to realize is that I should’ve been taking the title of this paper more literally: it is 100% specific to the Nexus 7k. The behaviors the paper describes, particularly around the data plane loop prevention protections for packets crossing the vPC peer-link, are specific to the n7k and are not necessarily repeated on the n5k.
Whether it’s Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it’s almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here’s how to respond when that happens. Continue reading So Your Username and Password Where in a Data Dump. Now What?
There’s a lot of information on the intertoobs about getting ssh-agent “working” in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).
This article doesn’t cover or care about any of that.
This article is concerned with:
- Enabling ssh-agent in such a way that I can “ssh-add” in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
- Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
- To avoid having to put my keys in the Keychain (just a matter of preference).
At Cisco’s GSX conference at the start of FY17, the DevNet team made a programming scavenger hunt by posting daily challenges that required using things like containers, Cisco Shipped, Python, and RESTful APIs in Cisco software in order to solve puzzles. In order to submit an answer, the team created an API that contestants had to use (in effect creating another challenge that contestants had to solve).
This post contains the artifacts I created while solving some of the challenges.
I’m a big fan of Let’s Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let’s Encrypt doesn’t have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let’s Encrypt software client and the Let’s Encrypt web service.
Since the protocols that Let’s Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:
- Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
- Elevated privilege. At least one of the clients I saw required root permission. That’s a non starter.