Reset Apple macOS Spotlight

The macOS Spotlight service might loose its touch. E.g. when some applications or documents won't show up when you <CMD><SPACE> them. Reason could be that the service or its database got corrupt for some reason.

The following 4 commands will reset the Spotlight service and database. So after you issue those commands the PC/laptop will be re-indexed (which could take a while).

sudo mdutil -a -i off
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
sudo mdutil -a -i on

Now, wait a bit, and everything should be back to normal.

Happy Spotlighting.

Installing Python Matplotlib On MacOS Sierra

I recently 'upgraded' to MacOS Sierra (Apple's latest Operating System) by doing a clean install. This resulted in a couple of challenges, including some software that could not be installed, and for which I had to find some alternatives.

Another issue I ran into is that some Python3 scripts with matplotlib wouldn't run, because matplotlib wouldn't install correctly.
I could 'pip' all I wanted, but the result was always:

$ pip3 install matplotlib
[...]
The following required packages can not be built: freetype

Some googling pointed me to some articles that freetype is/was a part of the XQuartz (X11) software that's no longer (pre)installed on MacOS Sierra. And in the past I have always upgraded my OS. The times that I did a clean install on this machine.... Must have been ages ago.

After some frustrating hours of trying to get this 'freetype' thing installed, I ran into an article on yantonov.com which solved my issue finally.

First I installed 'homebrew'.

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

After that I installed pkg-config and freetype:

$ brew install pkg-config
[...]

$ brew install freetype
[...]

And finally, I was able to successfully install matplotlib:

$ pip3 install matplotlib

Apple iOS Personal Hotspot Annoyances

This week, I ran into an annoying feature regarding the Apple iOS Personal Hotspot function of my iPhone 5s. I had to do some software testing with various WiFi clients. This worked fine, up to the moment that new devices ran into connectivity problems.

The new devices could connect, but got a message that there was no/limited Internet connectivity. Checking the IP address of the devices showed that they had an 169 address assigned.
So the iPhone wouldn't give new IP addresses to the new devices. Earlier devices that connected correctly could reconnect without a problem though.

It turned out to be a 'normal' DHCP problem. The IP address scope on the iPhone was depleted.

The iPhone has a small DHCP address pool that can give out 16 addresses (172.20.10.0-172.20.10.15). Of these 16 addresses are 3 taken by the network, broadcast (172.20.10.0 and 172.20.10.15) and iPhone itself (172.20.10.1). Leaving 13 addresses for other devices.

In normal situations, this shouldn't be a problem, but when your testing stuff, you can run into a shortage of IP addresses. Besides the shortage of addresses there is another challenge; no way of altering the DHCP lease time, or even clearing the issued IP addresses.

The lease time for the DHCP address is approximately 1 day (85536 seconds), as shown by a little network traffic capturing below.

20:53:29.544291 56:e4:3a:38:4d:64 > 00:23:6c:8d:7f:8e, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 45806, offset 0, flags [none], proto UDP (17), length 328)
    172.20.10.1.67 > 172.20.10.2.68: BOOTP/DHCP, Reply, length 300, xid 0xfd7e0982, Flags [none]
      Your-IP 172.20.10.2
      Server-IP 172.20.10.1
      Client-Ethernet-Address 00:23:6c:8d:7f:8e
      sname "Free-Public-WiFi"
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 172.20.10.1
        Lease-Time Option 51, length 4: 85536
        Subnet-Mask Option 1, length 4: 255.255.255.240
        Default-Gateway Option 3, length 4: 172.20.10.1
        Domain-Name-Server Option 6, length 4: 172.20.10.1

There is a function to reset the network settings on the iPhone, but that just clears everything regarding (wireless) network settings, but it doesn't touch the DHCP service in the iPhone. A reboot of the iPhone doesn't do the trick either. So you just have to wait till it clears automagically.

So there is room for improvement......

OS X Yosemite DHCP Server

This week I re-installed my Mac Mini server at home. It still ran Snow Leopard, and it was time to start with a clean slate. So after a couple of hours of pondering if I had forgotten to backup something, I started with a clean install of OS X Yosemite (10.10).

Everything went smooth, until I started using the DHCP service that comes with the Server App add-on.

My server uses 802.1q (VLAN-tagging) to connect several different VLAN's which I feed into several Virtual Machines. So I also use several DHCP Scopes for those segments.
The IP addresses for these scopes are all in the 192.168-range (class C subnets), so when I created the scopes I had to go through a simple wizard in the Server App. I just had to fill-in the blanks (very user friendly), and OS X did the rest.

Upon testing I ran into the weirdest behaviour on my network. Getting connectivity with a device took a very long time, and when the device got an IP address, it was from a different network (???)> So it couldn't communicate across the network.

At first I began to wonder if I had mixed up the VLAN names and tags, but those were correct. After an hour of troubleshooting (more and more DHCP clients were failing in the network), I found the problem;

When you create a scope Apple will assign a default subnet mask (255.255.0.0). I guess I should have seen it, but I didn't.

After I changed the subnet mask in the DHCP scopes everything went back to normal.

Lesson learned: Don't rely on wizards and other user-friendly stuff.

OSX 10.10 (Yosemite) and Audio Out Changes

Yesterday I ran into a new Yosemite feature that annoyed me a bit. After changing the input on my Dell 27" display from DisplayPort to HDMI, the screen turned black on my 27" iMac, and audio stopped. Forcing a reboot (holding the power button for >4 seconds) was needed to get the iMac's display back.

But from that point on, the audio was greyed-out in the menu bar. Changing the volume on the (Apple) keyboard gave a disabled icon on screen. Also, no audio was playing over my external speakers.

My first thoughts were that the earlier crash had corrupted something on my system, so I did an additional reboot. Nothing. After that a PRAM reset (power off, power-on and hold command-option-P-R until you have heard two start-up 'boings'). The start-up sounds were there, so the actual audio hardware was just fine.

When the desktop loaded still no audio control, until I unplugged my DisplayPort connector on the Dell 27" monitor. Audio (controls) came back instantaneous.

So, with DisplayPort connected to the external monitor: no audio (controls), and without the DisplayPort: audio (controls).

Turns out that with Yosemite, the audio is channelled BY DEFAULT over a DisplayPort connection (to a external monitor). In my case, the Dell also has an audio out connector, and I guess that is 'advertised' over the DisplayPort.

Changing the default behaviour is done in the System Preferences -> Sound

The first image shows the default (at least in my case). Changing the settings to the second image gave me back the audio and volume control.

View fullsize

View fullsize

I have no idea if this was also possible with Mavericks (or even earlier versions of OSX), but it's definitely a (default) feature that annoyes the hell out of me.

Even though I tackeled the audio problem, the issue with loosing the display when I change the video input on the external monitor still remains. But only if the desktop is extended to the second screen. It doesn't occur when the screen is mirrored.

Train iPhone 5s Touch ID

Touch ID is the name for the fingerprint reader in the new iPhone 5s. When you configure it, you have the possibility to register a number of fingers (5) with which you can unlock your iPhone.

Settings -> General -> Touch ID & Passcode -> Touch ID

View fullsize

For some reason this always failed after a couple of days on my phone. For some reason the fingers didn't 'register' properly, and I was forces to use the PIN.

The way to solve this (temporary) was to re-register the fingers, until I read about a way of training the device.
When you're in the menu where you normally register your fingerprints, you can register additional print data for each finger by just placing one og the already registered fingers on the home button. When the finger is recognized the registered finger entry on the iPhone turns grey for a second (as shown in the screenshot). Doing this for every finger a couple of times increases the registered data for those fingers. The more data that's registered the better the chance that the finger keeps getting recognized in the future.

UPDATE: With the iOS 7.1 update the Touch ID responds a lot better.