Introducing Trustmux: Your Terminal, In Your Pocket

I've spent almost 3 decades thinking about terminals. Byobu has been my home for shell multiplexing for almost two decades now — a text window manager wrapped around tmux (or screen, if that's still your thing), giving you persistent sessions, status bars, and the kind of muscle memory that makes a terminal feel like an extension of your hands.

But there's always been a gap for me: what happens when I walk away from my desk?

The Problem

I run long-lived shell sessions on my workstation. Background jobs, monitoring dashboards, and — more recently — long-running Claude sessions working through code while I step away. I wanted to check in on all of it from my phone. Not babysit it constantly, just glance at it, run a command if something needed attention, and get on with my day.

The traditional answer here is SSH, or its more mobile-friendly cousin, Mosh. SSH from a machine with a full sized monitor and keyboard and low network latency is of course awesome, with its fully synchronous connection.  But from a phone or tablet — every network hiccup, every WiFi-to-cellular handoff, shows up as lag or a dropped session. Mosh improves on this slightly, but it's still fundamentally built around maintaining that live connection state. On a phone, where networks come and go constantly, that model just doesn't hold up well.

I also tried Claude Mobile, which is excellent for what it does — but it only talks to Claude. I needed something that didn't care what was running in my terminal. Sometimes it's a Claude session, sometimes it's htop, sometimes it's a deploy script or huge rsync job I want to glance at, or even a different code assistant not named Claude. I needed access to the shell, not to a specific tool.

What I actually wanted was something asynchronous: connect when I need to, see the current state instantly, type a command if I need to, and disconnect without worrying about whether the connection survived. Mobile-native, not desktop-terminal-stretched-onto-a-small-screen.

So I built it.

Trustmux

Trustmux is a lightweight daemon that runs alongside your existing tmux or Byobu setup and exposes your sessions as a secure Progressive Web App (PWA) — installable on your phone or tablet, no App Store required.

A few design principles drove this:

Security first. Every connection is encrypted with real TLS certificates. There are two ways to get there:

• Tailscale (recommended): Trustmux binds to your Tailscale IP and uses tailscale serve for automatic certificate provisioning. Zero-trust networking, no port forwarding, no exposed surface area. Pairing your phone takes one command and a 6-digit code.
• Self-managed certificates: If you'd rather not run Tailscale, bring your own certificate — a self-signed cert works fine for personal use.
• Direct networking: If Tailscale is not your thing, and you just want to connect directly, and handle your port forwards, that works just fine too, as a fall back.

Asynchronous by design. This is the core insight. Trustmux doesn't try to maintain a persistent, fragile connection the way SSH does. It talks to tmux directly via libtmux, and streams terminal state to your device over a WebSocket connection that's resilient to network changes. Open the app, see exactly where your session left off, do what you need, close the app. No babysitting required.

A real PWA, not a wrapper. Trustmux installs like a native app — tap "Add to Home Screen" and you get a full-screen icon, an offline-capable UI shell, and silent background updates.

Tool-agnostic. Whatever's running in your tmux panes is what you'll see and interact with — shell commands, Claude sessions, log tails, whatever. Trustmux doesn't care; it just gives you the pane.

Installation

Trustmux is available on Ubuntu (ppa, stonking), Debian, and Fedora development repositories, as well as pip, Homebrew, and the Byobu PPA:

pip install trustmux
# or
brew tap dustinkirkland/trustmux
brew install trustmux
# or via PPA
sudo add-apt-repository ppa:byobu/ppa
sudo apt install trustmux

It's part of the Byobu project, so if you've already got Byobu (7+) installed, you're most of the way there.

Getting Started

Setup is three commands:

trustmux enable    # start at login (optional)
trustmux start     # fire up the daemon
trustmux pair      # generate a pairing URL and 6-digit code

Open the pairing URL on your phone, enter the code, tap "Add to Home Screen," and you're in.

On Security

I take this part seriously, given what's at stake — direct shell access to a workstation. This is exactly the kind of tool that deserves continued, public scrutiny, and I'd genuinely welcome additional expert eyes on it — particularly from people who think about authentication, certificate handling, and network exposure for a living.

Why I Built This

There's a part of this that's just personal. I like staying close to my shell — that's basically the whole premise of Byobu. As more of my work has started to involve long-running AI coding sessions, the gap between "what's happening on my workstation" and "what I can see on my phone" started to bother me. Trustmux closes that gap, on my terms, with a security model I trust.

If you run tmux or Byobu and have ever wanted to check on a session from the couch, the train, or the airport, I think you'll like this.

Try It

• Website: trustmux.dev
• Source: github.com/dustinkirkland/byobu (Trustmux is part of the Byobu project)
• Install: pip install trustmux, brew install trustmux, or via ppa:byobu/ppa

I'd love to hear what you think — what's missing, what's broken, what you'd want next. Feedback, issues, and pull requests are all welcome.

:-Dustin

(Re-)Introducing JeOS -- Just Enough OS, aka Ubuntu Core

Lean.  Agile.  Svelte.  Lithe.  Free.

That's how we roll our operating systems in this modern, bountiful era of broadly deployed virtual machines, densely packed with system containers.

Linux, and more generally free software, is a natural fit in this model where massive scale is the norm.  And particularly Ubuntu (with its solid Debian base), is perfectly suited to this brave new world.

Introduced in Ubuntu 8.04 LTS (Hardy) -- November 19, 2007, in fact -- JeOS (pronounced, "juice") was the first of its kind.  An absolutely bare minimal variant of the Ubuntu Server, tailored to perfection for virtual machines and appliances.  Just enough OS.

Taken aback, I overheard a technical executive at a Fortune 50 company say this week:

"What ever happened to that Ubuntu JeOS thing?  We keep looking at CoreOS and Atomic, but what we really want is just a bare minimal Ubuntu server."

Somehow, somewhere along the line, an important message a got lost.  I hope we can correct that now...

JeOS has been here all along, in fact.  You've been able to deploy a daily, minimal Ubuntu image, all day, every single day for most of the the last decade.  Sure, it changed names to Ubuntu Core along the way, but it's still the same sleek little beloved ubuntu-minimal distribution.

"How minimal?", you ask...

63 MB compressed, to be precise.

Did you get that?

That's 63 MB, including a package management system, with one-line, apt-get access to over 30,000 freely available packages across the Ubuntu universe.

That's pretty darn small.  Much smaller than say, 165 MB or 268 MB (which, to be fair, includes a bit more of an operating system -- much closer to say the standard Ubuntu Cloud Image, which is a 176 MB root tarball, or with kernel at 243 MB).

"How useful could such a small image actually be, in practice?", you might ask...

Ask any Docker user, for starters.  Docker's base Ubuntu image has been downloaded over 775,260 to date.  And this image is built directly from the Ubuntu Core amd64 tarball.

Oh, and guess what else?  Ubuntu Core is available for more than just the amd64 architecture!  It's also available for i386, armhf, arm64, powerpc, and ppc64el.  Which is pretty cool, particularly for embedded systems.

So next time you're looking for just enough operating system, just look to the core.  Ubuntu Core.  There is truly no better starting point ;-)

Enjoy,
:-Dustin

dotdee: A modern proposal for improving Debian Conffile Management

SOME BACKGROUND

Debian's management of conffiles is a truly inspired approach to a very difficult topic in any Linux/UNIX distribution.

Conffiles are files in /etc that the Debian package management system (dpkg) won't automatically overwrite when you upgrade a package.  Local modifications by the system administrator are preserved.  This a critical policy expectation by Debian and Ubuntu system administrators, which ensures the proper in-place upgrade of packages on a running system.  Moreover, handling conffiles correctly, as a package maintainer according to Debian policy, requires considerable expertise.  Debian Developer Raphaël Hertzog has one of the best, most concise explanations of how dpkg handles conffiles in this blog post.

THE ISSUE


Having read in detail several times now the Debian policies on conffile management, I see some room for improvement, with respect to modern Debian and Ubuntu deployments.  I believe there are two key points that the current policy sufficient handle...

1. Particularly in modern, massive Debian/Ubuntu deployments (think Cloud, Grid, and Cluster computing), it's no longer humans that are managing individual systems, but rather systems (puppet, chef, cfengine, et al.) managing systems.  (Insert your Skynet jokes here...)  As such, it's difficult (if not impossible) for a Debian package or a distribution to make configuration changes to another package's conffiles without violating Debian policy -- even when the change might objectively be the "right" or the "best" thing to do, in terms of end user experience and package operation (especially when the given system is only ever managed by a configuration management system).
2. In other cases, one local package has a run-time dependency on a second package on the local system, but requires the package it depends on to be configured in a particular way.  Again, if that configuration lives in a conffile owned by the second package, the first package cannot automatically make that configuration change without violating said policy.

As an exception, rather than the rule, there are a couple of very mature packages that provide smart frameworks enabling system administrators, packagers, and distributions to configure them all within policy.

A good example would be apache2's /etc/apache2 directory, which allows for said admins, packagers, and distributions to drop their own configuration modifications as files (or symbolic links) into sourced directories such as /etc/apache2/conf.d, /etc/apache2/mods-available, and /etc/apache2/sites-available.

A PROPOSAL

The concept of a ".d" directory in /etc is very well understood in most Linux/UNIX circles, actually.  Check your own /etc directory with the command: find /etc -type d -name "*.d" and you should see quite a number of ".d" style configuration directories.

Here, I'm proposing a tool that I think would greatly benefit Debian and Debian-derived distributions such as Ubuntu.  For the purposes of this discussion, let's call the tool "dotdee".  Its stated goal is to turn any given flat file on your system to a dynamically concatenated flat file generated from a unique ".d" directory dedicated to that file.  With such a dedicated and well-formed directory, system administrators, Debian packagers, and distributions could conveniently place additional configuration snippets in particular conffile's dedicated ".d" directory.

I have written a first prototype of the tool dotdee, which you can examine here.  It's a very simple, straightforward shell script, inspired a bit by Debian's incredibly useful update-alternatives tool.

The script runs in 3 different modes:

1. sudo dotdee --setup /etc/path/to/some.conf
2. sudo dotdee --update /etc/path/to/some.conf
3. sudo dotdee --undo /etc/path/to/some.conf

SETUP MODE

First the setup mode takes a flat file as a target.  Assuming the file is not already managed by dotdee, a new directory structure is created under /etc/dotdee.  In the example above, that would be /etc/dotdee/etc/path/to/some.conf.d.  So "/etc/dotdee" is prepended, and ".d" is appended to the path which is to be managed.  It's trivial to get back to the name of the managed file by stripping /etc/dotdee from the head, and .d from the tail of the string.

Next, the actual managed flat file is moved from /etc/path/to/some.conf to /etc/dotdee/etc/path/to/some.conf.d/50-dpkg-original.  Again, this a well-formed path, with "/etc/dotee" prepended, a ".d" appended, and the file itself is renamed to "50-dpkg-original".  This is intended to clearly denote that this is the original, base file, as installed by dpkg itself.  The number "50" is precisely halfway between "00" and "99", leaving plenty of room for other file snippets to be placed in ordered positions before and/or after the original file.

After this, we run the update function, which will concatenate in alphanumeric order all of the files in /etc/dotdee/etc/path/to/some.conf.d/* and write the output into /etc/dotdee/etc/path/to/some.conf.

Finally, the update-alternatives system is used to place a symlink at the original location, /etc/path/to/some.conf, pointing to /etc/dotdee/etc/path/to/some.conf.  Additionally, a second, lower-priority alternative is also set, pointing to dpkg's original at /etc/dotdee/path/to/some.conf.d/50-dpkg-original.

UPDATE MODE

As mentioned above, the update function performs the concatenation immediately, building the targeted path from its dotdee managed collection of snippets.  This should be run anytime a file is added, removed, or modified in the dotdee directory for a given managed file.  As a convenience, this could easily and automatically be performed by an inotify watch of the /etc/dotdee directory.  That, itself, would be a dotdee configuration option.

UNDO MODE

The undo function is something I added for my own development and debugging while working on the tool, however I quickly realized that it might be an important tool for other system administrators and packagers (think, postrm maintenance scripts!).

DPKG INTEGRATION

This would require some (minor?) integration with dpkg itself.  On package upgrade/installation, dpkg would need to need to detect when the target path of a file it wants to create/update is in fact a symbolic link referencing an /etc/dotdee path.  It would need to drill down into that path and place the file it wants to write on top of the 50-dpkg-original file instead.  I have not yet contacted the dpkg maintainers yet, so I don't know if this is a reasonable proposal or not.

IN PRACTICE

So what would this look like in practice?

Once integrated with dpkg, I'd like dotdee to be a utility that human system administrators could run to manually turn a generic conffile into a ".d" style configuration directory, such that they could append their own changes to some numbered file in the dotdee directory, avoid the interactive dpkg-conffile-changed prompts.

More importantly, I would like one package's postinst maintainer script to be able take another package that it depends upon and turn its conffile into a dotdee managed file, such that it could append or prepend configuration information necessary for proper operation.

COMMENTS?

I plan to lead a session on this topic at the Ubuntu Developer Summit in May 2011 in Budapest, and I have also proposed this on the debian-dpkg@ list as well.

But in the mean time, what do you think?  Have you encountered this problem before?  How have you solved it?  What parts of this proposal do you think are reasonable?  Are any parts completely unreasonable to you?  Can you think of any extensions or changes you'd make?  Would you use something like this?

Cheers,
:-Dustin