RWX Consulting

I didn’t really start to poke around with nettop until about five years ago, when I got the opportunity to go and give a talk about the nascent iCloud Drive and all the assorted shenanigans that went with it. iCloud, it transpired, would throw all kinds of data up from your machine to all kinds of places in the cloud in a pretty fascinating and intelligent way, and nettop was absolutely vital in showing what went where. Still, right out of the box nettop isn’t particularly user friendly. What follows is an abbreviated primer on how I use nettop. It doesn’t hit on every option, but it’s a good swing at the essentials.

When I plug nettop into the Terminal.app I am immediately hit with something like this:

Still, it’s worth sticking with because it’s entire purpose in life is to report in exacting detail on every single bit of data that goes in and out of your computer; what ports are in use, what interface you’re using, where that data is going and how fast it’s moving at. Used properly, it’s astonishingly capable and useful.

Making it readable

c - collapse all

This is the first option I hit when firing nettop up. The way that the tool throws the expanded view at you by default is pretty frustrating, and this immediately knocks that down to something more like this:

Out of the box you can get this view by launching nettop with a -P option to show a per-process summary. In fact, I’ve added this to my .zprofile:

alias net='nettop -P'

x – toggle human readable numbers

By default nettop is pretty much ideally setup. It’ll give you columns for rx and tx, and let you know in bytes, kilobytes, megabytes, gigabytes and who knows? Probably terabytes and petabytes, too.

You can also hit j in nettop to get this handy menu allowing you to select, deselect and reorder menus, thus:

Being picky

You can use the lowercase -p option to specify a process number or name, thus:

nettop -p Dropbox

…will feed you this:

But better yet you can use this:

nettop -Pp Dropbox

…to get this:

If you don’t know the name of the process you want to isolate (or you just want to pick from a menu later on) then you can hit p while in the nettop screen to get something like this:

If you want to break nettop results down by interface then that’s doable too.

nettop -t wifi – wifi interfaces.

nettop -t wired – wired interfaces.

nettop -t loopback – loopback interfaces.

nettop -t external – the combination of all non-loopback interfaces.

Delta mode

By default nettop shows you the current running total of data in/out for each process, but if you want a more granular look at the current bandwidth in use then you can toggle delta mode by either hitting d in nettop or launching it with the appropriate flag:

nettop -d

This option is pretty useful if you’re looking at a process that’s resting somewhere in the gigabytes. If you’re at 1Mb then the jump to 2Mb goes pretty quickly in the default view, but if a process is sitting at 17GB then it could be a long, long time before it refreshes to 18GB. Jumping into delta mode is a fast way of figuring out if the process is still pushing data in/out, or if it’s stuck or has fallen apart into a thousand little pieces.

Handling data

It’s great that nettop stays open until you want to close it, but sometimes you just want to be able to go grab a cheesy, delicious slice of a few seconds’ worth of output and then get back to your regularly scheduled prompt. That’s where the -l flag comes in; just specify the number of seconds you want to snag and it’ll take the appropriate snapshot and log it to the screen for you. It’s good on its own, but also great with other flags.

Thus nettop -t wifi -t wired -P -l 1 gets you this:

As I said at the top, there’s a lot more to nettop than these basics, and poking around the manpage will doubtless reap you rich rewards…

I mean, look:

It’s very, very pretty and very, very powerful, and the screen is lovely. But what we all care about is the keyboard, and that’s entirely understandable because the circa 2015-2019 “butterfly” keyboards are just horrible. When they don’t break they still feel cheap and tappy and wretched, and as the primary sensory experience that people have with their laptops fixing that is kind of a big deal.

Still, as far as I can tell it’s not user-upgradeable, and I won’t be getting one. I understand the reasoning behind having everything soldered onto the board; it reduces costs and makes the machine faster, more reliable and more secure. It’s just that it’s a lot of money for something that I could buy, use, and then run out of space on.

I’m hoping (and betting on) Apple promulgating this new keyboard across the line. I’m a consultant, which means that most of the time I’m looking for portability over power, so a big, beautiful, heavy laptop isn’t my speed. Put that keyboard in a MacBook Air and I’ll be beating a path to the Apple Store with my hands full of Benjamins and my heart full of joy…

(February update – after a lot of soul-searching I went and bought one. And it’s amazing, and I’m profoundly glad that I didn’t wait for them to make a 13″ version. You forget how handy it is to have a huge screen until you sit down and reflect how bad your eyesight is and how much more you can get done with the extra screen real estate…)

Even though Apple has effectively killed off macOS Server (or at least gutted it and left it a smoking ruin of its former glory) there are still a lot of uses for a big box full of drives stuck in a closet for people to keep all their files on. While the assorted macOS Server services have largely gone away there are lots of good third-party services that have taken their place, and they are still things that need remote access, control, troubleshooting and tweaking. Which means you still need to be able to get to them quickly, fully, and securely.

Now, there’s a phrase that I trot out whenever I’m asked to stand up in front of a crowd in a hotel ballroom and talk about security. Helen Keller nailed when she said that “Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it.” It’s a quote that I think should be seared onto the back of the eyelids of anyone who works in IT; there’s no such thing as “security,” and when you’re talking about that as a concept what you’re really talking about it the Mitigation of Risk.

There are no absolutes; every security procedure is effectively just a barricade, and you have to assume that time and ingenuity by bad actors are going to bring it down. The best thing you can do is stay vigilant and use common sense and good tools. In this case, that means using encrypted keys to authenticate access to servers.

So, here’s the scoop:

I have a 2009 Mac Pro sitting under my desk that I’ve hotrodded within an inch of its life with NVMe storage, a beefy graphics card, USB-C 3.1 and an astonishing twelve (twelve!) core 3.47Ghz Xeon. It’s full of big, fast storage and it’s a beast for Xcode builds, and the best thing about it is that I cobbled the thing together out of a lot of boxes of scrap. It’s running Catalina 10.15.1 with the dosdude1 hack, and I’ve ported my old .profile file into the new, shiny, zsh-compliant .zprofile file. I like to throw a lot of aliases in there, and what I really wanted to do was have aliases I could bang into the keyboard that’d log me into one remote server in my basement and another that sits across town in my office. Additionally, there are a couple of client servers that we have maintenance contracts on that I like to keep an eye on a couple of times a day on the grounds that this is an excellent way to catch little things before they turn into big things.

So, in total there are four servers, each in a separate geographic location and each with their own frighteningly complex password structure. I don’t keep passwords and credentials on a sticky note on my desk because that’s breathtakingly irresponsible, and Terminal doesn’t want to play nice with stashing credentials in Keychain, so I needed a better way of quickly getting remote access from the Terminal, and this is where SSH came in.

Step 1: Make some SSH keys using ssh-keygen.

It’s worth looking through the man page for ssh-keygen, as there’s a lot of good stuff there. What we need to do is pretty straightforward, though; make a private/public key pair and specify the type of key you want to make with the -t flag. There are a few options, but I used rsa:

ssh-keygen -t rsa

Step 2: Answer some questions.

Hit return to save the key to the default location in your home folder. Enter a passphrase, because not password-protecting your keys is A Bad Idea. There are many reasons to password-protect this key but the biggest, scariest one is that in the very unlikely event that anyone got hold of your ~/.ssh/id_rsa file then they’d be able to use it to log in as root on any server set up to take use that for authentication. Password protecting it with a strong password is essential.

Step 3: Push the public key to the remote machine.

You’ll need to have SSH enabled for this on the remote machine, but chances are that if you’re doing this then you already enabled SSH several months ago. The following command goes and reads the public key you created in ~/.ssh, then pipes that to an ssh session that logs into the remote machine, creates the user-level .ssh directory and writes that key into the authorized_keys file:

cat ~/.ssh/id_rsa.pub | ssh user@remotelocation.server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 4: Tell your client machine to cache the keys.

The key pair you generated way back in step 1 essentially works on a session basis. If you restart your Mac then you’ll have to enter the password to get this all working again. Fortunately, you can pre-cache the keys by using the ssh-add command

Step 5: Embrace the laziness.

Fire up your command-line text editor of choice (I like pico/nano) and edit your .zprofile with something like the following:

alias server1="ssh adminuser@remoteserver1.net"

alias server2="ssh adminuser@serverinmybasement.com"

alias server3="ssh admin@ancientxserveintheoffice.net"

…you get the idea. Save the file, open a new shell, and all things being equal you’ll be able to use those new aliases to securely log in to the appropriate remote server without fat-fingering a lot of fiddly passwords.

Step 1: Pursue a career in Broadcast Journalism.

Admittedly this seems an odd place to begin your exciting journey into the world of professional IT consulting, but here’s the thing they don’t tell you about working in radio right out of college: it’s nothing but long hours and the pay is an amount so minuscule that your paycheck is almost a piece of collaborative fiction that you and your employer get to co-author and enjoy together. It’s the early 1990’s and you have your freshly-minted Anthropology degree and nobody is scouring the earth for twenty-two year olds who can talk about Ritual Gift Exchange in Papua, so an opportunity to get paid to talk on air to Londoners slogging their way around the M25 will sound like a nice change of pace. But don’t be fooled. You’re going to need a second job, and possibly a third.

Step 2: Get a second job (and possibly a third).

If you’re pondering a second job then I’d suggest starting out doing sales for a large UK-based Apple reseller with a complicated and bloody-minded returns policy. As the new kid you’ll be the poor sap who has to do ad-hoc tech support, but hopefully you’ll be like me and turn out to – against all common sense and expectations – be really rather good at it. So good, in fact, that you’ll end up with a third job peddling your skills around Central London, fixing things for fledgling Creative Agencies and falling asleep on the tube a lot. You should keep doing that though, because eventually you’ll end up doing the same job in Atlanta and then New York and then Seattle; happily being given Macs that don’t work and poking and prodding and repairing until they’re back to their original state.

Step 3: Get a better job (and get better at it).

You’re going to also want to go work in-house for a really, really cool design firm for about seven years – right around the time when Apple decided to scrap the old Classic MacOS and replace it with the BSD-enhanced Mac OS X. Pro tip: spend nights and weekends learning everything you can about Linux and BSD so that when Mac OS X finally gets released you’re in the minority who actually know how to work with the thing. (You’ll particularly enjoy the part where you realize that you can effectively automate about thirty percent of your workload, but I’d recommend you don’t talk about that too loudly).

Step 4: Be your own boss.

Quitting when that company gets sold twice in two years and then sort of falls apart like Mister Potato Head is going to be difficult, sure, but you’ll do okay if you strike out as an independent IT consultant specializing in Mac OS X client and Server configuration, installation and support in a huge design market. I’d recommend getting a lot of qualifications and certifications and being diligent about treating people with respect because that attitude seems to be something in woefully short supply with some of your competitors. After all, are you an attorney or an architect or an artist or surgeon? No, no you’re not, and people who fill their heads with doing complex and fascinating work shouldn’t be expected to spend a lot of time worrying about how their network works. You take care of that, and they’ll take care of building and making things and changing lives. It’s a fair trade. Oh, and get pretty good at running cable and chasing down network issues, too. Maybe hire a couple of people once things really get into high gear.

Step 5: Be your own boss (with fewer clouds).

Moving to Santa Barbara a few years later – which will involve selling your existing business and starting another one in a different state entirely from scratch – will be more difficult, but if you got this far you probably don’t shrink from challenges so you’ll work hard and (because you’re pretty firm about the whole treating-people-with-respect thing) it should work out… pretty great. You’ll be surprised that Santa Barbara – which seems at first inspection to be a touristy hotspot – has a thriving underbelly of commerce, biotech and industrial design. Did you know that the Lunar Rovers were designed and developed in Goleta? No? Well they were! Who knew? Not you, it seems.

Step 6: Do interesting work with interesting people.

You’ll want to partner with other people who are really great, too. I’d suggest doing that for about ten years, but eventually it’ll make sense to go and do your own thing, and you should go and do that because, well, you like it. After all, you get to swan up and down the Central Coast of California, meeting jewelry designers, restauranteurs, industrial designers, munitions researchers, professional chocolatiers, architects, veterinarians, graphic designers and architects and plastic surgeons and artists and people who build exquisitely, meticulously precision-crafted homes out of old delivery trucks.

So, that’s my advice. If you’d like to know more then drop me a line…

There was a time when I worked at a design firm. Actually, “design firm” is a misnomer bordering on a lie, bit it’s what I mostly told people when they asked where I worked. The reality was a more complex beast in that the place I went to between eight and fourteen hours a day was essentially a company that specialized in branding and identity work. Design was a big component of that, but when I’d tell people that I worked for a Branding-And-Identity firm they’d mostly get confused looks on their faces, so “Design Firm” it became.

I am not a designer. I have negligible taste, exactly zero education in that field, and a gross deficit in any kind of artistic endeavor. I can’t draw a straight line and enjoy a relationship with color themed on mutual ignorance and distrust, but branding and identity work is fascinating stuff, and I genuinely enjoyed seeing the work that was done to rebrand companies and products and the identity work that went along with that. There are a thousand little decisions and considerations that come into play, and it’s extraordinarily detailed and perceptually complex stuff that I am profoundly amazed by. Anyone can make a cute logo, but getting to the heart of the institution and making something that’s informed by the history and mission of that institution requires an ability to make artistic, aesthetic, and intuitive judgments that is beyond most people.

So, as I think I made clear above, I’m one of the majority who don’t have that ability. But I do recognize the value of coming up with something that isn’t just an odd collection of shapes and colors. My prior company – now in the capable hands of my former partner, was Command Prompt – a name that spoke to the kind of work we did in the Byzantine back-ends of servers and networks and that also had connotations of control and, well, timeliness. When I decided to fire up RWX Consulting I dipped into that same playbook.

In UNIX/Linux/macOS you can specify a set of permissions on a file or directory that dictate who can access that and what they can do. Read permissions allow you to view the resource, Write permissions allow you to make changes, and if the file or resource is a program or command then the Execute permission allows it to carry out it’s purpose. In short, Read-Write-Execute (or R-W-X) is the simplest way of saying that you have complete control over the thing you’re trying to work with.

That’s the story I wanted to tell with my company name; that the core purpose of what I do is to make it so that the people I work with can use their tools to the fullest. If that’s something that I can help you with, then drop me a line.

Today was Apple’s big Fall 2016 New Product Introduction and Pancake Breakfast Jamboree. As is traditional, we got treats and surprises that are no less welcome for being predictable and indicative of solid – if relatively unremarkable innovation.

The Watch got an update to make it officially waterproof (as opposed to being unofficially waterproof) and it got a GPS chip, a brighter screen, and a faster processor. Great. I love my Apple Watch dearly because it’s an extremely useful adjunct to my iPhone 6 – which on a very practical level is pretty much my default computer these days.

The iPhone 7 was introduced to a public that had known about it for weeks if not months in advance. To be honest, I didn’t pay a lot of attention to the specs, so I’m going to play it safe and say that we probably got new colors, a better camera, more powerful processor and more storage. Oh, and a design tweak so that it doesn’t look like the 6s.

Much ballyhoo has been made of the lack of a headphone jack, and I’d really hoped for some nice wireless headphones in the box. Nothing exorbitant; I have a few pairs of cheap Bluetooth headphones that are solid and dependable and have excellent audio quality and battery life. I think they cost me about $15 a pair on special at Amazon. That would have been great. Instead, we got these:

…for $159.

This in itself would be okay with me – after all, there are plenty of fancy bluetooth earbuds out there that are cheerfully in that price range, and these do feature some nice Siri integration and probably sound very nice indeed. Plus, there’s a charging carry case for them that could be very handy. No, what I’m peeved about is what’s missing; to whit – a wire connecting one to the other.

Let me explain. Apple thinks that everyone has a head like this:

Observe, if you will, the classical profile and proportional elegance of the noggin. This model has ears that can cheerfully accommodate the squished grape shape of the Airbuds/Apple Headphones, which are designed to fit snugly into your ear canal without any of those tacky silicone bits that other folks put on the outside. Where this all falls apart is when you’re dealing with people like me, who have enormous, ungainly ears. If I put Apple headphones into my ears I can get about four steps without the things falling out, and the only way I can get them to stay is by corkscrewing them so deep into my ear canal that I run the risk of some kind of internal cranial bleed.

Now, the falling-out-of-your-ear thing is a constant issue, but not really too bad considering that A) my super-cheap earphones have silicone tips which greatly ameliorate the problem and B) they’re joined by a wire so if one falls out then it’s not going to bounce away across the floor never to be seen again. Also, they cost $15. Meanwhile, the AirPods cost ten times as much, and if one of them falls out while I’m running/walking/mucking horses then I’m willing to bet that that’ll be $159 I won’t see again…

When it comes to loading and working with with third party APIs for your car, it kind of goes without saying that there are some caveats to be considered. For one thing, Tesla’s servers don’t take kindly to being spammed into oblivion if your computer decides to be a Chatty Cathy – if you’re sending a ton of requests on a constant basis then that’ll put a load on the servers, and they’ll probably respond by blocking your IP address. Secondly, you’re tinkering and tampering with a big, heavy, complicated and expensive machine, so consider what you’re doing and don’t decide that it’d be neat if you could heat your house by cranking the temperature up on the heater and leaving all the doors open or something equally asinine. You should exercise common sense regarding activities that might reduce the efficacy of the battery or other systems of the car.

Also remember that if you’re tinkering with the locks and remote starting the car then you’re also practically rolling out the red carpet for someone to steal your car. It’s perfectly possible for me to be in my office and remotely unlock the car and start it up so that any passerby could just get into the thing and drive it away. I don’t do that because that would be dumb, and I’d hope that nobody else would either.

With that out of the way, let’s get on to the good stuff.

You’ll need some kind of environment that’ll allow you to access the REST API. There are some ways of doing it in Python (which is very tempting), but the simplest method is to use a Javascript runtime like nodejs. That can be downloaded from nodejs.org.

Once that’s installed you’ll use the npm to install the Tesla tools, thus:

Sudo npm install -g teslams

Every time you query Tesla’s servers you need some kind of authorization. On the car (and on the official client) that’s handled with an oauth token, but the simplest way to handle authentication in this case is to just use the raw credentials. Yes, I know it’s a bad idea.

There are a bunch of commands built into the API and there’s good documentation out there about what it all does (see here for a good rundown). Each requires a -u username and a -p password flag. I don’t really want to be able to unlock the car or flash the lights, but it might be nice to have a simple way to see how much charge is in the thing, so I added this line to my .profile (credentials changed for obvious reasons):

alias charge='chargebar -u myemailaddress@emailaddress.com -p mysupersecretpassword'

Firing up Terminal and typing in “charge” gets me this:

…which is pretty neat. Now I just have to find the time to get that data periodically pulled down into a .json file so that I could throw it up on something like Panic’s StatusBoard…

I bought a Tesla Model S a couple of years ago, and have only recently started shutting up about it. This has been a herculean effort all things considered because it’s absolutely the most incredible piece of tech I’ve ever owned. Sure, the iPhone is pretty remarkable and you can make a lot of solid arguments about the value of the personal computer of your choice, but can those things make you giggle like a five year-old on a regular basis as you mash the accelerator down and feel gravity put its hand on your face and push? No.

Also, it’s pretty and well-designed and comfortable and roomy and… I’m doing it again.

As it’s a nice modern car with all the bells and whistles and connectivity that you could hope for, it’s also stuffed with gadgets and gizmos that report who you are, where you’re going and what you’re doing. Every time someone crashes their Tesla and claims that Autopilot made them do it Tesla invariably releases a statement an hour or two later to the effect that they looked at the data from the car and can definitively prove that the person had their hands on the wheel or just hit the accelerator instead of the brake. They’re able to do that because the car continuously records speed, location, altitude, temperature, what systems are engaged and disengaged and reports that all back to Tesla’s servers. It would be creepy if it wasn’t so neat.

And if it wasn’t open. You see, the really neat thing about that data is that it’s not just locked away for Tesla’s own digestion and enjoyment; while the official Tesla API is still under lock and key there are plenty of other ways to get at that data. There are a few excellent iOS apps that will give you access to the controls of your car (some allowing things like Summon, which will wake your car up and make it drive to you), and a couple of excellent third-party Mac apps that will allow you to look at and control some of the more elementary functions of your car, such as VisibleTesla.

What I’m after, however, is something faster and more command-line accessible, so I’m going to spend the next couple of posts running through what’s required to get quick access to some essential information and functions through the Terminal on OS X.

Of course, if I mess it up then it’s not like I’ll brick my car. At least, I really hope not…