Re: [Nut-upsuser] Getting Error Using upscmd

[Greg Troxel via Nut-upsuser]

Atomic_Sheep via Nut-upsuser 
writes:

> I'm trying to run:
>
> $ upscmd -l myups
>
> where myups is the [myups] I provided in ups.conf file. and l is lower
> case l. In other words I'm trying to see what commands my UPS
> supports.
>
> I'm using the latest fully updated Raspbian 32bit as a fresh install.
> I installed NUT via CLI and have version 2.8.0-7.

That's old; 2.8.2 has been released.

> I get the error:
>
> $ Error: Connection failure: Connection refused
>
> Does anyone know how to troubleshoot this?

Usually, that's because there is no listening socket.  You left out the
part where you said how you started the daemons and how you used ps to
verify they are running :-)

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eco Eclipse 1600 connects via USB put does not put out any data:

[Greg Troxel via Nut-upsuser]

Stefan Schumacher via Nut-upsuser 
writes:

> Thanks for the info. Nut runs on bare metal, there is no
> virtualization layer. I will have a look at the github post after
> writing this post. I have compiled and installed nut 2.8.2 as
> suggested. But now I am confused: Where is the usb-hid driver, which I
> used in Nut 2.8.0? Does one need to pass a special flag to configure
> to build it?

My memory is that nut builds things if the prereqs are present.

so

./configure --help

and when you run configure, save stdout/stderr and read it.  especially
around building usb, and having the libusb1 libs present.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eco Eclipse 1600 connects via USB put does not put out any data:

[Greg Troxel via Nut-upsuser]

Stefan Schumacher via Nut-upsuser 
writes:

> I am using: Debian Bookworm 12.6 with these packages, which were
> installed from the official Debian Repository.
> ii  nut 2.8.0-7
>   all  network UPS tools - metapackage
> ii  nut-client  2.8.0-7
>   amd64network UPS tools - clients
> ii  nut-server  2.8.0-7
>   amd64network UPS tools - core system


Your mail is mangled.  Lines longer than 72 characters which are
logs/config/output etc. should not be wrapped.

But, I can tell that Debian has old nut.  My system has 2.8.2.  And
there are changes in git master since then.   I'm not the maintainer,
but for projects where I have a maintainer role, I expect the first
step is updating to the latest release if not from git.

> root@mars:/usr/lib/nut# ./usbhid-ups -DD -a Eaton
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
> USB communication driver (libusb 1.0) 0.43
>0.00 [D1] debug level is '2'
>0.001566 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' >
>0.001575 [D1] upsdrv_initups (non-SHUT)...
>0.004892 [D2] Checking device 1 of 7 (1D6B/0003)
>0.004908 [D1] Failed to open device (1D6B/0003), skipping:
> Access denied (insufficient permissions)
>0.004911 [D2] Checking device 2 of 7 (0BDA/5452)
>0.004917 [D1] Failed to open device (0BDA/5452), skipping:
> Access denied (insufficient permissions)
>0.004921 [D2] Checking device 3 of 7 (1D6B/0002)
>0.004926 [D1] Failed to open device (1D6B/0002), skipping:
> Access denied (insufficient permissions)
>0.004929 [D2] Checking device 4 of 7 (1D6B/0003)
>0.004937 [D1] Failed to open device (1D6B/0003), skipping:
> Access denied (insufficient permissions)
>0.004941 [D2] Checking device 5 of 7 (0463/)
>0.463157 [D2] - VendorID: 0463
>0.463198 [D2] - ProductID: 
>0.463215 [D2] - Manufacturer: EATON
>0.463231 [D2] - Product: Ellipse ECO
>0.463249 [D2] - Serial Number: 0
>0.463268 [D2] - Bus: 001
>0.463287 [D2] - Device: unknown
>0.463314 [D2] - Device release number: 0100
>0.463332 [D2] Trying to match device
>0.463350 [D2] match_function_subdriver (non-SHUT mode):
> matching a device...
>0.463603 [D2] Device matches
>0.463624 [D2] Reading first configuration descriptor
>0.463662 [D2] failed to claim USB device: Resource busy
>0.463689 [D2] Kernel driver already detached
>0.463714 [D2] failed to claim USB device: Resource busy
>0.463740 [D2] Kernel driver already detached
>0.463764 [D2] failed to claim USB device: Resource busy
>0.463787 [D2] Kernel driver already detached
>0.463809 [D2] failed to claim USB device: Resource busy
>0.463831 [D2] Kernel driver already detached
>0.463854 Can't claim USB device [0463:]@0/0: Entity not found

It's really hard to say from this.   I would think there is a way to
tell usbhid-ups the device name and have it just try that.Could be a
debian issue, could be something wrong with nut.   My advice would be to
build git master and debug from there, with gdb and ktrace (however you
spell ktrace on debian, perhaps it is strace).


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Permissions error

[Greg Troxel via Nut-upsuser]

Jack McGee  writes:

>> mythuser@amethi:~$ upsdrvctl start
>> Network UPS Tools - UPS driver controller 2.7.4
>> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
>> USB communication driver 0.33
>> kill: Operation not permitted
>> writepid: fopen /run/nut/usbhid-ups-cyberpowerAmethi.pid: Permission
>> denied
>> Using subdriver: CyberPower HID 0.4

> Not sure if this is the right solution, but I added write permissions
> on that file to the nut group.
>
> Now I see.
>
> mythuser@amethi:~$ upsdrvctl start
> Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> kill: Operation not permitted
> Using subdriver: CyberPower HID 0.4

You may also need write on the dir, for creating the file when it does
not exist.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Permissions error

[Greg Troxel via Nut-upsuser]

you need to understand what uid/gid you wish to run nut under, and
arrange that this uid/gid can open the devices, read the configs, and
write the state places.

you left out running 'id' before upsdrvctl start to see what the uid/gid
is.

(followups onlist only please)


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Greg Troxel via Nut-upsuser]

Tim Dawson  writes:

> LISTEN 1.2.3.4 2.3.4.5 987 
>
> is a mess . . . You either need to specify the default port number, or

agreed that this method is a mess!

But we have "just use multiple listen statements" which is
straightforward.

I am not really averse to having a format that is a more familiar idiom.
What I don't like is having two ways to do it over the long term, so I'd
want one to be deprecated and throw a warning and have a grace period.
Then the quesion is if making everybody change over those perhaps 2
years is worth the gain in clarity for the other people over the
indefinite glorious future.  That's a tough case to make either way.

Before doing this, I'd want to see a survey of the config grammers of
many other daemons to find out what is really common.

As an example, postfix lets you specify interfaces to listen on, and
then has ports in a different file.   So you can't have arbitrary
addr/port pairs; you have a list of addrs and a list of ports and you
get the crossproduct, it seems.   And then check out nginx:

listen  443 ssl;
listen  [::]:443 ssl;

which is spectacular in its implicit INADDR_ANY and : while having it
manifest for v6.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Greg Troxel via Nut-upsuser]

Jim Klimov  writes:

> Just to clarify: using a different port *is* possible since forever, with
> `LISTEN host port` (as two arguments to the directive); the question was if
> having a way to spell it as one argument as `LISTEN host:port` would solve
> some shortcomings/ease adoption more than introduce some new problems :)

Ah.  Well, if there is already a way to do it, IMHO adding a second way
is complexity with no benefit.

why would anyone want to use "host:port" when "host port" works?  That
just seems like "I want to rewrite the config format, because [why?]."


> With recent releases addressing this area, a host name resolving to several
> IP addresses should be recognized, but at the moment this would only emit a
> warning about the situation and the first seen IP address number would get
> attempted for bind(). If this proves to be a problem, should not be too
> hard to address (need to inject entries into an internal list tracking the
> sockets which is originally sized by amount of LISTEN lines; there is
> already precedent for injection of IPv4 and IPv6 where a single `LISTEN *`
> directive and avoided dual-stack mode are in place).

That seems separable, but I'd say listening on the first addr is a bug.

> As for practical use of non-default ports, NIT (NUT Integration Testing)
> scripts come to mind and do that extensively (especially where the same CI
> host/agent can be running different scenarios in parallel, so any one
> hard-coded port is prone to conflict).

That's fair.

> Other practical reasons might include security by obscurity (like runpning
> web consoles or ssh on strange ports), running different NUT data servers
> (e.g. real drivers on one, and "dummy-ups" or "clone*" relays on the
> other), or attempts to avoid conflicts with uncooperative software. Can't
> think of much more quickly :)

Given that it's already supported, that query of mine is out of scope.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Greg Troxel via Nut-upsuser]

Jim Klimov via Nut-upsdev  writes:

>   A recent discussion in the issue tracker brought up the idea to allow the
> `LISTEN` keyword to also accept a single "host:port" token (e.g. if there
> is only one argument, with at least one colon, and the last colon is
> followed only by numbers, split it into host and port) :
> https://github.com/networkupstools/nut/issues/2424

Is the point that people want to use different ports, and the current
situation lets you choose an address but not a port?

Assuming so, why would there be a restriction to a single host if there
is port, while one could have multiple listen addresses if not?  I would
think the : scheme should apply to each argument, with lack of : being
an implict :[normalport].

For me, the reason to use explicit listen is because you don't like *,
and if you are using IP addresses you might well want to listen to v4
and v6.

This raises the issue of whether "host" expands to all IP addresses
associated with a domain name.

>   There are also certain cons, primarily about parsing such stuff reliably
> and consistently in different code bases (now also with augeas and nutconf
> to worry about). The actual "production" parsing in NUT data server code
> should be trivial.

I find this whole "our config needs to be generally machine readable but
we aren't just changing it to a machine-readable format" to be odd.   If
we want to play in some world where that happens we should just flip to
yaml or something :-)

>   On a somewhat related note, should the port part be constrained to
> numbers, or should it also pass through the naming database (resolve via
> typically /etc/services on POSIX systems) if it is a non-numeric string,
> similar to how we resolve host names into IP address numbers?

sure, non-numeric port could go through getservbyname(3) and then fail
if not the expected protocol.  Don't talk about /etc/services but the
posix interface, except it's from 4.2BSD and I'm not sure it's been
specified by POSIX :-)

On the other hand, if you are using an alternate port, it's because you
are not doing the normal thing, and the idea that you specify 'ntp'
because you want nut on 123 doesn't really make sense.   And if you know
some name it's not hard to look it up by name.   So all in all, I vote
for no, it's a number.

>   What would the community say, is any of this worth spending time on?
> Would anyone volunteer to roll up the sleeves for that? :)

No and no, IMHO.   What is the problem being solved?  Are there actual
people who want to use a different port?  What are their reasons?
I can believe there might be a scenario, but it seems speculative.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Greg Troxel via Nut-upsuser]

Jim Klimov via Nut-upsuser  writes:

> A hiccup was reported about validating the tarball signature on some
> systems, so it was reissued from another workstation. Please don't worry :)

Do you mean the signature  was re-issued, which is ok, or that the
tarball was re-issued, which is very much not ok(!) ?

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Keeping the traffis on or off the list ?

[Greg Troxel via Nut-upsuser]

The list appears to have settings enabled:

  - modify the subject by adding [Nut-upsuser]
  - add a footer

I believe these are controlled by the list administrator, in the same
way as reply_goes_to_list.

Both of these are, in the eyes of DKIM, attacks on the integrity of the
message.

I believe that when mailman is attacking the message :-) due to
configuration, and the address in From publishes a DMARC policy, then it
changes the From: and inserts a Reply-To back to the sender.  Or rather
that there is a setting "when breaking the message and From has a DMARC
policy, forge from".

Here are the headers of a message you recently sent to the list (and not
also to me, so I'm seeing the list headers):

  From: Charles Lepple via Nut-upsuser 
  Subject: Re: [Nut-upsuser] Keeping the traffis on or off the list ?
  To: Jim Klimov 
  Cc: Charles Lepple , nut-upsuser Mailing List 

  Date: Sat, 17 Feb 2024 11:09:20 -0500 (43 minutes, 27 seconds ago)
  Reply-To: nut-upsuser Mailing List 

As you can see the From: is forged.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Keeping the traffis on or off the list ?

[Greg Troxel via Nut-upsuser]

I would guess that reply-to is getting added because of header munging.
Turn off munging and this all goes away.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Keeping the traffis on or off the list ?

[Greg Troxel via Nut-upsuser]

Reply-To: is about the *author*.  On a list, people should "reply all"
and include the list, generally, unless they intend to send a private
reply.  Having Reply-To set to the list violates standards and causes
the "reply" MUA action to send a reply to other than the author,
violating expectations.

> From: Roger Price via Nut-upsuser 

There's more broken: the list changes the subject and adds a footer,
breaking DKIM, and to work around that changes From: to the list.  This
also means the reply MUA sends an intended-private reply to the list.
So all of that should be deconfigured, with the list passing messages
unmodified except for List-Foo headers.

The Reply-To: you are seeing is a workaround for forging From, which is
a workaround for modifying the message.  Really, the solution is to just
stop all of this.  NetBSD lists have zero of it and there is no trouble.


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] BUG: KFENCE: memory corruption in free_async+0x1d8/0x1e0

[Greg Troxel]

Dirk Schneider via Nut-upsuser 
writes:

> Hi,
>
> i run NUT on a Raspberry Pi 3 Model B and after the latest OS Update i get
> the following Error from KFENCE, the current OS Version is the first with
> KFENCE so it possible that this Problem has was always existing.

You didn't say what operating system you are running or what nut
version.
However, based on:

> [21963.079554]
> ==
> [21963.079580] BUG: KFENCE: memory corruption in free_async+0x1d8/0x1e0
> [21963.079580]
> [21963.079604] Corrupted memory at 0x25448a9e [ ! ! ! . . . . . . .
> . . . . . . ] (in kfence-#183):
> [21963.079711]  free_async+0x1d8/0x1e0
> [21963.079728]  usbdev_ioctl+0x138/0x1c40
> [21963.079744]  __arm64_sys_ioctl+0xd0/0x130
> [21963.079769]  invoke_syscall+0x7c/0x130
> [21963.079793]  el0_svc_common.constprop.0+0x6c/0x160
> [21963.079815]  do_el0_svc+0x38/0x120
> [21963.079835]  el0_svc+0x34/0xc0
> [21963.079856]  el0t_64_sync_handler+0x11c/0x150
> [21963.079876]  el0t_64_sync+0x198/0x19c

it looks like this is a kernel memory validator of some kind, and it is
objecting to memory handling within the kernel.  I would therefore guess
this is not a nut or device bug, and would suggest reading the
usbdev_ioctl proc_do_submiturb source code.  Guessing wildly, there
might be an out-of-bounds write.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Should upsd abort if one if LISTEN addresses is not available?

[Greg Troxel]

Jim Klimov via Nut-upsuser  writes:

>   Issue https://github.com/networkupstools/nut/issues/723 was brought up
> recently, and I've re-verified it with the current codebase that it still
> happens.
>
>   The crux of it is that if upsd can LISTEN to some but not all addresses,
> it aborts because "no listening interface available" and worse - does so
> inconsistently (seems to depend on whether the *first* listed address
> works).
>
>   A fix (to count if at least one address either is or isn't accessible) is
> not complicated technically; a bigger question is which behavior would be
> "right" with regard to security(?) vs. usability? What do other networked
> servers do - so we might follow deterministic suit and claim least-surprise?

For security, usually the concern is "does not listen to any address,
unless it was explicitly configured (or that and localhost ok)".

For usability, there are two schools of thought:

  A) try to function partially if things are messy.  So iterate over the
  listen directives, try them all, and if any of them work keep going.

  B) do what was asked, and abort if not possible.  that way the user
  will see it isn't running, read the log, and fix it, by either
  choosing not to listen, or stopping the other thing.


As an example not about nut, I just moved a somewhat funky server
setup from one machine to another.  It wanted to listen on port X.   But
when starting, it failed.  Turns out nginx was listening, because the
default config listens on 80, and I didn't like that and changed *:80 to
127.0.0.1:X.  So I notice the program wasn't listening, read the log,
found who was listening to 8080, and then had an excursion into nginx
config, paging in my decisions, diffing from upstream, and deciding to
just drop the *:X listen there, and testing that I didn't break other
things.   Then restarted the funky service.  Total time, not counting
the nginx excursion, about a minute, maybe two.

So I am firmly in camp B.  Follow the directives and it's fatal if you
can't.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Spammy notification-tech diagnostic message

[Greg Troxel]

Vojtěch Hurčík via Nut-upsuser 
writes:

> Thanks for the reply, it's only reported once per spawned process and
> what you say makes perfect sense in this light. A configuration toggle
> or environment variable also seems like a good idea, but I'm sure I or
> we can also live with the message being reported once per process as
> it currently is... looking forward to the stable release & thanks for
> everything!

If it's only once per process, I lean lean to one of

  don't make it configurable and just phrase it so it isn't scary

or

  at cmake time, specify the integration with system management stuff
  and then get it right.


and overall the second seems nicer but ENOPATCH.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] My Back-UPS RS 1000 went haywire, any ideas?

[Greg Troxel]

Gennadiy Poryev via Nut-upsuser 
writes:

> I took an external voltmeter and made sure that actual input voltage
> is around 223 V and is not changing. However, each successive run of
> upsc indicated drastically different "input.voltage", arbitrarily
> jumping from 160 V to 280 V. Besides this, no other values seemed
> abnormal.
>
> Is this something that can be fixed in-house? Or something widely
> known about this particular model and/or vendor? I'm puzzled. Please,
> advice. Sorry for the offtopic once again.

I would guess one of

  Something is flaky and the power is not as good as it seems, or the
  wiring from power strip where you are measursing to UPS input is off.
  I would definitely remove and re-seat everything you can.

  The circuitry that senses voltage is off.

  The neutral is open and then all bets are off.  Did you measure hot to
  neutral, hot to ground, neutral to ground?  You say 230 and I'm
  guessing this is in a place with 230V outlets.  (In the US we have
  125V with neutral and 250V phase to 180-out-of-phase phase, for
  "single phase" service.)

  So actually, check the neutral inside the equipment.  Power it all
  down and unplug and be super careful as UPS devices have power inside
  when they are off and unplugged.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Do we need both Nut-upsuser and Nut-upsdev ?

[Greg Troxel]

Roger Price  writes:

> I would like to suggest that we merge the two mailing lists
> Nut-upsuser and Nut-upsdev.
>
> 1. Users increasingly post simultaneously to both lists.  One list is
> sufficient.

IMHO it's poor form to post to both, generally, unless it's an
annoucement.  The only reason to have a dev list is to spare the people
on the users list from getting content that is discussing changing the
code.

> 2. The very detailed technical discussions which previously justified
> a second Nut-upsdev list now take place on github.com/networkupstools
> , for example https://github.com/networkupstools/nut/pull/2013 “Define
> upsd option to LISTEN * as specifically handling both IPv4 and IPv6
> "ANY" address”.

Sort of.

The use of github isn't really a great thing.  It moves discussions from
a place where the set of people interested in nut code are to github,
and while people can subscribe all, it's way too much.  I get it that
detailed code review is there, but I think the larger picture
discussions belong on email.

I don't think it matters much one way or the other if we merge dev into
user -- I'm not one of the people seeking to avoid the dev content, and
list traffic isn't that high anyway.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] Setting up charge/voltage based shutdowns

[Greg Troxel]

Jim Klimov via Nut-upsdev  writes:

>   While looking at https://github.com/networkupstools/nut/issues/2014
> I understood that I am not sure if currently NUT has a standard way of
> triggering a shutdown based on remaining charge or runtime, if a
> device/driver lacks a `battery.charge.low` setting but has readings
> for the values themselves.

I am unaware of such a facility, but I think we should have it, and it
should be integrated enough that people don't need to use upssched.

My sketch:

  Accept that "LB" is baked into nut pretty hard.  Redefine LB as
  "driver says that it's time to shutdown", which is not necessarily the
  same as "hardware says battery is almost empty".

  Allow some generic config, to say:

should LB be triggered on hardware LB (default yes)
trigger LB if battery% < X (default not)
trigger LB if battery voltage < Y (default not)
trigger LB if battery runtime < Z (default not)
trigger LB if time on battery > W (default not)
  
  except that a driver can set defaults to trigger LB differently if it
  doesn't have a hardware LB indication.   Those defaults should be the
  traditional "maximize runtime".

  Admins that don't like this (and I don't like it either) should be
  able to easily configure a variable in upsd.conf to make things
  shutdown faster, for those that want more margin, or for those who
  think the point is to protect the equipment, not provide availability
  (the "if power is not back in 2 minutes, it's going to be longer than
  my runtime, so just shutdown" crowd -- and I'm very sympathetic to
  that use case).

  Or perhaps this involves renaming the flag passed around to be
  something other than LB, but it's basically "battery status is such
  that the sysadmin has said that in this condition, it's time to shut
  down".  But it does involve decoupling a hardware battery-is-critical
  indication from the nut-it's-time-to-shutdown LB flag.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Question on simultaneous IPv4 and IPv6 "any address" listening

[Greg Troxel]

Jim Klimov  writes:

> Thanks to everyone for a fruitful discussion, links and ideas.
>
> The result is nearing a merge at
> https://github.com/networkupstools/nut/pull/2013 and seems to not upset CI
> on any platform, including Windows (which behaves funny WRT binding to the
> same host:port as many times as you ask).
>
> Ultimately the chosen logic is that if there was a `LISTEN * ` in
> `upsd.conf`, the depending on CLI settings (-4/-6) or lack thereof we try
> PIv4, IPv6 or both, with the bigger logic for "both" being:
> * try to get IPv4 "ANY", to know we can do so
> * release IPv4, try to get IPv6 and then IPv4 again

As I commented on github, I think this is unnecessarily complicated and
thus not what we should do.

> If in the end neither socket works, declare a fatal error (could not
> fulfill the config requirement).
> If we could get IPv4 initially, and could not after getting IPv6, do not
> bother - assume a dual-stack system (and log it so).

You mean "a system that defaults to mapped addresses" :-)

> Also as part of this change, NUT would ask (although not insist) for the
> IPV6_V6ONLY socket option when preparing IPv6 connections, except when
> handling `LISTEN *`.

I don't know what you mean by insist.  To me the right logic is, after
opening a socket to be used for v6, very pseudocodish:

#ifdef V6ONLY_define_for_setsockopt
  call setsockopt to set v6only=1
  if that fails log an error
  /*
   * deal with bug reports later; it really seems buggy/odd to have the
   * setsockopt and then error on setting it to 1.
   */
  /*
   * It would be fine to ifdef out the v6only setting on openbsd if
   * that turns out ot be necessary.  But it wouldn't surprise me if on
   * openbsd setting it to 1 succeeds and setting it to 0 is an error,
   * in which case there is no need to special case it.
   */
#else
  /*
   * The operating system does not implement the setsockopt to control
   * whether mapped addresses are used.  Assume that it does not support
   * mapped addresses at all.
   */
#endif

and then for listen * to

  listen on v6, log erorrs
  listen on v4, log errors

and that's it.

I'm not sure what will then error; when we figure out what does we can
see what to do about it.

Overall I lean to doing things the simplest and most obviously correct
way possible and then to accomodate as necessary.

> Finally, I noticed that if some configuration hostname resolves to more
> than one address, the first one bound wins and others are ignored. This
> behavior was here before, the PR change just logs that this happens.

Not sure what you mean first bound wins/etc.  If you mean the hostname
is looked up and then the first address is picked arbirtarily and that
address is listened too, then ack that this is a pre-existing likely
bug, agreed that noting it is good, and agreed that there is no reason
to have to address that in this PR.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Question on simultaneous IPv4 and IPv6 "any address" listening

[Greg Troxel]

Jim Klimov via Nut-upsuser  writes:

>   I've recently found that at least on my test box the `LISTEN *` line had
> only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for
> `upsd`.

Interesting.  On one system I checked, I have 4 explicit directives for
127.0.0.1, ::1, and the LAN on v4/v6.  On another, I have an empty
upsd.conf and it is listening:

nut  upsd10474* internet stream tcp 127.0.0.1:3493
nut  upsd10475* internet6 stream tcp [::1]:3493

> In fact, at least on a "dual-stack" system, it seems impossible to
> bind to both - so depending on binding order I either lose IPv6 or lose
> IPv4 directly (but have it practically as IPv4-over-IPv6).

That is not intrinsic to a system that does v4 and v6.  It is about a
misfeature which if turned on, when one binds to v6 also sets up a
listener on v4 which connects as a mapped address.  These days, I view
it as a bug for a system to be configuret hat way.  On NetBSD, from
ip6(4):

 IPV6_V6ONLY int *
 Get or set whether only IPv6 connections can be made to this
 socket.  For wildcard sockets, this can restrict connections to
 IPv6 only.

which is 1 on my system.

>   Given that `LISTEN *` support is in fact not documented explicitly (I
> think), I am inclined to define it as listening to "any" on whatever
> address families are available and supported by the NUT build, and somehow
> ensuring that to the best of our capability (technical puzzles exist - see
> GitHub issue).

It seems really obvious that * means anything, so agreed.

I think it's important that the default, if there are no LISTEN
directives, be "listen on all localhost addresses of all address
familes".  And probably there should be a way to say that explicitly,
like "LISTEN localhost".

Practically, LISTEN localhost should:

#ifdef v6 at compile time
  open a socket and bind to [::1]:3493
error log that v6 bind failed
#endif

  open a socket and bind to 127.0.0.1:3493
if error:
  if there is a v6 socket:
debug log that v4 bind failed, maybe, or maybe it's a real
error?  need to figure out if v6only=0 systems some try to map
this.  The point  being not to fight os/sysadmin choice even if
misguided :-)
  else:
error log that v4 bind failed

and LISTEN * should

#ifdef v6 at compile time
  open a socket and bind to INADDR6_ANY:3493
error log that v6 bind failed
#endif

  open a socket and bind to INADDR_ANY:3493
if error:
  if there is a v6 socket:
debug log that v4 bind failed
  else:
error log that v4 bind failed




>   Detailed musing and logs are posted in
> https://github.com/networkupstools/nut/issues/2012
>
>   Pro/Con ideas are welcome :)
>
> Jim
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powering off the big stuff first

[Greg Troxel]

Dan Langille via Nut-upsuser 
writes:

> I had an idea last week: why shut everything off (in my basement) when
> the power goes off (and run time goes below X minutes)?

Makes sense to me.

I would say after 30s, start to shut off the "not important to keep
running" stuff.  At least for me, once the power is out even 10s, it is
almost certainly going to be 30 minutes.

I deal with this by having one UPS on a desktop computer and another for
a low power router/wifi, more or less.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Accessing: upsstats.cgi Error: no hosts to monitor (check hosts.conf)

[Greg Troxel]

Jim Klimov  writes:

> Not fully true about example configs in docs: man pages for CGI bits have
> some :)
>
> https://github.com/networkupstools/nut/blob/master/docs/man/upsset.conf.txt
> https://github.com/networkupstools/nut/blob/master/docs/man/upsstats.cgi.txt
> https://github.com/networkupstools/nut/blob/master/docs/man/hosts.conf.txt
> etc.

Fair enough, but I didn't find them when looking quickly.  What I was
hoping was to find a httpd-nut.conf file that would be installed to
$prefix/share/examples/nut and that would have paths substituted so it
could just be included.

I have lost track of apache config changes, but at this point I would
say 2.4 is normal and  and <= 2.2 is so old that all mention of it
should be purged.   Maybe the text should say "in apache 2.4, blah blah"
just so people on really old laggard term stable won't be misled.

Is anyone still using apache 2.2?

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Accessing: upsstats.cgi Error: no hosts to monitor (check hosts.conf)

[Greg Troxel]

Dan Grostick via Nut-upsuser 
writes:

> When Apache starts is complains about not finding the fully qualified domain 
> name.

That seems normal

> In the past, upsstats.cgi would just load. I didn’t have to do any Apache2 
> configuration. I don’t know what has changed.

in general this does need configuration.   read the apache config file.
read the apache logs.

> I’ve build NUT 2.8.0 from source, autogened, configured, make, make
> install, and it is running. Is there something I’m missing that isn’t
> getting updated when I do the make install?

I would not expect that to adjust apache configs.

> Upsstats.cgi and the others are located in the cgi-bin/nut/ folder.

generally one needs a config stanza that says for this web path execute
this binary.  Both ScriptAlias and Directory.

> I can get to http://192.168.123.49/ and the Apache page loads.
>
> Any suggestions?

Read the apache manual about to configure cgi.  (I'm actually serious.)

I don't see any example config files in the sources.


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Monitoring a remote UPS

[Greg Troxel]

Nichole Kaligian via Nut-upsuser 
writes:

> Every guide I'm finding is connecting their NUT server to the UPS directly.
> Is there no option to monitor a network-attached UPS? On its IP or
> hostname? This was my first assumption when looking at a product called
> 'Network UPS Tools', but it seems I'm misunderstanding? Thanks for any
> advice you can give me.

Others pointed you to the compatibility guide and net-snmp and that is
good advice.

Network in Network UPS Tools to me means that you can have one computer
monitor a UPS and have other computers (that are plugged in also) do
controlled shutdown.

While NUT does support SNMP, the scope is "any UPS that has a way to
report status, that anybody has figured out and made to work".  A lot of
them are serial and USB, but there is SNMP.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Synthesize low batt (LB) fron SNMP UPS which does not support this?

[Greg Troxel]

Willcox David via Nut-upsuser 
writes:

> Hmm, looking at status_commit(), if the UPS actually reported just
> “OB", but the “ignorelb” logic kicked in, wouldn’t status_commit()
> change it to “OB LB”? And would clients interpret that correctly?

Yes, if status_commit is called.

But what happens is:

  power is on, battery is at 100%, no flags

  power fails.  Device changes to OB.  battery voltage starts dropping

  time passes, say 20 minutes to 50% battery.   every polling interval
  (2s perhaps), the battery voltage, line voltage (0), output voltage,
  etc are reported.  But the driver does not try to change flags.


However, I suspect the driver reads flags every time and sets them.


The dummy UPS may get this wrong.


> And, assuming status_commit() is called, is the status so saved what’s 
> returned on a future client query? 

Yes, that's my understanding

> I’m really unsure how all of this works. I don’t suppose there’s some
> kind of “general flow of information” documentation somewhere?

https://networkupstools.org/
https://networkupstools.org/documentation.html
https://networkupstools.org/docs/developer-guide.chunked/index.html

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Synthesize low batt (LB) fron SNMP UPS which does not support this?

[Greg Troxel]

Willcox David via Nut-upsuser 
writes:

> In status_init(), if “driver.flag.ignorelb” is set in the driver state, the 
> “ignorelb” flag is set.
> In status_set(), if ignorelb is set, and the status being set
> (presumably from the UPS) is LB, it’s ignored. In other words, LB
> reported by the UPS is ignored.
> In status_commit(), if ignorelb is set, there’s code to compare
> battery.charge against battery.charge.low and battery.runtime against
> battery.runtime.low. If either is below the “low” setting, “ LB” is
> added to the status. (So “OL” would become “OL LB” and “OB" would
> become “OB LB”. And note that the two “.low” settings can be
> overridden in the config.

Interesting.  Perhaps the runtime check to set LB should be in
status_set also.  However I think it's more subtle than that.

Read

  https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html

and also look at some other drivers.


I think there's an assumption baked in that changing values like
battery% and line voltage is a different thing from changing flags, but
"set LB if battery <= X" crosses those.   So it may be necessary to
understand how this init/set interacts with everything else.

Perhaps we need a "update cycle done" call that is made every time
regardless of if the drive thinks it changed flags.  Or perhaps a driver
is supposed to call status_commit when it is done no matter what.  Some
code reading is in order!

> (I tried setting this but it didn’t seem to work. But then, I’m not
> sure how the NUT I installed from a package on my RPI compares with
> the source I downloaded.)

If you are trying to debug or to develop new things, you really have to
build from source and run that, rather than running old code from a
packaging system.  Nobody should run 2.7.4, pretty much for any reason.

> (I surmise from the way that code works that there must be a seperate
> process for each driver. Otherwise all of those static variables are
> scary.)

Yes, each driver runs as a process, as ps will show you, and this is
essentially the driver library from which a device-specific driver is
constructed.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] got nut 2.8.1 but despite reinstall, shows 2.7.4

[Greg Troxel]

gene heskett  writes:

> On 5/22/23 07:13, Greg Troxel wrote:
>> gene heskett  writes:
>> 
>>> Which file in the nut I pulled a month ago, should I start with to get
>>> the new version actually running? I still get - -V=2.7.4
>> It is likely that you have built new nut but old nut is still on
>> your
>> system.   I do a 'sudo make install' to write over the distribution nut
>> (on NetBSD/pkgsrc, surely not what you are using).
>> 
>
> I just found the 2.7.4 was a deb its listed in a synaptic search
> Should i purge it?

Sorry, I am not clueful about debian init scripts.  Often the debian
package will add init scripts to what upstream (ie. the nut project)
provides.

A gross hack would be to leave the 2.7.4 package and then build nut from
source with --prefix=/usr (to match the package) and then install over
it and then hand-rm files in /usr that were not written by the install.
And then hope the init scripts call nut the same way.

But really you should get advice from someone who is more
debian-clueful, and not from me!

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] got nut 2.8.1 but despite reinstall, shows 2.7.4

[Greg Troxel]

gene heskett  writes:

> Which file in the nut I pulled a month ago, should I start with to get
> the new version actually running? I still get - -V=2.7.4

It is likely that you have built new nut but old nut is still on your
system.   I do a 'sudo make install' to write over the distribution nut
(on NetBSD/pkgsrc, surely not what you are using).


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Synthesize low batt (LB) fron SNMP UPS which does not support this?

[Greg Troxel]

I should add that my thinking is in part due to having a python script
that does the equivalent of upsc and reports status to Home Assistant
over MQTT.  If I had a UPS that didn't do LB, I would still want to see
LB reported via this mechanism at the right time.  With this support in
upsmon, that wouldn't happen.   I see a lot of the point of nut as
regularizing all UPS units into defined semantics so that one can manage
them without knowing about the unit specifically.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Cyberpower BRG1350AVRLCD with powerpanel driver timeouts

[Greg Troxel]

Arturo Javier Alejandro Morán Rouzaud via Nut-upsuser
 writes:

> This is my first time using a mailing list, so please let me know if I
> missed something.

You are doing great!  Your message is well-formatted, readable, and on
topic.

I know nothing about Proxmox and have never used a cyberpower UPS, so I
held back but you deserve some help so here goes:

> - OS name and version: Proxmox Virtual Environment 7.4-3
> - NUT version: 2.7.4-13
> - NUT installation method: Debian package/apt
> - Exact device name and related information: Cyberpower BRG1350AVRLCD
> https://www.cyberpowersystems.com/product/ups/intelligent-lcd/brg1350avrlcd/

That has USB and serial.  usbhid is likely better, but it likely does
not work well in 2.7.4.

> - Complete problem description:

2.7.4 is ancient.  The current release is 2.8.0, from a year ago, and
there are fixes since then.  But so much was fixed from 2.7.4 to 2.8.0
that it just does not make sense to run 2.7.4, especially on a UPS that
is newer than 10 years old.  (I use UPS units manufactured in 1995, but
I'm odd!)

Building nut is not super hard, and I would recommend that you do that.
I am not clear on exactly where the docs are, but peruse:
  https://networkupstools.org/
  https://github.com/networkupstools/nut/
I have been building from git, running autogen.sh and configure.  I have
attached my script; it's for NetBSD instead of Debian but it will not be
hard to adjust.

> I'm trying to use this UPS over a serial connection with a Lenovo computer
> running Proxmox. I've already been successful in using it over the USB
> connection with a Raspberry Pi and both Raspbian and OpenWRT, but given
> this computer has a built-in (and as of yet non-functional) serial port, I
> wanted to try it out and see if I'm able to free up a USB port after all.

Do you mean that
  - running ups-nut on a RPI with Raspbian
  - using a USB/serial adaptor on the RPI
  - connecting the adaptor to the UPS with say a DB9 cable
then you can "upsc foo" and see UPS status?

and what version of nut?

Note to others: "man powerpanel" to understand that text is a flavor of
communications protocol that the powerpanel driver supports.

> I am able to connect successfully using the text protocol, however, it
> seems the driver times out after negotiating a link over the serial
> connection. At the moment I am testing it over a USB to Serial adapter, but
> even through this method the official Powerpanel is unable to detect the
> UPS at all, so only NUT seems to be the option here.

Are you sure the virtual USB device is really connected to the serial
lines?  I'm jumping to conclusions but this smells like a virtualization
interface issue.  On the other hand you seem to be getting bits.

> If I'm able to get the UPS working over the USB adapter, I'll be able to
> discard the powerpanel driver as a potential issue and move on to
> diagnosing the onboard RS-232, but for the moment I hope I've included
> enough information as a starting point.

You have, but this points to the port.   I suggest running the driver
with debugging.

> Thanks for the help!
>
> Settings:
> /etc/nut/ups.conf
> maxretry = 5
> [cyberpower]
> driver = powerpanel
> protocol = text
> port = /dev/ttyUSB0

man page says protocol is autodetected, so presumably you set it in the UPS.

> Debug trace:
> /lib/nut/powerpanel -a cyberpower -DD
> Network UPS Tools - CyberPower text/binary protocol UPS driver 0.27 (2.7.4)
> Warning: This is an experimental driver.
> Some features may not function correctly.
>
>0.00 debug level is '6'
>0.011614 Trying text protocol...
>0.112022 send: (2 bytes) => 0d 0d
>0.212152 read: (3 bytes) => 23 2d 33
>0.362686 send: (3 bytes) => 50 34 0d
>0.762718 read: (66 bytes) => 23 42 52 47 31 33 35 30 41 56 52 4c 43
> 44 2c 42 46 30
>0.762744  31 34 30 31 42 41 33 31 2c 42 47 38 4b 50 32 30 30 30 30
> 30 32 2c 43 79 62
>0.762752  65 72 50 6f 77 65 72 20 53 79 73 74 65 6d 73 20 49 6e 63
> 2e 2c 2c 2c
>0.762771 CyberPower UPS with text protocol on /dev/ttyUSB0 detected

that's a good sign.

>0.762792 send_to_all: SETINFO device.type "ups"
>0.762814 send_to_all: SETINFO driver.version "2.7.4"
>0.762819 send_to_all: SETINFO driver.version.internal "0.27"
>0.762828 send_to_all: SETINFO driver.name "powerpanel"
>0.762833 send_to_all: SETINFO ups.mfr "CyberPower"
>0.762837 send_to_all: SETINFO ups.model "[unknown]"
>0.762842 send_to_all: SETINFO ups.serial "[unknown]"
>0.762847 send_to_all: SETINFO ups.delay.start "60"
>0.762852 send_to_all: SETINFO ups.delay.shutdown "60"
>0.762858 send_to_all: SETINFO ups.model "BRG1350AVRLCD"
>0.762863 send_to_all: SETINFO ups.firmware "BF01401BA31"
>0.762868 send_to_all: SETINFO ups.serial "BG8KP202"
>0.762872 send_to_all: SETINFO ups.mfr "CyberPower Systems Inc."
>0.913265 send: 

Re: [Nut-upsuser] Enhanced driver troubleshooting

[Greg Troxel]

gene heskett  writes:

> Jim, would an upgrade to the install on my rpi4b running a medium
> sized 80+ yo lathe give me better control over a:
> device.mfr: CPS
> device.model: CP625HGa
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.offdelay: 120
> where that offdelay seems hard coded. The 625WA rating could run that
> pi for t least an hour, but it chops it off in 2 minutes.
> currently running 2.7.4 on raspios buster.

I think nut only works with lathes made after 1969 :-)

But seriously, a lot has been fixed/added since 2.7.4.

As I understand it, offdelay is about the time delta from telling the
ups to shut down until it kills power, so the OS can sync disks.  I have
a 90s UPS with a 10s delay and nut does not try to shut down until I get
a lowbattery indication, so I get 30 minutes of runtime with graceful
stop, vs maybe 40-something without nut to empty/hard-off.

Is your UPS shutting down without nut telling it to?

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Vertiv Liebert

[Greg Troxel]

Bruce Pleat via Nut-upsuser 
writes:

> Here's the (far less lengthy) output for the Vertiv Liebert:
>
> device.mfr: Vertiv Co
> device.model: Liebert PSA5
> device.serial: 3106602D04C
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0002
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 10AF
> driver.version: 2.7.4
> driver.version.data: Belkin/Liebert HID 0.17
> driver.version.internal: 0.41
> ups.mfr: Vertiv Co
> ups.model: Liebert PSA5
> ups.productid: 0002
> ups.serial: 3106602D04C
> ups.status: OB
> ups.vendorid: 10af
>
> As you can see, useful information is missing from the Liebert/Vertiv:
> I'm running it connected to a Raspberry Pi 4B (latest patches applied
> nightly), so I'd prefer to do it from there.
>
> Is there debugging I can do?
> (I'm a NUT rookie and admit to finding the docs overwhelming.)

I'm still sort of new, but:

  Build nut from source and use that (the tip of master from it), rather
  than whatever old code your OS provides.  2.7.4 is ancient and there
  have been a ton of improvements since then.  I am not sure there is
  anybody interested in helping you work on 2.7.4.

  Run the driver with debugging flags to get verbose logging.   upsc
  shows that variables you expect aren't there, and verbose logging will
  give you some insight into what's happening.

  See if other code, perhaps proprietary and even Windows, if you can
  hold  your nose and suspend your free software ethics :-), will report
  anything more.

  Find the docs that show what is available via HID and read the driver
  code to see if anything is missing.

My guess is that your problem is one of:

  something is going wrong and the device just isn't getting read.

  The HID data structures do not line up between what nut expects and
  the device provides

and that upgrading to current nut is reasonably likely to avoid a lot of
issues, even if it doesn't immediately work.  But it might.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nut server without nut-client/monitor?

[Greg Troxel]

Orion Poplawski via Nut-upsuser 
writes:

> To explain the motivation behind my question - I'm looking at tweaking
> the Fedora RPMs and noticed that currently the "nut" server package
> requires the "nut-client" package to also be installed (though not the
> reverse obviously).  With some effort we can split things up so one
> could install just the "nut" package.  But I'm thinking this really
> isn't particularly useful or interesting.  But I figured I would ask.

That question makes a lot more sense!

I maintain the nut package in pkgsrc, and we have one for server and
clients, but without usb, and then one with usb.  The basic one is only
10 MB.   But pkgsrc tends to split less than many GNU/Linux
distributions.

I can't imagine wanting to have the server without "upsc" in any even
slightly normal system.  Running upsc tells you the status, and even if
you don't really care about most of that, confirms that the server is
working.  It would really be an extreme embedded case to want to save
that space, and then it would be far more important to remove all
drivers that are not for your hardware, SNMP and USB support if not
used, etc.  Put another way, it's like ntpd without ntpq.  

You might want to split out nut-scanner.  But it's not really that big,
and I'm not sure how the maintenance effort trades off with space
savings.

All in all I find it sensible for the package with ${prefix}/sbin/upsd
and ${prefix}/libexec/[drivers] to depend on nut-client.  It's hard to
think of an actual user that would be bothered by this, that wouldn't
also want to hand-pick everything else about their system, because say
they are fitting in 4 MB of flash on an embedded box that does only
limited things.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] nut server without nut-client/monitor?

[Greg Troxel]

Orion Poplawski via Nut-upsuser 
writes:

> Would it be at all useful to have just the nut "server" components installed
> and running on a machine without a nut-monitor service running?

It really depends on your goals and your overall plan.

Generally, upsd and drivers just accumulate state and provide it to
clients, so they don't tend to be truly useful by themselves.

You could run a custom client that logs and reports state against upsd.

You could run upsmon across the network.  However, the shutdown process
assumes upsmon is local.

However, there's a normal plan, and if what you are doing is even sort of
normal, it's likely best to do the normal thing, unless you can
articulate why you want something different.

So:

  0) Read some stuff on the web:
 https://xyproblem.info/
 https://dontasktoask.com/ (not quite on point)
 
  1) Tell us your situation and what you want to accomplish.

  2) Tell us why, after having read the docs, you are heading towards a
  non-standard setup.
  

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...

[Greg Troxel]

Tom via Nut-upsuser  writes:

>>That makes sense.  So you'll have input voltage, output voltage, and
>>output current I would guess.  You might consider a nodemcu (ESP8266)
>>publishing via MQTT to reduce power and use of unobtainium.
>
> Yes, that is exactly what I was planning to instrument.  Maybe battery
> voltage too if I can access it.  I thought it might be useful to be able to
> see the open circuit battery voltage while charging, I dunno.

Actually, given that the output is a DC-DC converter, you really will
want to have some way to measure battery voltage so you can get
SOC/runtime.  I would suggest writing to their support and tell them
what you want.  From the site, they have higher than usual odds of being
cooperative.

> I'll look into this.  I have no experience with nodemcu's, and never heard
> of MQTT until your message, but I am always willing to learn
> something new.  Has NUT been deployed on a nodemcu?  It looks like these do
> not run traditional operating systems?

This would not run NUT or unix -- it's an arduino-class CPU.  I was
assuming you have another computer on that will and the RPI was just to
drive the i2c.

Basically:

  ESP8266: very small/low-power/cheap ($7?) arduino-ish dev board with
  wifi and GPIO/i2c/etc.

  nodemcu: software that lets you write in lua for the esp8266/esp32.
  Or you can write raw arduino code.

  MQTT: message bus for IOT where you have a broker and then some device
  writes values to a topic.  This lets you decouple the IO and the
  processing.

I have a python program that watches nut on a system and publishes a
json dictionary to an MQTT topic.  I have a remote Home Assistant that
ingests this and does display/logging/alerting.


So basically I am suggesting making a UPS that interfaces via MQTT and
an MQTT driver.  A lot more work that what you are proposing; I am
thinking the long game, which is not necessarily what you want to or
should do  -- but it's what I do


If you don't have a machine that can run nut as part of the always on,
then your RPI0W approach makes a lot of sense.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...

[Greg Troxel]

Tom via Nut-upsuser  writes:

> 1.  Yes, I plan to use a Raspberry Pi Zero W with an I2C interface wired to
> it which can monitor multiple channels of voltage and current.  Here is an
> example I am considering:
> https://www.amazon.com/Comimark-INA3221-Triple-Channel-Current-Voltage/dp/B07X524KSK
> It is based on the TI INA3221.

That makes sense.  So you'll have input voltage, output voltage, and
output current I would guess.  You might consider a nodemcu (ESP8266)
publishing via MQTT to reduce power and use of unobtainium.

> 3.  Although 'dummy' doesn't feel right, why not?  It could allow me to
> just use NUT right out of the box without having to muck with it.  I will
> look at other drivers (you mention JSON).  Maybe there is something else
> that can work straight out of the box...

It doesn't feel right to me because

  dummy is documented for testing and you aren't testing

  there is not, as far as I can tell, a path to write variables and
  perform instant commands

That doesn't mean it won't work.

> 4.  Logging, etc.  Perhaps...  My 'c' or 'Python' code that performs the
> smart UPS functionality can log information, at least during debug.

What I meant is that I log voltage in, power use, battery voltage,
reported runtime always, in Home Assistant and this is useful to
understand behavior.  Without a manufacturer determined mapping from
battery voltage and load to remaining runtime you have to do that.
Keeping those logs will let you figure it out.  My experience is pretty
much every time I log something about the world and look at them I learn
something.

> 5.  Perhaps there could be some general interest, but most just buy a UPS
> and don't want to gin up extra add-ons / interfaces.  They just want to
> plug & Play.  If I like the result, I could consider writing it up if there
> is some general interest.  Of course right now, Raspberry pi's are
> virtually non-existent due to supply chain issues.

Sure, but among the set of DIY people, sharing results is nice.

> 6.  My example .dev file was totally fake and I used it just to test my
> concept of using 'dummy'.  On the other hand, I feel like it is a
> reasonable set of parameters that I wll strive to provide.  Certainly the
> voltages and current.  The capacity and runtime will take more work, but
> they are really not required just to inform the NAS when line power has
> failed and it needs to consider shutting down.

Yes, although NUT is based on "LB" to trigger shutdown.  But that's easy
to synthesize.

> 8.  Realistic numbers? - I have a Qnap TS233 which is quite
> power-efficient.  I have measured the input current and when fully running
> it draws between 0.8 and 1.0 amps.  My router is about 0.7A, so this is a
> grand total of ~ 20 Watts.  The Battery Backup unit is this:
> https://cuttingedgepower.com/en-at/products/mini-ups?variant=42778989691115
> It is rated at 75 Watt Hours so I should be good for 3+ hours with the 20
> watt load.

So 1.9A, which seems fine.  I just thought 3.5A was high -- but I guess
you agree.

Thanks for the link - that site looks like it has lots of interesting
things.  You should hook up a wind turbine to charge the battery...

> 9.  My motivation here is this - Our power grid is excellent here.  I
> don't think we have had an outage greater than an hour since we have lived
> here (10 years).  We do have (a few times per year) momentary outages (less
> than a minute).  So, for 99.9% of the time, the battery will seamlessly
> keep the NAS running and it will glide through the short outage.  So the
> status doesn't need to be very fast.  This is mostly to ensure the NAS can
> shut down safely when there is an outage that lasts more than a couple
> hours (data protection rather than extended operation).

Where I live has a much higher ratio of trees that can fall on lines to
electric customers so I get outages more than an hour once a year or so,
depending on storms and 12h+ every 5-10 years.  But, I didn't mean to
question your motivation for this setup -- it makes a lot of sense and
is not so different functionally than the hour+ UPS I have on my router.
I just like to know right away when the power is out, even though that
is not actually useful vs 30s later.  And I want to be notified of 2s
outages.  These are not that rare when a fault happens and a recloser
opens and closes and by the time it closes some other protection device
has opened and thus the main distribution line doesn't see the fault.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...

[Greg Troxel]

Tom via Nut-upsuser  writes:

> I am working on setting up a 12V DC UPS that will power a NAS and a router
> for a few hours.  It contains some lithium-ion batteries, and a BMS to
> control charging.  Since it is just a dumb box with batteries, it has no
> intelligence to inform the NAS of its status.  This is where NUT comes in...

I don't follow.  "no status" but you are reading voltages.  Are you
using an ADC wired up to e.g. i2c, so you have added monitoring ability?
How are you measuring current?

> I would like to incorporate a Raspberry Pi NUT server into this scheme.
> The Rpi can measure input voltage, and output voltage & current to
> determine the status of this simple UPS.
>
> With some of the excellent documentation online, I have gotten a NUT server
> running on the Rpi, and my NAS (a Qnap) has been able to read the status.
> I used the 'dummy-ups' driver for testing this and it worked great.



I am not sure you are really missing anything, but I would suggest:

  You are doing two things.  One is finishing the job of building a UPS
  that report status from the battery system you have.  The second is
  making an interface from that to NUT.  Think about it in two parts.
  Build and debug it in two parts.

  dummy doesn't feel right because this is a real UPS, not a test setup.

  I wonder if any of the existing drivers has a generic UPS protocol
  that is written to be simple.  By that I mean a protocol designed to
  be written and read with minimal code, rather than NUT authors having
  to cope with what the hardware people thought was good.  json comes to
  mind.  I don't think the NUT RFC specifies this part at all.

  Having thought this far I can see why you ended up at dummy as writing
  a file with variables and values is exactly what the generic protocol
  ought to do.

  You definitely want logging of values to a db/etc. so that you can
  understand the relationships among voltage, current, runtime, SOC.
  But that's not really about NUT.

As for

> Now, for the real business - Since this is entirely homebrew, there is
> not an appropriate driver available.  I read about creating my own
> driver using 'skel.c' as a template.  But, nobody else would have any
> interest in my very specialized driver.

I don't follow.   Surely others might want to buy the battery thing, and
use the ADC etc., and replicate this.


> ups.mfr: Tom
> ups.model: My Contraption
> battery.charge: 100
> ups.status: OL
> input.voltage: 1.02
> battery.voltage: 11.5
> output.voltage: 11.2
> output.current: 3.4
> battery.runtime: 1000

> I write this file periodically (maybe every 15-60 seconds) and the Rpi NUT
> server would be none the wiser and just keep supplying the
> constantly updated contents of this file to the NAS.

I don't follow how much of this you think is real.  Battery.charge is
tough to estimate and your input.voltage does not make sense.  And the
output current seems high for what you described, but maybe your NAS
uses a lot.  I have 37W output from a UPS (AC) powering a router, a
RPI3, a POE ethernet switch, and an access point on the switch.  I guess
that's the equivalent of 3A at 12V, assuming 100% efficiency so 3.4 with
a NAS with disks is not implausible.

I would urge you to only write actual data and just leave out things you
don't know.   I suspect after a test run you will have a good curve *for
the load you actually have* mapping battery voltage to runtime.  Also to
charge.  So you can have some actual data and some synthetic data, just
like a real UPS :-)

I don't know how often dummy does stat(2) to check if the file has
changed but I would expect often and maybe it's the usual pollinterval.
As an example, I get a notification within seconds if my input voltage
drops below 100V (vs 125 nominal and 122-127 almost always).  Usually it
has gone to 0V.  There's a 1s poll interval, and then a python program
watching NUT sends this over MQTT, and then Home Assistant sends xmpp.
I have two concerns: one is that I want to know about even brief outages
and the second is that I want to know about them as they happen, not a
minute later.

If in a ramdisk (which seems necessary anyway) you could just write it
every second, and you could also write it once a minute OR if anything
has changed in an interesting way.  Interesting is at least any
ups.status change and any transition from input voltage being in the ok
range to being not in the ok range or back.



___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Question about Tripp-Lite UPS life span

[Greg Troxel]

Larry Fahnoe via Nut-upsuser 
writes:

> Somewhat off-topic, but seeking some input from other tech folk on
> this list. I have a Tripp-Lite SMART 2200 (a white tower that looks
> similar to, but predates the black SMART2200NET) that just failed its
> monthly battery test so I bought new batteries and replaced the old
> ones. Sadly once put back together, plugged in and enabled it did not
> power up--no lights, sounds, smoke, etc. I took everything apart again
> checking for blown fuses, loose connections, anything visually
> obvious, but found nothing. The old batteries measured 12.x volts each
> and the new batteries measured 13.x so I don't think I got a bad
> battery. I replaced with the same batteries I'd used in the past:
> Duracell SLADC12-35J Deep Cycle AGM SLA 12V 35AH; the last set lasted
> 7 years. Tripp-Lite considers these batteries to be non-user
> replaceable, likely because they're bolt on and opening the case is a
> bit of a chore. It's a well built unit though.

I saw an APC unit that would not power up with bad 18 Ah batteries.  I
hooked up (bogusly) some weak 7Ah batteries and it started but failed
under load (fair enough).  But the original symptom was "will not turn on".



Double check that neither battery is reverse polarity.   Use a voltmeter
if you can on the connections.

It could be that one or both of the new batteries are bad, showing 13.x
open circuit but not being able to supply current.   Can you put a load
on them to test?

If you put the old ones back in, does it turn on?

I would say that while it's possible you broke it by changing batteries,
that doesn't seem super likely.  Just being old doesn't make it that
likely to fail any particular day.

As a random datapoint I had 5 Best Fortress LI660 units from 1995.  4
are still ok and one had a leaking transformer and I recyled it.  I have
a Fortress II from slightly later (but 90s I think) and it's doing
fine.  All have had multiple battery changes, which is "not user
replaceable" by modern standards but "easy tech level".  Screwdrivers,
fiddling with wires on tabs, being careful not to short.  Sounds like
what you did, maybe a bit easier.

> The UPS has a system enable switch on the back and a momentary on/off
> switch on the front. I plugged it in to the wall, turned the enable
> switch on, and then pressed the front on/off switch. Nothing. I also
> tried holding the momentary switch in for 5 and 10 seconds. Nothing
> from pressing the alarm silence switch or holding both switches
> in. Breaker in back has not popped. No other obvious switches inside
> or out.
>
> I called Tripp-Lite support and the best that they could offer was
> that the UPS died, maybe as a result of replacing the batteries. Tech
> was polite, saying unit lasted a long time, but technically this
> doesn't really seem a reasonable explanation (to me at least). Sure
> things fail with age, sometimes silently, but I'd expect to see some
> evidence as to what failed. I'm bugged as my gut says it needs to be
> reset somehow, but service manuals are unavailable and the UPS might
> have been older than the tech.

> UPS unit:
> Model SMART2200
> Model # SM1834
> Date code -LW1GE (Nov 1998)
> Serial number E00321344

https://community.spiceworks.com/topic/279062-tripp-lite-ups-won-t-power-on
see last comment about stuck power button


So all in all it could be broken, but I don't buy that it should be
because of age.  Things just break more or less randomly.  And replacing
batteries is higher risk than sitting there.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Best Fortress users?

[Greg Troxel]

I have 4 Best Fortress LI660 units from 1995 and would like to improve
the driver.  Before I change things, I'd like to ask:

  Is anyone else using "bestfortress"?

I'll assume "no"; otherwise please email me or post here, and also
I'd like to know:

  Does 'upsdrvctl shutdown' cause poweroff to be delayed 10s like it
  ought to, or ??

  Do you try to set the lowbatt runtime threshold and how does that go?

  Do you have a protocol spec?

  Would you like to test what I change?



___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower

[Greg Troxel]

Bruce Pleat via Nut-upsuser 
writes:

> I'm using the latest updates to OS and running the latest apt nut packages
> in the dist (2.7.x?).

Debian 11 has 2.7.4.

That's old; 2.8.0 was released in spring of 2022.  And git master has a
lot of improvements since 2.8.0, and I would therefore recommend trying
that.  I think but am not 100% sure that there is a fix for the problem
you are seeing.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] battery.voltage Powercom Macan MRT-3000

[Greg Troxel]

What would be best is if they could just publish a protocol spec, or
mail you a copy with permission to add to nut docs.


___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] battery.voltage Powercom Macan MRT-3000

[Greg Troxel]

That makes sense to me.   The field needs to be split into bytes.  The
low byte is the integer part of voltags, and the high part is units of
10 mV.  And this is per cell.

Probably the unit is measuring the total and then dividing by 36.  But
volts per cell will have the same interpretation for varying cell
counts, so it's a nice representation.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] experience with old Best Fortress? shutdown not seeming delayed

[Greg Troxel]

I have several Best "Fortress LI660", manufactured ~1995, which use
bestfortress(8).  nut has been monitoring two of them just fine for
years via a USB/serial adaptor and homemade TXD/RXD/COMMON cable.

I am now trying to properly set up LB shutdown and have a few questions.

1) ups.shutdown.delay is set in the driver:

dstate_setinfo("ups.delay.shutdown", "10"); /* write only */

It seems nut in general documents 20, but I can't find that.  10 feels
short as a default.

The "write only" is confusing.  There is no way to set this, and it's
read when shutting down and is available to read in general.

Should this be changed to 20, and the comment cleaned up to say that the
user can't change this?   Why shouldn't it be changeable?

2) At shutdown, that value is used to generate a string which should, by
code reading, look like "OFF10".

I have the dim impression that there should be a space, as in "OFF 10"
but I could have bad memory or be confused.

3) It seems that "upsdrvctl shutdown" leads to rather immediate power
off, not a 10s delay.   Power to the load stayed off and came back.
This is with 'upsmon -c fsd'.

4) The driver says

grace = dstate_getinfo("ups.delay.shutdown");

if (!grace)
grace = "1"; /* apparently, OFF0 does not work */

and I wonder what happens with OFF0.  (Clearly OFF%S dereferencing a
null pointer is bad.)

5) It looks like an incomplete conversion to upslogx, and some remaining
printfs, obviously to be fixed by someone with time and interest.
Correct?



It's now on my todo list to see what happens with these commands; I
have a spare chassis w/o batteries that I can test with.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] How verbose should NUT be by default?

[Greg Troxel]

Jim Klimov via Nut-upsuser  writes:

>   The opposite opinion is that programs should be quiet until asked to
> squeak (e.g. by restarting with higher debug verbosity... "that would help
> troubleshooting why the rack went down last week, right!" says the sysadmin
> me).

That's a fair summary but my opinion is:

  daemon-type programs should not by default emit things to
  stdout/stderr, unless the daemon can't run.  Things like "upsd
  2.8.0.1" started are ok in syslog at LOG_INFO and we could probably
  regularize that.

  version is not interesting, because it's easy to tell what version is
  installed, and a well-run system has only one copy of nut.  And -D can
  print it to find out; it will be the same after a failure or before.

  "upsmon -K", documented to return 0/1, should not print by default
version
that there is no pidfile
that a upsmon daemon is or is not running
the location of POWERDOWNFLAG
and even that POWERDOWNFLAG is not set
  I'm ok with printing one line to stdout that it is set, because that's
  a big deal.
  I'm -1 but not a big deal on printing that is NOT set, because that's
  normal.
  I think it would be good to stat the dir containing POWERDOWNFLAG and
  print a warning if it is not there.

  All the notable things that lead to shutdown (UPS going on battery,
  lowbatt, decision to shutdown, setting FSD flag, setting killpower,
  calling shutdown) are fair game for syslog.

  syslog should mostly survive for post-mortem analysis

  console output is ephemeral anyway, usually

  extra info is harmful because it makes everything harder to read; a
  bigger haystack to find a needle (which may be not about nut)
  
Specifically, I find all of this to be noise:

  Network UPS Tools upsmon 2.8.0.1
  Note: A previous upsmon instance is already running!
  Usually it should not be running during OS shutdown,
  which is when checking POWERDOWNFLAG makes most sense.
  UPS: foo@localhost (primary) (power value 1)
  Using power down flag file /etc/killpower
  Power down flag is not set

as the man page says "retrrns 0 or 1" and this is replacing

  if [ -f /etc/killpower ]; then

upsmon startup:

  Network UPS Tools upsmon 2.8.0.1
  kill: No such process
  UPS: foo@localhost (primary) (power value 1)
  Using power down flag file /etc/killpower

again, all knowable statically from config.

upsd:

  Network UPS Tools upsd 2.8.0.1
  fopen /var/db/nut/upsd.pid: No such file or directory
  Could not find PID file '/var/db/nut/upsd.pid' to see if previous upsd 
instance is already running!
  listening on 127.0.0.1 port 3493
  listening on ::1 port 3493
  Connected to UPS [foo]: bestfortress-foo
  Found 1 UPS defined in ups.conf

again, all what was configured.

>   So here is a shout-out to other practitioners: should NUT programs print
> their banner and other info (e.g. competing daemon instance was/wasn't
> found and how that was determined) every time they start by default? Or
> should they indeed be revised to talk less (and then settings and
> init-scripts in packaging can be tweaked to retain current behavior should
> distros/users want to)? Note that an alternative is to redirect to
> /dev/null the messages in init-scripts and similar integrations instead.

It's not, because redirecting to /dev/null loses the ability for output
that is notable to appear.


And a question from me:

  Have you ever had a situation where the above verbose info, printed on
  stdout/stderr, was useful in diagnosing a previous problematic
  shutdown (a real one, not a testing one)?  If so please describe.
  

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] confusion about shutdown

[Greg Troxel]

On 1/5/23 3:04 PM, Jim Klimov wrote:
https://github.com/networkupstools/nut/pull/1762 
 (and maybe some of 
other recent PRs) updated quite a bit here and there, including a 
configure-time option for default POWERDOWNFLAG value (using legacy 
default still).


Distros now have easier time to put it into a tmpfs of their choice that 
they know will remain mounted.


Thanks - that is helpful.

In general, OS shutdown is tricky business before we add in killpower, 
and with killpower with no delay it is almost impossibly tricky.   I'd 
be a bit scared of assuming ramdisks are still there.


It looks like the FreeBSD port assumes offdelay is long enough (and that 
the UPS will have an offdelay).  It may be that essentially all units 
really do have a delay, and this is ok.


In NetBSD, ramdisks w/o device nodes are unmounted just before swap is 
deconfigured, which is before the place where critical filesystems would 
be made ro.


So I'll have a look at this file being removed on upsd startup, or in 
our rc.d scripts for now.



___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] confusion about shutdown

[Greg Troxel]

Charles Lepple  writes:

> On Dec 30, 2022, at 7:42 PM, Greg Troxel  wrote:
>> 
>> maybe me, maybe docs.
>> 
>> I have never had auto shutdown set up on netbsd.  Mostly I monitor to
>> mqtt.  But now I'm trying and have multiple confusions.
>> 
>> 1) 'upsdrvctl shutdown' vs 'upscmd shutdown.return'
>> 
>> upsdrvctl is about stopping the driver, but lowbatt shutdown wants to
>> send a command.  I don't get the upsmon example file:
>
> "upsdrvctl stop" is for stopping the driver, but "upsdrvctl shutdown"
> runs "$DRIVER -k" to kill power to the load on the UPS (which is
> actually a second, non-long-running instance of the driver that
> doesn't talk to upsd, after the rest of the system is ready to stop).
>
> That being said, upscmd needs to talk to upsd, which needs a running
> driver - IMHO this is only workable if you trust your
> delay-before-shutdown in the UPS. The "upsdrvctl shutdown" case can
> often be run after everything has been remounted read-only, at which
> point it is okay if there is no delay before the power gets pulled.

Thanks.  I am editing docs for a soon PR.  Checking my understanding:

psdrvctl stop will not affect the UPS, and upsdrvctl shutdown will spin
up $driver -k, assuming that the previous long-running driver is no
longer running.

And thus one does not use upscmd to do a shutdown, because it needs
upsd/driver running and in getting to fs being ro, those will have been
stopped.

And, one can either:

  do shutdown when upsd/driver/upsmon is stopped and hope delay is long
  enough

or

  have another script that runs essentially last, after the fs are ro,
  so even if no delay it's ok

> Hopefully explained by the above. Also, you don't have to check for the file 
> directly - you can use "upsmon -K" as in the following excerpt from the 
> rc.d/nut script in FreeBSD's NUT port:
>
> nut_poststop() {
> if ${nut_prefix}/sbin/upsdrvctl stop && checkyesno nut_upsshut; then
> if ${nut_prefix}/sbin/upsmon -K; then
> ${nut_prefix}/sbin/upsdrvctl shutdown
> fi
> fi
>
> }

got it about -K

This assumes delay, or is that somehow post remount ro?

>> 2) LB config.   On a Best Fortress, I can set lowbatt runtime, but only
>> 3 digits, even though I want 1800s.   Is this likely a Fortress
>> limitation, or a bug?  I will read the source...
>
> Looks like it might be a NUT bug. There should be room for four digits
> in the protocol, but the protocol appears to be minutes. NUT shouldn't
> limit the seconds field to three characters.

Thanks, will read the printed protocol spec I have someplace.

>> 2A) seems like nut should be able to have time-based config to start
>> shutdown, all of batt%, seconds remaining, and seconds on battery, built
>> in.
>
> Others have covered solutions in greater depth (I think Roger's config
> guide handles most of these), but IMHO things like "seconds on
> battery" aren't as easy as they look (unless you don't care about the
> intersection with seconds remaining).

Sure, I want:

  if on batt for 2min, start shutdown

and I'm fine with

  if LB, start shutdown

also firing.  Basically one UPS has a desktop (piggy, not important to
stay up, important not to break) and an RPI/switch/wifi (good to keep
running).

I have queued the config examples pdf for reading.

>> 3) seems like shutdown should remove /etc/killpower but maybe upsmon
>> removes it at boot.  should be explained more, probably, guessing it is
>> at boot since fs is ro
>
> probably should be removed at boot (or better yet, placed on a RAM-based 
> filesystem), but this is not my area of expertise.

/etc is ~never RAM-based, so we need to move to /var/run or equiv, but I
think removing it at startup is easy and maybe already done.  I will
look.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] [networkupstools/nut] Project Release Cycle Plan Needed (Issue #1769)

[Greg Troxel]

My thoughts are:

  we have an infinite number of version numbers

  it makes sense to, roughly every 6 months to a year, release 2.N+1.0 with
  whatever has accumulated after a several-week call for testing, even
  if it's not exciting.

  2.N.1 etc. can happen if there's something serious and othewise not.
  
So I see us as heading to 2.9.0 over the next few months but not
urgently.  I'm guessing Jim sees it similarly.



as for maintaining stable branches, that's work.  In another project I
maintain, I choose not to.  I don't want to do work for people that want
LTS -- they can do that work or pay for it.  (I find that the LTS world
tends to expect others to accomodate their desire for software that is
both old at new at the same time and I'm cranky about that, especially
for non-Free distributions.)

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] confusion about shutdown

[Greg Troxel]

maybe me, maybe docs.

I have never had auto shutdown set up on netbsd.  Mostly I monitor to
mqtt.  But now I'm trying and have multiple confusions.

1) 'upsdrvctl shutdown' vs 'upscmd shutdown.return'

upsdrvctl is about stopping the driver, but lowbatt shutdown wants to
send a command.  I don't get the upsmon example file:

  # POWERDOWNFLAG - Flag file for forcing UPS shutdown on the primary system
  #
  # upsmon will create a file with this name in primary mode when it's time
  # to shut down the load.  You should check for this file's existence in
  # your shutdown scripts and run 'upsdrvctl shutdown' if it exists, to tell
  # the UPS(es) to power off.


2) LB config.   On a Best Fortress, I can set lowbatt runtime, but only
3 digits, even though I want 1800s.   Is this likely a Fortress
limitation, or a bug?  I will read the source...

2A) seems like nut should be able to have time-based config to start
shutdown, all of batt%, seconds remaining, and seconds on battery, built
in.

3) seems like shutdown should remove /etc/killpower but maybe upsmon
removes it at boot.  should be explained more, probably, guessing it is
at boot since fs is ro

4) not clear where I should edit in the instant command, as it doesn't
belong when shutting down upsd, but yet it has to be before.  This is
complicated.

Any working code on NetBSD?

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] /etc/pki/nssdb is world readable complaint

[Greg Troxel]

Orion Poplawski via Nut-upsuser 
writes:

> nut-server/upsd complains that /etc/pki/nssdb is world readable. 
> However, this is the standard configuration (RedHat/Ubuntu).

did upsd complain, or some library it includes?  It seems possiblethe
issue is not really a nut one.



> If keys are present they should be protected by a pin/password.

I suspect opinions differ and  many think a file which could have keys
should not be readable.

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC ups reports "OL DISCHRG" as its normal status, even when plugged into mains

[Greg Troxel]

>> 0.430484 ups_status_set: seems that UPS [GamingUPS] is in OL+DISCHRG
>> state now. Is it calibrating or do you perhaps want to set
>> 'onlinedischarge' option? Some UPS models (e.g. CyberPower UT
>> series) emit OL+DISCHRG when offline.

I think the first questions are:

  what is the UPS actually doing?

  what do other programs, especially from the manufacturer, say?

and then perhaps there is need to  have a quirk table in the code to be
able to express things like

  For APC BGM1500, if it says OL+DISCHRG, rewrite that to OL, because
  it's confused.

so that then the later logic will be ok with it.

Presumably you are watching battery voltage and it's 26ish, assuming 2
12V in series, or similar, so not actually discharging.  True?

What is the status when the power fails?  You said it included DISCHRG,
but anything else?

Did you trace/debug-log the code that led to OL+DISCHRG?   What bits is
the UPS really sending?  Is this is a UPS bug or a nut bug, or the UPS
has an odd spec or ?

More questions than answers, but hope it helps


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ups-server grumpy after updating to Fedora 37

[Greg Troxel]

Sam Varshavchik  writes:

> After updating to Fedora 37 ups-server started having a bad hair day,
> spewing this:
>
> Nov 21 07:03:28 monster.email-scan.com nut-server[1735]: Can't connect
> to UPS [nutdev1] (usbhid-ups-nutdev1): No such file or directory
>
> May or may not be related: there's a widget on the desktop's XFCE
> panel, that shows the UPS's status as normal, so something, somewhere,
> is communicating with the UPS.

It is highly likely related.  Use fstat or lsof ([1] or however that is
spelled on Fedora) to figure out what process has the uhid device open,
and run the ups drive process under ktrace/ktruss/truss ([1]) to see
what is actually failing at the syscall level.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC SmartUPS powercycles when power returns

[Greg Troxel]

Andrea Venturoli via Nut-upsuser 
writes:

> I've got an APC SmartUPS 1500: it's connected via USB and I'm using
> the usbhid-ups driver. This used to work properly until recently.
>
> Now, when power goes out it keeps on going on battery potentially for
> several minutes, but, the moment line returns, I hear a click and
> power is cycled on the outlets (so every computer is rebooted
> forcily).
>
> I'm thinking about a hardware issue, but could it be that NUT is
> instructing it to do so?

I suggest an experiment:

  disconnect the USB cable to the NUT computer

  turn off power for 5 minutes

  turn power back on

and see what happens


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT can't connect to USB UPS on OpenBSD

[Greg Troxel]

Glad you got it working.


Marc-André Harbec  writes:

> Also, I found I had to manually start the USB driver. In my case:
> `usbhid-ups`. I don't know if it's something that needs to be done on
> all platforms (or it's OpenBSD specific), but I haven't read anything
> on this in the official documentation. The `upsd` daemon won't start
> if the driver is not already running, and it won't spawn it itself. I
> had too create my own service file for it:
>
> $ cat /etc/rc.d/usbhid_ups
> #!/bin/ksh

In pkgsrc (and hence on NetBSD), there is a /etc/rc.d/upsdriver and that
seems to run something that looks in /usr/pkg/etc/nut/ups.conf.   I have
a Best unit and that starts it at boot.   So you could perhaps create a
generic driver rcfile and use 'upsdrvctl start'.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT add on for Home Assistant

[Greg Troxel]

I did a quick experiment.

Machine A runs NetBSD 9, ups-nut 2.8.0, and Home Assistant Core
2022.8.4.  It has a ups foo.  Note there is no "nut addon" involved, or
any "addon" at all.  ("addon" is a Home Assistant concept for the Home
Assistant OS or Supervisor running progams not from Home Assistant.)

Machine A runs NetBSD 9, ups-nut 2.8.0.  It has a ups bar.

Since a long time, a year or two, the nut integration has been
configured on A to talk to foo, over the usual 127.0.0.1:3493.

I just set up an ssh tunnel to forward 3494 on A to 127.0.0.1:3493 on B.
I then added 127.0.0.1:3494 using the UI, and it appeared.  The entities
are better named, "Foo Voltage", so it appears a bunch of rough edges
are gone (which is typical in HA; just wait 6 months and things are
smoother).  I should delete and re-add my first UPS to get better names.

I then graphed some of the things together and it all seems fine.

So that's proof the integration can support two upsd servers, but you
have to be able to contact them, and there is the convention that they
listen on localhost only unless you change that.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT add on for Home Assistant

[Greg Troxel]

"z.kevino--- via Nut-upsuser" 
writes:

> Thanks for the reply.
> I was only showing the yaml to make it easier to send to this email
> list as I didn’t think a screenshot of the UI would make it
> through. The thing to note here is that these UPS are not connected to
> the home assistant raspberry pi, but are on another raspberry pi
> device which runs as the server. So the NUT add on is running as a
> client.

I don't understand why you are running a "NUT add on".  The integration
doesn't need that, if what you are trying to do is monitor some existing
nut instance.

If you are trying to have a local nut with no attached UPS, so that the
local machine shut down, that's fine.  But you would still configure the
remote nut server in the integration, because that connects to servers.

If you have the local nut instance being a client and also exposing a
copy of the remote server as if it is local, then I don't see why HA
wouldn't connect -- but I also don't understand why you would do that.

But I've never dealt with "add ons" in HA, as I run Core (which is just
"run the home assistant python process without delegating OS management
to the HA world", in other words the normal unix approach).

> I’ll start the process over and see if I can get it to work. Appreciate your 
> kindness. As an aside, I am running on the latest 
>
> Home Assistant 2022.8.4

That is certainly up to date.  I just wondered from the yaml as there
has been a huge yaml->UI-config gradual transition over the last year.


If it still won't do two, I would look at the source code for the
integration.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT add on for Home Assistant

[Greg Troxel]

"z.kevino--- via Nut-upsuser" 
writes:

> I am able to get the NUT add-on for Home Assistant to act as a client
> for one of the UPS units attached to my NUT-server running on another
> Raspberry Pi. What I am unable to do is to get it to attach to a
> second. I can attach to the second, or the first, but just not the
> second and first if that makes sense. Does anyone run this add on ?

I think it's very likely that this is an HA issue not a NUT issue.

I have run it, but only with 1 UPS.

It is IMHO a clue that the entities have display names that don't include the
device name (even if the nerd-name does).  For example, I have a UPS
named "foo" (not its real name :-) and I get

  sensor.foo_ups_input_voltage
  V_in

Instead the display name defaulting to "Foo V_in".

It looks like your YAML was munged.   But the documentation
  https://www.home-assistant.io/integrations/nut
says to set up the integration via the UI.

I have an entry for my UPS in
.homeassistant/.storage/core.config_entries

In theory, a second instance should work fine, and if not it's a bug.

But you'll have to be on 2022.8 and use the UI before they want to hear
about it, probably.


> My YAML:
>
> devices:
>   - config:
>   - nada
> driver: usbhid-ups

I'm surprised to see driver; that's configured in NUT and HA shouldn't
care.

> name: myups
> port: auto
> mode: netclient
> shutdown_host: false

again these two are surprising.

> users:
>   - actions: []
> instcmds:
>   - all
> password: XYZ
> username: ABC
> remote_ups_name: apc600
> remote_ups_host: 192.168.1.232
> remote_ups_user: XYZ
> remote_ups_password: ABC
> upsd_maxage: 10
> log_level: debug


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Where is nut-scanner on raspberry pi?

[Greg Troxel]

It turns out that there is a bug in nut about this, in 2.8.0.

I checked the pkgsrc package, and it doesn't have nut-scanner.  Usually
what is packaged is what upstream installs.  On digging in, I found that
the package did not declare a dependency on libltldl and thus it was not
visibile during the build, and nut-scanner was not built.

The first bug is that this is not documented in INSTALL.nut.  If it
were, it would be a package bug not to provide it.  It is sort of hinted
at that somehwere else there is a list of prereqs, and I eventually
found them, but I think "this is what you need installed to build", even
if a pointer, should be front and center in a really-hard-to-miss way.
And, there is a huge list of per-OS, without first things being
described in terms of upstream package names in an
OS/distribution-agnostic manner.

The second bug is that the nut-scanner man page is installed even if
nut-scanner is not built.  Probably the fix is to move man pages to be
with their programs so docs/code match, but that is surely a can of
worms and just conditionalizing it in the Makefile.am the same way that
the nut-scanner subdir is conditionalized is reasonable.

I changed pkgsrc to depend on libltldl and now I get nut-scanner.  I'll
likely commit that change.  But, the main nut package does not use usb,
and I haven't figured out how that works with the usb split package.

(I am not meaning to assert that nut-scanner does or does not belong as
default or that users should or should not use it.)

The nut-scanner I got doesn't seem that useful:

  OPTIONS:
-C, --complete_scan: Scan all available devices except serial ports 
(default).
  * Options for USB devices scan not enabled: library not detected.
  * Options for SNMP devices scan not enabled: library not detected.
  * Options for XML/HTTP devices scan not enabled: library not detected.
-O, --oldnut_scan: Scan NUT devices (old method).
  * Options for NUT devices (avahi method) scan not enabled: library not 
detected.
  * Options for IPMI devices scan not enabled: library not detected.
-E, --eaton_serial : Scan serial Eaton devices (XCP, 
SHUT and Q1).
-T, --thread : Limit the amount of scanning threads 
running simultaneously (not implemented in this build: no pthread support)


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Where is nut-scanner on raspberry pi?

[Greg Troxel]

華敏 座利 via Nut-upsuser  writes:

> Thanks, I'll check it out. Still would like to know why the documentation
> shows there should be a nut-scanner and it doesn't install on raspb o/s.
> But I do appreciate the tips on how to find what I need now. Thank you
> again !

You are having two problems:

  Your distribution is very old.  Generally, projects do not support old
  versions just because some old distribution has them.  I have no
  formal standing in nut, but in places where I do, I say "bug reports
  are accepted only against the latest formal release or the tip of
  master".  If you are running old code you should get support from the
  packaging system that provides old code.
[However, Debian 11 has ups-nut 2.74.]

  It seems that Debian's nut package doesn't install nut-scanner.  If
  that's because the default build installs it, but they chose not to,
  that is an issue you have with them and it would be appropriate to
  file a Debian bug.  But there might be a ups-nut-scanner package that
  has that separately.  And if the default build doesn't install it for
  some reason, that's an actual ups-nut issue.

Note that it also might be that you are running such an old version of
nut that nut-scanner wasn't included but probably not.  But probably not.

Note also that you can't use the current up-to-date nut documentation
about old versions and expect it to be right.  You need to use the same
version of docs.



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT can't connect to USB UPS on OpenBSD

[Greg Troxel]

Charles Lepple via Nut-upsuser 
writes:

> If that fails, I'd recommend using ktrace to find out what is failing,
> such that you get the "no USB buses found" error.

Definitely.  I would actually recommend ktrace first.  Then just
`kdump | egrep NAMI` will probably find the issue fast.

I use nut on NetBSD, and have done "manual kludge udev" by knowing what
serial port my UPS is going to be on  and in rc.local chowning it to nut
and linking it to /dev/tty.ups which is in the config.  That's serial,
not USB, but the same thing should work.

And agreed on /dev/ugen; I have a USB printer on /dev/ugen1.01

I suspect that nut needs to read /dev/usbN (for the bus that the UPS is
on) and read-write access to the ugen file for the HID endpoint, which
might be ugen, or it might be /dev/uhid2 (assuming it's like NetBSD in
this regard).


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Info on Cyber Power CP1500AVRLCDa

[Greg Troxel]

Sorry, I did find the compat list

https://networkupstools.org/stable-hcl.html

but I'm not really clear where the sort of extended discussion you are
providing belongs.  (I am sure it's useful.)


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Info on Cyber Power CP1500AVRLCDa

[Greg Troxel]

Thanks for posting all those details; they are interesting.

I think it would be helpful to publish the config, at least the nut
logic part, and the details of cyberpower actual vs documented behavior.
(nut github wiki if Jim thinks that makes sense?)  Or maybe there is a
better place.

It seems that while how a UPS has to behave to reliably and safely
handle loss of power and restart, with all the possible sequencing, is
pretty well understood on this list, a lot of devices don't do it right.
So having documentation per model that enables buying something that
works seems key, and I don't find that.

Perhaps a warning not to buy cyberpower products would result in bug
fixes.  Perhaps not.


It strikes me that it should be possible to express start delay as e.g.

  wait until both are true:
power has been stable for 120s
battery is at least 80% charged



For your own situation, I wonder if this is a job for a microcontroller
and a bunch of relays, to patch up your UPS and make your power
sequencing do what you want.  Or a tiny computer like an RPI, maybe with
its own extended battery, or hooked into your dhcp server.  Maybe that's
a crazy idea, and I know it has a lot of downsides.



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS restart after power-off

[Greg Troxel]

I have little useful wisdom, but:

Phil Chadwick  writes:

> I have NUT installed on FreeBSD 13.0-RELEASE-p11.  It's installed from a
> standard package, derived from nut-2.7.4.tar.gz.

That's now out of date; 2.8.0 is out.  (I don't have any reason to think
that is related to your issue.)

> I am suffering from a bug regarding the "ondelay" setting in ups.conf:
>
> https://github.com/networkupstools/nut/issues/625
>
> The "ondelay" setting in ups.conf is applied to "ups.delay.start" inside the
> UPS non-volatile memory.
>
> The difference between CP1500EPFCLCD UPSs and others is:
>
>   - other UPSs apply ups.delay.start seconds AFTER wall power returns; and
>   - the CP1500EPFCLCD applies ups.delay.start seconds AFTER shutdown.
>
> So if I set "offdelay = 90" and "ondelay = 100" the UPS re-starts 10 seconds
> after it shuts down.  The only way to stop this (and leave the UPS shut down
> until wall power returns) is to set "ondelay = 0".
>
> This means that the CP1500EPFCLCD (and probably similar CyberPower UPSs) have
> no option to delay the power up load.  It's always immediate.  So there is
> no chance to charge the batteries, or allow another UPS to bring up the
> network first.

Probably you don't want to do this and shouldn't (vs getting a UPS that
works correctly), but it would seem possible to have a microcontroller
that boots and waits a bit and then closes a relay, so that your loads
don't get power for a while even though the UPS is onl


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] I-D progress update - ISE comments - NETVER vs PROTVER

[Greg Troxel]

Roger Price  writes:

> On Tue, 19 Apr 2022, Matus UHLAR - fantomas wrote:
>
>> On 19.04.22 08:56, Roger Price wrote:
>>>
>>> The problem: the I-D uses PROTVER rather than NETVER, however 2.8.0
>>> only supports NETVER.
>>>
>>> The argument in favour of PROTVER is that the command is not asking
>>> for the version of the _network_.  It is asking for the version of
>>> the _protocol_.
>>>
>>> The argument in favour of NETVER is that it is currrently
>>> implemented in 2.8.0.
>>>
>>> Should the I-D revert to NETVER?   I will follow whatever the list decides.
>>
>> can NETVER be declared as obsolete alternative to PROTVER?
>
> If PROTVER was also implemented, then yes, but if PROTVER is not
> implemented, then there would be a divergence between the I-D and NUT
> 2.8.0, which I want to avoid.

2.8.0 doesn't exist yet.  I suspect Jim would be amenable to making a
change to PROTVER as primary with NETVAR as a deprecated alias, and then
we can have the spec say what it ought to.  It seems like a small code
change and rolling another rc.



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NEWLINE

[Greg Troxel]

Jim Klimov via Nut-upsuser  writes:

> I believe the code only deals with '\n' character for line-breaks, in
> protocol and probably configs.

Probably if nut started out as IETF-ish and was mimicking SMTP it would
look for \r\n, but it seems obviously unix-ish (seems normal to me!) and
is \n.   So just documenting that seems good.  That's about the
protocol.

The config file formats are an implementation detail of one
implementation and are thus beyond the scope of the protocol spec -- and
therefore should not be mentioned.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] I-D: ISE request for more detail on command STARTTLS

[Greg Troxel]

Roger Price  writes:

> The IETF Independent Submissions Editor (ISE) has asked for more
> detail on the command STARTTLS, in particular the use of certificates.

That's interesting, given how the overall state of PKI is not
particularly about NUT.

> I propose saying that NUT 2.8.0 supports the encryption of
> communications between Attachment Daemon upsd and Management Daemon
> upsmon using TLS 1.3 [RFC8446] with X.509 v3 certificates as defined
> by RFC5280 + updates.

This is really about the defined protocol and not really about any
particular implementation :-)

Certainly pointing to the normal RFCs is good.

I see two separate issues:

  Everybody knows that the current situation where there are 100 or so
  standard trust anchors isn't really safe, because the compromise of
  any of them could lead to a bad certificate being accepted.  But NUT
  isn't special.  This is really about the server certificate.  So I
  wonder if this is about the server cert, and what the SMTP spec says,
  and HTTPS, and thinking about why NUT is different.

  Sometimes people use client certs for auth.   I'm totally unclear
  (because I only run nut over localhost, and I haven't really read the
  details) on whether the protocol spec talks about client certs for
  authentication and hence authorization.

> I also propose adding a note that in the closely restrained world of
> UPS management, it may be possible to obtain better security using
> self-signed certificates.

There is also pinning.  And self-signed is not really the fix as much as
deconfiguring the trust anchors for the N-1 CAs one is not using,
although with a self-CA that means disabling all N.  I would hesitate to
do anything other than pointing to other RFCs that address this issue.
Again nut is not really special.

I am guessing their concern was lack of clarity about client certs and
the path to authorization.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] finding a common abstraction for reporting

[Greg Troxel]

[I was going to rely privately to reduce list traffic, but the list
instructed me not to do that :-( ]

Charles Lepple  writes:

> On Mar 17, 2022, at 7:26 PM, Greg Troxel  wrote:
>> 
>> My script is in the process of being extended to also deal with apcupsd
>> and that seems to have different variables, like timeleft in minutes
>> instead of runtime in seconds.  It seems obvious to me that I should
>> bring things into a common schema, because the monitoring system doesn't
>> care about UPS brand; it wants to know is utility power good enough, how
>> many seconds left, etc.
>
> I am not necessarily recommending that you should use apcupsd-ups
> (it's monitor-only and won't send the shutdown command[*], for one
> thing); however, it's worth pointing out that a few of the conversion
> factors are documented in that driver's source:
>
> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/apcupsd-ups.h#L66
>
> [*] https://networkupstools.org/docs/man/apcupsd-ups.html#_limitations

Thanks, that was useful.  The case that prompted me to ask was a UPS run
by someone else that I think is using apcupsd and not nut.  I'm not
responsible for the UPS; I just want to get power status.

>> I wonder how much NUT does that by itself, or if it's more doing format
>> translation of the individual units.  And I would appreciate comments on
>> the wisdom/necessity of this approach.
>
> What Jim said about this is technically correct, but I would look at it 
> another way:
>
> NUT defines standard units for variables (as long as the variables are
> not marked as "opaque"), and the drivers map device-specific readings
> to those standard units. (USB HID PDC tends to use seconds, as do most
> SNMP MIBs, if I am not mistaken.)
>
> Units are in parentheses in the Description column: 
> https://networkupstools.org/docs/user-manual.chunked/apcs02.html

Thanks.  So most of what I was asking about is defined: there are a list
of NUT variables, defined semantics, and units.

The thing that's messy is power vs realpower (which is a bit funny
because they are "apparent power" and "power").  It seems old Best units
report in VA and some APC in W.   Whether to map them both into
"power-ish" for the mqtt protocol is an interesting question, especially
since I don't really believe either measurement without confirming it.


To the extent my script supports apcupsd, it would make sense to do the
same normalization.


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ISE review of I-D: deprecate command VER?

[Greg Troxel]

Matus UHLAR - fantomas  writes:

> On 20.03.22 16:02, Roger Price wrote:
>>I received the following comment from the Independent Submissions Editor 
>>(ISE):
>>
>> The command VER is hazardous because it encourages exploiting of
>> implementation peculiarities that are not well documented in a
>> protocol.  The best example of such a failure is the browser version
>> field in HTTP.  A complete disaster.  You should warn against use of
>> this command, or even better, deprecate it.
>>
>> I was not aware of the disaster in the browser version field, but I
>> will warn against use of VER, and deprecate it, if you agree.
>
> Isn't this designed for announcing protocol version for compatibility?

Protocol version is one thing and should be defined by the RFC.  All
implementations of the protocol should advertise the same version.

Software type/version of the implementation is something else.


Yes, everything may be from nut sources, but having a protocol RFC is
about moving from "the protocol is defined by the code" to "the protocol
is defined by the spec".


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] finding a common abstraction for reporting

[Greg Troxel]

Jim Klimov  writes:

> As for "how much NUT" is doing, it depends :)
>
> For many of the values where mapping tables are involved, it just reads
> some number or string from the protocol encapsulation (usb-hid, snmp,
> netxml...) and passes it on. However, that entry's mapping may also involve
> scaling (multiply by a factor) or arbitrary subdriver-defined mapping
> functions (name phases from a number, print ISO date from country-preferred
> input, etc.) as the most common conversions.

Thanks.  I can see why it is that way.

I was wondering essentially about having a standardized UPS mib, both
names and units, and having each driver translate into that standard set
of values.

I'm monitoring 3, UPSes of 2 different brands, in 3 locations, heading
for probably 3 types in 5 lociatons.  I want a common view of how the
power is, without having to think about UPS type.  (I realize that I may
be the only one doing that.)

I will probably do a bit of this in the ups monitoring to mqtt python
script I'm working on.  Partly that's because some of them use apcupsd,
but partly because it seems easier.





signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ISE review of I-D: deprecate command VER?

[Greg Troxel]

Manuel Wolfshant  writes:

> Connected to outlook-com.olc.protection.outlook.com..
> Escape character is '^]'.
> 220 VE1EUR03FT022.mail.protection.outlook.com Microsoft ESMTP MAIL
> Service ready at Sun, 20 Mar 2022 22:20:44 +
>
> |_ssl-date: 2022-03-20T22:22:21+00:00; 0s from scanner time.
> Service Info: Host: AM5EUR02FT049.mail.protection.outlook.com; OS:
> Windows; CPE: cpe:/o:microsoft:windows
>
> I am too lazy to check but I am willing to bet a beer that somewhere
> over there there is an Exchange server

Sure; these things leak.  The real horror of the web is that clients
send version and the server modifies behavior based on it.

>> In general, a fair question is "What if we deleted this?  If we wouldn't
>> have trouble, why are we keeping it?"
> Connected to dell30-5x.
>
> Escape character is '^]'.
> ver
> Network UPS Tools upsd 2.7.4 - http://www.networkupstools.org/
> quit
>
> I for one do not see much trouble in advertising the version of nut
> and its website. But I am also the person who used lighttpd for 15
> years and made it advertise itself as MS IIS and exim advertised as MS
> Exchange, just for the fun of seeing failed exploits in the logs

So how about saying that

  ver is optional, in that it can return some NULL type of string (empty
  line).

  clients may log ver or show to humans for debuging, but they MUST NOT
  change behavior based on it.


The point of a protocol is to speak the defined protocol, and if there
is really one protocol per but version, things are off the rails.  (I'm
not saying there is a problem, just that there's a line nobody should
cross and I completely understand where the reviewer is coming from.)



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ISE review of I-D: deprecate command VER?

[Greg Troxel]

Roger Price  writes:

> I received the following comment from the Independent Submissions Editor 
> (ISE):
>
>  The command VER is hazardous because it encourages exploiting of
>  implementation peculiarities that are not well documented in a
>  protocol.  The best example of such a failure is the browser version
>  field in HTTP.  A complete disaster.  You should warn against use of
>  this command, or even better, deprecate it.
>
> I was not aware of the disaster in the browser version field, but I
> will warn against use of VER, and deprecate it, if you agree.

I am quite aware of it, but I haven't seen it called out like this.  The
basic issue is that we now have a culture of web servers serving N
different versions of pages based on the User-Agent field, instead of
coding to standards and expecting clients to meet standards.  "Disaster"
might be a slightly strong word, but it isn't at all confused.

So a good question is whether it's necessary.  Perhaps it's just a
management plane concept, but for SMTP the two sides don't specify
their software or protocol versions.

In general, a fair question is "What if we deleted this?  If we wouldn't
have trouble, why are we keeping it?"


signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] finding a common abstraction for reporting

[Greg Troxel]

I have been using NUT for a long time, but my UPS farm is very old and
homogenous: I have 3 "Best Power Fortress" from about 1995, and there's
one at someone else's.  (Yes, these really are 27 years old, and yes I
have changed the batteries.)  They report a bunch of variables, and I
have written a python program to report the interesting data over MQTT
for use in Home Assistant or whatever.  I mumbled earlier that I will
release that as open source and I mumble that again.

Nothing super interesting here:

  battery.runtime: 5940
  battery.runtime.low: 
  battery.voltage: 27.5
  battery.voltage.nominal: 24
  device.mfr: Best Power
  device.model: Fortress
  device.type: ups
  driver.name: bestfortress
  driver.parameter.baudrate: 9600
  driver.parameter.max_load: 660
  driver.parameter.pollinterval: 2
  driver.parameter.port: /dev/tty.ups
  driver.parameter.synchronous: no
  driver.version: 2.7.4
  driver.version.internal: 0.05
  input.frequency: 60.0
  input.transfer.high: 
  input.transfer.low: 
  input.voltage: 124
  output.current: 0.3
  output.voltage: 123
  output.voltamps: 37
  ups.delay.shutdown: 10
  ups.load: 5
  ups.mfr: Best Power
  ups.model: Fortress
  ups.status: OL 
  ups.temperature: 18

and it is turned into json (omitting much) as an MQTT payload:

{"tst":"2022-03-17T19:15:15.641791-0400","topic":"sensor/foo/bar-ups/json","qos":2,"retain":0,"payloadlen":233,"mid":27,"payload":{"time":
 1647558915.5165293, "runtime": 5940.0, "battery": 27.5, "frequency": 60.0, 
"line_v": 124.0, "output_v": 123.0, "output_a": 0.3, "output_va": 37.0, 
"output_percent": 5.0, "status": "OL ", "utility": "ON", "temperature": 18.0}}

I know from past discussion that reporting "status" this way is
nonportable/awkward, and I probably should omit it and just use
"utility" which maybe should be "utility_inuse".  My point is that what
the monitoring system cares about is "Is the UPS using utility power or
not" as a running on battery even if input voltage is non-zero is still
cause for concern.

And maybe I should drop output_percent and have rated_va configured (660
in this case) because it doesn't seem to be in the NUT output.

My script is in the process of being extended to also deal with apcupsd
and that seems to have different variables, like timeleft in minutes
instead of runtime in seconds.  It seems obvious to me that I should
bring things into a common schema, because the monitoring system doesn't
care about UPS brand; it wants to know is utility power good enough, how
many seconds left, etc.

I wonder how much NUT does that by itself, or if it's more doing format
translation of the individual units.  And I would appreciate comments on
the wisdom/necessity of this approach.

Thanks,
Greg



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Smart-UPS 1500 info though usbhid and apcsmart

[Greg Troxel]

I'm far from an expert, but I would not really expect serial to work
better.  I would try to turn on debugging first.

However, a UPS not reporting line in and line out voltage seems strange.



signature.asc
Description: PGP signature
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser