Get started with Cogitave Massar
Massar is the guardian agent that lets an authorized Cogitave operator open an audited terminal session on a customer device with no inbound port and no VPN. Understand the dial-out security model and how a session is bridged, then install, verify, and cleanly remove the agent on Linux and Windows using the real installers.
Modules2
Duration69 min
Levelbeginner
Prerequisites
- Comfort with a Linux or Windows command line and administering a host.
- No prior Cogitave, Rust, or agent experience required.
Modules in this path
- Understand Cogitave Massar Cogitave Massar is the guardian remote-console agent that gives an authorized operator a terminal on a customer device without opening an inbound port or requiring a VPN. This module explains what Massar is and the one job its agent performs, why an outbound-only connection model removes the need for inbound access, how a session moves control messages and terminal bytes across the agent-broker-operator chain, and how a device authenticates while Diyar-side RBAC and audit authorize and record who connects. It also states plainly which parts are shipped today - the CLI installers with a static per-device token, Windows and Linux support - and which are still previews, such as the graphical enrollment wizard and macOS support.
- Install and operate the Massar agent This module installs and operates the Cogitave Massar agent: the small, cross-platform binary a customer runs on a device so an authorized Diyar operator can dial in for an audited remote terminal, with no inbound port and no VPN. You install it with the CLI installer for your OS - install.sh on Linux, install.ps1 on Windows - confirm it is verified and running as a service, trace a session from open to close, reproduce the whole relay locally with the project's own dev harness, and remove it cleanly when you are done. Two facts are stated plainly rather than glossed over: today's supported install targets are Windows and Linux only, and every end-to-end proof described here is the local dev harness, not a production Diyar deployment.
Related
- Glossary The terms used across Cogitave documentation and training, defined once - agent kernel, capability grant, provider driver, sandbox, sovereign unikernel, MCP, evidence, and the words that are easy to assume.
- Introduction to Cogitave Diyar Diyar is Cogitave's edge-autonomous platform for operating regulated field devices, where the device stays the sole authority over safety and evidence and each industry ships as a signed, pluggable solution. Understand what Diyar is, why safety and evidence stay local to the device, and how a device becomes a solution through signed profiles, verdict engines, and app packages.
- How a device becomes a Diyar solution Diyar turns a physical device into a certified solution through layered signed documents and firmware-compiled registries, not through custom code written per customer. A signed device profile configures the edge's hardware at boot; a certified verdict engine - a frozen product engine or one of the generic function blocks - decides pass or fail; and a three-document app package computes, offline, exactly what a device is authorized to observe, operate, or actuate. The module walks each of these three layers as they exist in the Diyar edge platform today, closes with one worked solution (ISPM-15) built entirely on that machinery, and states plainly where a capability is proven only against internal example fixtures rather than a field deployment - because that distinction is part of what you need to evaluate the product honestly.