[Nut-upsdev] Man page sections

[Greg Troxel]

Jim Klimov <jimklimov+nut at gmail.com> writes:

> In context of the earlier posts in the thread: `upslog` pops up and is in a
> twilight zone: it is a client which does not need authentication (like
> upsc, but in a loop and may be looking at multiple sources). So perhaps
> correctly in "bin" by those criteria. But it can also be used as a daemon
> (optionally; reference service units provided for systems that would have
> them), so might be "sbin"-ish too.

I think it comes down to: would a normal user not acting
semi-sysadminish ever want to run it, and could they, doing something
useful.   I think it's ok for programs that land on the sysadmin side of
the divide to be in sbin.

> TBH, I am not sure the "requires (external) auth" mantra is a strong
> argument to put stuff (upscmd, upsrw, parts of NUT-Monitor) into sysmgmt
> area. A chat client like Pidgin or SSH client would need that too... but
> these are available as end-user programs that can be used by multiple users
> on a system for multiple different purposes (access same or different
> servers as  same or different people).

On one hand you are right, but pidgin/ssh are intended for remote
access, whereas I see nut clients intended primarily for the local ups,
where local might be different machine same cluster.  I'd again think
"is user acting sysadminish".  upsc is sort of "tell me the power
status" which feels semi-normal, but I'm not normal.


> The `nutconf` probably fits a sysadmin area, looking at and acting on the
> NUT configuration (so at least needs FS permissions to do its job);
> although in edge cases someone might use it with a custom `NUT_CONFPATH`
> e.g. for testing or package preparation. But these can do with
> fully-qualified path calls.

Definitely sbin.  and indeed sbin is not inaccessible, just not default.

> For the `nut-scanner` it depends: local devices (serial/USB) might be
> constrained by FS permissions (sysmgmt); scanning networked devices would
> not care (except on systems with detailed firewalls whose rules include
> user accounts and program names, or RBAC/SELinux/etc. complications). At
> least, the tool itself does not modify anything locally (only produces
> outputs that can be added into active NUT configs by copy-paste, shell
> redirect, `nutconf`, etc.) so is not strictly "sysmgmt". The most
> questionable part is whether layman users *should* be able to casually call
> something like this, and if fully-qualified path calls do not suffice (with
> the tool moved into "sbin"). IIRC it ended up in `bin` to facilitate setups
> for home users who would do most of the routine as the unprivileged
> account, but I don't think this should stop us if we deem a change needed
> (just someone should update blogs to `sudo -i` before most of NUT setup, if
> not yet).

I see nut-scanner as fundamentally sysadmin in intent and usage, even if
it doesn't need privs.   sbin is all about segregating commands that
normal users wouldn't want to run

> The (sample) `upssched-cmd` script probably should be in `sbin` if not
> under `libexec(/nut)` or even `share` (and maybe named as a `*.sample` like
> packaged config templates are).
> The actively used one (referenced as CMDSCRIPT from upssched.conf) should
> be a modified copy or unrelated code, placed wherever the local sysadmin
> deems fit.

agree that examples belong in share/examples/nut, not really installed