sync: auto-sync from HOWARD-HOME at 2026-07-05 15:29:59
Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-07-05 15:29:59
This commit is contained in:
95
.claude/skills/owncloud/SKILL.md
Normal file
95
.claude/skills/owncloud/SKILL.md
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: owncloud
|
||||
description: "Read-only inventory of ACG's ownCloud server (cloud.acghosting.com / 172.16.3.22, ownCloud 10.16 Community) for GPS backup verification: who has an account, per-user storage used + quota + last login, and which GuruRMM endpoints actually run the ownCloud desktop client. Triggers: owncloud, cloud.acghosting, who backs up to owncloud, owncloud usage, owncloud audit."
|
||||
---
|
||||
|
||||
# ownCloud Skill
|
||||
|
||||
Read-only client for ACG's live **ownCloud 10.16.0 Community** server
|
||||
(`cloud.acghosting.com`, VM `172.16.3.22`, Rocky Linux 9.6). Answers the GPS
|
||||
backup-audit question: **which customers back up here and how much data do they
|
||||
hold** - and, with `--rmm`, which enrolled machines actually run the ownCloud
|
||||
desktop client. It never writes.
|
||||
|
||||
This skill is one of the backup-verification siblings alongside `seafile`,
|
||||
`b2` (Backblaze) and `datto-workplace`.
|
||||
|
||||
## Running
|
||||
|
||||
```bash
|
||||
OWNCLOUD=".claude/skills/owncloud/scripts/owncloud.py"
|
||||
py "$OWNCLOUD" status # SSH ok + occ version / edition
|
||||
py "$OWNCLOUD" users [--json] # all users + enabled/quota/used/last login
|
||||
py "$OWNCLOUD" usage [--json] # per-user rollup, used GB desc (the audit view)
|
||||
py "$OWNCLOUD" audit [--client NAME] [--rmm] [--json]
|
||||
```
|
||||
|
||||
Add `--json` to `users` / `usage` / `audit` for machine-readable output.
|
||||
`--host` overrides the server IP (default `172.16.3.22`).
|
||||
|
||||
## Access channel
|
||||
|
||||
There is **no ownCloud admin web / OCS account** in the vault, so the channel is
|
||||
**SSH + the `occ` CLI**, not the OCS HTTP API (the OCS endpoint is reachable at
|
||||
`https://cloud.acghosting.com/status.php` but we lack an OCS admin cred). The
|
||||
client SSHes to `root@172.16.3.22:22` with **paramiko** (password auth,
|
||||
AutoAddPolicy) and runs occ **as the web user**:
|
||||
|
||||
```
|
||||
sudo -u apache php /var/www/owncloud/occ <cmd>
|
||||
```
|
||||
|
||||
Credentials load lazily from the SOPS vault (never hardcoded):
|
||||
`infrastructure/owncloud-vm.sops.yaml` -> `credentials.username` (root) /
|
||||
`credentials.password`.
|
||||
|
||||
## The occ / DB commands it settled on
|
||||
|
||||
- **status:** `occ status --output=json` (+ `occ -V` for the display version).
|
||||
- **users:** `occ user:list --show-all-attributes --output=json` -> per user:
|
||||
`uid, displayName, email, quota, enabled, lastLogin, creationTime, home,
|
||||
backend`. `lastLogin`/`creationTime` are Unix epoch seconds (0 = never); the
|
||||
client renders them as UTC.
|
||||
- **used bytes:** occ has **no `user:info` / per-user usage** on this version, so
|
||||
used storage is read from ownCloud's own **filecache** (the exact figure the
|
||||
UI shows). DB creds are read live from `config.php` (we already have root), then:
|
||||
`SELECT s.id, fc.size FROM oc_storages s JOIN oc_filecache fc ON
|
||||
fc.storage=s.numeric_id WHERE s.id LIKE 'home::%' AND fc.path='';`
|
||||
Each row is `home::<uid>` -> root size in bytes.
|
||||
|
||||
## What the data means
|
||||
|
||||
- **used_bytes** is the authoritative per-account storage used; an `enabled` user
|
||||
with non-zero usage is actively backing up here. `usage`/`audit` roll this up,
|
||||
sorted desc, with a total.
|
||||
- **quota** is a string: `default`, `none` (unlimited), or a byte/size value.
|
||||
- Usage is concentrated: as of the build (2026-07-05) a single account (`pavon`)
|
||||
holds ~14 TB and `sysadmin` ~2.9 TB, dwarfing the rest - ownCloud is used by a
|
||||
handful of clients, not the whole GPS base.
|
||||
|
||||
## The "both" cross-check (`--rmm`)
|
||||
|
||||
Server-side (occ) tells you who has an account; `--rmm` adds the endpoint half. It
|
||||
logs in to GuruRMM (`infrastructure/gururmm-server.sops.yaml`) and, for each agent
|
||||
(filter with `--client`), runs a **read-only** detection PowerShell reporting
|
||||
installed products / running processes / config folders matching **`ownCloud`**.
|
||||
An agent is reported only if the client is actually present. This dispatches a
|
||||
command to live endpoints - **always scope with `--client`** rather than sweeping
|
||||
all 350+ agents.
|
||||
|
||||
## Notes / gotchas / limitations
|
||||
|
||||
- **Dirty filecache (-1):** if a user's cached root size is `-1` (cache not yet
|
||||
computed), the client falls back to `du -sb <home>/files` for that one user.
|
||||
That du can take minutes on a multi-hundred-GB home (timeout is generous, 900s);
|
||||
`used_source` in `--json` reports `filecache` vs `du` per user. At build time
|
||||
one account (`anaise`) was dirty and resolved via du (~0.6 TB).
|
||||
- **Orphan storages:** the filecache can contain `home::<uid>` rows for deleted
|
||||
users (e.g. a former `QWM-Sheila`); the skill keys off the live `occ user:list`,
|
||||
so orphans do not appear in `users`/`usage`.
|
||||
- **No OCS/web API:** deeper per-file / sharing queries would need an OCS admin
|
||||
cred we do not have; occ + filecache cover the audit needs.
|
||||
- Shared plumbing (repo-root resolve, vault read, GuruRMM client + endpoint
|
||||
detection) lives in `.claude/scripts/backup_common.py`, used by all the
|
||||
server-backup skills. Detection patterns must be precise per backend - this
|
||||
skill uses `ownCloud` (not a bare `cloud`, which would over-match).
|
||||
Reference in New Issue
Block a user