What caused the error?

The ChromeOS Secure Shell app runs inside an isolated browser runtime (Native Client/WebAssembly), which makes its file parser far more strict than standard OpenSSH on Linux. It turns out two separate issues can trigger this exact error when importing a key.

How to fix it

First, the ChromeOS parser requires a strict trailing newline character (\n) at the very end of the private key file. If your key ends immediately after —–END OPENSSH PRIVATE KEY—– without a final blank line, the parser fails to detect the end tag. Just add an extra line at the end of the key-files, that’s all!

The problem

Two ways a service on a remote box can be listening:

• Bound to 0.0.0.0 or the LAN IP: reachable from anywhere on that network, including my Tailscale workstation.

• Bound to 127.0.0.1: only reachable from that machine itself, hence the SSH -L forward in the first place.

Mine was the second case. So instead of pointing Tailscale Serve at the server directly, I needed the workstation to run its own tunnel into that loopback port, then serve that local copy.

How to do it

Step 1: On the workstation (not my laptop), open a tunnel to the server’s loopback port.

ssh -N -L 8080:localhost:8080 user@192.168.1.50 -p 22

Step 2: Still on the workstation, point Tailscale Serve at the tunnel’s local end instead of the server’s IP.

sudo tailscale serve --service=svc:remote-webapp --tcp=8080 tcp://localhost:8080

Step 3: Confirm the port shows up as forwarded.

tailscale serve status

Now the chain is: tailnet device to remote-webapp.your-tailnet.ts.net:8080, which hits the workstation’s tailnet interface, which hits its own localhost:8080, which is the live end of an SSH tunnel into the server’s loopback service.

Making the tunnel survive reboots

Running that ssh -L command by hand is fine until the connection drops or the workstation reboots, then the whole chain is broken silently. A systemd user unit fixes that.

# ~/.config/systemd/user/remote-tunnel.service
[Unit]
Description=SSH tunnel to remote server (8080 -> localhost:8080)
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=4

[Service]
Type=simple
ExecStart=/usr/bin/ssh -N -i /home/user/.ssh/some_key -o IdentitiesOnly=yes -o BatchMode=yes -o ConnectTimeout=10 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o StrictHostKeyChecking=accept-new -L 8080:localhost:8080 -p 22 user@192.168.1.50
Restart=always
RestartSec=15

[Install]
WantedBy=default.target

A couple of flags are doing more than they look like. ExitOnForwardFailure=yes matters because without it, SSH can come up “successfully” even when the port bind failed, sitting there alive but useless, and Restart=always never triggers because systemd thinks it’s fine. ServerAliveInterval and ServerAliveCountMax exist for the same reason: a dead connection (router blip, server reboot) can otherwise sit as a zombie process instead of exiting and letting systemd restart it.

Enable it as a user unit, since everything else on this workstation already runs rootless:

mkdir -p ~/.config/systemd/user
systemctl --user daemon-reload
systemctl --user enable --now remote-tunnel.service

Testing it

Check the tunnel process is actually up:

systemctl --user status remote-tunnel.service

Active: active (running) since … Main PID: 48213 (ssh)

Then confirm the tailnet path end to end from another device on the tailnet:

curl remote-webapp.your-tailnet.ts.net:8080

If that returns the expected response, the whole chain (tailnet to workstation to loopback tunnel to server) is working.

I bought a cheap Chromebook because I was just curious about, got it very cheap, almost free, and quickly realized VS Code’s desktop app is not something you want to run on a dual-core Celeron with 4GB of RAM. The plan instead: run the editor on one of my homelab boxes and just hit it from the browser. code-server does exactly that, but getting it installed on Fedora CoreOS without touching the base image (and without exposing it past Tailscale) took a bit more care than the install docs let on.

Why not just use the installer as-is

code-server ships a one-line installer:

curl -fsSL https://code-server.dev/install.sh | sh

Looks harmless, but if you actually read the script, on Fedora it defaults to this path:

fedora | opensuse) npm_fallback install_rpm ;;

which runs sudo rpm -U package.rpm under the hood. That’s a system-wide install requiring root, and it fights rpm-ostree’s transactional model on an immutable host. Not what I wanted on CoreOS. The script does have a standalone mode that installs into ~/.local with no root and no package manager involved at all, it just isn’t the default.

How to do it?

Step 1: Install in standalone mode, which keeps everything inside your home directory:

curl -fsSL https://code-server.dev/install.sh | sh -s -- --method=standalone

Step 2: Make sure ~/.local/bin is actually on your PATH (CoreOS’s default profile doesn’t include it):

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Step 3: Write a minimal config at ~/.config/code-server/config.yaml that only listens on the machine’s localhost or your private VPNs address, Tailscale address, not on all interfaces:

bind-addr: 100.x.x.x:8080
auth: password
password: some-long-random-string
cert: false

I used a real password here instead of auth: none. Tailscale ACLs already gate who can reach the tailnet, but binding to the Tailscale IP directly (rather than 127.0.0.1 plus some separate tunneling step) means the port is only reachable at all through the tailnet interface, so a password is just a second layer that costs nothing. Though, it is not safe as it is written in plain text in the home folder.

Step 4: Set it up as a systemd user service so it survives reboots without needing an active login shell:

[Unit]
Description=code-server
After=network-online.target

[Service]
ExecStart=%h/.local/bin/code-server
Restart=always

[Install]
WantedBy=default.target

Save that as ~/.config/systemd/user/code-server.service, then:

systemctl --user daemon-reload
systemctl --user enable --now code-server
sudo loginctl enable-linger $USER

The loginctl enable-linger step matters, without it the service dies as soon as you log out of the SSH session that started it.

Testing it

From the Chromebook, over Tailscale, not the public internet:

curl -I http://100.x.x.x:8080

HTTP/1.1 200 OK

And from the browser, hitting http://100.x.x.x:8080 (or the MagicDNS name if you’ve set that up) should drop you straight into the login prompt, then the full VS Code UI, running entirely on the remote box.

Serving it with tailscale serve instead of a raw bind

Binding directly to the Tailscale IP works, but there’s a cleaner way that also gets you HTTPS with a proper cert: tailscale serve with a named Service. Instead of exposing the raw 100.x.x.x:8080 address, this gives code-server a real HTTPS URL on your tailnet’s MagicDNS domain.

Step 1: Point code-server at localhost only, since tailscale serve will handle the tailnet-facing side:

bind-addr: 127.0.0.1:8080
auth: password
password: some-long-random-string
cert: false

Step 2: Advertise it as a named Service:

tailscale serve --service=svc:code-server --bg --https=443 http://127.0.0.1:8080

That should return something like:

tailscale serve --service=svc:code-server --bg --https=443 http://127.0.0.1:8080

Available within your tailnet: https://code-server.your-tailnet.ts.net/

The --service=svc:code-server bit is what makes this different from a plain tailscale serve, it names the thing as a proper Service rather than just exposing a port on the current node, which matters if you ever want to move it to another machine later without changing the URL everyone (well, you) connects to.

One thing worth calling out: before --service=svc:code-server will actually work, the Service itself needs to exist in your tailnet, you can’t just invent a name on the command line and have it appear. Head to the Tailscale admin console, under Services, and create one named code-server there first (or via the declarative config file if you’re managing your tailnet that way). Once it’s defined and your node is approved to host it, the tailscale serve --service=svc:code-server ... command above will attach to that Service rather than failing or silently doing nothing.

Step 3: Check it’s actually up:

tailscale serve status

Step 4: If you need to take it down later, don’t just kill the service, drain it first so any open connections close gracefully:

tailscale serve --service=svc:code-server --https=443 off

One gotcha: the --bg flag matters if you want this to survive reboots or tailscale down/up cycles without manual intervention. Without it, restarting Tailscale drops the serve config and you have to re-run the command by hand.

How to uninstall it

Since it’s a standalone install with no package manager involved, uninstalling is just removing files and the service:

Step 1: Stop and disable the service:

systemctl --user disable --now code-server

Step 2: Remove the service file:

rm ~/.config/systemd/user/code-server.service
systemctl --user daemon-reload

Step 3: Remove the binary and installed files:

rm -rf ~/.local/lib/code-server-*
rm ~/.local/bin/code-server

Step 4: Remove config and data (your settings, extensions, etc.):

rm -rf ~/.config/code-server
rm -rf ~/.local/share/code-server

Step 5 (optional): Clear the install cache:

rm -rf ~/.cache/code-server

Step 6 (optional): If you enabled lingering just for this service and don’t need it for anything else running under your user:

sudo loginctl disable-linger $USER

That’s it, nothing touches the base CoreOS image since it was never involved in the first place. If you also set a Tailscale ACL rule specifically to allow reaching port 8080, worth cleaning that up too so it doesn’t linger as an unused rule.

Notes

• The installer’s default “detect” mode will try sudo rpm -U on Fedora. Always pass --method=standalone on CoreOS or anything immutable, or you’ll get a permission prompt you didn’t expect.
• There’s no auto-update mechanism with the standalone method. Updating means re-running the install script (it pulls whatever’s latest and just symlinks the new binary in) and restarting the service. Old versions pile up quietly in ~/.local/lib until you clean them out by hand.
• Binding to 127.0.0.1 and expecting Tailscale to somehow expose it doesn’t work on its own, you either bind directly to the Tailscale interface IP (what I did here) or use tailscale serve in front of a loopback-bound service. Worth knowing before you spend ten minutes wondering why the port is unreachable.
• code tunnel (Microsoft’s own tool) is a faster path to the same result, but it routes traffic through Microsoft’s relay servers instead of staying inside your own network. Given everything else here already runs on Tailscale, self-hosting code-server was the more consistent choice.

Why the official instructions don’t apply here

networkd-dispatcher is a hook mechanism for systemd-networkd. uCore doesn’t use systemd-networkd, it uses NetworkManager, same as regular Fedora Workstation. The good news is NetworkManager has had its own equivalent dispatcher mechanism for years, it’s already enabled by default, and you don’t need to layer any extra package to use it.

Setting up the NetworkManager dispatcher script

NetworkManager runs scripts from /etc/NetworkManager/dispatcher.d/ in alphabetical order whenever an interface changes state (up, down, connectivity change, etc). Since /etc is writable and survives rpm-ostree deployments, the script lives there permanently, same as your /etc/NetworkManager/system-connections/ files.

Create the script:

sudo mkdir -p /etc/NetworkManager/dispatcher.d
sudo tee /etc/NetworkManager/dispatcher.d/50-tailscale <<'EOF'
#!/bin/sh

if [ "$2" = "up" ] || [ "$2" = "connectivity-change" ]; then
    NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
    ethtool -K "$NETDEV" rx-udp-gro-forwarding on rx-gro-list off
fi
EOF

Then fix ownership and permissions. NetworkManager silently refuses to run dispatcher scripts that are group or world writable, or not owned by root, so this isn’t optional:

sudo chown root:root /etc/NetworkManager/dispatcher.d/50-tailscale
sudo chmod 0755 /etc/NetworkManager/dispatcher.d/50-tailscale
sudo restorecon /etc/NetworkManager/dispatcher.d/50-tailscale

That last restorecon call matters more than it looks. SELinux expects a specific context on dispatcher scripts, and if it’s wrong the script just won’t run, with no error telling you why.

Testing it

Run it manually first before trusting the automatic trigger:

sudo /etc/NetworkManager/dispatcher.d/50-tailscale
echo $?

0

A 0 means it ran clean. If ethtool isn’t installed (uCore’s base image is minimal, it’s not guaranteed to be there), you’ll get a command not found error instead. Check with which ethtool; if it’s missing, layer it with rpm-ostree install ethtool and reboot, or run it from a toolbox container if you’d rather not layer packages on the host.

Next, confirm the dispatcher service itself is alive:

systemctl status NetworkManager-dispatcher

Don’t panic if this shows inactive (dead). It’s D-Bus activated, meaning it spawns on demand when NetworkManager fires an event, does its thing, then exits. That’s normal, not broken. If it’s masked or disabled outright though, turn it on with sudo systemctl enable --now NetworkManager-dispatcher.service.

To confirm it actually fires and applies the setting, bounce the relevant interface and check the flags:

nmcli connection down enp1s0 && nmcli connection up enp1s0
ethtool -k "$(ip -o route get 8.8.8.8 | cut -f 5 -d ' ')" | grep -E "rx-udp-gro-forwarding|rx-gro-list"

rx-udp-gro-forwarding: on rx-gro-list: off

If you don’t see that, tail the dispatcher’s log while you reconnect the interface, it’ll tell you if the script is even being invoked:

journalctl -u NetworkManager-dispatcher -f

Notes

• If you’ve got a dual-NIC box (internet-facing NIC plus a second one for LAN or a shared connection), double check $NETDEV resolves to the actual uplink interface, not the LAN-facing one. The ip -o route get 8.8.8.8 trick handles this correctly on its own since it follows the real default route, but worth a sanity check the first time.
• Tailscale’s upstream doc assumes a single-NIC box. On multi-NIC setups just make sure the dispatcher script is targeting the interface that’s actually acting as your exit-node or subnet-router uplink.
• The permission and SELinux context steps aren’t optional extras, skip either one and the script fails silently with no obvious error in the logs, which is a fun way to lose twenty minutes.

Setting Up the Proxy

To route traffic from my laptop through the workstation and into the non-Tailscale server, I needed to configure both the Tailscale control panel and the workstation itself.

Step 1: I want to my Tailscale Admin Console and create a new Service. I named it something descriptive like svc:my-office-local-server and assign the incoming port as tcp:22.

Step 2: On my remote workstation (same physical network of the shared server), I ran the Tailscale serve command to forward incoming Tailnet traffic over the local physical network to the target machine.

sudo tailscale serve --service=svc:my-office-local-server --tcp=22 tcp://192.168.1.50:22

Available within your tailnet:

|-- tcp://my-office-local-server.tails-scales.ts.net:22 (TLS over TCP)
|-- tcp://<tailscale IPv4>:22
|-- tcp://<tailscale IPv6>:22
|--> tcp://192.168.1.50:22

Serve started and running in the background.
To disable the proxy, run: tailscale serve --service=svc:my-office-local-server --tcp=22 off
To remove config for the service, run: tailscale serve clear svc:my-office-local-server 

Perhaps you’ll need to approve the connection in your Tailnet console.

Testing It

Once the service is active and bound, I can attempt to connect from my remote pc or any other device on my Tailnet (if my ACLs allow it).

ssh username@my-office-local-server -p 22

Last login: Thu Aug 20 16:15:02 2026 from 100.64.0.5 username@office-server:~$

And as simple as that, there’s no need for me to remember IPs or setting ssh-config files for remote connections on each personal machine.

How to do it?

Solution, create a rule

sudo tee /etc/NetworkManager/conf.d/00-wifi-powersave.conf << EOF > /dev/null
[connection]
wifi.powersave=2
EOF

sudo systemctl restart NetworkManager.service

What does each line do?

| Line | Function | |——-|———| | sudo tee ... << EOF | Writes root file with heredoc (avoids Permission denied) | | wifi.powersave=2 | Disables power-save globally (2=off, 3=on) | | restart NetworkManager | Applies changes immediately |

Verify it works

# 1. File created
cat /etc/NetworkManager/conf.d/00-wifi-powersave.conf

# 2. Power management OFF
iwconfig wlp2s0 | grep "Power Management"

# 3. Test Tailscale
tailscale ping <remote-IP>

# for Fedora
iw dev wlp2s0 get power_save

wifi.powersave values

0 = Default (automatic)
1 = Don't touch
2 = OFF (this is what we want) ✅
3 = ON (avoid)

Note: Related to this gist.github

Running Glance with Podman

Glance listens on port 8080 (as of today, at least) in its container. Binding that port only to loopback keeps it off the LAN; Tailscale Serve will provide the HTTPS endpoint for devices in the tailnet. Glance’s upstream image uses /app/config for its configuration files. github

Step 1: Create a working directory and configuration directory.

mkdir -p ~/containers/glance/config
cd ~/containers/glance

Step 2: Create compose.yml.

services:
  glance:
    container_name: glance
    image: docker.io/glanceapp/glance:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./config:/app/config:Z

The :Z volume suffix relabels the bind-mounted directory for SELinux, which avoids the usual Fedora-family “permission denied” surprise when the container tries to read the config.

Step 3: Start it with Podman Compose.

podman compose up -d

Container glance starts and port 127.0.0.1:8080 is published on the host.

Adding feeds

Create config/glance.yml with one page and a couple of feed widgets. Glance’s feed widget accepts feed URLs, optional titles, and item limits. raw.githubusercontent

This is only an example because i will not share my own personal setup

pages:
  - name: Home
    columns:
      - size: small
        widgets:
          - type: rss
            title: Research and climate
            limit: 8
            feeds:
              - url: https://www.nature.com/nclimate.rss
                title: Nature Climate Change
              - url: https://agupubs.onlinelibrary.wiley.com/feed/19422466/most-recent
                title: AGU Earth and Space Science

      - size: full
        widgets:
          - type: rss
            title: Infrastructure
            limit: 8
            feeds:
              - url: https://www.redhat.com/en/rss/blog/channel/red-hat-enterprise-linux
                title: Red Hat Enterprise Linux
              - url: https://www.cncf.io/feed/
                title: CNCF

      - size: small
        widgets:
          - type: videos
            title: YouTube
            channels:
              - UCg6gPGh8HU2U01vaFCAsvmQ
              - UCR-DXc1voovS8nhAvccRZhg

The videos widget uses YouTube channel IDs rather than a normal channel URL. A practical way to find one is to open the channel’s page source or use YouTube’s channel URL after it resolves to a /channel/UC... address. Glance also supports a YouTube search URL pattern where a widget needs search-based discovery rather than a fixed channel. raw.githubusercontent

Restart the container after editing the config.

podman compose restart glance

Testing it

First, verify that Glance is answering locally.

curl -I http://127.0.0.1:8080

HTTP/1.1 200 OK

Then check the container’s parsed configuration and feed errors, if any.

Serving it through Tailscale

Tailscale Serve can reverse-proxy a local HTTP service to an HTTPS URL that is reachable only inside the tailnet. It supports a local port or loopback URL as the proxy target. tailscale

Step 1: Confirm that Tailscale is connected on the host.

tailscale status

The current machine appears as a connected node in the tailnet.

Step 2: Point Tailscale Serve at Glance’s loopback-only port.

sudo tailscale serve http://127.0.0.1:8080

Available within your tailnet:

https://<machine-name>.<tailnet-name>.ts.net

Step 3: Inspect the active Serve configuration.

tailscale serve status

The status should show HTTPS traffic being proxied to http://127.0.0.1:8080.

Open the displayed https://<machine-name>.<tailnet-name>.ts.net address from another Tailscale device. The dashboard should load over HTTPS without exposing port 8080 to the local network or public internet. tailscale

Management commands

Notes

• Keep the host binding as 127.0.0.1:8080:8080; changing it to 8080:8080 makes Glance reachable directly on every network interface.
• If SELinux blocks the bind mount on Fedora, ensure the volume ends in :Z; this was the missing piece when a container could start but could not read its mounted config.
• tailscale serve is tailnet-only. Do not use tailscale funnel unless the goal is deliberate public exposure; Funnel is the internet-facing counterpart. tailscale
• Feed availability is outside the container’s control. If one widget is empty, test its RSS URL directly before assuming Glance is broken.

That is enough dashboard infrastructure for one afternoon.

The Screen Off Command

KDE uses kscreen-doctor to control display power states safely on both Wayland and X11:

kscreen-doctor --dpms off

This command tells the display server to turn off the monitor’s signal without suspending the system, locking the session, or interrupting any running processes.

Create a Custom Application Launcher

1. Open the KDE Menu Editor
2. Create a new item.
3. Set the Name field to something like Turn off screen.
4. Set the Command field to:

   kscreen-doctor --dpms off
   

5. Assign an icon (a monitor/display icon) for quick visual recognition. Merely optional.
6. Save the entry.

How to do it?

Creating the sed rules file

Create the file that will contain the replacement regular expressions:

touch ~/.privacy_action.sed
nano ~/.privacy_action.sed

Paste the following content (sed basic syntax, control characters escaped with \):

# --- EMAILS ---
s/[a-zA-Z0-9._%+-]\+@[a-zA-Z0-9.-]\+\.[a-zA-Z]\{2,\}/EMAIL_REDACTED/gI

# --- ORCID (dash-numeric, must be locked in before phone regex runs) ---
s/\b[0-9]\{4\}-[0-9]\{4\}-[0-9]\{4\}-[0-9]\{3\}[0-9X]\b/ORCID_REDACTED/g

# --- TAILSCALE IPs (dotted-numeric, must be locked in before phone regex runs) ---
s/\b100\.\(6[4-9]\|[7-9][0-9]\|1[01][0-9]\|12[0-7]\)\.[0-9]\{1,3\}\.[0-9]\{1,3\}\b/TAILSCALE_IP_REDACTED/g

# --- GENERIC IPv4 ---
s/\b\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\b/IP_REDACTED/g

# --- MAC ADDRESSES ---
s/\b\([0-9a-f]\{2\}[:-]\)\{5\}[0-9a-f]\{2\}\b/MAC_REDACTED/gI

# --- IPv6 ---
s/\b\([0-9a-f]\{1,4\}:\)\{3,7\}[0-9a-f]\{1,4\}\b/IPV6_REDACTED/gI
s/\b\([0-9a-f]\{1,4\}:\)\{1,7\}:\([0-9a-f]\{1,4\}:\)*[0-9a-f]\{0,4\}\b/IPV6_REDACTED/gI
s/::\([0-9a-f]\{1,4\}:\)\{1,7\}[0-9a-f]\{1,4\}\b/IPV6_REDACTED/gI
s/\(^\| \)::1\b/\1IPV6_REDACTED/g

# --- TAILSCALE DOMAINS ---
s/\b[a-zA-Z0-9_-]\+\.\(ts\|tailscale\)\.net\b/TAILSCALE_REDACTED/gI

# --- SOCIAL MEDIA / GITHUB ---
s/@[a-zA-Z0-9_]\{3,\}/@USER_REDACTED/g
s|github\.com/[a-zA-Z0-9_-]\+|github.com/USER_REDACTED|gI

# --- USERS AND HOSTNAMES ---
s/\b\(my-username\|root\|admin\)\b/USER_REDACTED/gI
s|/home/[a-zA-Z0-9_-]\+|/home/USER_REDACTED|g
s|/var/home/[a-zA-Z0-9_-]\+|/var/home/USER_REDACTED|g
s/\b\(fedora-bazzite\|mi-laptop\|router-openwrt\)\b/HOST_REDACTED/gI
s/\b[a-zA-Z0-9_-]\+@[a-zA-Z0-9_-]\+\b/USER@HOST_REDACTED/g

# --- PERSONAL NAMES ---
s/\b\(Stephen\|Rykard\|Cole\|Kleene\)\([ -]\(Stephen\|Rykard\|Cole\|Kleene\)\)\+\b/FULL_NAME/gI
s/\b\(Stephen\|Rykard\|Cole\|Kleene\)\b/NAME_REDACTED/gI

Here you I just need to update accordingly with my personal information.

Configuration in KDE

1. Right-click the clipboard icon in the system tray and select Configure Clipboard…
2. Go to the Actions Configuration tab.
3. Add a new action with the following parameters:

Testing and Verification

To verify that the script works, you can test the output with the clipboard icon in the system tray, copy your text, clic and select Invoke action :

Clipboard content:

Hi, I'm Stephen Rykard Cole Kleene, my ORCID is 0000-0000-0000-0000.
Email me at stephen.kleene@example.com.

My GitHub is github.com/stephenkleene and on Twitter I'm @kleene_dev.

SSH into my box: root@fedora-bazzite, home dir is /home/my-username.
Router is at 192.168.1.1, my Tailscale node is 100.200.300.400 
and reachable at mi-pc.tailscale.net.

MAC address of the NIC: 00:1a:2b:3c:4d:5e
IPv6 local: fe80::a1b2:3c4d:5e6f, loopback is ::1

Expected output:

Hi, I’m FULL_NAME, my ORCID is ORCID_REDACTED. Email me at EMAIL_REDACTED.

My GitHub is github.com/USER_REDACTED and on Twitter I’m @USER_REDACTED.

SSH into my box: USER@HOST_REDACTED, home dir is /home/USER_REDACTED. Router is at IP_REDACTED, my Tailscale node is TAILSCALE_IP_REDACTED and reachable at TAILSCALE_REDACTED.

MAC address of the NIC: MAC_REDACTED IPv6 local: IPV6_REDACTED, loopback is IPV6_REDACTED

Step 1: In the browser’s address bar type about:config and hit “Accept the risk”.

Step 2: In the search bar located on top of the site search for privacy.userContext.enabled and double click it to set it to true

That’s it! enjoy Firefox’s containers.