# rubix-deploy

New Rubix server — full install flow. **Tested on Debian 13.**

**Repository:** https://gitea.dialer.work/swissdatabase/rubix-deploy  
App releases: https://gitea.dialer.work/swissdatabase/rubix/releases

## 0) SSH on a new VPS (from your PC)

Tested on **Debian 13** (Trixie).

```bash
wget -O bootstrap-vps-ssh.sh https://gitea.dialer.work/swissdatabase/rubix-deploy/raw/branch/main/bootstrap-vps-ssh.sh
```

```bash
chmod +x bootstrap-vps-ssh.sh
```

```bash
./bootstrap-vps-ssh.sh
```

```bash
ssh <your-host-alias>
```

## 1) Download Rubix (on the VPS)

Debian 13 VPS (see step 0).

```bash
wget -O install-rubix.sh https://gitea.dialer.work/swissdatabase/rubix-deploy/raw/branch/main/install-rubix.sh
```

```bash
chmod +x install-rubix.sh
```

```bash
sudo ./install-rubix.sh
```

The script will:

1. `apt update` / `upgrade`, install tools, **Docker** (`docker.io`) + Compose v2 plugin (apt or GitHub on Debian)
2. Ask for your **Gitea token** (if `GITEA_TOKEN` is not already exported)
3. Create **`/home/www/callcenter`** and download the latest **rubix** release

Optional: specific version `sudo ./install-rubix.sh v1.1.10`  
Optional: other path `sudo RUBIX_INSTALL_PATH=/opt/rubix ./install-rubix.sh`

## 2) Configure `.env` and start stack

While editing `.env`, set your domain values (`RUBIX_DOMAIN_CMS`, API/DB/Mail hosts, aliases) and make sure DNS A/AAAA records for those hosts point to this server (manage records at your registrar/DNS provider).

```bash
cd /home/www/callcenter/deploy/docker
```

```bash
cp .env.example .env
```

```bash
nano .env
```

Set at least: `GITEA_REGISTRY_PULL_TOKEN` (same token as step 1), `GITEA_REGISTRY_PULL_USER`, `MYSQL_ROOT_PASSWORD`, DB users/passwords, `COMPOSE_PROFILES`, domains, `RUBIX_STORAGE_ROOT`.

**`COMPOSE_PROFILES`** — comma-separated list of Docker stacks that `sudo ./up.sh` installs and keeps running. Default:

```env
COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk
```

| Profile | Container role |
|---------|----------------|
| `cms` | Rubix call center web app (Apache/PHP) |
| `mysql` | Percona/MySQL database |
| `phpmyadmin` | DB admin UI (`db.*` vhost) |
| `asterisk` | Dialer / SIP |

Optional profiles (add to the same line when needed):

| Profile | Container role |
|---------|----------------|
| `metabase` | Enhanced analytics at `/callcenter/admin/analytics` — while logged into Rubix, opening analytics in a new tab signs you into Metabase automatically (no second login). Dashboards respect work groups and permissions so each group admin sees only their data |
| `mailcow` | Full mail server stack (Mailcow); set `MAILCOW_HOSTNAME` and `mail.*` DNS |

Examples:

```env
COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk,metabase
COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk,metabase,mailcow
```

Start:

```bash
cd /home/www/callcenter/deploy/docker
```

```bash
sudo ./up.sh
```

Single service: `sudo ./up.sh mysql` / `cms` / `asterisk`

## Extra / Manual operations (optional)

Use these only when you need manual control (classic install via `sudo ./up.sh` already handles normal startup flow).

### SQL migrations (fresh database)

```bash
cd /home/www/callcenter/deploy
```

```bash
sudo RUBIX_MYSQL_VIA_DOCKER=1 MYSQL_DOCKER_CONTAINER=rubix-mysql ./apply_sql_migrations.sh
```

Use your `RUBIX_MYSQL_CONTAINER` from `.env`. Existing server: restore MySQL datadir under `RUBIX_MYSQL_DATA` instead.

### CMS HTTPS (when DNS is ready)

```bash
cd /home/www/callcenter/deploy/docker
```

```bash
docker-cms-certbot
```

### Dialer

```bash
docker-asterisk
```

```bash
/etc/init.d/callcenter2 restart
```

### Updates (app already installed)

```bash
cd /home/www/callcenter/deploy
```

```bash
./rubix_deploy_from_release.sh vX.Y.Z
```

## Software Update (CMS admin panel)

After the stack is running, app updates can be done from the call center admin UI instead of SSH.

### 1) Grant permission to the admin user

The user who should run updates needs the **Software Update** permission enabled.

1. Log in as a superadmin (or another user who can edit permissions).
2. Open **Management → Users Permissions** (search: `Users Permissions`).
3. Select the target admin user.
4. Enable **Software Update** (`gru`) and save.

Without this checkbox, the **Software Update** panel is hidden and API calls return *No Software Update permission (gru)*.

### 2) Open the panel

**Management → Software Update** (popup). The panel reads the installed version from `VERSION`, compares it to the latest release on Gitea (`RUBIX_GIT_RELEASE_URL` in `/etc/rubix/.env`), and shows deploy logs.

Required in `/etc/rubix/.env`:

- `RUBIX_GIT_RELEASE_URL` — e.g. `https://gitea.dialer.work/swissdatabase/rubix/releases/latest`
- `RUBIX_GIT_TOKEN` or `GITEA_REGISTRY_PULL_TOKEN` — token with read access to releases
- `RUBIX_PANEL_HOST_UP_ENABLE=true` — show host reload buttons (default: enabled)

Logs (under the install path):

- `deploy/rubix_deploy.log` — panel ZIP deploy
- `deploy/rubix_host_up.log` — host `up.sh` (when triggered)

Use **↻ Reload logs** to refresh both logs in the panel.

### 3) Update options

| Button | What it does |
|--------|----------------|
| **Install latest release** | Downloads the release ZIP from Gitea, syncs files into `/home/www/callcenter`, runs SQL migrations from the CMS container. Does **not** restart Docker services on the host. |
| **Install latest release and trigger reload** | Same as above, then queues `deploy/docker/up.sh` on the host (root cron, ~1 min). Restarts/refreshes the stack: Docker compose, MySQL users, firewall, host cron, SQL migrations via `docker exec`, certbot, fail2ban, etc. |
| **Trigger reload (up.sh only)** | No ZIP deploy. Only queues `deploy/docker/up.sh` on the host (root cron). Use when code is already up to date but you need containers/services refreshed and DB migrations applied on the host. Available even when no newer release exists. |

**Install latest release** = code + migrations inside CMS.  
**Trigger reload** = full host stack reload via `sudo ./up.sh` (panel cannot run it directly; root cron picks up the request).

Manual equivalent on the server:

```bash
cd /home/www/callcenter/deploy
./rubix_deploy_from_release.sh vX.Y.Z          # panel “Install latest release”
# or
cd /home/www/callcenter/deploy/docker && sudo ./up.sh   # panel “Trigger reload”
```

## Multi-company / multi-branch layout

Rubix is built around **work groups** so you can separate companies, branches, or teams on one platform.

**One server, several tenants** — run a single Rubix stack and assign users, campaigns, permissions, and data to different groups. Each group admin and their agents see only what their group is allowed to access.

**One server per tenant** — install a full Rubix stack on a separate VPS for each company or branch when you want hard isolation (own database, domains, and ops).

Choose based on scale, compliance, and how much sharing you want on the same host.

### Metabase analytics and groups

With the `metabase` profile enabled, analytics at `/callcenter/admin/analytics` is tied to the same Rubix session (auto sign-in when you open it from Rubix).

Metabase questions and SQL are adjusted so results respect **allowed work groups**: a group admin sees dashboards and query output for their groups only, not the whole server. Superadmins retain broader visibility according to Rubix permissions.