Tiered syncing - or selective syncing

Ideas
1

I use Atuin on a lot of hosts, some I control, and some I don’t.

I want to have them all sync to my Atuin server, but I don’t want them everthing to sync from my Atuin server to all hosts.

For host that I control , I want everything to sync.

But for hosts I don’t control I want to give them a tag, and then only have those tagged hosts sync with each other but still have their commands be available on hosts I control.

Here is a small example that might better explain what I mean:

./
└── MyHosts/
    ├── laptop
    ├── my-host-1
    ├── my-host-2
    ├── ClientA/
    │   ├── host-a1
    │   ├── host-a2
    │   └── host-a3
    ├── ClientB/
    │   ├── host-b1
    └──── host-b2

Each host has access to synced history on the same tier/level and everthing below.

So from my laptop I can access the history from all the other hosts in the entire tree.
Same goes for my-host-1 and my-host-2.

But when I’m on any host at ClientA I only have access to hosts in ClientA - same goes for ClientB.

You can think of MyHosts. ClientA & ClientB as tiered zones.

1 Like
2

Totally makes sense! Thanks for the suggestion.

I’d be interested in having something like this, though we’d need some way of adding structured data to hosts. Currently they just have a UUID assigned, though it wouldn’t be too difficult to add some more. Something like a name, tag, etc, would make sense I think.

1 Like
3

An alias set in the config?

At search time, it defaults to all, but can be filtered by alias?

Have to admit, it would be useful.

I’ve often wondered how to see the commands I ran on a certain machine.

Edit - perhaps they could be just a bunch of arbitrary tags? Seperate them by semicolons, or such.

e.g each machines config could have:

TAGS=“client_A;machine_1”
TAGS=“client_A;machine_2”
TAGS=“client_B;machine_2”
TAGS=“machine_2”

This way, coming to search, one can see the commands issued on machine_2, client_A… etc

No need for structure, except that created by the users, to match their own needs.

4

I think that sort of tagging is a bit separate from what I meant

This might be something a bit more useful to you there: Feature idea: Taggable environments to group shell commands

I was thinking more along the lines of giving a host a human-readable name, so that it can be referred to in search queries or other config. We can’t really rely on hostnames there, as they’re fairly unstable on some systems and aren’t exactly 1:1 to Atuin host IDs

5

This means that if you use the global filter on any of the host-aN, you will only see the history from ClientA.

I like this idea and had a similar one a while back. The reason I haven’t brought it up so far is, because I haven’t figured out where and how to configure those sync groups. One would need an additional “access level” on the sync server. But maybe there’s a better way.

6

I have a question: can this feature be implemented securely? i.e. some hosts can only read and write history from the same tier. What if a host lies about its hostname?

7

IMO only if a “super user” makes the connection between host-id (not hostname) and sync group.

8

In theory yes. In practice sync has not been designed with “sub users” in mind, so it would be a pretty large extension.

I think this makes sense from the perspective of keeping things tidy, if there are sets of commands you really just don’t want synced to some machines. That’s how I understood this feature request.

From a security perspective, don’t sign them all into the same account.

9

OK, that’s different than what I was thinking about. I have some hosts I consider less secure and so want their command history to be seen by more secure ones but not vice versa.

10

What level of trust do you give to them?

If I were concerned about machines I’m logging in to my Atuin account, I probably wouldn’t want them to be able to write to my history either

At some point the server could perhaps enforce access controls, but I’d like to have a good idea of the sorts of use cases people would have

11

If they can’t write with identity of other hosts, I’m fine with that.

My use-case: I have my own computers that I trust most, and so the command line will contain all kinds of secret tokens and other private information.

I have some remote servers that I trust less, and I don’t want them to be able to read the history of my own computers e.g. in case of being hacked. However reading the servers’ history on my own computers is fine.

This is not very important to me though. I can sync the servers with another account and copy commands as needed.

1 Like
12

makes sense, thanks for clarifying!

is it mostly just secrets/access tokens/etc or are there other things you’re concerned about?

I’d like to improve what Atuin does with secrets at some point, is all

:+1:

13

Other things that may contain information I don’t want to make public (I can think of at the moment): filenames, server names, urls, IP addresses, phone numbers, passwords (yes, sometimes I need it to be on the command line and reuse).

1 Like
14

My original reason for suggesting this feature came from a security/information compartmentalising consideration.

In essence: I want to keep my clients data separate.

But at the same time I find it extremely useful to have a full backup of every command I typed on every host available on my laptop.

For now I have separate sync accounts for every client I work for, which means sync “within a leaf tier” and backup - but no sync back to my laptop.

1 Like
15

I think if we approach this from a security angle, then realistically it needs to be as some sort of “organisation” grouping

This sort of configuration cannot work if all signed in machines have the same permissions - they’d be able to reconfigure themselves to have access to all data.

If different machines end up with different permissions, it’s probably better to actually have them as different users, just grouped with some sort of data sharing

16

Data sharing could probably be used to solve this in some way.

Maybe you could log in to more than one account at the same time, and then have some rules about how sync then works.