[Nut-upsdev] NUT driver scheduler

[Jonathan Dion]

Hello Roberto

On 7/26/06, Arnaud Quette <aquette.dev at gmail.com> wrote:
>
> Hi Roberto,
>
> please keep the list cc'ed has the below things can be interesting to
> others...
>
> 2006/7/25, Roberto - Engenharia - Microsol < roberto at microsol.com.br>:
> >
> > Hi Arnaud.
> >
> > My question was just to know if  had some another suggestion beyond
> > creating
> > a new file at conf/ dir to store "last test date". Just to listen
> > suggestions, no more. ;-)
>
>
> ok, I wasn't sure.
> for the moment, there is no internal mechanism to allow data persistance.
> But there is a sub project underway to deal with configuration files
> (formalism and accessors, check there: http://opensource.mgeups.com/projects/nut-config.htm
> ). And part of this is the variables settings in config files (
> https://alioth.debian.org/pm/?group_id=30602).
> That answers to 1 point of your need: retrieving a driver parameter at
> driver init.
> But not yet to the "store this data somewhere"... Though the best place is
> to store it in the driver's subjection, ie in ups.conf:
> [myups]
> ...
> battsched = ...
>
> For the moment, there are access rights problems that avoid driver to
> write in the config files.
>
> @Jonathan: do you have an idea to address this?
>

Yes, I have.
The new configuration format I'm working on will easilly enable to do this.
The  unified tree for data and config has a notion of access rights, as you
said. One of this rights is all_rw, that is to say that all nut user can
read and write it.

As I see it, you'll have to add the battsched value in the configuration
file with this right (manually or via libupsconfig)(because simple nut user
don't have the rights to add value in the tree) and then a client would be
able to ask upsd to modify the battsched value (nammed something like
nut.ups.myups.battery.sched I think). upsd will modify the value, and will
answer any request about its value. If you make another test, just ask upsd
to write the new value in this variable

When upsd will shutdown, it will save the configuration part of the tree in
the configuration files, including this value, so when upsd will restart,
the good value will be restored, inssuring its remaining.

For the moment, upsd don't have this unified tree and what I said is
impossible. You need to insure yourself the remaining of such a data. But it
will become possible as soon as the new upsd, using the unified tree, is
developed.

I'm writing a file text exposing all my ideas about the subject, and about
security issues it imply and so on. I'll put it on the list as soon as I
finish it.

NUT project is improving, new functionnalities will be available. Just let
it a little time.

8<------ sniping the last part.

Cheer,

Jonathan Dion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20060726/183fe92c/attachment.html