A key feature of sb is that it has been designed with multiple primary instances in mind.
When you execute a command on any sb instance in a cluster (let's say create a new user),
the action will be replicated to the other instance(s).
Whenever replication is enabled in the configuration, every action executed in sb
will result in:
- the action being executed locally as usual
- all data used for this action being encrypted and inserted in a local replication SQLite database
Note that enabling the replication also means starting the associated daemon.
This daemon executes three processes:
- query the replication database and push the entries to a message queue
- listen to the message queue and perform the replication actions for each entry it receives
- execute the PostExecution steps of the commands (mainly used for TTYRecs offloading)
As of today, only Google PubSub is supported, but another message queue can be added very fast by implementing the replicationqueue interface.
Every action being synced between all instances, it is expected that you can start a session on one sb instance,
and replay it on another instance a few moments later.
When the feature is enabled, the TTYRecs will be offloaded by the daemon to a remote object storage once an SSH session has ended.
Note that enabling the replication also means starting the associated daemon.
All TTYRecs are kept on disk while the SSH session is running.
When the session ends:
- The replication entry is added to the replication database
- The daemon pulls it and triggers the post-execution step:
- the TTYRec file is encrypted with the replication encryption-key
- the TTYRec file is pushed to a distant object storage
- the local TTYRec file is removed from the disk
As of today, the two following object storage solutions are supported:
Other remote storage systems can be added very fast by implementing the storage interface.