Users and Tenants
admin user can do anything with a Hotrod system. It gets its power from the admin role,
so if you wish you can create multiple admin users.
hotrod users add mike 'Michael Snipes' --roles 'user,admin'
That is, a Hotrod 'super-user' is a user with the 'user' and the 'admin' roles.
This is recommended practice, since users appear in the audit logs:
$ hotrod daemon 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 target=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 target=Durban
Restricting Access with Tenants
A target has an identifier, a human-readable name, associated tags, and a tenant.
The usual meaning of 'tenant' is the particular customer associated with the target, but it is a convenient way to divide the network of target nodes into areas of responsibility.
admin users can effectively do anything to any of the target nodes, which makes
them too powerful for most system management roles. However, if a user has a 'admin' role and
a associated tenant, then that user can only operate on targets 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 targets. The other restrictions occur because a tenant user like Bob may not have any power over other targets: they cannot modify the global or tag contexts, because these are shared for all targets.
Taming the Agent
Nodes of a Hotrod network can be seen as servers requiring monitoring. These servers can be rather more important than the Hotrod server itself! Making the sysadmin a Hotrod tenant admin gives them full control over Hotrod operations on the systems they are responsible for, without giving them access to other systems which are not their responsibility.
hotrod-agent will poll the
hotrodd server (the
--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.
--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 runs:
It is further possible to enforce acceptable Pipe policy on the agent level with
--exclude-pipe-features option. It is given a list of features from this list:
execthe pipe may not run any commands (
exethe files associated with the pipe may not be executable
scriptno scripting whatsoever
scriptactions, but no custom