• Search for:
    4 Aug, 2021
    Starting WireGuard Interfaces Automatically with Launchd on macOS
    Cloud

    In late June of this year, I wrote a piece on using WireGuard on macOS via the CLI, where I walked readers using macOS through how to configure and use the WireGuard VPN from the terminal (as opposed to using the GUI client, which I discussed here). In that post, I briefly mentioned that I was planning to explore how to have macOS’ launchd automatically start WireGuard interfaces. In this post, I’ll show you how to do exactly that.

    These instructions borrow heavily from this post showing how to use macOS as a WireGuard VPN server. These instructions also assume that you’ve already walked through installing the necessary WireGuard components, and that you’ve already created the configuration file(s) for your WireGuard interface(s). Finally, I wrote this using my M1-based MacBook Pro, so my example files and instructions will be referencing the default Homebrew prefix of /opt/homebrew. If you’re on an Intel-based Mac, change this to /usr/local instead.

    The first step is to create a launchd job definition. This file should be named <label>.plist, and it will need to be placed in a specific location. The <label> value is taken from the name given to the job itself, which you’ll see in the example job definition below. Since this modifies the networking configuration of your macOS system, it will need to be treated as a “global daemon” and will need to be placed in the /Library/LaunchDaemons directory.

    Here’s an example of a job definition:

    <?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>Label</key> <string>com.wireguard.wg0</string> <key>ProgramArguments</key> <array> <!-- Points to local version of wg-quick that
 fixes path issues with the script --> <string>/Users/slowe/.local/bin/wg-quick</string> <string>up</string> <string>wg0</string> </array> <key>KeepAlive</key> <dict> <key>NetworkState</key> <true/> </dict> <key>RunAtLoad</key> <true/> <key>StandardErrorPath</key> <string>/opt/homebrew/var/log/wireguard.err</string> <key>EnvironmentVariables</key> <dict> <key>PATH</key> <!-- Adds in user-specific and Homebrew bin directories to start of PATH --> <string>/Users/slowe/.local/bin:/opt/homebrew/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string> </dict> </dict>
</plist>

    For the most part, the job definition is pretty easy to figure out, but here’s a few notes:

    • The <label> reference in naming the file pertains to the value of the Label key in the job definition. In my example, I’m calling the job “com.wireguard.wg0”, so the filename should be com.wireguard.wg0.plist. Note that the extension is necessary.
    • Note in the ProgramArguments key that I’m referencing my personal changed copy of the Homebrew wg-quick script, which works around some path- and shell-related issues on M1-based Macs (as described here).
    • As mentioned earlier, users of Intel-based Macs would want to change references to /opt/homebrew over to /usr/local (and the reference to the local copy of wg-quick may not be necessary).

    Make sure this job definition is saved to an appropriate file name (<label>.plist) and it’s found in the /Library/LaunchDaemons directory. Then run these commands to inform launchd of the new job definition you just created:

    sudo launchctl enable system/com.wireguard.wg0
sudo launchctl bootstrap system /Library/LaunchDaemons/com.wireguard.wg0.plist

    After running these two commands, you should be able to run wg show and see your WireGuard interface up and running. It should get turned up every time you restart your computer and there is a network present/active.

    Additional Resources

    In addition to the Barrowclift post, I also found the launchd.info site to be quite helpful.

    Although the above instructions work without any issues on my Mac, I can’t guarantee they’ll work on every system out there. If you run into issues, or if you find that I’ve provided incorrect or incomplete information, please let me know. You can interact with me on Twitter, or drop me an e-mail (my address isn’t too hard to find).

    …

    Read MoreStarting WireGuard Interfaces Automatically with Launchd on macOS

    3 Aug, 2021
    An Alternate Approach to etcd Certificate Generation with Kubeadm
    Cloud

    I’ve written a fair amount about kubeadm, which was my preferred way of bootstrapping Kubernetes clusters until Cluster API arrived. Along the way, I’ve also discussed using kubeadm to assist with setting up etcd, the distributed key-value store leveraged by the Kubernetes control plane (see here, here, and here). In this post, I’d like to revisit the topic of using kubeadm to set up an etcd cluster once again, this time taking a look at an alternate approach to generating the necessary TLS certificates than what the official documentation describes.

    There is absolutely nothing wrong with the process the official documentation describes (I’m referring to this page, by the way); this process just creates slightly “cleaner” certificates. What do I mean by “cleaner” certificates? The official documentation uses a series of kubeadm configuration files, one for each etcd cluster member, to control how the utility creates the necessary certificates and configuration files. The user is instructed to use these configuration files on a single system to generate the certificates for all the cluster members. This works fine, with one caveat: each of the certificates will have an extra hostname—the hostname of the system being used to generate the certificates—encoded in the certificate.

    Instead of generating all the certificates on a single host, I prefer to generate the certificates on each host. This does require distributing the CA certificate and key to all three hosts, but it avoids the extraneous hostname on the certificates that results from generating all the certificates on the same host. One could also remove the CA key from the hosts after the certificates are generated, if there were concerns about it being copied too widely.

    Here’s the kubeadm configuration file I use, which is only very lightly modified from the one in the official documentation:

    apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
etcd: local: serverCertSANs: - "FQDN" peerCertSANs: - "FQDN" extraArgs: initial-cluster: ip-10-11-12-154=https://ip-10-11-12-154.us-west-2.compute.internal:2380,ip-10-11-48-148=https://ip-10-11-48-148.us-west-2.compute.internal:2380,ip-10-11-96-141=https://ip-10-11-96-141.us-west-2.compute.internal:2380 initial-cluster-state: new name: HOST listen-peer-urls: https://IP:2380 listen-client-urls: https://IP:2379 advertise-client-urls: https://FQDN:2379 initial-advertise-peer-urls: https://FQDN:2380

    (Note: the IP addresses above have been randomized and do not refer to actual instances in my account.)

    This configuration file is lightly modified to use fully-qualified domain names (FQDNs) where possible/supported by etcd. The listen-peer-urls and listen-client-urls settings require an IP address, but the other settings support FQDNs.

    Aside from populating the initial-cluster line—which has to list all the etcd cluster members—I copy this file unchanged to each host. On each host, I then customize the file using these commands:

    sed -i "s/FQDN/$(hostname -f)/g" kubeadm.yaml
sed -i "s/IP/$(hostname -i)/g" kubeadm.yaml
sed -i "s/HOST/$(hostname -s)/g" kubeadm.yaml

    Once the configuration file is appropriately customized for that particular host, then it’s just a matter of running the same commands as in the official documentation, just with slightly different parameters:

    kubeadm init phase certs etcd-server --config=kubeadm.yaml
kubeadm init phase certs etcd-peer --config=kubeadm.yaml
kubeadm init phase certs etcd-healthcheck-client --config=kubeadm.yaml
kubeadm init phase certs apiserver-etcd-client --config=kubeadm.yaml
kubeadm init phase etcd local --config=kubeadm.yaml

    Run these commands on each node, and you should end up with a working three-node etcd cluster.

    One other advantage of doing it this way is the potential for automation—the source config file is the same and can be distributed unchanged to each node, and the commands that are run on each host are the same and can be easily scripted (in fact, in some cases I’ve put all these commands into a quick-and-dirty shell script).

    Hit me on Twitter if you have any questions or any feedback. Thanks for reading!

    …

    Read MoreAn Alternate Approach to etcd Certificate Generation with Kubeadm