<div dir="ltr"><div>Just in case, I've double-checked what commonly lands into which directory without any large path customization except putting drivers out of sight.</div><div><br></div><div>
<div>This was a quick build test, so maybe there are further programs in
other build setups (and/or platforms). But I guess these ones are
widely used so should be present in almost all builds.</div><div><br></div><div>----</div><br></div><div>:; rm -rf /tmp/nnnn ; git clean -fdX ; ./autogen.sh && ./configure --with-all=auto --with-drvpath='${prefix}/drv' --enable-docs-man-for-progs-built-only=yes && make DESTDIR=/tmp/nnnn install -j 8</div><div>:; find /tmp/nnnn | grep -E 'libexec/|bin/'<br>/tmp/nnnn/usr/local/ups/cgi-bin/upsstats.cgi<br>/tmp/nnnn/usr/local/ups/cgi-bin/upsset.cgi<br>/tmp/nnnn/usr/local/ups/cgi-bin/upsimage.cgi<br></div><div><br></div><div>/tmp/nnnn/usr/local/ups/libexec/sockdebug<br>/tmp/nnnn/usr/local/ups/libexec/nut-driver-enumerator.sh<br>/tmp/nnnn/usr/local/ups/libexec/enphase-monitor</div><div><br></div><div>/tmp/nnnn/usr/local/ups/sbin/upsmon<br>/tmp/nnnn/usr/local/ups/sbin/upsd<br>/tmp/nnnn/usr/local/ups/sbin/upsdrvctl<br>/tmp/nnnn/usr/local/ups/sbin/upsdrvsvcctl<br>/tmp/nnnn/usr/local/ups/sbin/upssched<br></div><div><br></div><div>/tmp/nnnn/usr/local/ups/bin/upslog<br>/tmp/nnnn/usr/local/ups/bin/upsc<br>/tmp/nnnn/usr/local/ups/bin/nutconf<br>/tmp/nnnn/usr/local/ups/bin/nut-scanner<br>/tmp/nnnn/usr/local/ups/bin/NUT-Monitor<br>/tmp/nnnn/usr/local/ups/bin/upsrw<br>/tmp/nnnn/usr/local/ups/bin/upscmd<br>/tmp/nnnn/usr/local/ups/bin/upssched-cmd</div><div><br></div><div>----</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div>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.</div><div><br></div><div>Jim Klimov</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jun 4, 2025 at 2:31 PM Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim Klimov via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> writes:<br>
<br>
> The puzzle I found myself solving is whether all NUT programs truly fit<br>
> into "System management commands" (well, in a way they do all relate to<br>
> power mgmt), or if the division line is more about end-user/interactive<br>
> programs vs. daemons and sysadmin commands - similar to "bin" vs. "sbin"<br>
> (can that choice of install path semi-bluntly apply to man section<br>
> selection too)?<br>
<br>
>From having used Unix since Sixth Edition, and not really going to study<br>
anything before responding, my immediate reaction is<br>
<br>
Users should have /bin and /usr/bin in PATH, but not sbin. Programs<br>
in bin are thus intended for users, and man pages should be foo.1<br>
<br>
System administration is generally done with /sbin and /usr/sbin<br>
additionally in path. Programs in sbin are thus sysadmin commands,<br>
and man pages should be bar.8<br>
<br>
> Is the `NUT-Monitor` (python UI) a sysmgmt or user program? What about<br>
> `upsc`, `upscmd`, `upsrw`? Perhaps tools like `nut-scanner` or `nutconf`?<br>
> Or developer aids like `sockdebug`/`pipedebug`?<br>
<br>
To answer this, think about a computer with a UPS, and 8 users, 2 of<br>
whom are able to become root and do sysadmin, and 6 are not. This is<br>
the normal situation for a server.<br>
<br>
If it's reasonable for a non-admin user to run a program, and it will<br>
run and at least read status without needing to be a uid/gid with any<br>
kind of privileges, then that program should probably be in bin and .1.<br>
If the program doesn't make sense to use without privileges (even if the<br>
privileges are knowing a nut pw, not being uid 0), then it belongs sbin<br>
and .8.<br>
<br>
I would say<br>
<br>
bin/1:<br>
upsc <br>
<br>
sbin/8:<br>
upscmd, upsrw, nut-scanner, nutconf<br>
<br>
> There is less of question about `upsd` or daemon clients like `upsmon`,<br>
> `upssched`, `upslog`, CGI, drivers, etc. - they belong in .8.<br>
<br>
Agreed. But cgi doesn't belong in sbin. It belongs in libexec/cgi,<br>
because sbin should only contain programs that people run. Programs<br>
that are (only) run by other programs belong in libexec.<br>
<br>
<br>
<br>
<br>
An example of this "sort of logically system management but sensible for<br>
normal users" is envstat (on NetBSD) which prints the CPU temperatures.<br>
I would have said that belongs in bin/1, but it's in sbin/8. So not<br>
the right place (on a knife-edge decision) but consistentcy in place for<br>
program and place for manual.<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>