Removing .DS_Store Files

With the released of macOS 10.13 High Sierra, I did a review of my installed applications to make sure an upgrade would be as painless as possible. One item that caught my eye was Lingon X, which I use solely to remove .DS_Store files via launchd. You can manage this yourself, but Lingon X is so straightforward that it’s easily worth the cost ($10).

Within Lingon X, under the me section, I “named” my script:

local.dsstore.com

For the “Run” command I provided the following:

/usr/bin/find /Users/[user] -name *.DS_Store -type f -delete

Note: be sure to replace [user] with your actual user account. Interestingly, I tried using ~ (tilde) to indicate my own home folder, but Lingon X said that would result in an error.

Lastly, I selected “Scheduled” and decided to run this every 15 minutes.

Everything works as expected, and sometimes, if I’m really bored, I do something in Finder to create a .DS_Store file and, like watching paint dry, wait until my script runs and removes it.

macOS Sierra 10.12 SSH Keys

I updated to macOS Sierra 10.12 (GM) tonight and surprisingly everything seemed to work without any issues … at least so far. One thing that did come up, but was easily remedied, was that all of my SSH keys stopped working.

ssh git@github.com

The above command prompted for a password (assuming you use GitHub), which is should not do if SSH keys are set up properly.

Assuming your SSH keys are RSA-based, I have a quick solution:

cd ~/.ssh

This will get us into our user SSH folder

ssh-add -l

This lists all keys that the SSH agent knows about. After upgrading, this returned zero keys! Note: In reality ssh-add is session-based, and so each time you log in this command will show zero results (see below).

ssh-add -K ~/.ssh/[your-private-ssh-key-name]

You’ll be asked for the password (if one is set) for this private key

-K tells ssh-add to save the key into your Keychain, so that on subsequent logins, even if ssh-add -l shows nothing, ssh will also look in your Keychain to see if the key is save there.

[your-private-ssh-key-name] is likely id_rsa, but it could be others as well

Repeat step 3 as needed

ssh-add -l

You should now see you SSH key(s) listed

That worked for me, though oddly I had to do this process twice as the first time I made it to step four, then exited Terminal, none of my applications using SSH worked, I opened Terminal again and found that nothing was listed when I ran the ssh-add list command.

UPDATE:

This doesn’t seem to do what I thought it should, namely, upon reboot I had to repeat this process again. I have since added the following steps:

cd ~/.ssh/
sudo vim config

I then added this line to my SSH config file:

IdentityFile ~/.ssh/[your-private-ssh-key-name]

I saved the config file, and now my SSH keys work as expected.

UPDATE 2 (19 Dec 2016):

With Apple’s update to 10.12.2 I found myself having SSH issues yet again. A bit of searching pointed me to the updated man pages as seen via Terminal:

man ssh_config
AddKeysToAgent
    Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to ``yes'' and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If this option is set to ``ask'', ssh will require confirmation using the SSH_ASKPASS program before adding a key (see ssh-add(1) for details). If this option is set to ``confirm'', each use of the key must be confirmed, as if the -c option was specified to ssh-add(1). If this option is set to ``no'', no keys are added to the agent. The argument must be ``yes'', ``confirm'', ``ask'', or ``no''. The default is ``no''.
UseKeychain
    On macOS, specifies whether the system should search for passphrases in the user's keychain when attempting to use a particular key. When the passphrase is provided by the user, this option also specifies whether the passphrase should be stored into the keychain once it has been verified to be correct. The argument must be ``yes'' or ``no''. The default is ``no''.

I eventually landed on the following inside my config file (~/.ssh/config), erasing everything I had added in the first UPDATE.

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/[your-private-ssh-key-name]

Afterwards I restarted to flush anything in SSH and noticed that everything was working correctly again. At this point, it’s probably a good idea just to start with this, assuming you’re running at least macOS 10.12.2.

Note: The above example I actually repeated three times since I have more than one SSH key that I need to use. Just copy and paste, being sure to update your private key filename.

AirPort Utility 6.x “Flash on Activity”

The other day I updated the AirPort Extremes in my house, resetting them to their default settings. When I had everything up and running again, I noticed they no longer flashed with activity. I searched through the AirPort Utility 6.x (6.3.2) installed on Mavericks and could not find this setting. I searched DuckDuckGo and found a lot of other people longing for this option, too. Since you cannot install (can you?) AirPort Utility 5.x onto Mavericks, I ended up installing 5.x onto my Windows 7 VM. There I was able to find the setting, make the change, and was happy again.

But what if you don’t have a Windows VM? What if all you have is Mavericks? Well, I have an easy enough solution for you. In AirPort Utility 6.x, export your AirPort configuration file and save it to your desktop. Open this file with a text editor (such as Sublime or vim) and search for “leAC” (lower case L).

<key>leAC</key>
<integer>1</integer>

Change this to:

<key>leAC</key>
<integer>2</integer>

Save the file, go back into AirPort Utility 6.x and import this configuration file. Don’t change anything else in your file, just the 1 into a 2. This tells your AirPort that you’d like it to “Flash on Activity”. Let the AirPort restart and take note and the wonder that is a flashing green LED.

2014-10-06 Update

It seems this trick does not work on the latest Airport Extremes with 802.11ac. Even with the above set, the LED on the front of this device does not flash.

Upgrade MySQL 5.5 to 5.6 on OS X Mavericks

I needed to upgrade MySQL from 5.5.x to 5.6.x on my OS X server running OS X Mavericks (10.9) and I found a site that basically made it super painless. Nothing jumped out on my from Google regarding Mavericks, so this is really for that random person like me who was unsure how it should work.

First, go download the 64-bit DMG of MySQL from here. Don’t worry that it says 10.7, it will work just fine with 10.9.

Then go here and read this page … I’ll wait, but don’t follow all the steps until you read my next part.

While performing the steps above, you’ll reach a step that reads:

/usr/local/mysql/bin/mysql_upgrade

At this step, instead of the above, try this instead:

/usr/local/mysql/bin/mysql_upgrade -u root -p

This will prompt you for your root password, but it will also allow the upgrade script to actually run. Otherwise, the directions were perfect and you should really have no problem. If for some reason you don’t have root access to MySQL … you’ll probably want to ask someone who does.

iStat Server and opening port 5109 on OS X Mavericks

After upgrading to OS X Mavericks (10.9), iStat on my iPhone was no longer able to connect to iStat Server on Mavericks. I had vaguely recalled seeing the OS X Server installer tell me that ipfw should be disabled, so I disabled it. I didn’t really think of it at the time, but I had a firewall rule set to allow TCP port 5109 be opened for iStat Server … because simply adding it via the Firewall settings is System Preferences did absolutely nothing … for some reason.

So I recalled the installer mentioning pf and told me to use pfctl. That took me on a journey the OS X man page regarding pfctl and about an hour later I finally figured out how to make it all work … and here it is:

sudo vim /etc/pf.conf

Add this line to the config file (after the com.apple anchor is fine) where en0 is your ethernet adapter and port 5109 is the port you’re using in iStat Server:

pass in on en0 proto tcp from any to any port 5109

This allows TCP data on port 5109 to pass into your machine via en0. This allows it from any IP address, but you could have changed the first mention of “any” to an IP address in order to only allow from a single IP address.

If you aren’t using a wired connection, you can change en0 to en1, or if you’re uncertain which adapter you’re using, run the following command to see which is active on your setup, noting which has a status of “active”:

ifconfig

This should yield something like the following. Note how en0 is “active”.

en0: flags=[redacted]
	options=[redacted]
	ether [redacted]
	inet6 [redacted]
	inet [redacted]
	nd6 options=[redacted]
	media: [redacted]
	status: active
en1: flags=[redacted]
	ether [redacted]
	nd6 options=[redacted]
	media: [redacted]
	status: inactive

Save the config file and run the following to reload the config file, and verify using verbose:

sudo pfctl -vnf pf.conf

I also ran this, just in case:

sudo pfctl -Rf pf.conf

That’s all I needed and I was able to make my way into my machine. But, it wasn’t until I turned off SSL that I was actually able to connect to iStat Server. I’m hoping SSL is remedied soon! SSL now works once again!

XAMPP to MAMP

Tonight I decided to move from XAMPP to MAMP.

About a year (or so) ago my team transitioned from PC to Mac and when we went looking for an easy, self-contained Apache install, XAMPP was the answer.  Now we have OS X 10.7 Lion and well, I’m annoyed that XAMPP for OS X has not been updated since early March, 2010.  That’s right, over a year ago.

The reason I even began looking for a XAMPP alternative was that after upgrading to Lion, XAMPP just seemed to load pages slower than before, specifically on sites using databases that weren’t local to my machine.  Enter MAMP 2.0.  Newly released (literally yesterday) and plenty of people online giving it a thumbs up, I decided to give it a shot.

Because XAMPP for Mac (the Windows version has been updated much more recently) is over a year old, pretty much all the included applications are out of date as well.  XAMPP was on Apache 2.2.14 and although it wasn’t a necessity to have the latest Apache, it just seemed like I should be able to get it.

MAMP comes with 2.2.17 included (as of this writing, the current version of Apache is 2.2.19), which is at least newer than XAMPP.  Honestly, not a huge deal, right?

I guess what made me keep MAMP in the end is at least a decent GUI (non-Pro version) with some useful preferences (auto start servers) as well as phpMyAdmin built in.  Yes, I had phpMyAdmin installed with XAMPP (though it did not come with XAMPP), MAMP’s GUI makes it easy enough to get to these built in features that I actually find myself using them.

For reference, about 95% of my XAMPP Apache conf files made it into MAMP’s, save for SSL.  There are plenty of help online about MAMP and SSL, but basically you create your own certificate and uncomment a line in the main Apache conf file.

MAMP, a solution to a problem that didn’t really exist, but a solution nonetheless.