Documentation
¶
Overview ¶
Package cli is the command-line surface. Running the binary with no arguments starts the dashboard: that is the whole first-run experience.
Installing LAN Sheriff as a service, from the binary itself.
Why this exists when the packages already do it ¶
The .deb, .rpm and .apk have carried a systemd unit and a service account since M5. They cover Linux users who install from a package, and they cover them well. They do not cover the person who downloaded a binary from the releases page, or copied one off a test card, which is everybody on macOS and Windows and a good share of Linux besides. That person had a working dashboard for exactly as long as their terminal stayed open, and no obvious way to get from there to something that survives a reboot.
Without it, the realistic outcomes are a process tied to an interactive session that dies on disconnect, or a hand-typed command line that a reboot replaces with a different one. Neither is an install in any sense a user would recognise.
What it deliberately does not do ¶
It does not invent a second set of conventions. The service account, the data directory, its 0700 mode, capabilities rather than root, localhost by default, and a password the moment it is exposed: all of that is what the packages already do, and this reproduces it rather than improving on it. Two installers that disagree about where the data lives is worse than either.
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ( Version = "v.1.9.9PRB" Commit = "none" BuildDate = "unknown" // Build is the number of commits reachable from this build, which makes it // a counter that goes up on its own as work happens and never needs to be // remembered or edited by hand. A beta tester saying "build 412" identifies // the exact tree; "v.1.9.9PRB" identifies six weeks of them. Build = "0" )
Build information, injected at link time by the Makefile and the release workflow.
Functions ¶
Types ¶
This section is empty.