ClusterCockpit/cc-backend
1
0
Fork 0
mirror of https://github.com/ClusterCockpit/cc-backend synced 2026-06-17 17:07:29 +02:00
Code Issues Packages Releases Activity

Rewording of init README

Browse Source
This commit is contained in:
Jan Eitzinger
2026-06-17 15:24:13 +02:00
parent 83d04dff17
commit 3562bfa3aa
1 changed files with 18 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
init/README.md
View File

@@ -1,19 +1,19 @@
# How to run `cc-backend` as a systemd service.
# How to run `cc-backend` as a systemd service
The files in this directory assume that you install ClusterCockpit to
`/opt/monitoring/cc-backend`.
Of course you can choose any other location, but make sure you replace all paths
starting with `/opt/monitoring/cc-backend` in the `clustercockpit.service` file!
The `config.json` may contain the optional fields *user* and *group*. If
The `config.json` may contain the optional fields _user_ and _group_. If
specified, the application will call
[setuid](https://man7.org/linux/man-pages/man2/setuid.2.html) and
[setgid](https://man7.org/linux/man-pages/man2/setgid.2.html) after reading the
config file and binding to a TCP port (so it can take a privileged port), but
before it starts accepting any connections. This is good for security, but also
means that the `var/` directory must be readable and writeable by this user.
The `config.json` file may contain secrets and should not be readable by this
user. If this file is changed, the server must be restarted.
means that the `var/` directory must be readable and writeable by this user. The
`config.json` file may contain secrets. If this file is changed, the server must
be restarted.
```sh
# 1. Clone this repository somewhere in your home
@@ -55,8 +55,9 @@ It is recommended to install all ClusterCockpit components in a common directory
In the following we use `/opt/monitoring`.
Two systemd services run on the central monitoring server:
* clustercockpit : binary cc-backend in `/opt/monitoring/cc-backend`.
* cc-metric-store : Binary cc-metric-store in `/opt/monitoring/cc-metric-store`.
- clustercockpit : binary cc-backend in `/opt/monitoring/cc-backend`.
- cc-metric-store : Binary cc-metric-store in `/opt/monitoring/cc-metric-store`.
ClusterCockpit is deployed as a single binary that embeds all static assets.
We recommend keeping all `cc-backend` binary versions in a folder `archive` and
@@ -66,12 +67,13 @@ This allows for easy roll-back in case something doesn't work.
## Workflow to deploy new version
This example assumes the DB and job archive versions did not change.
* Stop systemd service: `$ sudo systemctl stop clustercockpit.service`
* Backup the sqlite DB file and Job archive directory tree!
* Copy `cc-backend` binary to `/opt/monitoring/cc-backend/archive` (Tip: Use a
- Stop systemd service: `$ sudo systemctl stop clustercockpit.service`
- Backup the sqlite DB file and Job archive directory tree!
- Copy `cc-backend` binary to `/opt/monitoring/cc-backend/archive` (Tip: Use a
date tag like `YYYYMMDD-cc-backend`)
* Link from cc-backend root to current version
* Start systemd service: `$ sudo systemctl start clustercockpit.service`
* Check if everything is ok: `$ sudo systemctl status clustercockpit.service`
* Check log for issues: `$ sudo journalctl -u clustercockpit.service`
* Check the ClusterCockpit web frontend and your Slurm adapters if anything is broken!
- Link from cc-backend root to current version
- Start systemd service: `$ sudo systemctl start clustercockpit.service`
- Check if everything is ok: `$ sudo systemctl status clustercockpit.service`
- Check log for issues: `$ sudo journalctl -u clustercockpit.service`
- Check the ClusterCockpit web frontend and your Slurm adapters if anything is broken!