TRACKALERT(1)

📦
version 3.0.0 · 3 versions
, in ubuntu stonking

💖 TRACKALERT — the trackalert manual page 💖

okay bestie, so trackalert(1) is the manual page for the trackalert daemon, and I'm about to make it make sense. no cap.

✨ NAME ✨

trackalert — a daemon that tracks and alerts on long-term abuse trends for logins 🕵️♀️💅

🌸 SYNOPSIS 🌸

trackalert [OPTION]...

that's it. that's the whole vibe. options only, she doesn't take positional args fr fr.

🦋 DESCRIPTION 🦋

okay so. trackalert is out here running a simple HTTP server that accepts JSON formatted commands reporting successful and unsuccessful logins. she's a whole mood 💅

the way that she can be both a client AND a server?? main character energy, honestly. as a server she typically runs under systemd control — though she can also be run as a traditional daemon, or in 'interactive' mode. as a client, she connects to a trackalert server and hands you the same interactive commands. iconic 🔥

and bestie, she's scriptable in Lua — check the trackalert.conf file for a simple example. in fact, literally all configuration is done using the Lua language, because trackalert.conf is simply a Lua script. she said "config file? no, that's a program" 💀✨

🌈 SCOPE 🌈

trackalert depends on a system to feed her login reports, and that's typically going to be wforce (configured with a webhook that triggers only on "report") integrated with her using the HTTP/JSON API. she doesn't find the tea herself, she waits for it to be delivered 🫶

🎀 OPTIONS 🎀

  • -c — act as a client, connecting to a trackalert instance at the IP/Port specified in the 'controlSocket' function in trackalert.conf. a custom configuration file can be specified too ✨
  • -C, --config FILE — load configuration from FILE. and heads up bestie: trackalert will chdir to the directory where the configuration file is located. she moves in, she's not commuting 😭
  • -R, --regexes FILE — read device parsing regexes from FILE (usually regexes.yaml).
  • -s — run in foreground, but do not spawn a console. use this switch to run trackalert inside a supervisor (use with e.g. systemd and daemontools).
  • -d, --daemon — operate as a daemon 👑
  • -e, --execute CMD — connect to trackalert and execute CMD.
  • -f, --facility FACILITY NAME — log using the specified facility name, e.g. local0.
  • -l, --loglevel <0-7> — logs sent to stdout will be filtered according to the specified log level, matching the equivalent syslog level (0 - Emerg to 7 - Debug).
  • -h, --help — display a helpful message and exit. she's helpful 💖

🧚 CONSOLE COMMANDS 🧚

the following commands can be run from the console when trackalert is started with the -c option. group chat commands, basically 💬

🔑 makeKey()

returns a string to be used in the setKey() function in trackalert.conf to authenticate sibling communications. all siblings must be configured with the same key — no secret-keeping between sisters 💅

> makeKey()
setKey("CRK+jKBpzXNLmM2A4C7OpFCBxiwpYlreCWgGEAIKAQI=")

📊 stats()

returns statistics about the trackalert process. for example:

> stats()
40 reports

🛡️ showACL()

returns the configured ACLs for the trackalert server.

> showACL()
127.0.0.0/8
10.0.0.0/8
100.64.0.0/10
169.254.0.0/16
192.168.0.0/16
172.16.0.0/12
::1/128
fc00::/7
fe80::/10

🪝 showCustomWebHooks()

returns information about configured custom webhooks. for example:

> showCustomWebHooks()
ID        Name                 Successes Failures  URL
1         mycustomhook         10         0         http://localhost:8080/webhook/regression

⚡ showPerfStats()

returns information about performance statistics. okay listen, this one has lore:

stats beginning with WTW refer to the time that worker threads waited in a queue before running. stats beginning with WTR refer to the time that worker threads took to run. each stat is in a bucket, where each bucket represents a time range in ms, e.g. 0-1. a server that is not overloaded will have most stats in the 0-1 buckets. she's thriving, not stressed 🧘♀️

for example:

> showPerfStats()
WTW_0_1=2939287
WTW_1_10=9722
WTW_10_100=4
WTW_100_1000=0
WTW_Slow=0
WTR_0_1=2939229
WTR_1_10=2837
WTR_10_100=131
WTR_100_1000=0
WTR_Slow=0

📈 showCommandStats()

returns information about the number of REST API commands that have been called, including custom endpoints. stats are for the previous 5 mins, and due to the counting method, may be approximate when the numbers get very large — so don't @ her about exact digits 💀

for example:

> showCommandStats()
addBLEntry=0
allow=23942
delBLEntry=0
getBL=0
getDBStats=0
ping=300
report=19232
reset=24
stats=92
customEndpoint=2821

🌟 showCustomStats()

returns information about custom stats that are incremented from Lua. stats are for the previous 5 mins, and due to the counting method, may be approximate when the numbers get very large (same energy as above, bestie).

for example:

> showCustomStats()
custom1=0
custom2=8405

🌍 reloadGeoIPDBs()

reload all GeoIP DBs that have been initialized. refresh her memory, she'll remember everything 🧠✨

for example:

> reloadGeoIPDBs
reloadGeoIPDBs() successful

🏷️ showVersion()

returns the current version of the trackalert server. for example:

> showVersion()
trackalert 1.2.0

👀 SEE ALSO 👀

trackalert.conf(5) trackalert_api(7)

go read those next, bestie, they're part of the lore 📚💜

👑 AUTHOR 👑

Open-Xchange 2018

okay that's the whole page, you ate that 🫶 and just so you know who wrote this banger: it's from the trackalert(1) manual, sourced and dated 2026-07-28. periodt. 💅✨🌸

📦 where this page comes from