R2FS!

The R2FS! page configures the identity keys, the encryption requirement, and the network allow list for remote R2FS! storage nodes. Together they control which remote nodes can authenticate to this server, how their connections are protected, and from which network sources they may connect.

Identity keys

Identity keys are shared secrets that authenticate remote R2FS! nodes with this server. At least one key must exist for R2FS! connectivity.

The keys table shows each key (masked, with only the last characters visible) and its Notes. When the table is empty it reads "No identity keys yet."

Adding a key

Click Add key to open a dialog. It has two fields:

• Key: the shared secret. It is entered as a masked value you can reveal.
• Notes: a free text description to help you recognize the key later.

The Add action stays disabled until a key value is entered. Adding a key stages it; remember to save the page to persist your changes.

Deleting a key

Use the delete action on a key row. A confirmation dialog asks "Delete this R2FS! identity key?" before the key is removed. As with adding, deletions are staged until you save.

Encryption

R2FS! v2.2 and newer encrypt every connection to this server and verify both ends of it mutually, using the identity key you already configure and nothing else. There is no certificate to issue, copy between machines, or renew: the encryption keys are generated in memory each time a service starts, and the identity key remains the whole of the trust. Nodes running v2.2 or newer do this automatically, whether or not the setting below is enabled.

Older nodes cannot do any of it. R2FS! v2.1 and older connect without encryption, and the server keeps serving them through a compatibility layer so that upgrading does not cut off your whole fleet at once.

Require R2FS! v2.2+ mutually verified encryption

Leave this unchecked while any node older than v2.2 is still in service. Enable it once every node has been upgraded: from then on the server refuses any node that connects without encryption.

Enabling it takes effect immediately, on new connections, without restarting anything. Nodes that are already attached without encryption keep their current connection and are refused the next time they reconnect, so a fleet converges rather than dropping all at once. Disabling it takes effect just as quickly.

TIP

Finding the nodes that still need upgrading. While the compatibility layer is on, the server log records every node as it attaches and says whether the connection was encrypted. A node that attaches without encryption is logged as a warning naming the node and the virtual file system it serves, so you can search the log for those warnings to see exactly which nodes will stop connecting if you enable this setting.

WARNING

Encryption is not in force until this setting is enabled. While the compatibility layer is on, an attacker positioned on the network between this server and a node can choose the unencrypted transport, so the site is no better protected than it was before. The nodes that have been upgraded genuinely are encrypted in the meantime, but the protection applies to the site as a whole only once this setting is enabled.

Allow list

The allow list restricts R2FS! connections to specific IP addresses or CIDR networks. Leave it empty to allow connections from any source.

Entries are managed with the address and CIDR editor. Each entry can be an individual IP address or a CIDR network range.

Saving

Changes to the identity keys, the encryption requirement, and the allow list are applied together when you click Save. If you leave the page without saving, staged additions and deletions are discarded.