Introducing tori, a tool to track your system's configuration and replicate it.

I've been simultaneously using and developing it personally for the past 5 months, and now I would like to teach it to fly so it can break out from our nest.

This version still has very few of the features I enjoy in my personally-hardcoded version. If it sounds interesting, just stay tuned.

I wrote a blog post with a more in-depth description of what it is, how it works and why I built it:

https://blog.jutty.dev/posts/introducing-tori.html

#OperatingSystems #portability #SysAdmin #shell #POSIX #ash #BSD #FreeBSD #Linux #VoidLinux #Debian #ConfigurationManagement

Introducing tori • jutty.dev

@jutty ahoi! This really looks like a fun project. I saw your rationale on reinventing the wheel and wanted to ask if you had special considerations regarding Ansible.
I know, „i wanted to do this“ trumps everything, still I’m curious

@the_enid Ansible is very powerful and I don't know very much about it, but I guess I wanted to build something more minimal and local, meant for managing your personal machines.

For this use case, I guess also prefer having simple function calls over nesting YAML with indentation, not my favorite format due to having poor readability.

@jutty @the_enid I think there’s still a lot to research about alternatives to Ansible especially coming to this space, I was thinking about writing something similar these days, maybe I’ll just give a shot to tori 😬
@dottorblaster It's still a hatchling, but I hope you stay around to see it growing!

@jutty

Very interesting, Void Linux user here as well.

I have written myself some ansible alternative, based on the approach by drist:

https://dataswamp.org/~solene/page-drist-official-website.html

I do however have some idea for a long time to save configuration inside some files that can be read and reapplied distro-independent.

For that to work, I would write general wrappers (like svc_enable) which based on someones distro calls the appropiate systemd/runit/sysvinit etc. commands.

[1/?]

Solene'%

Solene's Percent %

@jutty

There is one remaining problem though:
Packages. They can and do differ from naming and content.

Some have packages with feature X compiled, others dont. Some have these same package names, others not.

There are things like https://pkgs.org/ which can and will make it easier, but a conversion will always be quirky. (It's in the nature of things)

So, I believe there is nothing we can do about that pkg part.

[2/2]

Packages for Linux and Unix - pkgs.org

Search and download Linux packages for Adélie, AlmaLinux, Alpine, ALT Linux, Amazon Linux, Arch Linux, CentOS, Debian, Fedora, FreeBSD, KaOS, Mageia, Mint, NetBSD, OpenMandriva, openSUSE, OpenWrt, RHEL, PCLinuxOS, Rocky Linux, Slackware, Solus, Ubuntu and Void Linux distributions

@Anachron Yeah, that is certainly a thing. As it stands now, a separate package list would be required per distro.

I suppose something like void:package-name, fbsd:package-name, etc, could be a solution to allow having them in a single file? Still, they would have to be manually specified per OS.

@jutty yep but I would say this is not worthy to spend time on.