Nut upsdev - Jun 2017 - Proposed new documentation "Configuration Examples"

Allow me to suggest a couple more sample configs: 1) Server as UPS controller
with clients that are also on UPS, considering shutdown sequencing and 2) Multi
power supply server with multiple UPS (with or without clients).

- Tim

On June 13, 2017 10:01:54 PM CDT, Charles Lepple <clepple at gmail.com>
wrote:
>On Jun 9, 2017, at 10:16 AM, Roger Price wrote:
>> 
>> Most of the questions asked in the nut-user mailing list seem to me
>to be either erudite technical discussion of new and exotic UPS units,
>or n00b questions of the style "I have this old UPS so I installed NUT
>but it didn't work".
>> 
>> NUT is thoroughly documented with man pages and User Manual, but from
>my own experience it is not easy for Joe N00b to know what a working
>setup should look like in his case.
>
>To be honest, I am not sure that documenting these configurations will
>reduce the number of questions. Many people have preconceived notions
>of what NUT should do, based on what their current OS or
>vendor-provided software does (e.g. shut down after N minutes on
>battery). Perhaps the solution is to help map their configurations to
>NUT equivalents?
>
>> To address this, I propose a "NUT configuration for Noobs"
which is
>called "Configuration Examples".  A 27 page PDF file formatted to
be
>read on a 17 inch or bigger monitor using for example muPDF or evince. 
>It could be printed, but fewer people have printers these days.
>> 
>> The configurations are:
>> 
>> 1. Simple server with no local users
>> 2. Workstation with local users (solves the wall problem)
>> 3. Workstations share a UPS
>> 4. Workstation with a heartbeat
>> 5. Workstation with timed shutdown
>> 6. Workstation with additional equipment
>> 
>> The first version is at http://rogerprice.org/NUT/ConfigExamples.pdf
>Before I announce this in the nut-user mailing list, any comments,
>especially on the choice of configurations, are very welcome.
>
>Before I get into specifics, I would like to mention that there is a
>lot of useful content in this document, and it seems like a good
>companion to the NUT documentation.
>
>With that in mind, please understand that this criticism is meant to be
>constructive, although I do not have ready answers for all of these
>points.
>
>I agree that printers are becoming less and less common. However, I am
>not sure that a two-column format with little space and no rule between
>the columns is the best choice for screen display. Many PDF viewers can
>display two pages side-by-side, and will do so with a dark border
>around each page. There is probably a middle ground between these
>dimensions and the ones used in the AsciiDoc-generated PDFs.
>
>There are recommendations out there concerning maximum line lengths for
>readability, and I think they are closer to 65 characters. The 90-100
>character lines seem to me to be harder to read, especially with the
>close column spacing.
>
>I think color can be useful in diagrams, but it can be distracting in
>running text. Also, red/green colorblindness is probably common enough
>to consider choosing another color for either upsd or upsmon.
>
>The CHRG and DISCHRG status flags are probably confusing for an
>entry-level text, and are more informational than the critical OL/OB/LB
>flags. Some models do not indicate CHRG or DISCHRG, and others will
>omit CHRG if they are OL but not topping off the battery.
>
>On page 5 (right column), it mentions that
>/usr/lib/systemd/system-shutdown is for user scripts, and
>/lib/systemd/system-shutdown is for system scripts. Should the first be
>/etc/systemd/... or /usr/local/systemd/... ?
>
>You have probably noticed that I often link to a specific section of
>the NUT HTML documentation. I appreciate that you have written this in
>a tutorial format rather than as a reference, but you may still need to
>point users to a specific location, and page numbers are not stable
>over time (and neither are section numbers).
>
>Also, some of the internal references to lines and sections do not seem
>to be links. (This might be my web browser and PDF reader combination,
>but usually the table-of-contents links work.)
>
>The last one is a bit pedantic, but the K&R format of the source code
>is probably not important enough to mention in the introduction.
>Usually "K&R" refers to code that will not compile without
adjustment
>in a C89-compliant (or later) compiler.
>
>I am also curious whether you tried to edit any of the existing NUT
>documentation before creating a new document. We chose AsciiDoc in part
>because it should not be as much of a burden as other markup formats to
>read or write, and because it offers several output formats. If it
>turns out to be a deterrent to contributions, that is something we
>should address. I am concerned about the maintainability of several
>documents going forward, and I (selfishly, perhaps) would appreciate
>more help on the core NUT documentation. Your thoughts on this would be
>appreciated.
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170613/da211da1/attachment.html>

On Tue, 13 Jun 2017, Tim Dawson wrote:
> Allow me to suggest a couple more sample configs: 1) Server as UPS 
> controller with clients that are also on UPS, considering shutdown 
> sequencing and 2) Multi power supply server with multiple UPS (with or 
> without clients).
Noted, thanks, Roger

On Tue, 13 Jun 2017, Tim Dawson wrote:
> Allow me to suggest a couple more sample configs: 1) Server as UPS 
> controller with clients that are also on UPS, considering shutdown 
> sequencing and
It would be good to add this, but I lack the depth of understanding needed 
to write a tutorial.  For example I do not understand the "magic" of 
shutdown sequencing.
> 2) Multi power supply server with multiple UPS (with or without 
> clients).
A tutorial to cover this needs to talk about cabling, automatic transfer 
switches, the management of possibly brutal phase shifting and other 
electrical engineering problems as well as the nut configuration.  It's an 
interesting subject, but well beyond my experience.

If you would like to draft a chapter, I would be happy to include it.  A 
simple ascii file with no formatting or markup is sufficient.

Roger

My thought of #2 require none of that . . . I have a server with two supplies,
and two UPS units. One supply is on each UPS, and clients are distributed
otherwise to balance. The main thing is to ensure that it is documented
accurately how to config so that the server only shuts down when the *second*
unit hits low battery . . .  I found the info on this topic almost nonexistent
at present . . .

- Tim

On June 21, 2017 4:38:53 AM CDT, Roger Price <roger at rogerprice.org>
wrote:
>On Tue, 13 Jun 2017, Tim Dawson wrote:
>
>> Allow me to suggest a couple more sample configs: 1) Server as UPS 
>> controller with clients that are also on UPS, considering shutdown 
>> sequencing and
>
>It would be good to add this, but I lack the depth of understanding
>needed 
>to write a tutorial.  For example I do not understand the "magic"
of
>shutdown sequencing.
>
>> 2) Multi power supply server with multiple UPS (with or without 
>> clients).
>
>A tutorial to cover this needs to talk about cabling, automatic
>transfer 
>switches, the management of possibly brutal phase shifting and other 
>electrical engineering problems as well as the nut configuration.  It's
>an 
>interesting subject, but well beyond my experience.
>
>If you would like to draft a chapter, I would be happy to include it. 
>A 
>simple ascii file with no formatting or markup is sufficient.
>
>Roger
>
>
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170621/b6d7075e/attachment.html>