Admin

There is one group of users, called “Admins”, which have elevated powers. This includes:

  • They have an “Admin” tab at the top right.

  • There, they can configure settings of the server in “Site Settings” – i.e. those values, which are not set in the global.settings dict in your my-values.yaml config file.

  • Create/modify Licenses.

  • Manage “Registration Tokens”.

  • Open any project.

  • Adjust resources of individual projects: open a project → Upgrades → “Admin Quota Editor” → “Edit”.

  • Impersonate any user to give support, debugging issues, etc.: Admin → “User Search”.

  • Access more detailed information via “CRM” files: create them with the ending *.cocalc-crm.

Elevate privileges

If you created an admin via the Admin Setup, but you want more users to have that role, you have to modify the database directly. Note: for security reasons (lack of monitoring/oversight), there is no control for admins to elect other users as admins.

UPDATE accounts SET groups='{admin}' WHERE email_address='[email protected]'

or by account id:

UPDATE accounts SET groups='{admin}' WHERE account_id='Account-UUID-XYZ-ABC'

Note

To remove someone from the admin group:

UPDATE accounts SET groups=NULL
WHERE email_address='[email protected]'
-- or, see above
WHERE account_id='Account-UUID-XYZ-ABC'

Note

It’s also a good practice, to wrap such statements in a transaction.

Create accounts

If those additional accounts for admins do not exist yet, you can either create these accounts via the API or directly via the database as well. In the latter case, you have to make sure the email_address field is unique and other setup actions will not run – which is fine, if you just want a brand new account on a fresh setup.

INSERT INTO accounts (account_id, first_name, last_name, email_address, creation_actions_done, created)
VALUES (gen_random_uuid(), 'Foo', 'Bar', '[email protected]', TRUE, NOW())

To set a password, it’s probably best to trigger a password reset or tell the user to open the path: /auth/password-reset.

Per-project PVC mode

By default, the home directory of every project is a sub-directory of one large, shared PersistentVolumeClaim (projects-data). All project pods mount this PVC, and manage uses subPath to scope each project to its own directory.

Optionally, the manage service can be switched into a mode where it creates one PVC per project instead, and mounts that PVC as the project home. This is useful when:

  • The cluster’s storage of choice is ReadWriteOnce only (e.g. Longhorn, EBS, Ceph RBD) — ReadWriteMany is required for the shared-PVC default but not for this mode.

  • You want per-project quotas enforced at the storage layer rather than via in-pod limits.

  • You need per-project snapshots/backups handled by the storage class.

What changes when the mode is on:

  • On project start, manage creates a PVC named according to a template (e.g. pvc-cocalc-project-<PROJECT_ID>) if it does not already exist, using the configured storage class and size.

  • The project pod is rewritten to mount that PVC as its home — the shared projects-data PVC is no longer needed for project home directories.

  • The manage ServiceAccount is granted persistentvolumeclaims permissions in the namespace’s Role. No extra RBAC is granted when the feature is off.

  • The manage-copy and manage-share pods both gain a read-only mount of the ssh-gateway-keys Secret at /secrets/keys (mode 0400) and use the gateway’s id_ed25519 keypair to drive rsync over SSH against port 2222 of the project pods. The shared-PVC mount is dropped from manage-copy in this mode (it is unused); manage-share keeps it because public-share output is still written there.

  • When a copy or share operation needs to read from a project that is currently stopped, the manage service starts it briefly and schedules a deferred stop (~10 min later, skipped if the project is in active use).

  • Optionally, the original shared projects-data PVC can be mounted read-only inside each project for migration scenarios, so users can still reach their pre-migration data.

Prerequisite — ssh-gateway:

This mode requires global.ssh_gateway.enabled: true. The ssh-gateway publishes the keypair that manage-copy and manage-share reuse, and the project image already trusts the gateway’s public key on port 2222 — so no project-side change is needed, but the gateway must be present. The chart fails to render if per-project PVC mode is configured without the gateway.

Reclamation:

manage never auto-deletes per-project PVCs — losing a project’s home is unrecoverable, so reclamation is left as an explicit admin step. After deleting a project from CoCalc, run kubectl delete pvc <pvc-name> (or run a separate sweep job) to reclaim the storage.

Switching modes is one-way as far as the chart is concerned: existing projects continue to use whatever volume they were started with until the project pod is recreated. Plan a migration window if you have live data on the shared PVC.

To enable and configure this mode, see Per-project PVC mode (advanced).