fswatch is a simple file system monitoring module that takes advantage
of the persistent module framework in MIG to do continuous file
integrity scans of specific paths on the file system. When changes are
detected, alerts are generated and appear in the agent's log file.
Agents which are added or updated via a heartbeat message will have the
loadername value populated if the agent instance is associated with a
loader instance. This also permits targeting of agents using the loader
name associated with the agent.
Optionally create a summarized log entry for each command dispatched to
an agent by the scheduler. Currently this log entry just includes the
agent name, the loader name (if it is associated with a loader
instance), and the action name.
Use the agent ID/queue location information sent by the loader and
update a new queueloc column associated with the loader instance. This
provides an accurate means to identify any agents associated with a
given loader instance.
This allows these functions used within the agent to be used by the
loader as well. This is intended to establish a correlation between the
agent and a loader instance using the unique agent ID.
setadmin in mig-console was replaced by setperms; remove an old
reference to it in the help output. Also removes some references to
isadmin that were still present in API documentation.
Closes#312
When building the mig-agent or mig-loader targets and specifying AGTCONF
or LOADERCONF, configuration.go in the relevant directory is replaced by
the referenced configuration. If AGTCONF or LOADERCONF is not
overridden, the configuration is not replaced.
This can lead to inconsistent build results, as by building for example
the mig-agent target a second time with no AGTCONF, the replaced
configuration.go will be retained.
This changes this behavior, so configuration.go is always replaced with
the configuration files in conf/, unless the Makefile configuration
variable has been overridden.
Adds the ability for persistent modules to read a configuration file
that can be used to control their behavior.
In some cases, we may want a persistent module to be configurable. A new
configuration variable PERSISTCONFIGDIR has been added which indicates a
directory the agent will look in for persistent module configs. When the
agent starts a persistent module, it will determine if modulename.cfg
exists in the config directory; if so the agent will load the config and
send it to the newly executed module, which it will read on stdin. The
module can then read this configuration, and configure itself as needed
before it begins it's primary execution functions.
Modules specify the configuration format within the module code itself,
so each module that makes use of this can have it's own configuration
parameters.
Aaron Meihm
Julien Vehent [:ulfr]
jboyer2012
rvnr
Rob Murtha