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,

This is the first time that i had to use E-mail like forums i'm only hitting reply to mail NOT replay to all mails THIS IS upssched.conf # This file is auto-generated by openmediavault (https://www.openmediavault.org) # WARNING: Do not edit this file, your changes will get lost. CMDSCRIPT /usr/bin/upssched-cmd PIPEFN /run/nut/upssched.pipe LOCKFN /run/nut/upssched.lock AT COMMOK * EXECUTE

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

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,

The trip to FOSDEM 2025 was great fun, with many interactions, useful lectures and fruitful conversations. It was insightful to randomly meet at least one person using the project, a few eager to use and asking question, and sadly quite a few who did not recognize not only "NUT" but also "UPS" key words. Face-to-face talks to maintainers of Debian, OpenIndiana, Tribblix and

The trip to FOSDEM 2025 was great fun, with many interactions, useful lectures and fruitful conversations. It was insightful to randomly meet at least one person using the project, a few eager to use and asking question, and sadly quite a few who did not recognize not only "NUT" but also "UPS" key words. Face-to-face talks to maintainers of Debian, OpenIndiana, Tribblix and

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

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

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