Skip to main content

tori is a tool to track how your system changes and then be able to replicate what you care about in another system.

Take a common Unix-like operating system, say Debian or FreeBSD. You install it and then start making changes.

You install packages, edit configuration files, create symlinks here and there, tweak certain settings through commands or graphical interfaces that store your preferences in a completely unknown location.

And you just keep doing it, because you don’t have the time to document every change or version control everything. As time goes by, you have arrived at a system that works for you. It consists of the packages you need and the configuration for everything to work as you expect it to.

The problem is: you don’t really know how you got there. It’s so scattered that there is now no way to:

  1. Do it all again from memory
  2. Know what changed as it keeps changing
  3. Know when what changed changed
  4. Know if all the changes are still in place
  5. Replicate these changes in another machine

tori solves this by making the process of configuring a system more declarative. It allows you to organize what packages a given system should have and what configuration files, symlinks and other tweaks are expected.

~/.config/tori
├── base
│   ├── etc
│   │   ├── pf.conf
│   │   └── rc.conf
│   └── home
│       └── juno
│           ├── .mailrc
│           └── .shrc
├── packages
└── tori.conf

An example of a configuration directory using the file tree strategy to lay out files.

Instead of scattering symlinks all over the place, tori will look at this core reference of what the system state should be and compare it to what the actual system state is. Depending on how interactive or aggressive you configure it to be, it will then either ask you how to conciliate these differences or do it for you.

tori is not so much about controlling a machine through instructions, it is more about being aware of how the specific packages, files and directories you care about are changing and then enforcing a given point along those changes as your baseline.

Once tori is installed, you can use its check command to ask “Is this system still as I specified in my tori configuration?”

It will then look into your tori configuration directory. If it finds a package file, it will compare the list of packages to the packages that are actually installed. If you installed or uninstalled something since you last changed that list, it will ask you how to proceed.

“A screenshot of a white-on-black terminal screen. It reads: [tori] 07:37:38: System and configuration packages differ Installed packages not on configuration: bastille fend ksh neomutt [1] Uninstall all [2] Enter packages to uninstall [3] Add all to configuration [4] Enter packages to add to configuration [5] Decide on editor [6] Cancel Choose an option [1-6]:”

Similarly, it will also compare the files in your configuration directory to their equivalents in the filesystem. Perhaps a DNS configuration file was changed by a system daemon you were unaware of. Perhaps a package update overwrote some configuration file you didn’t know had changed.

tori lets you manage this complexity from one single directory that becomes your specification of what the system state should be.

If you are interested in trying it out, head to get started or just delve into the documentation.