...
Initial set of keys/commands
Command | Reported information | Potential use |
ps | ps output | Look for hung processes |
du | du -a /persist | Track down disk usage |
du.<subdir> | du -a /persist.<subdir> | E.g., du.log, du.IMGA |
state | All of /var/run content | Snapshot for all agents and object |
state.<agent> | /var/run/<agent> | Snapshot for one agent |
state.<agent>.<type> | /var/run/<agent>/<type> | For agent and type |
state.obj.<key> | /var/run/*/*/<key> | E.g., look for an instance UUID |
config | /config except any *.key.pem | Looking for stale files |
persist.<subdir> | ls /persist/<subdir> | Looking for stale files or missing certs |
lspci | Alpine lspci output | Check if pci controllers match model |
lsusb | Alpine lsusb output | Check if any USB devices connected |
iptables | Iptables -t filter; iptables -t raw; iptables -t nat, all with -L -nv | Check if iptables are wrong + counters |
route | ip route show | |
route.X | ip route show table X | |
rule | ip rule show |
Considerations for adding future commands
...
Currently none of the defined commands alter the state of the device, and if there is a desire to alter the state (e.g., purge certain directories to recover from low on disk space) it would make sense to explore alternative approaches than this basic fire-and-forget approach.
Implementation notes
The device will retain counter Y value for command string X, in similar ways as it retains a rebootCount and uuidtonum persistently across reboots.
This could be in /persist/status/zedagent/KeyToNum/X.json
When zedagent receives config items from the controller it will compare the counter Y with what is recorded, and if it is different than it will send the requested output to the log API. It makes sense for the log output to include the command string and counter value.