gotify-commander v0.4.0

Highlights

• Four new commands, 27 in total: failed, health, docker (only the containers you allow) and digest, a daily health summary.
• Commands posted while the plugin was disconnected now run once it is back, if they are newer than defaults.replay_window (5 minutes).
• Mac targets with os: darwin run macOS commands, and commands sent as messages can ask for a confirmation code first.

Same build matrix as 0.3.0: Gotify 3.1.1 and 2.9.1, on amd64, arm64 and
armv7. No configuration change is required to upgrade; every new setting is
optional and off by default except the message rate limit, which is now 20
per minute.

Added

• New command failed [vps/mac]: the failed systemd units, or
  "✅ No failed units". On the mac target it first asks the machine its
  system and answers "not available on macOS" there.
• New command health: one message with every mount at 85 % or more, the
  load average against the CPU count, the memory in use, the failed units
  and the certificates that expire within 14 days, each line marked ✅ or ⚠️.
  It reads the certificates with the same find and openssl calls as
  certs.
• New command docker ps|restart|logs <name>, limited to the containers in
  the new docker.allowed_containers setting and only when docker is
  installed. docker restart is a dangerous command: one at a time, like
  reboot.
• New command digest, which sends the health summary now, and the new
  digest: section (enabled, at, timezone) that sends it every day at
  that local time.
• New setting defaults.replay_window: how old a command posted while the
  plugin was not connected may be and still run when it connects again. 5m by
  default; 0s turns the replay off. A negative value is refused when the
  configuration is saved. Changing it reconnects the stream listener.
• A command older than the replay window is not run. The reply is
  "⌛ Command expired, not executed: ", with only the command word.
• Optional confirmation for commands sent as Gotify messages, off by
  default. List the commands in the new require_confirm setting, for
  example [reboot, shutdown, stop], and the first message no longer runs
  them: the reply is "⚠️ Confirm reboot vps: reply confirm 4821 within
  60 s", and only confirm <code> runs it. The code is random, works once,
  and only one command waits at a time; a new one replaces it and says so. A
  wrong or expired code gets "❌ No pending command for that code". The
  panel keeps asking in the browser.
• New confirmation: section for that reply: keyword (the reply word,
  confirm by default), prompt (the request text, with {command},
  {keyword}, {code} and {seconds}) and window (how long a code works,
  60s by default). A keyword that is not one lowercase word or that is also a
  command or service name, a prompt without {code} and a window under 1s
  are refused when the configuration is saved.
• New setting enabled_commands: the only commands that run, from messages
  and from the panel. Left out or empty, all of them run. Any other command
  gets "🚫 Command disabled by configuration" and is not counted. Unknown
  names in either list are refused when the configuration is saved.
• New setting ssh_targets.<name>.os: linux (the default) or darwin.
  With os: darwin, free, top, ip, ports and connections run
  macOS commands on that machine. Any other value is refused when the
  configuration is saved.
• logs works for Mac services: the last log_lines lines of the macOS
  unified log of the service's process, from the last 10 minutes.

Changed

• Commands sent as Gotify messages: the default limit goes from 10 to 20 per
  minute. The panel keeps its 10 per minute.
• New setting defaults.rate_limit_per_minute for the commands sent as Gotify
  messages. Empty or 0 means 20; a negative value is refused when the
  configuration is saved.
• The rate limiter moved to the internal/ratelimit package. The panel and
  the message path each have their own limiter, so they keep separate
  budgets.
• History entries saved by an earlier version have no timestamp. The panel
  drops them the first time it loads.

Fixed

• The mac target ran Linux commands that macOS does not have: free -h,
  ps --sort, hostname -I and ss. With os: darwin it runs vm_stat
  (shown as free, active, inactive and wired MiB), ps -r, ipconfig getifaddr en0 (or the ifconfig addresses), lsof and netstat
  (counted in Go). updates mac runs softwareupdate -l; updates alone
  keeps checking apt on the VPS.
• restart, stop, start and status of Mac services did not agree:
  launchctl load and unload need the path of a plist, while status
  looked for the label. All of them now use the label from launchd in the
  user's GUI domain: restart is launchctl kickstart -k, stop is
  launchctl bootout, start is launchctl enable plus kickstart -k,
  and status of a service without a port reads launchctl print
  (running (pid N), not running or not loaded). This does not depend
  on os, since launchd only exists on macOS. After a stop the service is
  unloaded, and start answers with launchctl's "Could not find service"
  error until it is loaded again on the Mac (launchctl bootstrap gui/<uid> <plist>).
• A command posted while the plugin was not connected to the Gotify stream
  (a Gotify restart, a dropped connection) was never run: Gotify does not
  push stored messages to a client that connects later. On every connection
  the plugin now reads the newest 100 messages of the command app and runs,
  oldest first, the ones it has not taken yet. A message that arrives both
  ways runs once.
• The ID of the last command taken is kept in the plugin storage, next to
  the generated password, and saved before the command runs: a reboot or a
  restart of Gotify is not run again on the way back up. On the first start
  after the upgrade nothing in the history runs.
• Saving the configuration in the Gotify UI no longer resets the command
  count, the last command and the uptime shown on the plugin page and by
  /health. The stream listener keeps its connection when server_url,
  client_token and command_app_id did not change; it reconnects only when
  one of them, or replay_window, did.

Security

• Commands sent as Gotify messages are rate limited: 10 per minute per plugin
  instance by default. Before, any client token of the user could queue 16
  reboots. A command over the limit is not run and gets "⏳ Too many
  commands, try again in N s". The panel keeps its own 10 per minute.
• reboot, shutdown and every command in a danger: true category run one
  at a time, from messages and from the panel. A second one sent while the
  first is still running is refused with "⚠️ Another dangerous command is
  still running". Other commands keep running.
• The panel's command history in localStorage expires after 24 hours. The
  password dialog says so and points to the Clear button.

Compatibility

A Go plugin only loads in the Gotify release it was built for.
Pick the file for your Gotify version and architecture.

Gotify	Architecture	File
3.1.1	amd64	gotify-commander-linux-amd64-for-gotify-3.1.1.so
3.1.1	arm-7	gotify-commander-linux-arm-7-for-gotify-3.1.1.so
3.1.1	arm64	gotify-commander-linux-arm64-for-gotify-3.1.1.so
2.9.1	amd64	gotify-commander-linux-amd64-for-gotify-2.9.1.so
2.9.1	arm-7	gotify-commander-linux-arm-7-for-gotify-2.9.1.so
2.9.1	arm64	gotify-commander-linux-arm64-for-gotify-2.9.1.so

Each file has a .sha256 next to it: sha256sum -c <file>.sha256.