RivetMSP 26.10.15

[26.10.15] RivetMSP — RivetCore 1.0.0-rc.11: remote tools, file transfer, log collection, RMM scale

Ports RivetIT's released adoption (26.10.38) of RivetCore 1.0.0-rc.11 (RMM Phase 6 remote tools, Phase 8 log collection, scale items S3 to S8). DB 2.6.88 (one idempotent step gated on 2.6.87 that runs Core migrations 0021_rmm_scale_storage and 0022_rmm_remote_and_logs through the Core runner: ten new tables, nothing existing altered; plus settings.config_rmm_remote_manage_lvl3 and the four config_rmm_extstore_* columns, all off; db.sql carries it and a fresh import equals a migrated database). Nothing is switched on by this update: the remote_tools, filetransfer and logs sub-switches, partitioning, herd control and the external metric store are all off until an administrator turns them on, and older agents are answered exactly as before (golden transcripts replay identically).

Deploy notes: back up the database, pull this tag, composer install --no-dev --no-plugins --no-scripts, php scripts/update_cli.php --update_db (2.6.87 to 2.6.88; safe before or right after the code). No new cron line. The live nginx rules are not changed by this release (the shipped templates already deny backups/, where file transfers are stored). To use remote tools or logs, roll out an agent built from RivetCore rc.11 first.

• Device bridges: api/v1/agent_transfer.php and api/v1/agent_logs.php, routed above the bearer parsing and documented in openapi.yaml; api/v1/rmm_gate.php is Core's rc.11 template (answers both while the module is off and enforces the warm start before any database work). File transfers live in backups/endpoint-transfer (EA_TRANSFER_DIR overrides).
• Remote tab on the asset page (services, processes, files, MeshCentral desktop/terminal/files) in its own handler agent/post/rmm_remote_tools.php; agent/post/rmm_remote.php (Remote Connect) is untouched and now pinned by a test.
• Logs and Log rules (Endpoints menu, shown only to users with the ability; asset Logs tab), client scoped by Core.
• Administration: cards for Remote tools, File transfer, Log collection, Scale settings, Metric storage and partitioning and the External metric store. RivetMSP writes metrics through Core's DatabaseMetricSink, so Core's daily rollup and partitions apply to RivetMSP's own tables: the storage card lists rmm_metric_hourly, rmm_metric_daily and endpoint_agent_check_history, shows the rollup status, and Enable converts every table the probe allows (naming any it leaves plain); the Performance and capacity panel shows the autoscaling hint, cache, herd control and the three tiers.
• Permissions: new ability rmm.remote.manage (administrators; a role with scripts level 3 and remote access only while the new Administration setting is on); sending a file to a device and the remote-tools settings stay administrator-only. Events rmm.file.transferred and rmm.log.rule_matched appear in the picker (read from Core's catalog).
• Operations: cron/integration_worker.php --worker=N runs several queue workers; with Redis the RMM read cache and token buckets use it from every entry point; housekeeping (already called by cron/cron.php) now also builds the daily rollup, prunes logs, expires transfers and flushes the external buffer. The external store's three settings are registered for key rotation and a schema scan fails when a secret-looking column is missing from the registry.
• Tests: tests/rmm_ui.php with new fragments (remote, logs, admin incl. the rollup and partitioning of all three tables on MariaDB 11.8), three browser smokes (17, 15 and 18 checks, desktop and phone, light and dark), tests/real_agent_proof/run.sh (39 checks with the real Linux agent built from rc.11 under systemd), policy conformance cases, registry scan. Not verified: any Windows code path, a real MeshCentral server, Core's S9 24-hour 10,000-device run, and live systems (nothing was deployed).