Introduction
There have been a number of outages to the office internet recently, which has resulted in the router being rebooted. When the router has come back online the DHCP setup has resulted in computers being assigned an IP in a different subnet than previously.
While this is not a concern for regular internet access, it does affect internal systems. Our network of Mac Studios had been assigned static IPs, and those IPs were for a specific subnet. Now that the router has changed the subnet for IPs being issued from DHCP this meant those computers were no longer reachable, as they were on a subnet the router did not recognise.
Jason set about changing things so we could enter an age of non-static IPs, with the aim to eliminate reconfiguring the router after each outage, and to ensure predictable access to the Mac Studios.
The two main ways people use the Mac Studios is via SSH and VNC (screen sharing). From inside the Tapadoo network we can use the local host names e.g. rex.local for this, but when accessing from home this is not so straight-forward, as those names will not resolve to an IP.
We could setup a private network in Cloudflare Zero Trust, and that may well be a project for another day, but given this is new territory for us, we wanted a simpler way to do it in the short-term.
Just use ping
As a first stab to sort this out we could ssh into a box and then ping another computer to get it’s IP. This is a cart before the horse scenario though, as we’d need to know the IP of the box to ssh into it.
I also experimented with some Apple Script and this ssh approach to provide a simple macOS UI to make screen sharing simple. In the video below you can see the source for this and it in operation.
However, in this case you can see it relying on the SSH config and this would most likely prove to be something that would enter the realm of “how-do-i-via-dm-in-slack-too-frequently”.
Make it more complex but simpler
This sounds like an oxymoron, but to make things simpler for the end-user, the solution did need to be more complex.
The solution is to host a page at vnc.tapadoo.com that would have up to date IP address and VNC information.
How is the page generated?
The page is generated by Python that runs every five minutes on slinky-dog.
Wait, it’s just boring static HTML?

Yes, we could have done this dynamically, but that would be more complex and less suitable for this scenario. The program runs through 120 IP addresses (we can move to the full 510 in future if required), which takes some time. Doing this each time someone refreshes a page would be wasteful and time consuming.
By running the program every five minutes, we have up to date information, and because it’s static HTML it renders blisteringly fast.
Tell me more about this Python
The source code is available in the server-ops repository.
The broad strokes of how it works are that it tries to open a socket to port 5900 on each IP address, and if it succeeds then we know this IP supports VNC. Then it does some brute force matching to figure out the name of the box this IP is associated with, and also does a lookup to find the username we use for screen sharing on that box.
With the results gathered, the HTML is generated and copied to it’s final destination.
Why is it running on slinky-dog?
slinky-dog is where we serve the content for apps.tapadoo.com. Rather than configuring a new web server somewhere, I thought why not add a new server to the existing nginx configuration on slinky-dog for the new vnc domain:
# vnc.tapadoo.com server
server {
listen 80;
listen [::]:80;
server_name vnc.tapadoo.com;
location / {
root /Library/Server/Web/Data/Sites/vnc;
index index.html;
}
}
How does it run every five minutes?
It uses launchd. The agent definition is in the com.tapadoo.vnclist.plist file. The schedule is defined by the StartInterval key and then the value is specified in seconds.
<key>StartInterval</key>
<integer>900</integer>
And the domain name and security is handled in Cloudflare?
Yes. A new application and route were added via Cloudflare Zero Trust, with access configured to only allow Tapadoo Staff.
That’s all folks!
I hope you found that was a smidgen interesting. Please report any bugs or feature requests using the create issue form. For any discussions/chats start a thread in #development on Slack. Thanks!