.. index:: Admin .. _ops-admin: 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 :ref:`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 :ref:`initial-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. .. code:: sql UPDATE accounts SET groups='{admin}' WHERE email_address='email@address.tld' or by account id: .. code:: sql UPDATE accounts SET groups='{admin}' WHERE account_id='Account-UUID-XYZ-ABC' .. note:: To remove someone from the admin group: .. code:: sql UPDATE accounts SET groups=NULL WHERE email_address='email@address.tld' -- 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. .. code:: sql INSERT INTO accounts (account_id, first_name, last_name, email_address, creation_actions_done, created) VALUES (gen_random_uuid(), 'Foo', 'Bar', 'foo.bar@domain.tld', 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``. .. _ops-admin-per-project-pvc: Per-project PVC mode ---------------------------------- By default, the home directory of every project is a sub-directory of one large, shared :term:`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 :term:`ReadWriteOnce` only (e.g. Longhorn, EBS, Ceph RBD) — :term:`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-``) 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`` :term:`ServiceAccount` is granted ``persistentvolumeclaims`` permissions in the namespace's :term:`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`` :term:`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 `` (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 :ref:`config-per-project-pvc`.