Fediversity

The five functions

This part tells how the system does each of the five functions of the scope.

Install applications

The operator selects applications in the form of panel. core makes the form data: a JSON Schema of the options of each application, and the catalog of the applications. api gives them to the browser (/schema, /applications). When the operator deploys, the browser sends the configuration to api (/deployments/submit/{id}). api asks panel if this account can change this deployment, validates the configuration, puts a build in the queue, and then runs the deployment program of core. The deployment program makes the machines on the Incus hypervisor, the DNS records, the certificates and the secrets, and it installs the NixOS configuration of each machine.

Details: Make a deployment in the user guide of the panel, the design of the API, and Add an application for the application side.

Configure applications

The options of an application are the options of its component in the data model of core (Operator configuration). panel shows them as a form. A change of the configuration is a new submit: api validates the new configuration and deploys it. core also gives a table of option renames, and api uses the table to move a stored configuration to the current options (/schema/migrations).

Details: the schema and migration sources of the API, and the data model.

Update applications

The version of an application comes from the revision of the code that a deployment uses, and that revision pins nixpkgs. Thus an update is a deploy with a newer revision. Each deployment has an update policy in api (/deployments/update_policy/{id}): manual, automatic or window. With manual, the operator starts the deploy. With the other two policies, api starts the deploy when it finds a new default source, immediately or in a maintenance window.

Details: the update policy of the API.

Manage users

There are two sets of users:

  • The accounts of the operators are in panel. An operator logs in with the single sign-on of the hosting provider or with a local account. The hosting provider manages the accounts in the administration pages of panel. panel keeps which account owns which deployment, and api asks panel before it does an action.
  • The users of the applications are in the deployment of the operator. Each deployment has its own lldap directory and its own Authelia single sign-on. core connects each application to them through the ldap and oidc resources. The operator adds users in lldap, and the groups in lldap give the roles in the applications.

Details: Manage the users of your deployment for the operator, Manage users and groups for the hosting provider, and the architecture page of the panel for the accounts.

Switch an operator to and from a different hosting provider

A move has a source and a target, and each is an installation of Fediversity.

  • At the source, api exports the deployment (/migration-string/{id}). The core/effects/migration effect stops the services of each application and makes a snapshot of its data. The result is a migration string. It holds a pointer to the snapshot of each application, and the transfer code of the domain when the registrar account of the source holds the domain.
  • At the target, api imports the string (/migration-import/{id}) and deploys the configuration. The core/effects/migration-restore effect restores each application from the snapshot of the source. The target can transfer the domain to its own registrar account.

The configuration of an operator can name its own module source. Thus the operator can move away from a hosting provider that uses a different revision of the code.

Details: Export a deployment for a migration and Restore the apps of a migration in the hosting-provider guide, the export of a migration in the design of the API, and the switching and exit clauses of the contract templates.