Noah Masur's Site

Don't Bring Your Work MacBook To The Apple Store

Tue, 26 Nov 2024 16:28:36 -0700

It all started when I plugged in my MagSafe charging cable and saw that it was blinking orange. I looked at my Mac and noticed it was not charging at all. Rebooting didn’t help, or using a different charging cable.

So I decided to go to the Apple Store. I could have brought it to the IT department at work instead, but then I would have to setup a loaner machine while I waited for the repair. I was working remotely out of state anyway; plus, since it was just a broken charging port, I figured it would be an easy fix. Right?

Right?

First Visit: Bad Omens

The first warning sign of trouble that I should have noticed was when I brought in the machine: they said they needed to restart it to run a diagnostic, and they asked me for the firmware password to unlock the bootloader. I told them that the firmware password was controlled by JAMF, and I would need to ask someone at the office to send me the latest version of the password (it was outside of office hours).

The Apple rep told me that they could order the part for me anyway so it’s ready when I came back in. I shrugged but I knew that would be heading back home by the time the part arrived. I could still charge my computer with a USB-C cable, so I put it off until later.

Second Visit: The Monster Awakens

I spoke to the company IT department and asked how I can get the JAMF password. They said that it rotates every 15 minutes, so someone would need to be on hand to respond to my request for it during my visit with Apple.

I decided to wait until a Friday afternoon to go to the store because I could drop it off for the weekend and pick it up after a day or two without losing the ability to work. I made the mistake of choosing the Apple Store that was 25 minutes away because I thought I would only have to be there twice.

When I brought the machine, they were able to run the diagnostic using the password I got from my colleague. Of course, like the previous store, they had to order the new charging port so I would have to bring my device back in a few days.

Third Visit: The Horror Grows

I dropped off my laptop at the Apple Store and make my way back home, satisfied that this slightly annoying problem will be alleviated.

However, the next day I receive a strange email from the Apple Store stating the following:

We have some important information about the service of your product. Please get in touch as soon as possible—you can contact us at (123) 456-7890.

That seemed a little less than ideal, but I wasn’t too worried. I called the number and found an automated message directing me to various lines. I mentioned that I was returning a call from the Genius Bar and I was transferred to another line.

The line rang for 5 minutes straight and then hung up on me. There was no hold music, just ringing. Then click and the call was over.

Confused, I called the number again. Directed to the repair department. Same response. A third time, after 20 minutes of trying. No difference.

I called the automated number again and this time asked for the Sales department. I was immediately sent to a real person, although the Sales department was apparently centrally located and not connected to my particular Apple Store. I explained to the Sales rep what happened and how I was trying to call back the Genius Bar at a particular store location, and they very kindly helped connect me to someone over there via a direct line of some sort. I was very grateful as this was not in their job description but they chose to help me out anyway.

Getting in touch with the Genius Bar, what did I find out? Yup, they needed to run a final diagnostic to hand over the computer and therefore they needed the JAMF password again. Of course.

Fourth Visit: A Creeping Sensation

I spend another 25 minutes going to the Apple Store on Monday morning, ready to pick up my computer. I had informed the IT team that I would need the password again so I just had to wait for work hours to begin.

I got the password and had them reboot the machine to run the diagnostic. They plugged in the charging cable and I noticed it was still blinking orange like it had before. That did not seem like a good sign. Did the repair technicians fail to even attempt to charge the device after replacing the cable?

The diagnostic did not pass. The technician told me that the real issue was almost certainly with the logic board, whose contact point with the charging port may have shorted out or something.

Well, great.

They said they would order the new logic board, and I would just have to come in again. They said that the NVME drive is soldered to the board and will be replaced as well, meaning I need to make sure I backup everything off the device.

So I thanked them and left to head into work.

Fifth Visit: Something Lurking Just Ahead

I wait for another Friday afternoon, after preparing my backups, and leave the laptop for repair once again. I was ready to have this over with.

On Saturday, I once again receive the dreaded email:

We have some important information about the service of your product. Please get in touch as soon as possible—you can contact us at (098) 765-4321.

This time I know what to expect. I don’t bother calling. I just have to come in during work hours and get the password again to run the diagnostic once more. So I wait patiently.

Sixth Visit: Absolute Terror

Another Monday morning and another 25 minutes travel to the Apple Store for my ritual encounter with the repair team.

However, this time they did not run the diagnostic. Instead, they told me something unusual. Apparently, according to the repair technician who was working on the board, they are not capable of replacing a logic board that is protected by a firmware password.

They said that the firmware password would need to be removed, which means that it will need to be essentially unrenrolled from JAMF.

This was a non-starter.

Somehow neither the technician who ran the diagnostic and ordered the part nor the technician who accepted my dropped off machine had understood that this was the case.

I knew immediately at that point that I had to give up with the Apple Store. This whole mess probably should have gone through the IT RMA process the entire time and I was hopelessly naive.

So the lesson is thus: Don’t do what I did. Don’t try to bring a managed computer to the Apple Store for repair.

Nix Turns Installing Software On Its Head

Thu, 21 Nov 2024 17:04:18 -0700

There are plenty of benefits to using the Nix package manager, NixOS, and the rest of the Nix ecosystem. However, for people unfamiliar with Nix, one of the fundamental paradigm shifts is how Nix changes what it means to install a software package.

Traditional Package Management

A traditional package manager will install software programs at the user’s whim to a designated location on disk. These files are automatically exposed to your environment via a PATH or simply placed in a known location to be consumed.

/usr/bin/python3

This leads to three problems:

There is no coupling between the environment and the package manager. So if a package is required by an environment or another package dependency, you simply have to hope that you already installed it. Now you have an environment that cannot guarantee that all of its dependencies are available.
Since you cannot link a package to its dependant environments, you can never be sure if it can be safely removed from your system. What happens if you uninstall a package that is required by another program or environment? To avoid the risk of breaking things, you usually end up with a growing pile of bloat on your system.
For software placed in a standard location, you cannot install more than one version of the same package. Not only does this make managing multiple environments painful, but sometimes two or more packages might be incompatible if they both depend on different versions of the same libraries.

Nix Architecture

These problems are moot with the Nix architecture. This is because Nix doesn’t really have the concept of “installing” a program. Instead, packages are built (or downloaded from a cache) and placed in the Nix store, and packages are also exposed to the environment.

The Nix Store

The Nix store is simply a location on your system (/nix/store/) where software that is built or downloaded by Nix resides. This is an immutable file system that can only be altered by the Nix daemon. Every package sits in a specific build directory with a unique name based on its package name and a hash (such as pwvfrkynkyhbnidikifjz5skxq892g5a-ffmpeg-headless-6.1.1-lib/).

These programs can all be accessed with the full Nix store path, but doing so would be incredibly tedious and impractical.

Nix Environments

Every tool in the Nix ecosystem has a way of exposing packages from the Nix store to the current environment, such as NixOS, Home-Manager, Nix profiles, or Nix shells.

With these tools, you use the Nix language to declare the environment’s or program’s dependencies, and Nix will automatically resolve them to the path in the Nix store and use them as shared libraries or place them (or symlink them) onto your current PATH to be used like normal programs.

The Cool Part

Here is the cool part: if you declare a program as a depencency for your environment, your system, or another program, Nix automatically build (or download) any dependencies that are missing from the Nix store.

This solves problem 1: you have a guarantee (after build time) that your environment includes the dependencies you have declared. What about problems 2 and 3?

For problem 2, Nix doesn’t worry about always keeping the exact set of packages built in the Nix store. Nix keeps track of which dependencies are required by your different environments, and when you choose to garbage collect it will simply purge the existing packages that are not declared as dependencies of anything else. You can set the garbage collector to run on a schedule; if you accidentally purge too aggressively, the worst case scenario is that you have to wait for Nix to rebuild or redownload a few packages.

For problem 3, the uniqueness of the Nix store paths allow you to reference multiple packages with the same name. You can expose one version of a package to one project shell environment and another version to a specific dependant package, while another lives in your default shell. If they all happen to require the exact same version, then great — you get to save some space. But otherwise, you don’t ever have to think about it.

Fundamental Benefits

The Nix ecosystem has a ton of benefits: declarative configuration, build guarantees, Nixpkgs availability, rollbacks, lazy functional modules, temporary environments, but fundamentally they all are sourced from rethinking, from the ground up, what software installation means.

Package Language Servers Into Neovim Using Nix

Sat, 16 Nov 2024 11:25:05 -0700

The introduction of the language server protocol has made it easier to use a variety of different text editors for programming with hints and autocompletion instead of requiring more complex IDEs.

Unfortunately, it also means that most text editors don’t come bundled with their own language server and instead expect it to be installed separately on your machine. While there are some tools that intend to make it easier to install language servers from inside Neovim, such as mason.nvim or lazy-lsp.nvim, I prefer the guarantee that the Neovim package contains everything that I need to use the LSP at install time.

nix2vim

The flake nix2vim is a framework for building a Neovim package and Lua configuration with Nix. It comes with a function called neovimBuilder that can be paired with imported modules to add plugins, setup and use statements, vim options settings all in the Nix language for translation into Lua. You can also add lua sections if you need to bail out to normal Lua code.

One of the benefits of this is that you can use Nix expressions inside of the Neovim configuration, which means that nixpkgs can be included directly and rendered into Nix store paths when the final output is transpiled to Lua.

LSP Configuration

It’s easy enough to configure the LSP and include its package at the same time. In my config, I include the language server program alongside its settings:

use.lspconfig.lua_ls.setup = dsl.callWith {
 settings = {
 Lua = {
 diagnostics = {
 globals = [
 "vim"
 "hs"
 ];
 };
 };
 };
 capabilities = dsl.rawLua "require('cmp_nvim_lsp').default_capabilities()";
 cmd = [ "${pkgs.lua-language-server}/bin/lua-language-server" ];
};

In this case, I’m using dsl functions to mimic certain Lua calls and to bail out for more complex code. For the actual language server command, I’m identifying the store path to the nixpkgs object and including the program directly.

When the Neovim package is built, the language server becomes a dependency, so therefore you have a guarantee that the LSP is ready when you launch Neovim. You can also imagine calling the Neovim package as a function and passing the specific version of the language server based on the needs of the project, and/or including only the language servers you need for those projects with a project-specific Neovim.

Using Hammerspoon as a macOS Window Manager

Fri, 15 Nov 2024 10:52:53 -0700

Before macOS got built-in window tiling features there weren’t too many great ways to control window panes.

You either had to pay for an app like Rectangle or Magnet and remember to download it whenever you setup a new computer, or use something like Tiles, or a full-featured window manager like Yabai.

However, since I was already using Hammerspoon for other automation, I figured it would be easiest to just repurpose it as a window management tool, partially inspired by this video.

Hammerspoon

Hammerspoon is an engine that allows you to write basic Lua scripts to interact with the UI and other elements of macOS. I use it to develop my own special keyboard shortcuts, such as:

A set of quick-launch keys for various applications.
Convert my CAPSLOCK key into a double CTRL/ESC utility key.
Dismiss alert notifications with a keypress after I’ve read them.

Window Management

Changing the window settings is pretty simple. After binding the modifiers and key with hs.hotkey.bind({ "alt", "ctrl", "cmd" }, "m", someFunction), you can then get the current focused window with hs.window.focusedWindow() and frame with win:frame(). If you want to maximize the window, use win:screen():fullFrame() to get the max size and set the frame to that size. Divide the max width by 2 and move the origin to the left or center to half-maximize (tile to one side).

In my setup, I have the following keybinds:

CMD + ALT + CTRL + n: Move window to next screen.
CMD + ALT + CTRL + b: Move window to previous screen.
CMD + ALT + CTRL + m: Maximize window on current screen.
CMD + ALT + CTRL + o: Half-maximize to the right.
CMD + ALT + CTRL + u: Half-maximize to the left.

Prebuilding and Running AWS Instances with NixOS, GitHub Actions, and Terraform

Thu, 14 Nov 2024 15:58:23 -0700

The typical strategy for automatically launching Linux VMs in AWS looks something like this:

Use Packer to create an EC2 instance, connect to it via SSH, run commands to configure the machine, snapshot the EC2 as an AMI, and then terminate the instance.
Use Terraform or another deployment script to launch a new EC2 instance using the AMI as a base.
Configure user data (cloud-init) to run initialization scripts on first boot.

This process is brittle, requires multiple steps, including launching a new EC2 instance multiple times. Instead, I like to prebuild a NixOS AMI and let Terraform import the image into AWS and launch the machine in a single action.

Prebuilding the Image

In my flake, I use nixos-generators to create an x86-64 Amazon image from my pre-configured NixOS configuration. I use nix build to create a .vhd disk image file which can be uploaded to S3 afterwards or picked up by Terraform and pushed to S3.

Importing the AMI

In order to generate a valid AMI, the .vhd file must be imported directly from S3. With Terraform, this can be done using the aws_ebs_snapshot_import resource.

Once the AMI is imported, you can reference it in a basic aws_instance resource just like any other EC2 launch.

Putting It All Together

Using a GitHub Actions workflow you can perform the following steps to automatically launch everything in one swoop:

Enable KVM in GitHub Actions in order to generate the image locally.
Build the image with nix build, using a cache if available.
Upload the image to S3, which can also be done in Terraform instead. One reason to include this step outside of Terraform is, if you want to sometimes skip building the image to save time, Terraform doesn’t have to expect the image to always be there on disk.
Run Terraform apply to import the image and launch the EC2 instance.
Get the host IP and wait for SSH to be ready in order to push content that does not belong in the Nix store (i.e. secrets).
Push secrets to the machine with SSH using the pre-generated SSH key placed in the config.
The systemd services will automatically start up, including registering their domain names with Cloudflare.

The instance is now running on AWS and ready to send or receive traffic!

Nextcloud NixOS Setup Overview

Tue, 06 Feb 2024 20:30:53 -0500

Here is my setup.

I just use services.nextcloud.enable = true to run Nextcloud, since I don’t run any of my services in containers or Flatpaks. Systemd feels most native to NixOS.

You get Nextcloud, Redis, and the MySQL database basically for free. I also use the Nix-packaged Nextcloud plugins and, for any missing, I pin their releases to my flake and add them as pkgs with an overlay.

The biggest change I made was to disable nginx because I already use Caddy as my reverse proxy for all my services. This means I had to write matching rules to convert the recommended nginx config into Caddy routes.

I wouldn’t suggest that everyone use this exact approach, but I do recommend starting with the native NixOS services and tweaking their settings to fit your needs rather than immediately jumping to containers or Flatpaks.

Caddy Cloudflare DNS on NixOS

Sun, 10 Sep 2023 13:12:26 +0000

If you serve Caddy from behind Cloudflare and enforce, you may run into an issue with auto-provisioning ACME SSL certs.

By default, Caddy uses the HTTP validation method which requires no setup but does involve serving traffic on HTTP / port 80, including through Cloudflare. I prefer Cloudflare to enforce using HTTPS / port 443 everywhere, which means that every time I want to validate a new cert I have to temporarily disable the HTTPS enforcement and/or set the SSL settings to “flexible” instead of “strict”.

For hands-free automation, this is a non-starter!

The solution is to switch from HTTP validation to TXT validation, which doesn’t require serving HTTP but does require updating your DNS records to receive an SSL cert.

Updating DNS with Caddy

Caddy has a plugin to connect to Cloudflare’s DNS service and automatically manage the records for cert validation, but it’s not packaged in NixOS.

So the next step is to recompile Caddy with the Cloudflare DNS plugin using an overlay. Here’s what my overlay looks like:

_final: prev:

let

 plugins = [ "github.com/caddy-dns/cloudflare" ];
 goImports =
 prev.lib.flip prev.lib.concatMapStrings plugins (pkg: " _ \"${pkg}\"\n");
 goGets = prev.lib.flip prev.lib.concatMapStrings plugins
 (pkg: "go get ${pkg}\n ");
 main = ''
 package main
 import (
 caddycmd "github.com/caddyserver/caddy/v2/cmd"
 _ "github.com/caddyserver/caddy/v2/modules/standard"
 ${goImports}
 )
 func main() {
 caddycmd.Main()
 }
 '';

in {
 caddy-cloudflare = prev.buildGo120Module {
 pname = "caddy-cloudflare";
 version = prev.caddy.version;
 runVend = true;

 subPackages = [ "cmd/caddy" ];

 src = prev.caddy.src;

 vendorSha256 = "sha256:mwIsWJYKuEZpOU38qZOG1LEh4QpK4EO0/8l4UGsroU8=";

 overrideModAttrs = (_: {
 preBuild = ''
 echo '${main}' > cmd/caddy/main.go
 ${goGets}
 '';
 postInstall = "cp go.sum go.mod $out/ && ls $out/";
 });

 postPatch = ''
 echo '${main}' > cmd/caddy/main.go
 cat cmd/caddy/main.go
 '';

 postConfigure = ''
 cp vendor/go.sum ./
 cp vendor/go.mod ./
 '';

 meta = with prev.lib; {
 homepage = "https://caddyserver.com";
 description =
 "Fast, cross-platform HTTP/2 web server with automatic HTTPS";
 license = licenses.asl20;
 maintainers = with maintainers; [ Br1ght0ne techknowlogick ];
 };
 };
}

The primary change we’re making here is pulling in the Go module for the plugin, and updating the resulting vendorSha256.

Once we have made our overlay (I gave it a separate pname above called caddy-cloudflare) we can use it in our Caddy settings.

services.caddy.package = pkgs.caddy-cloudflare;

You could also just override the caddy package and not bother to update services.caddy.package, but I like that 1) I have to choose to use it explicitly, and 2) I can conditionally enable this version of the package only for machines that use Cloudflare, in case I

In my previous post, I explained that I use the JSON config format instead of a traditional Caddyfile, which gives me more control over options as well as the ability to merge together routes from different services.

services.caddy = {
 adapter = "''"; # Required to enable JSON
 configFile = pkgs.writeText "Caddyfile" (builtins.toJSON {
 apps.http.servers.main = {
 listen = [ ":443" ];
 routes = config.caddy.routes;
 };
 });
};

Adding the following into the JSON configuration will enable the new Cloudflare DNS plugin as an ACME DNS provider, which will automatically create the necessary records to solve the LetsEncrypt verification challenges.

apps.tls.automation.policies = [{
 issuers = [{
 module = "acme";
 challenges = {
 dns = {
 provider = {
 name = "cloudflare";
 api_token = "{env.CF_API_TOKEN}";
 };
 resolvers = [ "1.1.1.1" ];
 };
 };
}];

However, we’ll need an API token for our Cloudflare account in order to make those changes to our DNS as securely as possible.

Setting the Cloudflare API Key

Check the Cloudflare docs for how to generate an API token from your profile. For our purposes, the token should have the following permissions:

Zone permission: DNS -> Edit
Zone resources: Include specific zone / all zones -> (Your zone)

You should take this API token and write it out into a secret text file with the following format:

CF_API_TOKEN=yourtokenhere

This is because we will load it as an environment file, so it must be a file that a shell can evaluate.

Next, you’ll need to securely deploy your new secret file to a location on your disk. You could use one of the following methods:

Manually copy the text file to a path on your target system.
Deploy using agenix or sops-nix.
Build your own secrets management tooling.

In any case, make sure the file permissions are set to be read by caddy:caddy (or whatever user is running the caddy service) with 0400 access.

Then you’ll need to set the following to load the secret as an environment file for the systemd service:

systemd.services.caddy.serviceConfig.EnvironmentFile = /path/to/your/secret

I’ve also found that I needed to enable CAP_NET_BIND_SERVICE to grant the systemd service the ability to bind to lower ports (such as 443):

systemd.services.caddy.serviceConfig.AmbientCapabilities = "CAP_NET_BIND_SERVICE";

At this point, your Caddy service should be able to modify DNS records and receive LetsEncrypt certificates automatically! Take a look at my Cloudflare configuration settings and my Caddy overlay as examples.

Nextcloud Behind Caddy on NixOS

Tue, 29 Aug 2023 11:56:26 +0000

Nextcloud can technically run behind any reverse proxy but their documentation is sparse and don’t include full examples.

The Nextcloud NixOS module automatically enables nginx by default. Since I run Caddy bound to 443 for the rest of my services, I didn’t want to have to proxy to a local nginx service just to hit Nextcloud. They have some documentation for using Apache httpd, but I had to adjust for Caddy.

Here is my full configuration on my system, but I’ll break it down to explain it in detail.

First, after enabling Nextcloud, you should at least have the following in your configuration.

services.nextcloud.config.trustedProxies = [ "127.0.0.1" ];

This allows any local reverse proxy (including nginx, Caddy, etc.) to connect to the Nextcloud service.

Next, we disable nginx, since enabling the Nextcloud module will enable nginx by default:

services.nginx.enable = false;

We have to make sure that Caddy’s user will have access to talk to the Nextcloud PHP service and access to the files served by Nextcloud.

services.phpfpm.pools.nextcloud.settings = {
 "listen.owner" = config.services.caddy.user;
 "listen.group" = config.services.caddy.group;
};
users.users.caddy.extraGroups = [ "nextcloud" ];

(Your users and groups for Caddy and Nextcloud may be different, so keep that in mind).

The next step is where things get serious because we have to generate Caddy’s config file. You could use the Caddyfile format for brevity, but I have chosen to generate a JSON file for a few reasons:

The format is easier to organize and manipulate from Nix expressions. I am serving multiple sites from the same Caddy service, so combining all routes into a single JSON file is cleanest for me with Nix.
The JSON format has more options that can give you more control over settings, especially when they differ between routes or hostnames.

My general Caddy setup looks like this — first, I establish a list of sets option called caddy.routes, so I can add them from services in multiple places:

options.caddy.routes = lib.mkOption {
 type = lib.types.listOf lib.types.attrs;
 description = "Caddy JSON routes for http servers";
 default = [ ];
};

Then I use this for my base Caddy config, sticking the routes into apps.http.servers.<something>.routes:

services.caddy = {
 adapter = "''"; # Required to enable JSON
 configFile = pkgs.writeText "Caddyfile" (builtins.toJSON {
 apps.http.servers.main = {
 listen = [ ":443" ];
 routes = config.caddy.routes;
 };
 });
};

The routes themselves are mostly written like the following, and can be added anywhere in your config (even multiple times, which will merge into one list automatically):

caddy.routes = [{
 match = [{ host = [ "my.host.name" ]; }];
 handle = [{
 handler = "reverse_proxy";
 upstreams = [{
 dial = "localhost:1234";
 }]
 }]
}]

In the above example, Caddy will match on the public hostname of your service, and then act as a reverse-proxy by connecting to the local port 1234 on your machine where the service is running. This is how I setup most of my web services.

With Nextcloud, things will be a little different. The best Caddy reference I found was this Reddit comment with a working Caddyfile. However, we need to translate it for our JSON configuration.

Step one is to set a single route with everything inside the handle attribute.

caddy.routes = [{
 match = [{ host = [ "your.nextcloud.domain" ]; }];
 handle = [{
 handler = "subroute";
 routes = [
 # ... Everything goes in here
 ];
 }];
 terminal = true;
}];

All of our Nextcloud routes I describe below will be subroutes of the original handle, which matches on the hostname of our Nextcloud service.

The first subroute sets variables and headers for the other subroutes. The variable is required for working with apps, and the header enforces the use of HTTPS on the browser.

{
 handle = [
 {
 handler = "vars";
 root = config.services.nextcloud.package;
 }
 {
 handler = "headers";
 response.set.Strict-Transport-Security =
 [ "max-age=31536000;" ];
 }
 ];
}

The next subroute makes use of this root variable to serve content from the /nix-apps/ and /store-apps/ directories, which are the built-in and marketplace plugins for Nextcloud. You will likely need this even if you are just using Nextcloud out of the box.

{
 match = [{ path = [ "/nix-apps*" "/store-apps*" ]; }];
 handle = [{
 handler = "vars";
 root = config.services.nextcloud.home;
 }];
}

Next, we have a subroute for managing CardDAV and CalDAV traffic (for contacts, calendars). These URLs are redirected to a specific PHP location explained in the official docs.

{
 match =
 [{ path = [ "/.well-known/carddav" "/.well-known/caldav" ]; }];
 handle = [{
 handler = "static_response";
 headers = { Location = [ "/remote.php/dav" ]; };
 status_code = 301;
 }];
}

The next subroute is used to deny access to sensitive or internal-only files by returning a 404 error response.

{
 match = [{
 path = [
 "/.htaccess"
 "/data/*"
 "/config/*"
 "/db_structure"
 "/.xml"
 "/README"
 "/3rdparty/*"
 "/lib/*"
 "/templates/*"
 "/occ"
 "/console.php"
 ];
 }];
 handle = [{
 handler = "static_response";
 status_code = 404;
 }];
}

We also need a subroute to redirect /index.php requests to the base homepage instead of trying to use a PHP file that doesn’t exist.

{
 match = [{
 file = { try_files = [ "{http.request.uri.path}/index.php" ]; };
 not = [{ path = [ "*/" ]; }];
 }];
 handle = [{
 handler = "static_response";
 headers = { Location = [ "{http.request.orig_uri.path}/" ]; };
 status_code = 308;
 }];
}

For incoming requests, we rewrite their paths to be relative to the current directory.

{
 match = [{
 file = {
 split_path = [ ".php" ];
 try_files = [
 "{http.request.uri.path}"
 "{http.request.uri.path}/index.php"
 "index.php"
 ];
 };
 }];
 handle = [{
 handler = "rewrite";
 uri = "{http.matchers.file.relative}";
 }];
}

Of course, we eventually have to send PHP traffic to the actual PHP service, which in this case is not listening on a local port by default, but on a UNIX socket.

{
 match = [{ path = [ "*.php" ]; }];
 handle = [{
 handler = "reverse_proxy";
 transport = {
 protocol = "fastcgi";
 split_path = [ ".php" ];
 };
 upstreams = [{ dial = "unix//run/phpfpm/nextcloud.sock"; }];
 }];
}

Finally, all other requests are served simply as static files:

{ handle = [{ handler = "file_server"; }]; }

That’s it! Now Caddy will serve as the ingress to Nextcloud directly.