similar to: NUT and sleep/hibernation

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

Windoze in da NUT house! Codebase of the NUT for Windows branch was merged to main codebase, not in the least to avoid bit-rot and need for resynchronisation with merge conflicts that regularly arose as the two branches "just co-existed". More community work is needed to complete some drivers' functionality and MSI package delivery, but for many use-cases it may already "just

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

"Good news, everyone!" With CI builds of the branch now regularly passing on both the multiplatform FOSS NUT CI farm (including linux+mingw cross-builds), and CircleCI with MacOS, and newly on AppVeyor with Windows+MSYS2 (including integration tests with live upsd and some dummy-ups instances), after ironing a few wrinkles I intend to PR and merge it into the main NUT codebase soon,

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 feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

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 feel free to post issues for this project if you think of some more... Jim On Thu, Jun 23, 2022, 23:52

Roger, I just ran a manual test, killing power and see what happens.  I set the Synology “Time before DiskStation goes into Safe mode” to 5 minutes so I didn’t have to wait like an hour until it powered down.  Here is the log: https://hastebin.com/ovuwilufeb.sql Everything appeared to be normal; the servers powered off and the Synology went into safe mode.  Power was then cut to the Synology

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

Hello, and welcome to the NUT community! :) On one hand, it would generally help to read up the documentation about NUT architecture, seeing as it is a crucial part of your systems' uptime and data integrity. On another hand, for this particular use-case: it is quite possible to set up monitoring-only systems which only inform you if some *other* NUT data server has had interesting

fredag 27 oktober 2023 20:07:58 CET skrev Jim Klimov: > Hi, this does sound like a useful idea - although for the principle of > least surprise and for variation in deployments, I'd rather have it as a > (non-default state of a) configuration toggle that can be set via > `upsmon.conf`: whether this particular client exits after processing FSD or > not. The onus for the rest

Hello Jim, That?s a great help for me. You?re a so kind person ~ Our engineer download the branches f17d9f5 as below and repackage it for test. After testing, The Beta NUT works well with ST VID "0x0483", PID "0xA430. Please tell me how to speed up for merging this to formal version. May I have your predict schedule if possible? Thanks.

I?m making some progress I believe? I switched off and switched on the UPS further to the laptop having started the daemon and I?m not getting the same error message which is probably due to the server working in the background still locking the device I think the daemon starts but gets into an infinite loop and doesn?t finish and hand back control. Here are the updated traces I got by

Hi, this does sound like a useful idea - although for the principle of least surprise and for variation in deployments, I'd rather have it as a (non-default state of a) configuration toggle that can be set via `upsmon.conf`: whether this particular client exits after processing FSD or not. The onus for the rest would be on general systems integration - e.g. ensure that init scripts `K*`ill the

On Friday 27 of October 2017, Aki Tuomi wrote: > On 27.10.2017 11:20, Arkadiusz Mi?kiewicz wrote: > > Hi. > > > > What's the approach for securely enabling imap hibernation in case when > > each user uses different uid and gid? > > > > Looks like none and 0666 on hibernation and imap master sockets is the > > only way? > > > > Thanks,

Open-Xchange Security Advisory 2021-01-04 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOP-2009 (Bug ID) Vulnerability type: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences Vulnerable version: 2.2.26-2.3.11.3 Vulnerable component: imap Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.13 Vendor notification: 2020-08-17

Open-Xchange Security Advisory 2021-01-04 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOP-2009 (Bug ID) Vulnerability type: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences Vulnerable version: 2.2.26-2.3.11.3 Vulnerable component: imap Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.13 Vendor notification: 2020-08-17

upsmon.conf on server:  https://pastebin.com/z4CrUTxb nut.conf on server:  https://pastebin.com/540ShZH7 Permissions for /etc/nut:  https://hastebin.com/qecolodapi.diff On the Synology (I didn’t edit any of these files): ups.conf:  https://hastebin.com/dedereqizi.shell upsd.conf:  https://hastebin.com/pupeseweda.css upsd.users:  https://hastebin.com/ocenamecex.cs I don’t think I am able to run

Hi Jim, I was thinking about setting different values for each device , so the first system has higher values and shutdowns?earlier:override.battery.charge.lowoverride.battery.runtime.low Won?t it work ? Best Regards,Strahil Nikolov? On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote: Yeah, I have no lack of imagination about

Hi Jim, I was thinking about setting different values for each device , so the first system has higher values and shutdowns?earlier:override.battery.charge.lowoverride.battery.runtime.low Won?t it work ? Best Regards,Strahil Nikolov? On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote: Yeah, I have no lack of imagination about