nut
nut copied to clipboard
networkupstools
Windows port
Complete port of NUT to MS Windows.
Alioth feature request: https://alioth.debian.org/tracker/index.php?func=detail&aid=302177&group_id=30602&atid=411545
- the port is almost done, and available on branch windows_port: https://github.com/networkupstools/nut/tree/windows_port
- MSI packages are already available, though not 100 % mature http://www.networkupstools.org/download.html#_binary_packages
- a cross-compilation effort is underway, from Linux using mingw-w64
- cross-packaging (MSI) should also be addressed: http://freecode.com/projects/msitools
- Need team review (@aquette at least, @clepple, @balooloo and others appreciated).
I did a regression check on whether the code compiles for non-Windows systems, and it looks like there is an issue with this trunk merge to 2.6.5: 6e51ff2bd
The code still compiles, but the documentation does not: http://buildbot.networkupstools.org/public/nut/builders/Ubuntu-natty-x86/builds/322/steps/compile/logs/stdio
It looks like it is related to the change to the formatting of the INSTALL file, but it is possible that another related change did not get pulled in from the trunk.
I think the INSTALL file was overwritten by mistake during that merge with the standard GNU installation instructions:
http://trac.networkupstools.org/projects/nut/browser/branches/windows_port/INSTALL?rev=3714 versus http://trac.networkupstools.org/projects/nut/browser/trunk/INSTALL?rev=3857
I'm going to copy over the INSTALL from master, and apply this commit: http://trac.networkupstools.org/projects/nut/changeset/2958/ (but @bohe-eaton feel free to update the instructions if they are out of date)
Hello!
A few weeks ago I have successfully built NUT in MinGW environment using Windows-v2.6.5-7 branch (you may find a manual I have posted to nut-upsdev mailing list).
I would like to help with Windows port development. I have examined the source code of several components (upsd, upsmon, nut) and I have got some ideas. I will be happy to share them with NUT team.
MAINTAINER UPDATE: Links to those mail posts in the archive:
- https://alioth-lists.debian.net/pipermail/nut-upsdev/2016-April/007171.html - [Nut-upsdev] How to build NUT Windows Port
- https://alioth-lists.debian.net/pipermail/nut-upsdev/2016-April/007172.html - [Nut-upsdev] NUT Windows port sources review
hi @intrudo , thanks for jumping in. The best for now is probably to present your ideas here and / or to fork a branch of the Windows one and start applying these ideas.
see also ntUPSd - Network UPS Tools Services for Windows (https://github.com/6XGate/ntUPSd) from @6XGate
thx and cheers
Hi @aquette ! Let’s start =)
First of all, I would like to say that I am not going to do something without acceptance of NUT Team (it would be great to coordinate high-level tasks at least). Please, feel free to say "no", if something is out of your vision/roadmap.
I sent a message with my ideas to nut-upsdev list and discussed some points with @clepple already. You may find there more details why I think so. So, here are just short descriptions.
- Produce cross-compiled source code to build *nix, x86 and x64 versions from single sources. Linux environment must be used only.
- Make a software abstraction layer (SAL) to hide all functions’ calls like "system", "syslog", etc. Windows version will have special implementation of them, *nix will translate the calls to standard ones. For example, no one will call "system" directly, but "nut_system" only. "nut_system" will call standard "system" function for *nix and "CreateProcess" for Windows. As result of such abstraction, we will have common program flow in source code without platform specific conditions like #ifdef.
- Improve logging for Windows version and use file-based log instead of Windows Event Log. Moreover, standard syslog should be supported in Windows version too (to have equal behavior with *nix version).
- Eliminate NUT service in Windows version (it provides "syslogd" and "initd" functions). Implement every daemons (upsmon, upsd) as Windows services. Here is open question what to do with drivers; it looks quite redundant to port every driver as service. I think to create additional Windows service (or extend upsdrvctrl program) to control them (start, stop, etc.), so, they can stay as console applications.
Sure, I see many minor tasks, but let us discuss them later.
The one thing I worry is branch. I was going to fork Windows-v2.6.5-7 branch and completing Windows port there. @clepple thinks that Windows-v2.6.5-7 should be rebased before. Unfortunately, I am not GIT expert and I am afraid that there will be many conflicts during rebase. Moreover, I think that my commits will be quite massive. What is the best way to synchronize master branch and my repository? I will be glad to get any hint.
I have looked into sources of ntUPSd project. They are complete different from NUT one, but maybe I will find something useful there.
Thanks!
The best for now is probably to present your ideas here and / or to fork a branch of the Windows one and start applying these ideas.
@aquette for reference, here is the previous nut-upsdev discussion: http://lists.alioth.debian.org/pipermail/nut-upsdev/2016-April/007172.html
Let me know if you have further questions about why I don't think a major Windows development effort should be based on that branch. The architectural changes that @intrudo proposed are probably best done by using Windows-v2.6.5-7 as a guide. For instance, there are a lot of #ifdef WIN32 blocks that will get even messier if 64-bit #ifdefs are needed. Also, a lot of drivers have been added or changed substantially since 2.6.x, and I think it would be best to re-port them using the proposed APIs and coding style.
Well, if you do not mind, I will fork Windows-v2.6.5-7 branch to implement the SAL. After it is completed, we could get back to the question of proper branching and future merge.
Well, if you do not mind, I will fork Windows-v2.6.5-7 branch to implement the SAL. After it is completed, we could get back to the question of proper branching and future merge.
Agreed. For prototyping, I do not mind development on that branch (or a branch of the branch, given that branches are cheap in Git). I just want to make sure that everyone understands that merging (in the Git sense of the word, where two lines of history connect back to each other) any of the old Windows-* branches back into master will be a train wreck due to the leftover translated SVN cruft, plus the rebasing issues. (We cleaned up most of the SVN cruft in master with reposurgeon, and spent a lot of time verifying correctness against old tarballs, but we did not do the same to the Windows branches.)
I think a lot of the Windows-specific files from the branch could be copied over to a new Windows branch that starts from either v2.7.4 or master, though I think that they would change a bit for the proposed reduction of #ifdef WIN32 blocks.
Depending on which library is being used for the windows port, would it not already either include a system and syslog function, or not include either, and thus allow us to write a replacement function also removing the need for different code for each platform.
Adding a user provided doc on "How to build NUT Windows Port": http://lists.alioth.debian.org/pipermail/nut-upsdev/2016-April/007171.html
After a few years' general hiatus on this subect, I tried to revive the changes from Windows-2.6.5-7 branch against current NUT master and came up with https://github.com/networkupstools/nut/tree/Windows-v2.8.0-1 which then got fixed (of accumulated typos and other merge conflicts) into passing builds on Linux (non-regression, testing more with CI farm now) but would need a Windows build env setup to see if the actual ifdef Win32 codebase still works.
The "just for fun" bit turned into half-a-week-long git rebase spree, trying to not distract... fat chance :)
Building the NUT 2.8.0 based branch natively on Windows proved problematic, mainly due to the hassle of sourcing a reliable MinGW environment (there are many variants and packagings, including CygWin and MSYS2) as well as lack of MinGW for Linux on a box I tried. But also because it is much more strict in default compiler settings, and notable differences between the original NUT-for-Windows effort and current codebases over time.
Now I tried to take a step back to and expected-working solution, to build the 2.6.5-based codebase according to its instructions in scripts/Windows/README file, and results are quite promising.
I found that Ubuntu 21.10 does ship a usable mingw environment, so built much of NUT and its dependencies for MinGW in an LXC container and rsync'ed files to a Windows 7 machine to test.
The resulting updated code and instructions are at https://github.com/networkupstools/nut/tree/Windows-v2.6.5-8 branch (specific state that "works for me" is tagged as https://github.com/networkupstools/nut/releases/tag/Windows-v2.6.5-8 now).
Early starts were with 32-bit MinGW (i686) and seemed to compile but I did not test them. Later attempts involved 64-bit target for dependencies (libregex, libusb-1.0 and libusb-0.1-compat for the old codebase, libnetsnmp...) and NUT.
I did successfully test an Eaton-ECO USB UPS as far as seeing its identification; but the state was bogus (OB all the time) and not much more data was exposed. Currently I did not care to test much if that is a NUT 2.6.5 issue (old codebase), or Windows porting issue, or even if the UPS (with no load) was just asleep. Replugging the wall cord did not help at least ;)
This particular deployment began throwing libusb interrupts errors soon after driver init, and the "pollonly" driver option helped avoid that (in hindsight, I'm not sure if the info updates are really happening though, or it was stuck with what it saw at init time).
The nut-scanner succeeded to find the USB UPS, as well as scan the network for a NUT server and report the devices configured on it - so confirming that libltdl magic is also usable. It however relies on suffixed DLL names like libusb-0-1-4 (without the .dll extension) which for now are hardcoded in the WIN32-specific source code section. I suppose installing those libs with standard names (per respective libname string variable) might work and would be more simple then.
The net-snmp sources refused to build a DLL, so it is statically linked into nut-scanner and snmp-ups drivers. No idea how well it works beyond that, as I have no devices to test against at the moment. In particular, nut-scanner seems to have frozen when scanning even one IP address (-s and -e with same value). Maybe that is about timeouts waiting for reply (should be 30 sec IIRC, so a much longer freeze is strange) or due to "non-LTDL shim" to use the library methods (just assigning our pointers to method names, without lt_dlsym in a WIN32 build).
I did not yet look at the Installer or DriverInstaller directories, just hacked into the build-mingw-nut.sh a few lines to copy a few dependency DLLs (custom built prereqs and winpthread) into the nut_install/bin directory which I rsync'ed to the Windows machine.
FWIW, binaries produced for this experiment are archived at https://github.com/networkupstools/nut/releases/download/Windows-v2.6.5-8/nut_install-2.6.5-8-gd1b8d14d1.zip
Funnily enough I starred and watched this repo yesterday while doing my own NUT on Windows testing, after discovering the latest msi installer wouldn't properly finish installation, I looked it up and came across similar reports, and a workarounds here and here
I actually did manage to get it working in standalone mode, and I did also have libusb interrupt errors for which I enabled pollonly to dismiss them given that information was still being updated, and yes I did confirm that the UPS state was being updated, at least as far as usage and estimated time on battery goes (edit: I forgot the input/output voltage and frequency also updated within the +/-1 variance), I had pollinterval at 1 and pollfreq as the default 30.
I did end up scrapping NUT and going back to the default MGE UPS driver as, aside from the issues, NUT was lacking a few features I was hoping to utilize, specifically performing shutdown based on battery percentage and/or estimated runtime (whichever happens to be lower) but apparently my UPS (Eaton 5E 2000i USB) does not support those features ("low" stats)? So it would probably require a client to consume the data produced by NUT to offer those features.
Ideally the Windows NUT driver would also be identified as a battery, just like the default MGE driver, to offer at least some of those features, using the default driver and the Windows battery settings in "power options" (performance profiles) I've set different battery percentage thresholds, performance throttling and more, however it still lacks the option to shutdown/hibernate based on runtime (which given usage, might be only a couple of minutes), which would be useful when leaving the system in some high-usage state such as 3D rendering overnight. Perhaps this could be implemented with a "dummy" driver that consumes information from UPS(es) and aggregates percentage/runtime, it could perform similar assumptions to DEADTIME among other things such as maintaining last known and estimating battery percentage loss to trigger Windows battery power options such as performance throttling, low/critical thresholds warning prompts prior to shutting down.
My reason for considering NUT on Windows is because I'm currently using it on an unRaid system with a similar UPS (Eaton 5E 1500i USB), for which the plugin does allow the system to shutdown based on estimated runtime remaining, and because the default MGE driver has a pretty annoying issue, it randomly disconnects momentarily for a second or two at random periods (usually no more than twice a day, and as little as once every few days), while the disconnection issue alone is not a huge problem, the events that it produces do, as Windows triggers multiple events when it stops recognizing a battery and recognizes one again, which leads to a brief (roughly 2-3 seconds) system hang/unresponsiveness. Since I'm not sure whether I can trust my NUT configuration to shut down my system in the event of a power loss, I was not able to test whether the UPS disconnects with the libusb/NUT driver (I had a stale data issue with unRaid at the default pollinterval of 2, but I came across a suggestion to change it to 1 and it's been fine for over a week now, so I'd expect no less on Windows either).
Thanks, lots of good ideas here though not sure who and when would follow up on these :)
Representing NUT in same way as a laptop battery for different systems (dbus, hal, windows, linux, mac....) does sound reasonable and did for years :) but for some reason nobody published such PRs. Given NUT's layered architecture, and the fact that the UPS may be connected elsewhere, it might be a client similar to upsmon hooking deep into a system. Especially if we get to consider multiple PSUs fed by numerous UPSes in general redundant case; not sure if OS battery facilities even have a concept for that across the board.
Finally note that existing NUT for Windows packages are based on 2.6.5 release codebase (and some later merges from trunk development) so evolution and bug fixes there fizzled out roughly in 2013. Lack of features and data points may just be due to that. I'm (slowly... but knowing now that the machinery is viable is a big boon to enthusiasm) struggling to get modern code to just build in similar manner, let alone function and be tested/testable :)
Regarding hibernation, power profile switching, etc. you might consider setting up some batch/powershell scripts as Task Scheduler event handlers, and then use upsmon NOTIFYCMD or eventually SHUTDOWNCMD to pull their strings. Not sure if upssched works on Windows but it might be useful for complicated logic too.
I do have SHUTDOWNCMD configured to a hibernation command, the issue is that I have absolutely no idea when it would trigger, since my UPS does not report and does not support configuring "low" battery percentage or runtime remaining, I don't know when NUT would decide to shut down the system, and when my system is high usage (100% GPU utilization + high CPU utilization, typically when rendering overnight or gaming) the UPS itself estimates up to 3 minutes of runtime as opposed to the lightweight/idle estimates of 15 to 25 minutes (based on HWiNFO64 readings from the MGE UPS driver), that's a problem because I have experienced periods where hibernation actually takes a few minutes to finalize, so unless the system knows to throttle and hibernate (nearly immediately in the high usage scenarios) there's potential for the UPS to run out of battery before the system can shut down in time, and that's especially true if NUT would trigger the shutdown command late (ex: 10~20% battery remaining), that's what I meant when I previously said "I'm not sure whether I can trust my NUT configuration", because I have no idea when/if it will send the shutdown command, or what it would do in the meantime before the shutdown command while the system is on battery.
FWIW, just now got the 2.8.0-based variant to build with mingw on Ubuntu! Pushed the branch so CI rolls it around other platforms and targets.
If anyone wants to give it a spin, routine should be like this:
:; git clone -b Windows-v2.8.0-1 https://github.com/networkupstools/nut nut-win
:; cd nut-win
:; ./autogen.sh && (cd scripts/Windows/ && ./bu*sh all64)
Note that prerequisites like libusb may be needed - requiring you build them for mingw - for a NUT build to be useful (more details in scripts/Windows/README). Resulting installed proto-tree would be in scripts/Windows/nut_install/ -- rsync that to a Windows box and should be sufficient (was with 2.6.5 based builds).
By now the 2.8.0-based NUT for Windows branch seems on par with its 2.6.5-based "origin" in terms of what and how I can build, and how it (mis-)behaves in a greenhouse build and operational environment - e.g. usbhid-ups and nut-scanner now see a connected device again, yay! but the driver crashes in cleanup routine after ctrl+c.
Not quite production ready for general availability, but still - a solid foundation again to research, tinker and improve (able hands welcome; I won't progress on it much further - especially not soon), so really a big achievement.
With recent push, build also works in MSYS2 (which also ships mingw) straight on Windows. Slooowly, but it passes, and lets see and fix a different set of bugs :) Notably, a different set of dependencies is easily available, e.g. "out of the box" can build for neon (xml), modbus and cgi but not for snmp.
The cat is off to vacations, mice can play :)
Announced on the mailing lists as:
- https://alioth-lists.debian.net/pipermail/nut-upsdev/2022-June/007741.html
- https://alioth-lists.debian.net/pipermail/nut-upsuser/2022-June/012870.html
@clepple : in discussions here and elsewhere a few years ago you mentioned that existing Windows branch should not be merged to master, but should rather be the basis/inspiration for separate work to provide NUT for Windows. The mailing-list discussion unfortunately fizzled, but it did provide a lot of interesting ideas and practical info (for build environment preparation).
My recent experiments were in fact started from that older branch, updating and fixing it for modern NUT codebase as well as CI. Do you still think it should not be merged "as is" (when CI works for all platforms, there is some effort needed still) so people can tinker with current NUT master on Windows to make it actually usable and packageable?
@jimklimov I admit I haven't followed your recent Windows work, but if you are truly proposing a merge of the old SVN-era Windows branch with no rebasing to remove all of the SVN "merge" issues (since SVN did not support actual merges at the time, we had a lot of regressions introduced on that branch by improper SVN usage), then I still think merging is a bad idea. We spent a lot of time carefully translating SVN trunk to Git master via reposurgeon, but that was production code, and many people have kicked the tires on Git master (and 2.7.x) since then. The same cannot be said for the original SVN Windows branch.
If I were more actively involved with NUT development these days, I would really not want to sift through all of the Windows experiments when triaging non-Windows bugs. It sounds like you are familiar enough with both the current POSIX code and the Windows code, so if you are up to the task, I don't want to get in your way. But this is another round of changes that makes me less confident in looking over PRs and approving them (at least without testing on real hardware, which I really don't have time to do).
Well, as far as codebase text merges go, I did sift through the changes keeping in mind the past two years of "fightwarn" and other improvements, so most of those Windows-related commits made some sense to me and/or were adapted to be "sort of rebased" (old metadata, somewhat new content after conflict resolution). Technically the effort was a cherry-pick of a few hundred commits over recent post-2.8.0 master codebase, I think (I had several starts addressing it all the while changing workstations, so not sure OTOH which attempt survived) :)
One thing of note, the discussion from 2016 mentioned that there can be a benefit to managing daemons and drivers as separate Windows services; the Windows-branch codebase did add and later deprecate such ability along the way. I am not sure about the reasons, but at least there is "existing" source code in history to revive, if someone wants to address that.
I hope that those compiler warnings and CI running many scenarios (and lots of iterations until all is green) would give a measure of confidence about non-regression at least for currently well-supported targets, and would allow the Windows related effort to not bit-rot again. Hopefully someone would walk the next mile to also shape it into a prime-time product.
Thinking of it, just comparing the current state of two Git branch tips to ignore blocks hidden by WIN32 macro, so looking at differences in POSIX code (if any) should also help weed out bugs and PR the improvements, if any, or confirm that there are no expected differences for Unix/Linux behavior.
With recent PRs merged, the Windows branch now includes master (and exceeds with almost no changes to POSIX part of the codebase), and beside our usual NUT CI and CircleCI multi-platform testing, it builds every commit with semi-natively (Windows MSYS2) on AppVeyor and makes a tarball so people can try it out:
- https://ci.appveyor.com/project/nut-travis/nut
- FYI: To experiment with recent NUT codebase built (not packaged or otherwise integrated so far) for Windows you can try archives from https://ci.appveyor.com/project/nut-travis/nut/build/artifacts
Note that all envs (MSYS2, linux+mingw 32-bit and 64-bit) are all differently capable in terms of 3rd party deps provided. But at least it feels great to have explored so many viable options! ;)
As noted in the https://github.com/orgs/networkupstools/projects/2/views/1 project, there are still quite a few caveats and commented-away incomplete features which make Windows builds not "prime-time" for each and every use, but at least as built, it should already cover many of the typical bases like USB, ModBus, (maybe less so for Serial ports), NetXML and SNMP... Volunteers to code the missing bits and especially to test against real HW are quite needed at this point.
Posted the PR above (#1611) which I hope will take care of merging the codebases, so existing NUT for Windows effort becomes part of "master" branch. This does not mean the end of the journey, as there are at least the existing disabled and questionable parts of code (see project referenced above) to take care of, for the added platform to be "on par" with the POSIX builds feature-wise, and packaging which was not revived yet but is something valuable to end-users on that platform. And the multitude of supported build environments currently gives a choice of "either these or those" third-party libraries and so NUT capabilities, something to level out as well.
- FYI: To experiment with recent NUT codebase built (not packaged or otherwise integrated so far) for Windows you can try archives from https://ci.appveyor.com/project/nut-travis/nut/build/artifacts
Just wondering with these builds, if set up as a NUT client, what is meant to be run for it to monitor the server in the background?
On Linux when the NUT packages are installed it auto starts a upsmon background process that keeps track of the server, and from my brief check of the old (~2013) official Windows installer it sets up a background service that presumably does the same thing.
I notice there's a upsmon binary in the sbin directory that picks up on the config files in etc but unsure if the idea is that is meant to be left open in a CMD window or what the proper binary to leave open would actually be (if there isn't any binary that can be opened as a background process).
Edit: tested a forced shutdown via the server and indeed the upsmon window left open detected it and shutdown the system (had previously edited the SHUTDOWNCMD to be the Windows equivalent of shutdown /s).
Hopefully in the future there could be a version that could be started as a window-less background process (or if there's a way to do this currently I'd be interested).
Thanks for the confirmation it works at least so :)
Looking at the scripts/Windows/Installer sources (should be of same provenance as what made the 2013 packages), there seems to be StartService.bat and StopService.bat mentioned all over the place in the XML file. Haven't made much more sense of it yet, and nobody else contributed so far, so the pretty installation in Windows is in limbo :\
Those files just go net start "Network UPS Tools" or net stop "Network UPS Tools" so apparently the service is registered somewhere along the way :)
There seems to be a services/Windows/wininit.c which wraps the starting of daemons and installation of the service in the later iterations. As I was importing the old code cherry-pick by cherry-pick, similar abilities appeared and disappeared in daemons themselves - so apparently predecessors on that fork deemed it better at some time to wrap a single unit for "everything NUT" rather than separately upsd (+ drivers?) and upsmon.
According to the Makefile.am there, this program should get built as nut.exe. And also nearby, a halt.c => halt.exe to drive the poweroff via Windows API.
With the above in mind, in the XML file for Windows packaging I found this block:
<!-- To Add Service in Service Table-->
<!--Register NUT Service -->
<CustomAction Id="RegisterNUTService" FileKey="nut.exe" ExeCommand="-I" Execute="deferred" Return="asyncNoWait" HideTarget="no" Impersonate="no" />
<!--Stop Service-->
<CustomAction Id="StopService" FileKey="StopService.bat" ExeCommand="" Execute="deferred" Return="asyncNoWait" HideTarget="no" Impersonate="no" />
<!--UnRegister NUT Service -->
<CustomAction Id="DeRegisterNUTService" FileKey="nut.exe" ExeCommand="-U" Execute="deferred" Return="asyncNoWait" HideTarget="no" Impersonate="no" />
and the SVCNAME mentioned in wininit.c (aka "Network UPS Tools" mentioned in those batch files) is tucked away in common.h so was not an easy git grep hit.
Thanks for the confirmation it works at least so :)
:) Tbh I'm not familiar with it all know how I'd be able to modify the source but I did try nut.exe -I (seen in the XML above) to see if that would register the service but it produced the error:
OpenSCManager failed (5)
Apart from registered Windows services I know there are some executables that run as UI-less processes. One such is display-switch (a clever pseudo KVM) which when opened by itself just remains open in the background until terminated, but when opened via console window will print out config info.
Though given there are already some code basis for the Windows service approach I suppose that makes more sense to get functional.
OpenSCManager failed (5)
Just in case: did you do it from a "Run as Administrator" sort of CMD session?
Oh wow, I feel silly. Running the console as admin made it successfully install. Nice!
It auto detected my forced shutdown signal from the server and shutdown as expected.
Great to have this native port, since I tried WinNUT-Client first but it failed to detect FSD signals sent from the server and had various disconnects that wouldn't auto re-connect. Thanks for the work you've put into it :+1: