Repository navigation
RivetMSP 26.10.18 (RivetCore 1.0.0-rc.15: Mesh device group id in MeshCentral's URL form)
Adopts RivetCore 1.0.0-rc.15. A real MeshCentral (an owner's server) showed that its device group id (meshid) is not hex: it is 64 characters of base64 in MeshCentral's URL spelling (@ for +, $ for /; 48 raw bytes), with no mesh// prefix, and the download address is https://<mesh>/meshagents?id=4&meshid=<64 characters>&installflags=0. Core now accepts that, and RivetMSP's Mesh card follows. DB 2.6.90: one idempotent step gated on 2.6.89 that runs Core migration 0024_rmm_mesh_group_url through the Core runner (one added column, endpoint_agent_mesh_settings.group_id_url varchar(64) NOT NULL DEFAULT '', guarded by information_schema; nothing else altered; db.sql carries it and a fresh import equals a migrated database). Nothing is switched on by this update. Rows saved with rc.12 to rc.14 keep working (the URL form is derived from their stored hex). Ported from RivetIT 26.10.41 (same Core pin and the same behaviours; RivetMSP's own card and page structure). The warning is shown inside the Mesh card, once, instead of in the toast.
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.89 to 2.6.90; safe before or right after the code, and until it runs everything works: only the verbatim URL form is not remembered). No new cron line, no nginx change. Roll out an agent built from RivetCore rc.15 with this server if you use the optional Mesh install: the installer payload's mesh.meshid is now the URL form (same member, payload version 1), which agents from rc.12 to rc.14 cannot use (they record a Mesh error; the RivetMSP install itself is unaffected). After the update, re-save the group id once if you want the verbatim form MeshCentral printed kept; reissue installers from the updated server.
- Device group id field (Administration > Endpoint agent > MeshCentral). Help text: paste the download address from MeshCentral (device group, Add Agent, Windows 64-bit installer) or just its
meshid; it is 64 characters, not hex; treat it like an invitation key. The field is no longer limited to hex: it takes the whole pasted address, the bare 64-charactermeshid,mesh//<64>and the old hex form, trims only whitespace and sends the raw value to Core (mesh_group_id) with room for a pasted address (2000 characters). Core refuses whitespace inside, quotes,&,#, a wrong length and another alphabet with one sentence and writes nothing; what was typed is put back escaped. The field stays a masked password input with its show toggle and now reads backmesh_group_id_url(the canonical hex stays inmesh_group_id). Warnings from the save response (today: a pasted address for a host other than the saved MeshCentral address) are shown in the card after Save ("Saved, with a warning: ..."), once,role="alert". - Certificate pin. Help text: leave empty when the server certificate is issued by a public CA such as Let's Encrypt (a certificate that renews every 60 to 90 days would break a pin); use a pin only for a private CA or a self-signed certificate. Read it from the server shows Core's
pin_probe.noteand, whenpin_probe.publicly_trustedis true (a second, verified handshake succeeded), shows a "publicly trusted: no pin needed" panel and offers no way to put the hash in the pin field; for a self-signed certificate the proposal, the note and the button are as before. - Core's note under Advanced now says what was checked against a real MeshCentral (the download address shape, agent id 4) and what was not (Linux agent ids, install arguments, node-id locations).
- Installer payload and Linux command.
mesh.meshidand the Linux--mesh-group-idcarry the URL form (verbatim as pasted, else derived from the hex);install-linux.shquoting ('...') is Core's, so the$in an id is safe. - Pin:
rivet/rivet-core ^1.0.0-rc.15(lock referenceb930c50063823d1ee324216b7612e518bbb87998), vendored copy identical togit archiveof the tag;tests/wave1_integration.phpfollows the pin and the new step (82 checks, was 79). - Tests:
tests/rmm_ui.php1667 checks (was 1617; the Mesh fragment now covers the baremeshid, the whole pasted address for the saved host and for a different host (warning), hex,mesh//, whitespace trimming, 19 hostile or malformed values refused with nothing written, escaping of a hostile value put back, clearing, a row from before migration 0024, the new help texts, the self-signed probe note and the publicly-trusted panel, end to end through Core's verified handshake against a LOCAL CA (a secondphp -Sstarted withcurl.cainfo= that CA, plus the control that the same server is not trusted by the first web server; this proves the wiring, not Let's Encrypt itself;tests/support/tls_stub_server.pyanswers the HEAD that handshake sends)),tests/rmm_installer_ui.php85 (payload decode shows the URL-formmeshid, verbatim for a pasted address with@and$),tests/endpoint_agent_module.php84 (the 2.6.89 to 2.6.90 step, idempotent, equals a freshdb.sqlimport), the Mesh browser smoke 19 checks (was 15: the same forms through the real page, the warning, hostile values, and the payload decoded from a real installer download), the other eight browser smokes, golden replay, real agent (12) and real P2/P3 agent (30) suites with an agent built from the rc.15 tag, phpunit (229 tests) and the regression list. Known results, identical on 26.10.17 (rc.14, checked by running the same suites on that tree in the same environment):sla_pause2,recovery_integration3 (the 600000-iteration drill archive), browserrmm_p68_admin_smokecheck 14 (queue-worker guidance text, environment dependent), andendpoint_agent_golden.php strictreporting only the four intentional01-disableddifferences (a disabled module answers 503module_disabled;goldenreplay, which allows exactly those, is clean);rmm_smokecheck 25 and aHQsubstring in a CSRF token on the fields page ofrmm_ui_p23_a_policies.phpare intermittent. The real-agent proof (tests/real_agent_proof/run.sh, docker, a real systemd agent built from the rc.15 tag, a MOCK Mesh server) passes with 71 checks. The real-agent proof harness (tests/real_agent_proof) now uses a fresh random URL-form group id. Every group id in the tests is generated at run time or a fixed fake; no real MeshCentral address or id is in the repository. - Not verified: only the Mesh download address shape and agent id 4 were checked against a real MeshCentral (by Core, not here); the Linux agent ids, the install and uninstall arguments, where the node id can be read, and everything on a Windows host are not. Nothing was installed from a real Mesh server and nothing was deployed.