~chetan/blog/

Working around macOS privacy controls

2022-01-14T23:27:59Z

Problem

You need to run a program (like icalBuddy) which requires access to protected macOS resources like your Calendar, Reminders, or Contacts. When you run it from the terminal, you are prompted as usual and grant access. Later, you try to run that program via some other process and nothing happens or you get some obtuse error.

In my case, I was trying to run icalBuddy to pull my calendar appointments into Obsidian, following Ben’s example. Worked great from the command line but not so much from within Obsidian. The problem, as it turns out, is that the privacy grant applies to the “top most app” which launches the process, in this case iTerm.app, and there’s no way to manually grant access directly to icalBuddy or Obsidian.

Solution

After struggling to find a working solution via lots and lots of github reports of similar problems, I finally found a working solution in this comment. I’m writing up here my full solution here as I’m sure I won’t be the last to run into this.

In simple terms, we create an Automator application which simply runs the program we need with whatever arguments we like. We can even pass extra arguments on the command line. The program is saved as a .app and when executed, the privacy prompts are opened and the grants assigned to our new .app.

1. Open /System/Applications/Automator.app and create a new Application:

2. Search for ‘Run Shell Script’ and drag it into the workflow area:

3. Change the pass input setting and add script:

Here’s the script for easier copying:

rm -f /tmp/getCalEvents.out
/usr/local/bin/icalBuddy -npn -nc -ps "/: /" -iep "datetime,title" \
    -po "datetime, title" -b "\n\n### " \
    -tf "%H%M" -ic "$1" \
    eventsToday 2>&1 >>/tmp/getCalEvents.out

4. Save the application somewhere, e.g., ~/bin/getCalEvents.app and run it once. You should get the privacy prompts as usual which results in the following access grant:

5. Finally, to integrate it into our application, we create another small wrapper which opens the app and returns the output from the tmp file:

#!/bin/bash
rm -f /tmp/getCalEvents.out
open --wait-apps $HOME/bin/getCalEvents.app --args Calendar
cat /tmp/getCalEvents.out

Save that script to, e.g., ~/bin/getCalEvents and call it from your application.

The New Foursquare

2014-08-06T18:17:21Z

Yeah, but do you have them all in a spreadsheet on google docs?

A hard core of Foursquare users love to checkin. I am one of them. I want to database my life, the places I go, and what I see and do there. I have checked in a total of 6,342 times since I started using Foursquare.

via The New Foursquare – AVC.

Goodnight. Sleep Clean. – NYTimes.com

2014-01-12T15:09:57Z

We’ve known for some time that sleep is essential for forming and consolidating memories and that it plays a central role in the formation of new neuronal connections and the pruning of old ones. But that hardly seems enough to risk death-by-leopard-in-the-night.

via Goodnight. Sleep Clean. – NYTimes.com.

DevOps: It’s the culture, stupid!

2014-02-23T18:55:24Z

Last week saw the return of DevOpsDays to New York and like many who attended, I went into day one without a solid definition for, or real understanding of, what “DevOps” actually means. Does it mean wearing both dev and ops hats? Is it a new team outside of the existing dev and ops teams? Is it a tool?

My first introduction to DevOps was probably via tools like Puppet and Chef, a new breed of configuration management tool. Though Puppet had already been around for quite a while and was steadily gaining in popularity, Chef arrived at around the same time that the DevOps movement began. So with all the overlapping blog posts on the two, it’s all too easy to take and automation tool like Chef and come up with a very literal (and very wrong) definition: Chef/Puppet = Automation Software = Infrastructure as Code = Development + Operations = DevOps! Got it! Well, not quite…

By the end of day two I think I finally had it sorted out. DevOps isn’t just about fancy tools or automation or “infrastructure as code” or anything of the sort; no, it’s really quite simple: it’s the culture, stupid!

In hindsight it’s very telling that there were nearly no scheduled talks about tools (Etsy’s Morgue being the lone exception, but I’ll come back to that) — this wasn’t a conference for learning about shiny new toys like Ansible or Salt, but instead for learning about DevOps culture.

John Willis probably describes it best with his acronym, CAMS: Culture, Automation, Measurement, Sharing. So measurement and automation facilitate a culture of collaboration and sharing between teams. Not just dev and ops, but also QA, product, and really just about every single group in the organization. So tools are important, but culture comes first. If you don’t get the culture right, the tools aren’t going to help. If your teams don’t communicate, the tools alone won’t save you. Remember, the goal is to ship better product, not to ship crap products more quickly.

(Kris Buytaert added lean to the mix to create CLAMS, which is great, but not absolutely necessary. Your org doesn’t have to be lean or agile in order to benefit from a DevOps culture, but DevOps is essential to efficiently do agile well.)

What Is DevOps Culture?

Engineering teams have traditionally been siloed in their own little worlds. The usual software development cycle goes something like this: developers work on a release for six months with no involvement from the operations team and when it’s ready to go into production, simply “throw it over the wall” to ops. So it’s no surprise that memes like this one hit all too close home:

DevOps is a reaction to the increasing tensions between various groups in the engineering organization; an attempt to call a cease fire and get them to work together, rather than continue their petty turf wars. There were repeated calls last week to break down those silos, collaborate and share more, though at the same time, while great in theory, there was very little in the way of “here’s how you do it,” only examples of how not to do it.

DevOps Culture Is Blameless Culture

One talk which I thought at least indirectly shed some light on the topic was Bethany Macri’s introduction to Morgue — Etsy’s new open source tool for collecting post-mortem information after a production failure. While the tool itself is intriguing, the most interesting part of the talk for me was the description of their “blameless” post-mortem process, which although I had seen John Allspaw talk about it a couple of years ago (blog post, video), now when presented within the larger DevOps context really started to click.

What is it?

Having a “blameless” Post-Mortem process means that engineers whose actions have contributed to an accident can give a detailed account of:

what actions they took at what time,

what effects they observed,

expectations they had,

assumptions they had made,

and their understanding of timeline of events as they occurred.

…and that they can give this detailed account without fear of punishment or retribution.

— via Blameless PostMortems and a Just Culture

What it boils down to is this: once you put all blame aside, you get an honest understanding of what happened and why. Willis alludes to the same idea in his anecdote for the definition of Sharing:

Jody Mulkey, the CIO at Shopzilla, told me that they get in the war room the developers and operations teams describe the problem as the enemy, not each other.

Blameless culture can also be applied to the engineering org as a whole, throughout the entire development lifecycle; not just during post-mortems. If you can get people across various teams to step back for a second and realize that everyone is working towards the same basic goal in the interests of the company, you can hopefully move the group in a more open and collaborative direction. Teams should be willing to accept input from other teams, even if unprompted. It’s not because your code sucks, it’s because we think it can be better, and if the result is better, we all win, right?

Some actionable advice

Etsy gives us some very actionable advice for running post-mortems in a blameless way, but how do we apply this to the rest of the organization? The best answer I’ve been able to come up with is in the form of more questions, asked by people wearing different hats in an organization:

Developers:

What can I do to help ops? Are there changes to the build process I can make so my app is easier to deploy? Easier to monitor? A more usable log format? What can we do in the app to mitigate the production incident we just had?

Making architecture changes? Need to add a queue? I should involve ops in the discussion.

What about a tighter feedback loop with QA?

QA:

What’s going on in production? Can I see logs? Metrics?

What’s the current build running right now? What’s the configuration?

Operations:

What information can I provide back to dev & qa from our various environments? Do they need access to logs or metrics?

Do we have clear, standard processes for the build/deploy/postmortem (support) phases?

Business:

What’s in production right now?

How often do we deploy? Are they features or fixes going out?

What’s the error rate?

How’s performance?

The common thread here is visibility into what’s going on, not in any one area, but everywhere. This is where automation and tooling plays a huge role because answering a lot of these questions without the right tools would be far too time consuming to have any chance of actually getting an answer, much less with any regularity.

Getting to the Bottom of HealthCare.gov’s Flop

2013-10-26T01:59:33Z

according to the research firm the Standish Group, 94 percent of large federal information technology projects over the past 10 years were unsuccessful — more than half were delayed, over budget, or didn’t meet user expectations, and 41.4 percent failed completely.

via Getting to the Bottom of HealthCare.gov’s Flop – NYTimes.com

S3 enabled disks?

2013-10-25T15:02:16Z

Sounds interesting, but no mention of OpenStack..

Yesterday Seagate introduced its Kinetic Open Storage Platform, and I’m simply blown away by it. It’s a truly elegant design, “as simple as possible, but no simpler”. The physical interconnect to the disk drive is now Ethernet. The interface is a simple key-value object oriented access scheme, implemented using Google Protocol Buffers. It supports key-based CRUD (create, read, update and delete); it also implements third-party transfers (“transfer the objects with keys X, Y and Z to the drive with IP address 1.2.3.4”). Configuration is based on DHCP, and everything can be authenticated and encrypted. The system supports a variety of key schemas to make it easy for various storage services to shard the data across multiple drives.

via Reinventing storage – Ethernet über alles! | Speaking of Clouds

A few feet from failure: why Verizon FiOS in New York is a sad joke

2013-10-11T03:27:11Z

This is insane.

When asked whether Verizon had met its contract obligations, the mayor’s office first asked The Verge what Verizon had said, then referred us to DOITT, which actually has the contract. DOITT referred us to the mayor’s office. When told that the mayor wasn’t commenting, DOITT suggested we speak with Verizon. When pressed, a spokesperson said, "We just don’t have anything to add here."

via A few feet from failure: why Verizon FiOS in New York is a sad joke | The Verge.

Terrorists win

2013-09-10T20:53:57Z

Game over.

The US government has betrayed the internet. We need to take it back

2013-09-06T00:22:04Z

We’ve had enough of lawyers and politicians not fully understanding technology; we need technologists at the table when we build tech policy.

via The US government has betrayed the internet. We need to take it back – Bruce Schneier.

N.S.A. Foils Much Internet Encryption

2013-09-05T23:25:43Z

Unlike some classified information that can be parceled out on a strict “need to know” basis, one document makes clear that with Bullrun, “there will be NO ‘need to know.’ ”

via N.S.A. Foils Much Internet Encryption – NYTimes.com.