See docs/config-prereqs.txt for dependency packages I install on CI agents
for various OSes, aiming to build as much as possible there.
To the other direct question: yes, Debian 11 is possible (and a dozen
others) as confirmed daily by CI builds ;)
Jim
On Tue, Aug 16, 2022, 21:57 Roger Price
Great news, and big thanks for the hard effort you (and many others) put
into it!
Jim
On Wed, Aug 10, 2022, 13:03 Roger Price wrote:
> It is a pleasure to report that RFC 9271 is now available at
> https://www.rfc-editor.org/info/rfc9271
>
> My thanks to everyone who contributed the
I can best suppose so far that for one, printf in shell may differ from
that in C and from scanf for that matter. And I think OTOH that scanf can
signal an error if the formatting string does not match expected pattern.
Maybe this is what happens to reject the device, maybe some other fault.
Try
Ahoj,
Just in case, did you check other subdrivers there? They all are for
variants of Megatec Qx family, UPS vendors were creative with it...
Jim
On Tue, Aug 16, 2022, 03:46 Tomáš Thiemel via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
> Hi.
>
> I bought new UPS which is not
Posted https://github.com/networkupstools/nut/issues/1560 lest we forget :)
Jim
On Sun, Aug 14, 2022, 02:06 Jim Klimov wrote:
> Haven't poked INSTALL.nut for a while, PRs welcome. And there were many
> bite-size PR ideas in this thread ;)
>
> There was quite a bit of details poured into
Also search NUT github issues, there were a few threads about Home
Assistant in the past year or two. Something about "just one of something
at a time" rings a bell in this context, but I can't elaborate just OTOH
now :)
I think some posts also detailed (or referred to docs about) building your
Haven't poked INSTALL.nut for a while, PRs welcome. And there were many
bite-size PR ideas in this thread ;)
There was quite a bit of details poured into docs/config-prereqs.txt that
grew along with CI farm over the past year or two, so covers many OSes
(even Windows, it its branch).
>From my
Back from vacations, and before I dive into real-life work, I went over
some ideas and notes from the NUT for Windows effort.
Now they should be tracked at
https://github.com/orgs/networkupstools/projects/2/views/1 and community
help is welcome :)
I probably forgot or missed some caveats - so
Hello all,
After a hectic month in private life, as a byproduct I've got a viable
merger of last released NUT 2.6.5 based Windows-ready codebase (thanks to
the giants active a dozen years ago, on whose shoulders I stood today) and
modern 2.8.x/master, fixing the merge conflicts and build
Thanks for the heads-up. I think Riello engineers who wrote the ser/usb
drivers were active relatively recently, maybe they would make some
better-informed comments and/or propose a correct HCL update.
As for a network card, I'd expect that to support at least the standard
IETF SNMP MIB. If there
One thing I'd check are the two lines in upsmon.conf it complains about -
seems like you had uncommented descriptions of key words instead of setting
them up.
The access denial, that one seems to be a mismatch of login/pass specified
in upsmon.conf client and that for the server in upsd.users
Adding to what others said, your best bet should be that the VM host
monitors two UPSes with two NUT driver instances (snmp or usb), and upsmon
client would specify that each UPS powers e.g. one of your two PSUs - and
one well-fed PSU is sufficient to run. Then when power does go critical,
upsmon
First of all, please check if NUT 2.8.0 (2.7.4 is 6 years old) or a build
of current git head fares better.
If it does not, see if adding a USB_DEVICE entry similar to those existing
but with your ProductID would "just help" - assuming this device follows
the same protocol as others.
As for
According to issues discussed over the past year or so on github, seems so
- that at least some models and/or OSes and/or chipsets have a problem with
libusb interrupt mode; more often failing during device discovery than
after some successful uptime.
I don't think there was reliable statistics
Another "moderately worst case" scenario is to run the NUT driver as root
(with the option in its ups.conf section), at least that helps for ruling
out this permissions sort of issues vs. other moving parts.
Note that generally USB device numbers are not "bolted" and depend on
enumeration order
Great news and great job, thanks!
Jim
On Tue, May 17, 2022, 06:41 Roger Price wrote:
> The IESG [1] has approved the NUT I-D.
>
> Backgound: The Internet Engineering Steering Group (IESG) is a body
> composed of
> the Internet Engineering Task Force (IETF) chair and area directors. It
>
Hi, sorry for missing this in my mailbox.
The short answer is that a port=file.xyz would now loop like before (which
was the only mode then).
Since 2.8.0 there are 3 modes in setting as well as reports in `upsc` etc.:
2 for explicit behavior (dummy-once as default for *.dev and dummy-loop as
Hello, fellow NUTs!
After a long and windy trip since the last official release v2.7.4 half a
dozen years ago, we the community, contributors and maintainers are proud
to announce at last the general availability of NUT v2.8.0!
As always, the new release includes numerous new drivers,
Great, thanks!
Just verified - both work (and say "1.3") in current master builds.
Jim
On Wed, Apr 20, 2022, 10:31 Roger Price wrote:
> On Tue, 19 Apr 2022, Jim Klimov wrote:
>
> > I think I committed one recently; should be possible anyhow.
> >
> > On Tue, Apr 19, 2022, 14:38 Roger Price
As far as I know the FSD flag by design can only be raised; many phrases
refer to it as "latching" - much for the same reasons as you outlined:
people usually want the datacenter in a predictable hands-off state. If
something begins to shut down due to critical power state of the UPS,
everything
Note: There was an issue with original publication of the source tarball
for rc2, so it was re-published on github releases and on nut website.
On Sun, Apr 10, 2022, 16:40 Jim Klimov wrote:
> Hello all,
>
> Having 10 days since an rc1 and a number of issues fixed and late-coming
> features
I believe the code only deals with '\n' character for line-breaks, in
protocol and probably configs.
Jim
On Sun, Apr 10, 2022, 19:26 Roger Price wrote:
> The IETF requires that the I-D contain an ABNF (Augmented Backus-Naur
> Form)
> grammar of the NUT commands and responses. At the end of
Hello all,
Having 10 days since an rc1 and a number of issues fixed and late-coming
features integrated, I'm rolling the dice again with NUT v2.8.0-rc2
Hope it brings no bad surprises either :)
Jim Klimov
On Fri, Apr 1, 2022, 02:01 Jim Klimov wrote:
> Hello, fellow NUTs!
>
> It is with a
UPDATE: could not reproduce in Rocky Linux 8.5 nor Ubuntu 20.04, detailed
in issue #1344
On Sun, Apr 3, 2022, 12:16 Jim Klimov wrote:
> Hello all,
>
> A concern was raised (in issue #1344 among other things dealing with
> recent git-source NUT setup on Rocky Linux 8) that new systemd service
Also does not seem dictated in docs nor comments.
De-facto it is a string pointer, in some code constrained by a SMALLBUF
sized character array, where SMALLBUF is a macro currently defined to 512.
Looking on a larger scale, it seems the server-client code currently passes
it in the open (safety
Did not find a definition in the docs quickly...
I think Arnaud mentioned that there was (planned to be?) some constraint,
but looking at the parsing code it seems that de-facto we check for (and
strip away) the opening and closing brackets in the first token after
`parseconf` separated the lines
Great thanks for handling this!
Jim
On Mon, Apr 4, 2022, 15:17 Roger Price wrote:
> I have begun the process of requesting the transfer of port 401/TCP (ups)
> to the
> NUT Project with Jim as Assignee. For the project's records I attach a
> copy of
> the request.
>
> Since this transfer
Hello all,
A concern was raised (in issue #1344 among other things dealing with
recent git-source NUT setup on Rocky Linux 8) that new systemd service
definitions misbehaved on a client-only system.
Per report, the `nut-monitor.service` (which both `Wants` and is `After`
the
> Are there any known backward incompatible changes?
e.g. conf file settings or commands that won't work anymore?
None that I am aware of. There are a few new config keywords (and aliases
to older concepts), so programs from the older NUT packages would probably
safely refuse to start while
Hello, fellow NUTs!
It is with a [happy] heart that I must proclaim today, that the long
reign of NUT v2.7.4 is coming to an end. Its anticipated successor of half
a dozen years, release-in-waiting NUT v2.7.5 has also quietly expired, and
[won't] be sorely missed. They were survived by the next
Regarding VA/W conversion, keep in mind the power crest factor, and that it
is not always sqrt(2)/2 =~0.7
Some devices actually report theirs and I've seen the likes of 0.9 for
example.
On Mon, Mar 21, 2022, 14:36 Greg Troxel wrote:
>
> [I was going to rely privately to reduce list traffic,
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
On a side note, new configuration file keywords added in earlier PRs, and
to a lesser extent this protocol change (should not be disruptive for
old/new server/client chatter), prompted the anticipated next NUT release
to be semver bumped to 2.8.x (x=0).
On Fri, Mar 11, 2022, 19:39 Jim Klimov
FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of
`PRIMARY` alias to `MASTER` on protocol side, hopefully completing the
puzzle for issue #840.
Reviews and testing would be welcome :)
On Sun, Mar 14, 2021, 00:34 Jim Klimov wrote:
> Thanks again for all the suggestions.
That is odd, I wonder if stdout/stderr get processed differently with debug
on or off, and/or daemon/foregrounding involved.
Is this with a packaged NUT 2.7.4 or with a recent (custom?) build from the
master branch? Last month PRs were merged to separate the debugging in
daemons from deciding to
Getting a bit lost here. Why telnetd and port 23?
The original suggestion was IIRC to
telnet 192.168.1.235 3493
from .236 and vive-versa to see if the upsd port (3493) is reachabl - so if
clients on one Pi can see devices served by (connected to) the other.
Am I missing sone context?
Jim
I think yes, so far it is mostly trial and error; we have yet to see a
"scientific" body of work explaining what fares better when (OSes;
platforms - cpu, virt, powersaving; libusb versions; devices from PC side,
usb hubs along the way, usb-serial converters if any, ...), or at least
statistics,
So just to clarify - the faulty system uses the older packaged NUT (in
Linux) and the newer build of master (in FreeBSD) works better?
Does the newer one also use libusb-1.0 dependency (vs. 0.1 likely for
packaged one), is the custom build that new? It may be that some transport
deficiencies were
Hello all,
Somewhat in relation to FOSDEM as a nice point on the calendar, and largely
to address the lags we've had with publication of HCL and DDL information,
and also as a side project of preparing for a new release (that should
better list the currently known compatible hardware), the NUT
I agree this is a very weird situation now... there is effectively a bounty
with a prize, to "just improve" an already existing driver with vendor
docs/specs and other cooperation, and nobody steps up for a month :\
Possibly, people experienced with Qx drivers are all not online lately for
Just to clarify: I don't think there is a NUT driver that would consider a
computer's local battery as an UPS - probably no-one came around to write
one, and probably that would be very much OS-dependent (more than HW
dependent).
The laptop should be okay as a NUT client (for external NUT
A small heads-up: the DC/Networking migration (impacting NUT CI farm) took
longer than anticipated, but should be completed today. So the earlier
postponed merges of several large waiting PRs (several layers of
libusb-1.0* iterations and several device supports) should continue this
week.
Jim
>> code thinks it is 3k'th iteration over 2.7.4 since it is not marked as
>> 2.7.5 yet in configure.ac.
>>
>> Jim
>>
>>
>> On Mon, Dec 27, 2021, 11:00 Yogesh Bhanu wrote:
>>
>>> Hi Jim,
>>>
>>> I was able to test it on Arch
I suppose you could bump debugging in the NUT driver (not sure how you'd do
that with docker - maybe by tweaking the systemd unit ExecStart for it?)
and get a printout of the bytes it receives on the wire.
@nbriggs might help decipher those, possibly finding errors that would need
workarounds...
I've made a centos7 container on the farm today and updated the docs to
reflect the nuances. The libusb* branches seem to be building ok there
(with some warnings for system headers).
Do I get it right that there is no libi2c-devel (smbus.h and userland
i2c-dev.h) in the distro?
Jim
On Sun,
Small notice: people willing to test have suddenly got a couple more days
before I merge these libusb* branches and other large pending PRs.
FossHost (who provide VMs for the NUT CI farm) are currently migrating them
to another datacenter by 29th evening, and we'd be changing networking
setup
.4.r3891.gea87c8c7.
>
> Good Luck and a Happy new year.
>
> Cheers,
>
> Yogi
>
> On Sun, Dec 26, 2021 at 10:51 AM Jim Klimov via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Reminder: I plan to merge
>> https://github.com/networkupstoo
Great news, and thanks for stepping up to help with the packages!
I think the NUT CI farm should try i2c on debian and derivatives, so gotta
check what it dislikes about EL7. This branch did bump the default
--enable-warnings=medium level since it was "solved" on all of the many
tested systems,
Good question. "No" actually; this testing session is intended for local
builds against various versions of whatever (generations of libusb in
particular) a system has (some OSes serve both generations and can try
several builds). Many target OSes have no support for deb or rpm and are
not linux
Reminder: I plan to merge
https://github.com/networkupstools/nut/tree/fightwarn-libusb-1.0+0.1 as
"libusb-1.0+0.1" branch and as master after that, early next week.
If anyone has tested this codebase against hardware, or needs a few more
days to do so, please let me know here or in issue #300.
Hello fellow NUTs :)
It seems the magic of the season might just help us finish some long
story arcs and tie up loose ends... oh, wait, that is wording about other
"seasons" ;)
In our case, the "fightwarn" effort is reaching a major milestone to
finally pass the builds with "medium" level of
Not sure... could it be a sensors or firmware issue with the UPS? Or a
different tech of battery misinterpreted by the device? (e.g. when one
replaced a lead-acid battery with LiIon hack).
Out of interest, is it possible for you to swap those batteries in your two
UPSes to see if the other one
Given how driver says it has version 2.7.2, I have doubts about it being
the "latest version" (latest official release 2.7.4 is about 5 years old
now, cleaning up codebase for 2.7.5).
Among things recently fixed in master branch, "Invalid mibs" may have meant
no response to queries for OID -
Hello, and thanks for asking :)
For NUT currently, website refresh is a manual process. There is a
`Makefile` driven automation for that now, but so far humans look over it
and tweak because not always not everything works well to make it a github
or similar CI action.
Historically the NUT
FWIW, posted a couple of updates to the FAQ:
* https://github.com/networkupstools/nut/pull/1196 : docs/FAQ.txt: update
for use-cases of dummy-ups in relay mode
* https://github.com/networkupstools/nut/pull/1197 : docs/FAQ.txt: update
for interactions via github (issues, PRs, ...)
Comments welcome
Glad to help! I hope to take a look at the FAQ sources then.
On Fri, Nov 19, 2021, 17:02 K.C. Tessarek wrote:
> Hello Jim,
>
> On 2021-11-19 02:32, Jim Klimov wrote:
> > it seems like the use-case for dummy-ups driver in relay mode. The driver
> > instance on server X would act as a client to a
The "serial" config fields are for serial numbers, and I'd expect they are
what helps NUT identify your devices.
Some value of "port" is required; maybe it could be the "/dev/apc-X"
instead of "auto".
Jim
On Mon, Nov 22, 2021, 11:04 Jarrod Coombes via Nut-upsuser <
Great to see you have solved this!
Just for posterity: normally NUT server (upsd) won't start without any
devices configured. In master branch, an ALLOW_NO_DEVICE patch was added
some time ago to let upsd run always. So that should be in 2.7.5 eventually.
As part of that context, a service
Hello,
it seems like the use-case for dummy-ups driver in relay mode. The driver
instance on server X would act as a client to a particular device from NUT
server on the NAS, and republish the data points as its own.
It is also a useful setup for networked UPSes, which often can handle only
a
Hello world,
As posted at
https://github.com/networkupstools/nut/issues/300#issuecomment-969385505
and https://github.com/networkupstools/nut/issues/300#issuecomment-970243340
in greater detail, during the past weekend I have updated the "libusb-1.0"
and "libusb-1.0+0.1" branches in NUT
Hello,
I can at least address part of your question -- NUT per se is not limited
to monitoring one device per system. Each driver runs as a separate
process, using a separate device node to talk to USB hardware.
Can't vouch however for other variables in the equation, such as system
drivers,
Thanks for the update. Technically, they could both be dirs or separate
tmpfs mountpoints (to facilitate cleanup during reboot), but then various
software would have to be careful about using exact paths and not expecting
two entry points to same content.
Oh all those lazy people, where do they
Thanks for the test...
Got a few ideas:
1) Can you check with snmpwalk that the UPS does serve an IETF MIB for
power devices at .1.3.6.1.2.1.33.1.1.2.0? As David suggested in the thread
on SpiceWorks site, might also play with authpriv and noauthnopriv
settings.
snmpwalk -v 3 -u youruser -l
Note, you linked to latest tagged release (some 5 years ago, we are still
finishing some clean-ups for cutting a 2.7.5 release), same as (or baseline
for) what distros package.
The fix you want is (expected to be) on master branch head.
On Fri, Oct 8, 2021, 23:06 Nathan Dehnel via Nut-upsuser <
gt; On Tue, 24 Aug 2021, Arnaud Quette wrote:
>
> > Le ven. 20 août 2021 à 17:38, Roger Price a
> écrit :
> > On Fri, 20 Aug 2021, Jim Klimov via Nut-upsuser wrote:
> >
> > > It is a bit unclear what "or otherwise and Combined date and time
&g
Dittoing what I wrote in PR comments:
It is a bit unclear what "or otherwise and Combined date and time
representations" means. An example of ISO 8601 date representation (one of
many offered by the standard) "or otherwise"? Which combined date and time
would we take - e.g. MMDDTHHMMSSZ
> What files would make the most sense to check?
I'd say the killpower flag file sounds most suspicious for this role.
In some distros it may be in /etc and there was an init-script to
delete it early in boot.
Regarding the "pile of ASNs", I wonder if David could (get someone to)
produce a
Wondering further: Could it be the UPS itself?
Say, something among the test commands tells it to power off after a
timeout or when load drops, and UPS announces back the FSD for its load to
hurry up powering off, so a newly started NUT forwards that to upsmon...
Might test that by booting the
Cheers all,
I am not one to spam with links too often, but when I came across one
blog praising our project and outlining a modern setup with scripted email
notifications, I just could not resist :)
Good proposal, makes sense.
Sorry for slow replies, I'm now largely offline for a few weeks coming.
Jim
On Thu, Aug 12, 2021, 10:55 Roger Price wrote:
> On Thu, 12 Aug 2021, Arnaud Quette via Nut-upsuser wrote:
> > following a 10 days period after my above announcement, I've considered
> the
Hello fellow NUT users and contributors!
A lot has happened during the past months, culminating with last Friday of
July (Sysadmins' Day) as a reasonable moment to mark a milestone. Sorry,
not yet NUT 2.7.5, but with CI make-over to help it happen.
As some may know, we were using the public
Sounds reasonable to me, and hopefully might be aliased in a
legacy-compatible manner (client asks with new command, if rejected try
old; accept both words on server side) so it could happen in current master.
Note that similar protocol changes e.g. for master vs primary were just
planned as a
Sounds correct to me too, after browsing the code a bit recently when I was
adding the new names for old concepts.
As for login the word, here a client (upsmon) logs into the server (upsd)
to be counted and informed about FSD due to a particular UPS going
critical, if I got that correctly.
Actually there was some interest expressed lately about NUT on Windows from
various requests, so I hope someone in the community would have time and
resources to look into that, but I have no gauge currently on how different
variants behave or were built at all. Note that the latest
Thanks for the details, they do help to get the picture clearer :)
Regarding `delay “2” until the end of “1”` my first shot would likely be
scripting as suggested in first reply. Since I've mostly dealt with shell
scripts (and enabled SSH on ESXi) in my past, I can only elaborate on that
:)
Hello,
Looking at logged NUT issue discussions like
https://github.com/networkupstools/nut/issues/475,
https://github.com/networkupstools/nut/issues/483 and
https://github.com/networkupstools/nut/issues/646 I see people did have
success with models named similar to yours. So generally it should
Just in case: there have been some mistakes in NUT codebase for SNMPv3 (or
rather AES) support found and fixed during the past year, so the errors
could be already in a 2.7.4 release (did not check for that). Do you have a
chance to build current master branch from github and see if it works
Sorry for the late reply, added the alternate question wording to FAQ.txt
in NUT sources, it should eventually get to the website when we regenerate
that.
On Mon, May 10, 2021 at 3:09 PM graeme vetterlein <
graeme.nutu...@vetterlein.com> wrote:
> My question was answered by the FAQ (so kudos
Hello all,
Looking at NUT pull request (PR) history on GitHub, I see that we have
had a non-trivial number of stalled driver contributions sharing a prominent
similarity: proposed names for some of the variables did not fit into the
list
defined at
Hi all,
In the comments for https://github.com/networkupstools/nut/pull/638/ adding
support for "hunnox" subdriver I saw somebody report that the branch also
supported their Powercool branded device. I am brushing that submission
into shape to merge it, and for that matter also plan to merge the
I took a look at https://github.com/dmacias72/NUT-unRAID/ plugin source
(not sure it is the one you have, just the first recent plugin from
googling).
Unfortunately it does not seem to reference actual NUT source well, nor a
plugin version, but just hoards several timestamped tarballs with
I believe nutdrv_atcl_usb is orthogonal to nutdrv_qx "fuji" subdriver. They
both handle devices using an "ATCL" USB chip which does not have a
registered vendorId/productId, but that is where similarity stops.
Different UPS vendors implemented different protocols and abilities using
that chip as a
and (some) "sheep" in this context, that might make intuitive sense.
Happy holidays and thanks for voting,
Jim Klimov
On Sun, Mar 21, 2021, 19:29 Dan Langille wrote:
> Thank you. I think you've handled this well.
>
> On Sun, Mar 21, 2021, at 2:01 PM, Jim Klimov via Nut-upsuser
So, for the past couple of days the SurveyMonkey results are not changing,
with 13 replies overall. Should we wait for more or everyone passionate
enough has already spoken? In practice I'd likely follow up on a weekend
anyway, but... the weekend is coming! :)
Currently we have a clear leader
Thanks again for all the suggestions.
For now I've prepared draft PRs, mostly to map out where the changes are
needed - based on my earlier work with the originally proposed terminology.
Now that we know where to change it, should not be too great a hassle to
replace again by some other choice...
Thank you for the suggestions, keep them coming :)
To me, I think I considered pub-sub but it did not quite fit - gotta
refresh my memory by code re-reading (or expert comments) - I found I'm
vague now on who hits the big red button to shout that a particular power
source device got critical -
One solution can be a "dummy-ups" driver in proxy mode (and an upsd)
running on Firewall1 and so republishing data from a real device handled by
existing nut-server to a NUT client on Firewall2.
Note this can suffer from some lags compared to a real connection, but e.g.
a proxy like this allows
201 - 287 of 287 matches
Mail list logo
