Category Archives: General

Transporter Desktop on High Sierra

If anyone out there is still using the File Transporter system, there’s a compatibility issue with High Sierra. The last version available via the official update channel is 4.2.12, but there’s a patch for version 4.2.18 available from their support site. This restores access to the Transporter Library.

This issue reminded me that support for this system ended in September, 2017, so I’m on borrowed time. I just upgraded to the 2TB storage plan on iCloud, so I may test migrating the data I have on the File Transporter into iCloud… but that seems risky.

Python 2.7 via Homebrew

I missed the memo, but back in January Homebrew announced that as of version 1.5, python would be upgraded to use Python 3.x. This change went live on March 1, and I noticed it over the weekend while tinkering with Homebridge.

While I was rebuilding Homebridge with the latest version of Node.js, I kept banging into node-gyp errors having to do with using Python 3.x. I’m not alone, though there is already a pull request to fix this issue.

For the time being, I’ve made two changes to please node-gyp:

  1. Forced a link of the new python@2 keg1:

    brew link python@2 -f

  2. Added the following to my ~/.bash_profile, so that python will point at python2:

    export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"

I think I’ll revert the second change once the node-gyp issue is resolved, to begin forcing myself to use Python 3.x.

EditorConfig

Yesterday, I lamented the limitations of BBEdit’s Dropbox sync:

I wish there was a way to sync language-specific settings for BBEdit via Dropbox.

Specifically, I wanted to sync my soft-wrap settings for Markdown files. My main need for this is in editing the text files that drive this blog1. Yes, this is a trivial problem; it’s one checkbox in BBEdit’s Preferences Pane. It would be easy to recreate on both of my computers. It would be easier still if the preference would sync.

@daiwei replied on Micro.blog with an interesting idea:

If you know where the settings you want to synchronise are stored, simply copy that file(s) to where you want them on Dropbox, and symlink it/them?

I haven’t tried this, and I’m afraid of what might happen if I were to have BBEdit open on both computers at the same time. Maybe I’d just end up with conflicted copy files from Dropbox, but BBEdit’s release notes specifically call this out as unsupported:

The system does not support relocation of the core preferences data file (~/Library/Preferences/com.barebones.bbedit.plist), so you won’t be able to synchronize preference settings.

The BBEdit support team replied to me on Twitter, and offered a solution I was completely unfamiliar with:

Apparently, BBEdit natively supports EditorConfig files. EditorConfig files are used to enforce consistent configurations across editors for a given project, and they’re fairly widely supported. While soft-wrap settings aren’t part of the core properties, BBEdit has defined BBEdit-specific keys, including x-soft-wrap-text, x-soft-wrap-mode, and x-soft-wrap-limit.

Based on this, I created an .editorconfig file in the root directory of the files for this blog, that only contains one key:

# EditorConfig is awesome: http://EditorConfig.org

# top-most EditorConfig file
root = true

# Soft-wrap every markdown file (in BBEdit only)
[*.md]
x-soft-wrap-text: 1

Now, if I ever forget to enable soft-wrap as a language-specific setting in BBEdit on a new machine, this file will override the global setting and enable soft-wrapping. I’ll still have to deal with this for files in other directories, but this will cover 90% of my use cases.

  1. I’m still publishing this site using Dr. Drang’s WP-MD tools. ↩

Thoughts on Publishing a Workflow

I published a Workflow.app Workflow a while back, and I was surprised to learn that, before the app is ‘accepted’ for publication, the Workflow team may edit your workflow.

The Workflow team confirmed this on Twitter:

This has been on my mind for a while, and my feelings are still conflicted:

  • They didn’t tell me that they made changes, but the workflow is still attributed to me when you access it. This feels like a misrepresentation of my work.
  • They actually improved the workflow slightly, and I’ve benefited from these improvements.

While I’m glad they improved it, I think they should have given me the right of refusal regarding accepting their changes, or at a minimum notified me that they were making changes. In this case, I would have accepted them, but I’m not sure that I always would.

Leaving Crashplan

Back in August, Crashplan announced they were leaving the consumer business. This is disappointing to me because I’ve had a family plan subscription for five years. Their service bailed me out when we had an apartment fire that destroyed our computers.

Michael Tsai has a great roundup of the community’s response, and the consensus opinion seems to be that BackBlaze is the best option for most people. For me, though, BackBlaze would be a substantial increase in price, since they don’t offer a family plan.

Over the five years I subscribed to Crashplan, I spent an average of $99/year1 for unlimited storage space for up to ten computers. I only ever connected seven computers to the service, and they ranged in space requirements from 1.4 GB to 3.7 TB; in total, my cost worked out to $0.0016 per month per GB.

I’ve been considering my options:

  • I can stay on Crashplan. On their small business plan, the cost becomes $10/month/computer, for a total of $840/year (although they’re offering 75% off for a year, so $210 for the next twelve months).
  • I can switch to BackBlaze. To connect those seven computers would cost $420/year; this is still a substantial increase.
  • I could try a more DIY solution, using Arq to backup to B2. Their price is $0.005/GB/month; this would cost me $304/year.

What I’ve settled on is a combination of the above. If I exclude the one computer with 3.7 TB of data, I can backup the other six computers to B2 for $82/year. For one year, I can continue backing up the large computer to Crashplan for $30/year ($2.50/month), for a total of $112/year2. This is the lowest cost option I’ve seen, and keeps the price increase to a minimum.

After the first year, I’ll likely switch the large computer over to BackBlaze, since it will be half the cost (at $5/month) of staying on Crashplan Small Business (at $10/month). That will bring my annual costs to around $140/year.

This is a fairly substantial price hike, but the value of cloud backups is well worth this price increase. However, having been burned once, I’d avoid Crashplan at all costs if I were considering solutions for a small business.

  1. The list price was $150/year, but I would extend my subscription when they had sales. ↩

  2. The tipping point is 500 GB; a computer larger than that is cheaper to store on Crashplan for $2.50/month, smaller than that is cheaper to store on B2. ↩

macOS Adaptive Firewall

After that last post on enabling SSH back to my iMac, I realized I should do a little more research into security precautions. I stumbled onto information about the macOS Server Adaptive Firewall.

Enabling it couldn’t be much easier. It’s two commands; first to self-configure, and then to start the firewall:

sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -c
sudo /Applications/Server.app/Contents/ServerRoot/usr/libexec/afctl -f

kyrpted.com has a more thorough explanation of how to use the Adaptive Firewall, but I feel a little better knowing it’s running.

SSH to Mac

I’ve taken a bold step: I’ve enabled SSH back to my home computer.

Enable SSH in macOS Server -> Settings

For OPSEC, I’ve disabled all authentication methods except Public Key, with the hope that I can have a secure, reliable, SFTP connection my home machine from anywhere.

To make this change:

  1. I added my public key to ~/.ssh/authorized_keys
    • You can run this command: ssh-copy-id -i ~/id_rsa.pub username@ip.add.ress.here
    • …or just copy ~/.ssh/id_rsa.pub into ~/.ssh/authorized_keys/
  2. I enabled Remote Login in System Preferences
  3. To disable password-based authentication, I edited /etc/ssh/sshd_config with these changes:
    • ChallengeResponseAuthentication no
    • PasswordAuthentication no
    • UsePAM no1

That tutorial also recommends setting KbdInteractiveAuthentication no, but according to ssh.com:

Specified whether keyboard-interactive authentication is allowed. By default, the value of ChallengeResponseAuthentication is used.

Since it takes the value of ChallengeResponseAuthentication by default, I haven’t specified a value for KbdInteractiveAuthentication.

After making these changes, it’s important to restart ssh:

sudo launchctl stop com.openssh.sshd

If it looks like I’ve done something foolish, please let me know!

  1. This isn’t called out in that tutorial, but disabling PAM seems like the most prudent thing here. ↩