Users and Tenants
The admin
user can do anything with a ScubaLite Connect system. The admin
role has full rights, so if you wish you can create multiple admin
users.
$> hotrod users add mike 'Michael Snipes' --roles 'user,admin'
That is, a "superuser" is a user with the user
and admin
roles.
This is recommended practice, since users appear in the audit logs:
$ hotrod server logs
timestamp | level | message
---------------------+-------+------------------------------------------------------------
2020-10-26T13:42:55 | INFO | saving license from HOTROD_LICENSE_KEY
2020-10-26T13:42:56 | INFO | user=admin successful login from 127.0.0.1:56974
2020-10-26T13:42:56 | INFO | user=admin adding pipe=uptime to agent=Cape Town
2020-10-26T13:42:57 | INFO | user=admin creating user=bob
2020-10-26T13:42:57 | INFO | user=bob successful login from 127.0.0.1:56988
2020-10-26T13:42:57 | INFO | user=bob adding pipe=ping to agent=Durban
Restricting Access with Tenants
An Agent has an ID, a human-readable name
, associated Tags, and a Tenant.
The usual meaning of Tenant is the particular customer associated with the Agent, but it is a convenient way to divide the network of Agent nodes into areas of responsibility.
Regular admin
users can effectively do anything to any of the Agent nodes, which makes them too powerful for most system management roles. However, if a user has an admin
role and an associated --tenant-ids
, then that user can only operate on Agents sharing that Tenant.
$> hotrod users add Bob 'Bobs Burgers' --roles 'user,admin' --tenant-ids 'Western Cape'
The user Bob
only has power over a subset of the Agents. The other restrictions occur because a Tenant user like Bob
may not have any power over other Agents: they cannot modify the global or Tag Context, because these are shared for all Agents.
Taming the Agent
Nodes on a network can be seen as servers requiring monitoring. These servers may be more important than the Server itself. Making the admininistrator a Tenant admin
, gives them full control over operations and access only to the systems they are responsible for.
By default, the Agent will poll the Server (--poll-interval
value in seconds) and if the Server state has changed, the Agent will download any updated Pipes. This central control is appropriate for a fleet of collectors, but sometimes the Agent is a guest on a system.
If --poll-interval
is set to zero, then the Agent does not poll at a fixed interval. Instead, it waits for a notification. Logs and volume reports will still be transferred, but no automatic updates take place. Instead, the administrator will review the changes, and then explicitly run:
$> hotrod-agent --update
It is further possible to enforce acceptable Pipe policy on the Agent level with the --exclude-pipe-features
option. It's given a list of features from this list:
exec
the Pipe may not run any commands (input-exec
,action-exec
, oroutput-exec
)exe
the files associated with the Pipe may not be executablescript
no scripting whatsoeverinit-lua
may havescript
,actions
, but no custominit.lua