What’s the sane way to make sure that you’re not aggressively stupid with Munki changes? How do you maintain an orchestra of munki servers without relying upon a source control scheme?
This Week’s Newsletter has a doozy:
Conferences also show you exactly how much work you have left to do. And that’s okay, work isn’t a bad thing. It just sometimes puts that workload in stark relief and that can feel a little bad sometimes. Technical Debt is difficult to overcome because it requires a change in understanding – and often times training – but it serves to make your organization stronger.
Below are the slides for my 2016 Talk at MacDevOps on Securing Munki. The talk was a good way to revisit what I’ve done with Munki in a Box and discuss some of the maybe not-so-great choices that were made along the way to get to where we are now with the security branch.
The talk focuses on the nature of the munki transaction, and where your deployment system can be vulnerable to attacks from casual interference, dedicated individuals with a grudge or a motive, or larger actors. There is also some advice about how to mitigate the problems that are presented by the architecture.
I’m not a fulltime security anything, but I’ve learned a lot in the last year by doing things that maybe aren’t advisable any longer. So, to anyone who used MIAB before 1.5.0 beta 2, there’s some work you should do to secure your repository if you meet certain use cases, and I strongly recommend that you adopt SSL encapsulation of the munki transaction, and the use of HTTP Basic Auth to secure your repository against prying eyes.
I’ll be making some changes to MIAB over the summer to automate the creation of a CA and enrollment of device certificates using the micromdm scep library and a web server that actually isn’t part of Server.app (likely to be the Go-based Caddy server as described by Viktor in a great blog post)
We got the chance recently to sit down with Arek Dreyer, author of so, so many books, in time for the release of his new 3rd Edition of Managing Apple Devices. We talked about WWDC, writing books like Managing Apple Devices, as well as nearly getting arrested in a Chicago Server Room, and the first apps we bought. Co-hosts Charles Edge and Emily Kausalik were awesome, as was our mixing engineer Aaron Lippincott, who made us sound amazing.
I suppose we could’ve made that “tails” and had a good laugh about how cute the puppy was. Episode 5 saw us talking with Andrew Seago of MacBrained, as well as Miles Leacy of Walmart. We had some audio drama, but we learned a lot in the process. Listen in for discussions of WWDC’s rumor mill, single sign-on as it stands today and in the future, and a whole segment on the importance of communities like the awesome MacBrained.
Knowledge is tricky. Some kinds you can only acquire through experience, dug deep in the trenches amid the fray. Other kinds come easily in books and training manuals and classes held in labs. No matter how you learn, there are good resources in print for the Mac Admin, be they books and manuals, blogs and journals, magazines and other news media. This library, catalogued below, is far from canonical, but it does have the resources that I consider to be the best of breed.
If you think I’ve missed the mark for some reason, or you think I’m missing something great, drop me an email and we can figure it all out.
Please note: Some of these may be in your local library’s collection, either digitally or physically, and libraries remain great technical resources. Use yours!
- Enterprise Mac Administrator’s Guide – Charles Edge & William Smith – Paperback & Kindle – Apress Digital Edition available
- Enterprise Mac Security: Mac OS X – Charles Edge & Daniel O’Donnell – Paperback & Kindle – Apress Digital Edition available
- Managing Apple Devices, 3rd Edition [Pre-order] – Arek Dreyer & Adam Karneboge – Paperback (2nd Edition (Dreyer & White) is out, covers 10.10 & iOS 8)
- OS X Server 5.0 Essentials – Arek Dreyer & Ben Greisler – Paperback & Kindle
- OS X Support Essentials 10.11 – Kevin White & Gordon Davisson – Paperback & Kindle
- Learning UNIX for OS X – Dave Taylor – Paperback & Kindle – O’Reilly Safari
- Mac OS X and iOS Internals – Jonathan Levin – Paperback & Kindle
- Mac OS X Advanced Systems Adminstration – Edward Marczak – Paperback & Kindle
- Essential Systems Administration – Æleen Frisch – Paperback & Kindle – O’Reilly Safari
- UNIX Power Tools – Peek, O’Reilly & Loukides – Paperback & Kindle – O’Reilly Safari
- Tubes: A Journey to the Center of the Internet – Andrew Blum – Paperback, Hardback & Kindle
Sometimes, you just need to get up-to-speed quickly, or need a good example of how someone else explains a product or one of its features.
- Take Control of Slack Basics – Glenn Fleishman – PDF, Mobi, ePub
- Take Control of Slack Admin – Glenn Fleishman – PDF, Mobi, ePub
- Take Control of OS X Server – Charles Edge – PDF, Mobi, ePub
- Take Control of iCloud – Joe Kissel – PDF, Mobi, ePub
- Photos for Mac: A Take Control Crash Course – Jason Snell – PDF, Mobi, ePub
Networking & Wireless
- CWNA Deluxe Study Guide – David Coleman & David Westcott – Hardcover
- CWTS Official Study Guide – Robert Bartz – Hardcover & Kindle
- Cisco Routers for the Desperate
- Network Fundamentals: CCNA Exploration Companion Guide – Dye, McDonald & Rufi – Hardcover, Paperback & Kindle
- 802.11ac A Survival Guide – Matthew Gast – Paperback & Kindle – O’Reilly Safari
Network Warrior – Gary Donahue – Paperback & Kindle – O’Reilly Safari
Learning the bash Shell – Cameron Newham – Paperback & Kindle – O’Reilly Safari
- Learning Python – Mark Lutz – Paperback & Kindle – O’Reilly Safari
- Learning Python the Hard Way – Online Course with Downloads
- Swift Programming: The Big Nerd Ranch Guide – Matthew Mathias & John Gallagher – Paperback & Kindle
- OS X and iOS Kernel Programming – Ole Henry Halvorsen & Douglas Clarke – Paperback & Kindle – Apress Digital Edition
- Mac OS X for Unix Geeks – Ernest Rothman – Paperback & Kindle
Mac Admin Blogs
- Rich Trouton – Der Flounder
- Greg Neagle – Managing OS X
- Nick McSpadden – OS X Dominion
- Pepijn Bruienne – Enterprise Mac
- Charles Edge – Krypted
- Ben Toms – MacMule
- Graham Gilbert
- John Kitzmiller
- Various Authors – Amsys
- Flying Toasters
- Scripting OS X
Mac Admin Podcasts
This is part of Techno Bits Vol. 71. If you’d like to read more like it in your email every week, sign up
There’s been a lot of talk lately about Apple’s competitive advantage, and how we’re standing at some sort of mobile precipice that might find Apple on the receiving end of the same treatment Apple gave to RIM a while back. It’s good to stop and think about these kinds of things, and that’s important.
But in this case, I don’t see the case being adequately made.
I think we are at a technological inflection point, but in a lot of cases, it’s Apple pushing the marketplace forward, not sitting still. The first of these cases is Apple Pay. The state of payment structures in the US is antiquated and terrible. We pay with plastic cards with magnetic stripes that are easily duplicated, a technology that has been subject to fraud since before I left college more than 15 years ago.
Europe banded together years ago with Visa and Mastercard to create the EMV Chip-and-PIN system to build better cards. I’ve had one in my American Express since 2001 or so. But only within the last year have I ever used it to make a payment. Why? Because no one’s incentivized a movement away from the stripe payment system. This past year, a change in liability for fraud started to push more contactless and chip reader terminals to the forefront.
I’ve spent the past three months on a project replacing all of the old stripe readers with new chip and contactless systems for a client with a large venue. We’re now four big events in, and I can tell you more about the problems in the payment space than I thought I’d ever be able to. The biggest problem with chip card transactions? Time and User Awareness. If you get a user that’s never used their chip card before, even with the best terminals on the market today, you’re adding 30 to 60 seconds of frustration and delay to the transaction. And that’s with the best terminals on the market today!
What about the mom and pop shop on the corner that has no control over that experience?
It’s pretty bad.
Even with the shiniest new terminals, they’re still not the bulletproof credit card swipers that we’re used to, the ones that rarely if ever malfunction, because their software was treated like the software to keep astronauts alive: it can only fail safe, it can only be changed rarely. It was ossified technology for good reason: it worked, and it worked well, and it worked for people who didn’t want or need to understand every moving part behind it. The credit card industry had made it simple by taking on the technical requirements and adhering to them in an act of ironclad religious devotion that you might find admirable in a cargo cult.
Sure, contactless is a better experience, thanks to Apple Pay, because they put a lot of thought into the user experience, but it’s still a vanishingly small percentage of commerce. Apple can do better here by evangelizing the ease of use to both commercial institutions and users alike. This needs to be better if we’re going to complete that changeover. In addition, these transaction times need to get better and not worse.
But, if you want to see what the future looks like for payments, read what happened when a Buzzfeed writer lived only off contactless and bitcoin for a period of time.
Let’s slide onwards here to another advantage that Apple has: research and engagement with the scientific community. Last year, they released ResearchKit, designed to provide the research community with necessary and almost futuristic backends for collecting complex data from layman users. It was a huge project, to the point it was released in a keynote by now-COO Jeff Williams last year.
Better still, Apple both open-sourced ResearchKit, and then released CareKit to help medical environments make apps that can persist outside of the care environment.
Apple has an unquestionable commitment to medical research with iOS devices as tools to help gather data.
Meanwhile, Android has ScienceJournal which looks like a tinker toy.
So, I don’t think that Apple is nearly as poised to fall as quickly as RIM fell, especially not with their massive cash reserves and revenues. But it’s important to stay agile, and I expect Apple won’t disappoint. Even if I don’t want a Siri bridge for home, it would make sense to build it elsewhere if only to help mollify concern they’re missing a crucial interface.
So, it’s not all bad. Even if the markets make it seem that way. Apple is best when they have to compete for their lives. I look forward to seeing them hungry and behind. It’s when we get the best work from them.
Links to Read
- Blacktip: We’re moving from Google to Office 365. [Blacktip IT]
- Windows 7 (Sort of) has a Service Pack 2 [Ars Technica]
- A 4K Display that can actually be 4 different HD displays. I want this SO HARD [The Verge]
- A real virus affects Ubiquiti AirMax Antennas [UBNT Community Forums]
- Collecting 802.1X data using Python [Mike Lynn’s Github]
- Dealing with Documentation Debt [18F]
While I was in London for MacADUK, Charles Edge and I started talking about adding a Podcast to the MacAdmins community, and as it happened, we weren’t the only ones who wanted to start something new. Adam Codega from Upserve, Dr. Emily Kausalik, Jason Miller from Thumbtack, Marcus Ransom from RMIT, Pepijn Bruienne from University of Michigan, and John Kitzmiller from Fastly all wanted to chip in, and we’re going to rotate through hosts on the show as we go.
First episode is now posted, and it’s Adam, Dr. Emily, Charles and myself, talking a bit about iOS 9.3, Apple’s Ethernet Drivers, and Google SSO, before we sat down for an interview with the Organizing Committee of the Penn State University Mac Admins conference.
Come on out and listen!
I’ve been fascinated by the Eero for some time, mostly because I love the idea of dirt-simple wireless mesh access points. That’s a challenging space to operate in, and if it’s done well, it has the potential to do a lot of good in putting crappy wireless repeaters out of the marketplace before they convince someone to do impossible things with Wi-Fi.
Recently, though, I’d read some odd things about them, and I wanted to see if I understood the whole situation. First up was something specifically I’d read: they use 40 MHz channel widths in the 2.4 GHz spectrum. My primary experience with devices that work like that has been finding them in use at various corporate sites where they’re just blotting out entire swaths of a very crowded spectrum. It lead to this slide’s existence:
It’s safe to say that I feel strongly about this.
Weirder, though, the Eero doesn’t move from its channel position at channel 1 no matter the situation. While 2.4GHz does only have three channels in 2.4 that are unencumbered by adjacent channel interference, it seems odd to pick one and lock right down to it. I asked the CEO of Eero about this on Twitter, and he came back with evidence: “Across now thousands of networks, the best channel has been 1.” In addition, while it will default to 40 MHz widths in 2.4 GHz, if things are crowded, it will dial it back to a standard 20 MHz width.
Fascinating, right? Wait ’til you see what else they’re doing.
Yes, that graphic is right. They are using 802.11ac in the 2.4GHz range! HOW?!
Well, for one, Eero is not Wi-Fi Alliance certified, which means their gear isn’t necessarily adhering to every part of the 802.11 set of standards as designed and approved by the IEEE. That means that they can choose to do more innovative things with their units, at the cost of a pretty and recognizable badge on their box.
Now, why’s this all matter at all? The culmination of our Wi-Fi deck at Cascadia was the definition of transmit speeds, which depend on the guard interval, the encoding and modulation scheme, the channel width, and the number of spatial streams available. Like a mathematical equation, these group together to give us a decent result. Wi-Fi works by encoding signals through amplitude modulation and phase-shift keying, which combine to put the wave in a specific position in a given polar chart, like so:
Depending on how the amplitude and phase are shifted together, you can line up each symbol in one of 64 positions, which a fourier transform can quickly calculate. That’s how Wi-Fi works. But until 802.11ac – which is a 5GHz technology by specification – 64-position Quadrature Amplitude Modulation was the limit. With 802.11ac, when conditions are right, everything upshifts to 256-position QAM, and the chart gets a whole lot denser:
Sure enough: 2 spatial streams, with a short guard interval, in a 40MHz channel in the 2.4 GHz band, at 256QAM 5/6, gets you a 400Mbps Tx Rate, and that’s what Wi-Fi Explorer sees in this test provided by a friend-of-a-friend.
It’s a pretty neat trick to make 802.11ac work in the 2.4 band, especially when you think they’re flouting the standards to prove a point. I’m interested to see a little more about how these handle the backhaul between units, but I’m not sure I want to spend $500 to find out more.