Domain services for Linux — central identity, access, and computer administration for Linux desktops and servers.
Home: https://github.com/blakemcbride/Tuxdom
Please read before using this. Tuxdom is complete to its current stage, but it is untested. It has not been validated in production or in any sustained real-world deployment. Treat it as a working body of code to read, build, and experiment with — not as something to put in front of an organization's logins yet. See Status.
Tuxdom gives a small or medium-sized organization the most important corporate benefits of Microsoft Active Directory — one place to manage people, groups, computers, who may sign in to what, and what is shared between those computers — without requiring anyone to understand LDAP, Kerberos, DNS, certificate authorities, or Linux authentication internals.
You install one server, open a web browser, and work in five nouns:
People who exists
Groups which people belong together
Computers which machines you manage
Access which groups may sign in to which computers
Shares which directories are offered, and who may read or write them
That is the whole mental model. The system is sophisticated internally; it is meant to be simple to install, simple to understand, and simple to operate.
Install the server on a Linux machine with PostgreSQL. Java and Tomcat come with the package.
sudo dnf install tuxdom-server # Fedora
sudo apt install ./tuxdom-server_0.1.0-1_all.deb # Debian / Ubuntu
sudo tuxdom-server setup --organization "Your Organization"setup creates the database and its login, generates the server's signing key and
certificate, loads the schema, starts the service, and prints the console URL along with a
one-time administrator password.
Join a computer to the organization:
sudo dnf install tuxdom-client # Fedora
sudo tuxdom join your-server.example.comIt asks for a one-time enrollment code, which you generate in the console. The agent starts itself and the computer appears in the console within a few seconds. You do not edit any file on that machine.
Everything after that happens in the browser. See the Administrator Guide for the full walkthrough, and Operating Tuxdom for the day-to-day guide.
There is no public package repository yet. To produce the packages the commands above install, see docs/building.md.
tuxdom-server one Java service, one PostgreSQL database
│
│ HTTPS, request-signed with each machine's key
│
tuxdom-agent one C daemon per managed computer
├── NSS module users and groups come from the agent
├── PAM module logins are checked by the agent
└── policy cache a signed document, so offline still works
Two properties shape everything else:
- Every managed computer keeps a local administrator account. If the server is unreachable and the agent fails, that account still works. Tuxdom refuses to join a computer that does not have one.
- Laptops keep working offline. Someone who has signed in before can sign in again with no network for a configurable number of days. The trade is that a central disable does not reach that laptop until it reconnects.
Applications talk to the server over OpenID Connect. Scripts talk to it with read-only API credentials. Neither has any other way in.
Any managed computer can offer a directory to the organization, and any other managed computer can mount it — at whatever path suits that machine. Who may read or write is decided centrally, per person, per group, or for everyone, and it is enforced against the person, not the computer they happen to be sitting at.
Share a directory Use a shared directory
Computer: sd-files1 Share: accounts (offered by sd-files1)
Directory: /srv/projects/accounts Put it at: /home/mary/work/accounts
Share it as: accounts
Everyone read only
Group "accounting" read and write
User "contractor-jo" no access
All of it is done in the console. Nobody edits /etc/exports, /etc/fstab, or
krb5.conf, and nobody runs mount. The agent on the offering computer configures the
NFS export and the file permissions; the agent on each using computer sets up an
automount; and the directory is simply there for whoever signs in, with the access that
person was given. Withdrawing a permission removes it from the offering machine, not
merely from the database. Ordinary users see the folders shared with them, and where to
find each one, in their portal.
Underneath, it is NFSv4 with sec=krb5p: every request is authenticated with the Kerberos
ticket the person received at login, and everything on the wire is encrypted. That is what
lets "Mary may write, Jo may not" hold against Mary and Jo rather than against their
machines. Mounts are automounts, never fstab entries, so a laptop that leaves the office
does not hang at boot; and they are never soft, so an unreachable server makes things
wait visibly rather than corrupt data quietly. System directories cannot be shared and
nothing can be mounted over one — the server refuses, so a tampered machine cannot be
talked into it.
Sharing is built on the Kerberos realm, which is created from the console, and is currently available on Fedora and RHEL computers only; a Debian or Ubuntu computer can be managed but can neither offer a share nor use one. The Shared directories chapter of the Administrator's Guide covers the console screens, and Operating Tuxdom covers what to watch once shares are in use.
- Central users and groups, with password policy, MFA, and passkeys
- Machine enrollment with per-machine credentials
- Login authorization per computer and per computer group
- Central
sudoand central SSH keys - Central disable — turn off an account once, everywhere
- A signed policy engine, including software package enforcement, with Explain and Simulate so you can see what a policy did and what it would do before saving it
- Inventory and compliance search across the fleet
- Coordinated agent upgrades with staged rollout and automatic rollback
- Service accounts and API credentials (read-only)
- OIDC single sign-on for web applications
- A Kerberos realm with a ticket issued at login
- Shared directories — a directory on one computer, mounted on any others, with read or
write decided centrally per person, per group, or for everyone, authenticated and
encrypted with Kerberos (
krb5p). See Shared directories - An audit trail of administrative actions, logins, and agent upgrades
- Backup and restore
Tuxdom is not an Active Directory clone, and several of the gaps below are decisions rather than omissions. The full inventory, assessed against the code rather than the plans, is in Future.md.
The ones most likely to matter to you:
- No second server. There is no replication and no replica KDC. Existing users keep signing in when the server is down; new enrollments, policy changes, password changes, fresh tickets, and the console do not. Recovery is restore-from-backup — hours, not seconds.
- No LDAP endpoint, no RADIUS/802.1X, no general PKI, no integrated DNS.
- No Windows, no macOS, no SMB. Shared directories are for Linux computers only.
- No trusts, no cross-realm, no federation; no OU tree and no scoped delegation.
- Every machine requires the agent — there is no agentless mode.
| Path | Contents |
|---|---|
admin/ |
The server: a Java web application built on the Kiss framework, served by Tomcat |
client/ |
The C client: tuxdom-agent, the NSS module, the PAM module, the tuxdom command, and SELinux/AppArmor policy |
packaging/ |
RPM and deb package builds for both server and client, plus the systemd units and templates they share |
docs/ |
Administrator Guide, operating guide, build instructions, threat model, failure matrix, man pages |
manual/ |
LaTeX sources for the Administrator's and User's Guides (make builds the PDFs) |
tests/ |
Unit, API, integration, UI, acceptance, fuzz, and VM test suites |
Design and planning documents — tuxdom-plan.md, V2-PLAN.md, IMPLEMENTATION-PLAN.md,
tuxdom-kerberos-plan.md, tuxdom-file-sharing-plan.md — record why the system is built
the way it is.
Full instructions, including the Debian/Ubuntu cross-build caveat, are in docs/building.md. In brief, on Fedora:
# Client dependencies (it is C)
sudo dnf install -y gcc make rpm-build \
pam-devel openssl-devel libcurl-devel jansson-devel \
libargon2-devel libselinux-devel selinux-policy-devel \
systemd-rpm-macros
# Server additionally needs a JDK 21 or newer
sudo dnf install -y java-21-openjdk-devel
packaging/client-rpm/build-client-rpm.sh # -> packaging/client-rpm/out/
packaging/server-rpm/build-server-rpm.sh # -> packaging/server-rpm/out/The .deb packages must be built on a Debian or Ubuntu machine; they need the Debian
toolchain and cannot be cross-built from Fedora. tests/vm/README.md describes standing one
up.
To build just the client binaries without packaging:
make -C client # libnss_tuxdom.so.2, pam_tuxdom.so, tuxdom-agent, tuxdomThe version number appears in three places that must agree: VERSION= in each build script,
%global tux_version in each spec, and TUX_AGENT_VERSION in client/agent/tux_agent.h.
The suites are shell and Python scripts, grouped by what they need:
make -C tests/unit # C unit tests, no server required
tests/api/console-test.sh # API tests, against a running server
tests/integration/phase5-test.sh # container-based integration tests
tests/vm/join-rollback-test.sh # full-VM tests; see tests/vm/README.mdtests/fuzz/ fuzzes the NSS parser (make -C client fuzz-run).
Fedora, Debian, and Ubuntu LTS — for both the server and the clients. The client packages
are architecture-specific; the server package is noarch and carries Tomcat and the built
web application.
A Debian or Ubuntu computer gets accounts, access rules, SSH keys, software policy, and settings, but its package does not yet wire in Kerberos — so it cannot offer or use a shared directory yet. Use Fedora or RHEL where you need the whole system.
Version 0.1.0 — complete to its current stage, and untested.
Tuxdom is a project Blake McBride set out to build. What is here is finished to the point the plans describe: Version 2 added single sign-on, policy, software management, inventory, agent upgrades, and API credentials without adding operational surface — no new daemon, no queue, no scheduler, no alert lifecycle — so the list of things that can be misconfigured is close to what it was in Version 1.
What has not happened is testing. The code has not been exercised in production, and the
test suites under tests/ have not been run to the point where anyone should rely on the
result. A system that decides who may log in to a company's computers is exactly the kind of
software that deserves to be proven before it is trusted, and that proving has not been done.
Further development and testing will occur as time permits. Reports from anyone who builds it and finds where it breaks are welcome at https://github.com/blakemcbride/Tuxdom/issues.
BSD 2-Clause. See LICENSE.
Copyright (c) 2026, Blake McBride.
Tuxdom lives at https://github.com/blakemcbride/Tuxdom.