search for: nutconf

Hello everybody, so, here's the summary of my progress (note that it also includes a few items to discuss, so I'm cc-ing this to nut-upsdev as well). I. The planning: 1/ libnutconf: The core (i.e. config. classes and their (de)serialisers) is coded, UT in progress. Signalisation shall follow; I have a couple of practical thoughts & comments to this, see below. In general, I'd like to have libnutconf core UT-ed this week and the signal handling coded at the very least....

...fig. files (or possibly other config. resources). The vision is that using a set of such high-level libraries, NUT will become an open framework (or platform, if you prefer) for further development of more complex power control solutions. (I hope I've formulated that, well.) Now, the (C++) libnutconf library design and development was started by Emilien K. some months ago; during the last month or so, I continued on the implementation, culminating these days by announcing that the core is basically coded. The library now contains an I/O layer, allowing synchronous access to configuration data...

...(may be more simple to use and consistent with some other software setup), although I don't think it was an issue ever brought up in discussions before. 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. 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 n...

...(may be more simple to use and consistent with some other software setup), although I don't think it was an issue ever brought up in discussions before. 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. 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 n...

...ht 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 wo...

...ht 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 wo...

Cheers all, With PR https://github.com/networkupstools/nut/pull/2425 I've paid some attention to the tools we have to help external consumers edit NUT configuration files. These go back to issues like https://github.com/networkupstools/nut/issue/2294 (originally posted for "nutconf" improvement, and now with some more TODO's linked to it) and https://github.com/networkupstools/nut/issue/657 about known unfinished business with augeas as of quite a while ago. My investigation with the latter found that the parser seems to work for simple wordings, which frankly cov...

...of documented recommendations on who should be able to read what, especially if you run parts of NUT all as different role accounts. Generally none of the daemons should be able to write there, so a compromised program can not change configs. ** There is a place for additional tools like augeas and nutconf whose job is to maintain configs, but they are not daemons and their permissions are of whoever called them - e.g. root. Defaults cater to locations that are present or can be made on a majority of systems, and are intended to be tweaked and tuned to specific distro's tastes. Nothing should pr...

I'm following up on a request from a pkgsrc user to improve the package, and that's leading me to thinking part of the issues are in nut, vs the package. Setting aside daemons that run as root vs not, there are two kinds of directories, using the BSD hier(7) scheme: /var/db/nut: - state files intended to persist across reboots /var/run/nut: - pidfiles - (probably)

...me git python perl curl make autoconf automake libltdl-dev libtool valgrind cppcheck pkg-config gcc g++ clan libtool-bin libxml2-utils xsltproc asciidoc libusb-1.0-0-dev libusb-dev libsystemd-dev python3-systemd ./autogen.sh ./configure ./configure --enable-dependency-tracking --enable-strip --with-nutconf --with-usb --with-nut-monitor --with-nut-scanner --with-libsystemd --with-doc --enable-strip --with-ssl=NO --with-openssl=NO --with-user=ups --with-group=nut [Do I also need: "--enable-inplace-runtime"?] make DESTDIR=/tmp/package install make DESTDIR=/tmp/package install-conf [Not sure if...

...gt; > 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 &g...

...gt; > 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 &g...