Uninstall
This page shows how to uninstall node, ctrl, and the two gateways, and what data stays on the hosts and in external storage afterward. To reinstall or upgrade a package, see Reinstall and upgrade.
Notes
- The package scripts refuse to replace or remove the package when the service is still running, the systemd state is unknown, the configuration is missing but leftover state exists, or the maintenance check fails. After you fix the problem, retry the same operation.
- Both remove and purge delete only the package files and the service's enablement links. The data listed in Data left behind is kept. To destroy it, the deployer does so separately.
Order across components
To remove a whole deployment, uninstall the components in this order:
- The E2B gateway and the Exposure gateway, so that no new external requests arrive. See Uninstalling the gateways.
- Each node. See Uninstalling a node. Draining, cleaning up, and retiring a node all go through ctrl.
- ctrl, last. See Uninstalling ctrl.
Uninstalling a node
- Drain the node so that ctrl places no new Workspaces on it. Drain does not clean up any data.
- Delete or export all Workspaces, detached Volumes, and retained layers on the node.
kibo workspace list --node node-a --all -qlists its Workspaces. - Wait until the node reaches
DRAINED, then retire it withkibo node retire. ctrl then no longer counts it as a member of any storage pool, and the node ID cannot be enrolled again. Retire while the node service is still running: a stopped node is no longerDRAINED, andretirethen accepts it only afterkibo node isolate. - Stop the service, run the maintenance check, and purge the package.
Drain the node and list what is left on it:
kibo node drain node-a
kibo workspace list --node node-a --all -qAfter the cleanup, wait for DRAINED, retire the node, and remove the package:
kibo node drain node-a --wait --timeout 10m
kibo node retire node-a
sudo systemctl stop kibotos-node.service
sudo kibotos-node check-maintenance --config /etc/kibotos/node/config.toml --operation remove
sudo apt-get purge kibotos-nodeThe package scripts run the same --operation remove check, disable the service, and end the data-plane and egress processes. For retire and what happens to a pool that only this node reached, see Nodes.
Uninstalling ctrl
Uninstall ctrl after all nodes and gateways. Stop the service, then purge the package; the package scripts disable the service:
sudo systemctl stop kibotos-ctrl.service
sudo apt-get purge kibotos-ctrlReinstalling node after uninstall
After uninstall, /etc/kibotos/node and /var/lib/kibotos/node still exist, but the kibotos-node binary has been removed, so the install script has no binary to read these records with. When you reinstall:
- If any
kibotos-vmm-*units remain, the installation is refused and lists these units. After you confirm they are no longer needed, stop them (runsystemctl reset-failedfor any that are still listed), then retry the installation. - If there are no VMM units, the installation continues, keeps the existing configuration, identity, and records, and tells you to check before starting.
After the installation finishes and before you start the service, check the retained state with the newly installed binary:
sudo kibotos-node check-maintenance --config /etc/kibotos/node/config.toml --operation upgrade
sudo systemctl enable --now kibotos-node.serviceKeeping the identity works only for a node you did not retire: a retired node can never register again. If you do not plan to keep the existing identity, delete these two directories before installing, and enroll again by following Install node. After a retirement, use a new node ID.
Uninstalling the gateways
Stop the service first, then remove the package. The package scripts disable the service:
sudo systemctl stop kibotos-e2b.service kibotos-gw.service
sudo apt-get remove kibotos-e2b kibotos-gwData left behind
Neither remove nor purge deletes the following. Delete what you no longer need yourself:
| Component | What stays |
|---|---|
| ctrl | /etc/kibotos/ctrl/ (configuration and files it names), /var/lib/kibotos/ctrl/ (pki/ with this deployment's identity, credential-keys/), the PostgreSQL database, and the objects under kibotos-template/v1/<namespace>/ and kibotos-transfer/v1/<namespace>/ in the bucket |
| node | /etc/kibotos/node/, /var/lib/kibotos/node/ (the node identity in pki/, records, runtime installations, and the Template cache), pool directories outside storage.root, and the AppArmor local fragment /etc/apparmor.d/local/kibotos-node-roots if you created it |
| E2B gateway | /etc/kibotos/e2b/ and /var/lib/kibotos/e2b/, including its Operator identity |
| Exposure gateway | /etc/kibotos/gw/ and /var/lib/kibotos/gw/, including its Operator identity |
| All packages | The system accounts the packages created |
- A shared pool on NFS may still hold other nodes' objects. Delete its directory only after every node that declares it is gone.
- Keep
pki/andcredential-keys/if you may reinstall ctrl on the same database. Withoutpki/, all nodes and Operators must enroll again. Withoutcredential-keys/, the caller credentials stored in the database cannot be decrypted.
Upgrade from v0.2.x to v0.3.0
This page describes what you must do, beyond the general cross-version upgrade steps, when you upgrade from v0.2.x to v0.3.0. "Step N" on this page refers to the step table in Cross-version upgrades.
node and VMM processes
This page explains how node, VMM, data-plane, and egress processes run under systemd, and the two check commands to run before you replace the node binary. For complete upgrade and uninstall steps, see Reinstall and upgrade.