[Bug]: NetClient broken on M1 (arm64) Mac

[ViRb3]

Contact Details

No response

What happened?

Traditionally, homebrew uses a prefix of /usr/local/bin. This means that netclient would be installed under /usr/local/bin/netclient. This path is also hardcoded in the launch daemon created on installation from homebrew.

On M1 (arm64) Macs, due to the architectural changes, homebrew changed its prefix to /opt/homebrew. This means that netclient is now installed under /opt/homebrew/bin/netclient. This means that the launch daemon is invalid and essentially renders netclient unusable. Additionally, the PATH environment variable in the launch daemon needs to have /opt/homebrew/bin, as this is where wg would be. But what is more, even after fixing these two issues, netclient still does not run due to the raised security level on the new Macs:

This is trivial to fix though, remove the quarantine flag of the binary in your installation script:

xattr -c /opt/homebrew/bin/netclient

After applying all these changes, I can finally use netclient. I hope you can incorporate what is necessary to fix it for everyone :)

TL;DR of fixes (run as sudo):

sed -i '' 's|/usr/local/bin/netclient|/opt/homebrew/bin/netclient|g' /Library/LaunchDaemons/com.gravitl.netclient.plist
sed -i '' 's|/usr/local/sbin|/opt/homebrew/bin:/usr/local/sbin|g' /Library/LaunchDaemons/com.gravitl.netclient.plist
xattr -c /opt/homebrew/bin/netclient

# if applying changes post-mortem, need to reload launch daemon
launchctl unload /Library/LaunchDaemons/com.gravitl.netclient.plist
launchctl load /Library/LaunchDaemons/com.gravitl.netclient.plist

Thanks!

Version

v0.14.6

What OS are you using?

Mac

Relevant log output

No response

Contributing guidelines

• Yes, I did.

[ViRb3]

When attempting an upgrade from 0.14.6 to 0.15, netclient tried to install in /Applications/ and the whole setup broke. I had to manually uninstall and install 0.15.0 cleanly, then apply the above fix.

[varoudis]

is it ok to run netclient on MacOS without the daemon? (launchctl unload /Library/LaunchDaemons/com.gravitl.netclient.plist)

And only use it with "sudo netclient daemon" when required to join the netmaker network?

[mattkasun]

if your run without the daemon, the client will not get any updates from the server ....eg if another peer joins or leaves the network or if a gateway is created or deleted.

Also, if your local public ip or wg listening port changes, the server will not be updated and thus all the other nodes in the network will not get your new endpoint.

instead of running without the daemon you would be better to not install netclient, create an extclient and download the conf file to your mac, copy it to /etc/wireguard/wg0.conf and just run wg-quick up wg0

[varoudis]

If I run “sudo netclient daemon” on a terminal on demand only. Is this the same?

[mattkasun]

netclient daemon is not a one-shot program, it runs continuously

[varoudis]

Yes I know. Id like to leave terminal open as long as I need the netclient to run.

my unix/linux knowledge tells me its ok, but I wanted to make sure as I might be missing something MacOS specific.

[adamphetamine]

Hi @varoudis,
Great work getting the Homebrew version working on Apple Silicon. Sounds like there's 2 issues here- the binary is not signed so it isn't trusted, and the launchd fails because the binary has moved.

You can see a discussion of the first issue here-
Homebrew/discussions#3204
The .pkg version is signed, so this must be a bug or regression in the Homebrew version.

We* also had the second issue with the .pkg version for macOS, and the devs fixed it. At this point I'd advise moving to the .pkg version- it does everything I can think of to be compliant with Apple's rules. Brew faces an impossible task - it doesn't do stuff 'the Apple way' and things break in interesting ways...
*I helped because I am keen to see Netmaker do well, I do not speak for the devs or the company

PS I migrated my data from Intel to M1 over the weekend and my netclient came across with no issues...

[ViRb3]

@adamphetamine The reason you had no issues after migration is likely because Homebrew kept its old prefix (/usr/local) instead of using the new, M1 prefix (/opt/homebrew).

[adamphetamine]

@ViRb3 I am not using Brew version,
My install is from .pkg and is in /usr/local/bin on my new Apple Silicon Mac

[mattkasun]

brew package updated
#15

[ViRb3]

@mattkasun you're missing a closing bracket which completely breaks the script:

• https://github.com/gravitl/homebrew-netclient/pull/15/files#diff-f34635067c494585ebe9482de8bcfae46eee210dfbbb30bc966522b1014538a6R3

[mattkasun]

@ViRb3 good catch... fixed

[ViRb3]

Hmm, even with the new changes I don't see a difference in behavior. Maybe Homebrew is still downloading the old version from before these fixes, even though I deleted all caches and reinstalled the tap?

Anyway, I also noticed a few more issues:

• Invalid syntax, i.e. arch = foo cannot have space before and after the equals sign. This ends up leaving arch empty, so the intel amd64 if case will never execute
• Some variables not quoted, will break if path inside contains a space
• The uninstall script does not remove the installed launch daemon

I would recommend running the scripts through https://github.com/koalaman/shellcheck, it catches all of these issues.

I took the liberty to simplify the installation and crafted an upstream formula: Homebrew/homebrew-core#109801. Due to being a formula instead of a cask, it comes with a bunch of benefits such as building from source, releases per macOS version and architecture, and automatic daemon management. I tested it and works great on M1 Mac.