Configuring Federation Sharing

Introduction

With Federated Cloud Sharing, you can easily and securely link file shares between Myota Vaults, in effect creating a "cloud" of Myota Vault installations.

  • For security reasons, federated sharing strictly requires HTTPS (SSL/TLS).

  • If you want to use HTTP for development and testing purposes, you have to set MYOTA_SHARING_FEDERATION_ALLOW_HTTP_FALLBACK to 'true'.

Configuration

Follow these steps to establish a trusted connection between two servers.

  1. Verify that both servers have SSL certificates.
    If you open the server URL in your browser and see a lock icon on the left-hand side of the address bar, the certificate is valid:

    Lock icon in the address bars in Firefox, Google Chrome, and Safari

    Lock icon in Firefox, Google Chrome, and Safari, width=300

  2. Verify that MYOTA_OVERWRITE_CLI_URL is set to 'https://<YOUR-SERVER-URL>' instead of localhost:

  3. Navigate to Admin settings  Sharing  Federation

  4. Add server 1 to the trusted servers on server 2

  5. Add server 2 to the trusted servers on server 1

  6. Run on both servers:

  7. Run the OCA\Federation\SyncJob job with the force option on both servers.
    You can get the corresponding job ID by using the background:queue:status the admin console command:

  8. The check should now be green

  9. Now sync your users by running on both servers

  10. Configure automatic acceptance of new federated shares

    Automatic acceptance of new federated shares will not work if the option Add server automatically once a federated share was created successfully is also set. This is done because of security concerns.

Working With Proxies

Some Myota Vault instances are not connected to the internet. They cannot access the public network. Therefore, federation will not work without a proxy.

Set the MYOTA_PROXY and MYOTA_PROXY_USERPWD configuration variables.

Creating a New Federation Share

Follow these steps to create a new Federation share between two Myota Vaults. This requires no action by the user on the remote server; all it takes is a few steps on the originating server.

  1. Enable the Federation app.

  2. Create a federated share by entering username@serveraddress in the sharing dialog (for example freda@https://example.com/myota). When Myota Vault verifies the link, it displays it with the (federated) label. Click on this label to establish the link.

    image, width=350

  3. When the link is successfully completed, you have a single share option, and that is can edit.

    image, width=350

    You may disconnect the share at any time by clicking the trash can icon.

Federated Sharing Scanner CronJob Configuration

The Federated Sharing Scanner is a background job used to scan the federated shares to ensure the integrity of the file cache.

On each run the scanner will select federated shares that satisfy these requirements:

  1. Ensure that within a single cron run, at max cronjob_scan_external_batch scans will be performed out of all accepted external shares (default 100)

  2. A scan of that external share has not been performed within the last cronjob_scan_external_min_scan seconds (default 3 hours)

  3. The user still exists, and has been active recently, meaning logged in within the last cronjob_scan_external_min_login seconds (default 24 hours)

  4. There has been a change in the federated remote share root etag or mtime, signaling a mandatory rescan

To enable the cronjob, go to Settings  Admin Settings  Federated Cloud Sharing and enable the checkbox:

Checkbox, width=500

Alternatively you can use the command line:

You can also configure these settings of the cronjob:

  1. the minimum amount of time since last login of a user so that a scan is triggered (ensures only active users get fed shares synced)

  1. the minimum amount of time since last scanned so that the next scan is triggered (avoid frequent scan when active collaboration)

  1. the maximum number of federated share scans per 10 minutes (scan performed only if fed share files got updated)

  2. Use the following command to force a run of the scanner cronjob:

Known Issues

Persistent Locks Are Not Guaranteed

There is a known bug in propagation of persistent locks to federated instances. If a user creates an exclusive lock on a share, no other users should be able to modify it, nor its contents, and all users should see a lock icon on the share.

However, this isn’t the case. The following functionality has been recorded:

  • The user who created the lock sees the lock icon throughout the share.

  • The top-level of the share for receivers shows the lock icon.

  • Sub-items of the share do not show the lock icon.

  • The share and its contents can still be modified by all users; specifically:

    • Sub-items can be deleted.

    • Sub-items can be created.

Tips

VCARD properties

It is possible to configure the VCARD properties that are searched in order to retrieve a list of federated users in the share dialog. By default, Myota Vault uses CLOUD and FN properties, however this list may be configured by the admin:

Possible values are:

  • VERSION

  • UID

  • FN

  • N

  • EMAIL

  • CLOUD

The value CLOUD enables searching by federation ID. Note that when EMAIL or CLOUD are enabled, hostnames are included in the search. Results are then returned for substrings of the hostname part, even when no user related field matches.

Listing Federated Shares

In case you want to see which federated shares exist on your server, you can use this command to list them.

Currently there is no Myota Vault the admin console command to list federated shares, that’s why you have to use these database queries to obtain the information.

Federated shares are saved in your database.

Incoming shares can be listed with the following query:
select * from oc_share where share_type=6;

Each unique ID gives you an incoming federated share.

Outgoing shares can be listed with the following query: (replace cloud.example.com with your instance URL)

select * from oc_share_external where remote NOT IN ('https//cloud.example.com');

Each unique ID gives you an outgoing federated share.

Exit the database console with this command:

quit