How to use a USB drive with FreeNAS

First of all, a disclaimer: I use this setup just as a secondary backup, I do not recommend you rely on USB drives as storage media for your FreeNAS server.

Overview

I have a few spare 2 TB drives that used to be in my homeserver, and I wanted to connect them to my FreeNAS every few weeks to store some backups on them, then disconnect them and put them in a drawer.

Preparing the USB hard drive

If your drives are not brand new, chances are you already have some data on them, so you’ll need to wipe them first. To do so, connect your drives to FreeNAS, login to the webinterface, go to the Storage tab, click on “View Disks”, select the correct one from the list, then click on the “Wipe” button on the bottom of the screen.

Everything will turn red now. That’s because you’re doing something potentially dangerous. Make sure you really select the correct drive, otherwise you might destroy all of your data.

A Quick wipe is usually enough. Select that and proceed.

Once the wipe is completed, you can turn the disk into a Volume you can use on FreeNAS, just like your main one(s). Head over to the Storage tab, click on the “Volume Manager” button. You will see your newly wiped disk there, give it a volume name, tick the “Encryption” checkbox if you’d like, then click on “Add Volume”. I’ll call mine “ColdStorage” for the purpose of this tutorial.

Do NOT select any “Volume to extend”. That would mean you’d bee adding a single (USB!) hard drive striped to your main pool, and that drive would become the single point of failure for all the data in that pool.

After the disk has been initialized, you can start adding datasets, clone other ones, setup network sharing, whatever.

Disconnecting the USB drive

Once you’re done with it, you will want to disconnect your USB drive to store it somewhere. To do so, once again go to the Storage Tab, select your pool from the list (ColdStorage in this example), then click on the “Detach Volume” button. You will only see this button if you select the pool, while if you select the dataset with the same name you will get a different set of buttons.

I’m not sure that I have to point that out, but let’s do it anyway: do NOT select “Mark the disks as new (destroy data)”. Once the pool has been detached, you can disconnect the USB drive.

Reconnecting the USB drive

For the thousandth time, go back to your trusty Storage tab, then click on the “Import Volume” button. A box will appear, select wether you have an encrypted volume or not, then click OK. FreeNAS will stop a few seconds to reflect on the good it’s made in its life, then it will present you a dropdown from which you’ll be able to select your USB volume. Click OK and it will be once again available in FreeNAS.

Display the currently playing track in iTunes/Spotify on the Touch Bar

Ever since I got my 2016 15″ MacBook Pro with Touch Bar, I wanted to have it show one thing: the currently playing track. Today, thanks to the amazing Better Touch Tool and some Apple Script (which I don’t like, but it gets the job done), I finally have that functionality.

It’s really easy:

  1. Open Better Touch Tool and click on the Touch Bar section.
  2. Add a widget and select the “Run Apple Script and Show Return Value” option.
  3. Click on the “Advanced Configuration” button and paste the relevant Apple Script (see below).
  4. Optional: set the Predefined Action to “Open Application / File / Apple Script …” and select iTunes/Spotify: this will always bring iTunes/Spotiy to the foreground when you tap the widget.
  5. Optional: set the iTunes/Spotify icon as the widget’s icon (You can right click on the .app bundle, click on “Show Package Contents”, then go to Contents/Resources. The icones are respectively iTunes.icns and Icon.icns, just drag them over their spot in BTT.)

Here is the script for iTunes:

And here is the one for Spotiy:

The only difference between the two is the name of the app in the first if and in the tell statement.

Better Touch Tool hides the widget if the Apple Script returns nothing (which is the case when the music is paused or when the iTunes/Spotify are closed): you can work that around by replacing the two return "" with return " ", i.e. returning a space when nothing is playing. It’s not very aesthetically pleasing on the Touch Bar because the button is asymmetric, but you can do that if you prefer it that way.

Force standard RGB out over HDMI on macOS

I own a 27-inch Philips Brilliance 272C monitor, which features both DisplayPort and two HDMI ports, both supporting the full 1440p resolution at 60 Hz.
DisplayPort has always been literally plug-and-play, and I have always used it to connect the monitor to my Mac. In fact, it was the only way I could have get full resolution on my old 2010 15″ MacBook Pro.

Yep, that’s totally my desktop

Last year my brother got a 2015 13“ Retina MacBook Pro, and I noticed that when using HDMI to connect to the screen the image would be not nearly as good as over DisplayPort, colors were off and there was even some sort of ”ghost” of the current picture shifted a few pixels.

I finally decided to look for the cause of this and I narrowed it down to one thing: for some reason macOS thought the monitor was a TV (?) and it spit out a weird color mode instead of regular RGB, which resulted in the crappy image quality.

I got to this conclusion through Mathew Inkson’s great post on this matter, and ran the script by Andrew Dagherty he linked.
Basically the script generates an override file that needs to be placed into /System/Library/Displays/Contents/Resources/Overrides (which by the way requires you to disable SIP), which forces macOS to output the correct RGB color mode.

For some reason, though, it didn’t work for my monitor, it looked like the override never got loaded by macOS. Upon further inspection of the plist file generated by the script, I noticed that there were a weird character in the screen name, which made the whole file invalid (you can see it in the screenshot below).

 

I simply edited it and removed the garbage it spit there (definitely the screen’s fault, though, not the script’s), rebooted, et voilà, everything worked fine and the image was perfect both through DisplayPort and HDMI.

I can also confirm that the same workaround works perfectly with my shiny new 2016 15″ MacBook Pro through this cheap USB-C to HDMI adapter by VTIN.

If someone has the exact same monitor, I have uploaded the override files here. Just extract the DisplayVendorID-410c folder you find in the zip file to /System/Library/Displays/Contents/Resources/Overrides (again, you will have to temporarily disable SIP or proceed thorugh alternative methods to write at that path).

Check macOS installer build

My new 15″ MacBook Pro is coming this week, and due to multiple reports of units shipping with SIP (System Integrity Protection) disabled I wanted to play it safe and immediately wipe the new machine with a clean install of macOS from a thumbdrive. The question was, however: is the build of macOS currently on the Mac App Store the most recent one that supports the new MBPs (10.12.1 build 16B2657)?

Screenshot of Terminal showing the commands to run

Finding out is not that easy, actually. First you’ll want to download macOS from the Mac App Store, then open the terminal and launch a few commands to mount the nested DMGs you donwloaded with the installer, and then check a plist file:

hdiutil attach /Applications/Install\ macOS\ Sierra.app/Contents/SharedSupport/InstallESD.dmg
hdiutil attach /Volumes/OS\ X\ Install\ ESD/BaseSystem.dmg
cat /Volumes/OS\ X\ Base\ System/System/Library/CoreServices/SystemVersion.plist

Just make sure paths are correct.

Attaching the DMGs might take a while, as they need to be verified first. You can skip the verification process by putting -noverify between attach and the file path.

You should get something like this:

<?xml version=“1.0” encoding=“UTF–8”?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList–1.0.dtd”>
<plist version=“1.0”>
<dict>
 <key>ProductBuildVersion</key>
 <string>16B2657</string>
 <key>ProductCopyright</key>
 <string>1983–2016 Apple Inc.</string>
 <key>ProductName</key>
 <string>Mac OS X</string>
 <key>ProductUserVisibleVersion</key>
 <string>10.12.1</string>
 <key>ProductVersion</key>
 <string>10.12.1</string>
</dict>
</plist>

You can clearly see that ProductVersion is 10.12.1 and ProductBuildVersion is 16B2657.

Foscam Safari plugin and macOS Sierra

foscam-logoI’ve had two Foscam security cameras (model FI9805W) for a few years, and I’ve been able to view their image and adjust their settings with no problems using the official plugin in Safari, which worked fine on Sierra too.
However, I recently purchased a third camera (model FI9828P V2), and its plugin didn’t work with macOS Sierra.

Thankfully, I stumbled upon a post in the Foscam forums that provided a working version of the plugin. I took the liberty of uploading to my blog as well, you can download it from here.

Blocking access to DD-WRT’s web interface from guest network

Even though I’ve shifted all the routing functionality of my LAN to the excellent pfSense (and specifically to a PC Engines alix2d2, for the time being), DD-WRT still plays a role in my network, since it powers a couple of my access points.

ddwrt

One of its key features that I rely on is the ability to make two or more SSIDs available, bridging the wireless networks to different VLANs in order to separate them. I have a couple of them at the moment, but the main “secondary” network is the guest one.

On my guest network, I want to prevent any access to DD-WRT (such as the web interface, SSH management, and so on). AFAIK, there’s no graphical way to do so in the admin panel, so I resorted to a quick iptables rule.

iptables -I INPUT -i br1 -d <DD-WRT's IP on guest net here> -j DROP

Basically this tells the firewall to DROP every packet that comes in from the br1 interface (make sure it’s the correct one in your config) and that is destined to its IP address on that interface.

To save and apply this rule log into the web interface, go to Administration/Commands, paste the command above (make sure you’ve inserted the correct IP) and then click on the “Save Firewall” button. Done.

Note: with this rule DD-WRT will be unreachable from that VLAN/SSID, even to you, so you’ll always have to access it from the main VLAN/network.

Throttling iCloud’s upload: here is the IP subnet

TL;DR 54.231.0.0/16

For those of us with limited upload bandwidth, just plugging an iPhone in for a charge while on home wifi can bring our connection to its knees. As convenient as automatic online backups are, they tend to monopolize all the available bandwidth, and saturating your upload means crippling the download as well (it has to do with buffer bloat, delayed ACKs, and other stuff).

iCloudThrottle

Through some Google-fu I found (one of) the subnet(s) used by iCloud, so that I can easily throttle the upload traffic without imposing a limit on all the upload coming from iOS devices. The subnet is 54.231.0.0/16.

Thanks to my pfSense router, I put together a nifty set of rules that throttles uploads to that subnet from 8 am to midnight, limiting it to 50% of my available bandwidth. During the night, it is unlimited.

Just a quick overview of what’s needed to do that on pfSense (not a full tutorial, sorry):

  • A schedule that defines the times you want the limit to be enabled
  • Trafic shaping with a dedicated upload queue with a fixed maximum rate, in addidition the default ones
  • A floating rule of type Pass, applied on both WAN and LAN, TCP protocol, destination 54.231.0.0/16, active during the day, sent to the queue you created earlier w/ the limit enabled.

Actually I have 2 schedules, one for the day and the other for the night, an additional queue for unthrottled iCloud backups and an additional floating rule that is identical to the one above apart from the fact that it is enabled during the night and sends traffic to the unthrottled queue. This allows me to have nice graphs that show only iCloud traffic. Definitely not necessary, but cool.

pfSenseQueues

Add SSL support to podPress

podPress is a dead WordPress plugin that makes it easy to publish podcasts using WordPress, and I still use it on my podcast network, EasyPodcast. That is going to change once we deploy my own, custom built CMS, but I still have to use it for the time being.
podPress HTTPSThis week I switched everything to HTTPS, feeds and media delivery included, and podPress started having issue in detecting the episode mp3’s file size and duration when I provided either an http or https link to the file.

This is due to a couple issues: it wasn’t recognizing HTTPS URLs, since it had an hard-coded check to make sure they were served over HTTP (I can see the point: you wouldn’t want to serve podcasts over FTP). Once I patched this, the file size detection started working again (it just reads the content-length HTTP header).

I was still experiencing issues getting the mp3’s duration: to do so, podPress downloads the mp3 (with curl, since it’s available on my server) and analyzes it using the getID3 library. However, I found out that for some reason the download file had the HTTP headers prepended to its contents, so the library couldn’t properly parse the mp3. It was due to a curl option in the code that enables that behavior. Why that was added to podPress and why it wasn’t an issue over HTTP is beyond me.

The two changes I made are both in the podpress_admin_functions.php file, and involved lines 1028 (to allow SSL) and 1618 (to prevent HTTP headers from being written to the file).

Here’s the diff file.

Enable Guest Network on AirPort Basestations in Bridge Mode

TL;DR AirPort Basestations in Bridge Mode support the creation of Guest Networks, and all their traffic gets sent to VLAN 1003 on the Ethernet side.

I have a couple 5th-gen Apple AirPort Extreme Basestations in my house that I use to provide wifi access, together with a couple cheap TP-Link TL-WR841ND flashed with DD-WRT, and I run them all in bridge mode, as I don’t need their routing capablities. I rely on my PC-Engines Alix 2d2 running pfSense to be my router, so I just need wifi access points, not full-blown wireless routers.

One nice feature that you get if you do run AirPort Basestations as routers is the ability to have a completely isolated wifi network for guest use, that gets internet access but does not allow communication with devices on your private LAN.

Due to what I think is a bug in AirPort Utility, you can enable the guest network even when running your AirPort in bridge mode, the network is created and you can connect to it, but it looks like it doesn’t work: you don’t get an IP through DHCP, and any traffic seems to end nowhere.

After some Googling and Wiresharking, I found out that what actually happens is that AirPorts funnel all the guest network traffic to VLAN 1003, so if you have network equipment that is able to deal with VLANs you can actually use both Bridge Mode and Guest Network at the same time.

Luckily enough, my pfSense-based router is more than capable to do that, so I set up a Guest Interface on VLAN 1003, configured the DHCP server to assign addresses on that interface (on 10.10.10.0/24, while my main LAN runs on 192.168.1.0/24) and set up firewall rules to only allow traffic to the internet, and not to my LAN or other local subnets (such as my VPNs, and a second LAN I run on a different VLAN).

ARP moved messages in FreeNAS/pfSense explained

kernel: arp: x.x.x.x moved from xx:xx:xx:xx:xx:xx to xx:xx:xx:xx:xx:xx on em0

Ever since adding a pfSense router and a FreeNAS box to my network, I noticed quite a few ARP moved messages in my system logs, and I finally found out what causes them.

TL;DR: Nothing to worry about.

Long(ish) version

First a little background. ARP messages are excahanged in ethernet networks (even wireless ones) in order to keep track to which physical (MAC) address each IP belongs to, so especially if you have static IP addresses or static leases in your DHCP server, you shouldn’t be seeing messages like these, which indicate that a given address is now assigned to a different device, hence the change of the MAC address.

I had noticed a couple interesting things about these MAC addresses: they all belong to Apple devices (you can check by entering the first three 2-character blocks in a lookup service), and one of tham always belonged to a Mac. The other one belonged to an AirPort base station (either an Extreme or an Express), which initially made me worry that somehow my Wi-Fi network was breached and somebody was connecting to it and stealing an IP. Actually it didn’t make much sense, unless the AirPort itself was hacked and used as a sort of relay.

After some googling, I came to this post on the FreeNAS forums where they explained that this behavior is due to a feature of AirPort base stations called sleep proxy.

Basically, when a Mac goes to sleep, its Bonjour-advertiesd services would disappear, making it no longer visibile on the network. AirPort base stations understand Bonjour, and they get notified when a Mac goes to sleep, so they start broadcasting the Mac’s services (file sharing, screen sharing, SSH, etc.) and “grab” its IP. This way, when somebody tries to access one of these services, either because they already knew the sleeping Mac’s IP or because they discovered it through Bonjour, the AirPort wakes the Mac by some kind of WOL technology, maybe a simple magic packet. When the Mac comes out from sleep, it takes its IP back, thus generating a second, opposite entry in pfSense’s/FreeBSD’s system log.