Arjen de Korte ha scritto: > Citeren Marco Chiappero <ma...@absence.it>: > >>> And "centralized" is a very important keyword here; having >>> to modify upssched scripts on dozens of machines when the plan changes >>> is a real PITA. >> I agree, and that's the reason why I said there is a need for a >> director. It takes care about settings and actions, clients should only >> obey and possibly show UPS informations. It's also a metter of role: the >> system managing the UPS is the only one that should decide and control >> who can keep running and for how long, not the server administrator (and >> maybe you're not even the server owner or admin)! >> This should also make the powershare feature easier to implement since >> the computer controlling the UPS knows everything. > > Please elaborate here, because as far as I know we already have this > (the 'upsd' server).
Please read the last mail from Gabor, his idea it's really close to mine. To me clients have to be as "stupid" as possible (requiring almost no configuration) and simply obey to commands issued by the server. This means that clients shutdown configuration has to be done on the machine controlling the UPS(es). This way it is the server (connected to the UPS) that allows someone to use the UPS it owns for the time it considers fine, it is not a client that tells the server how much it wants to stay up (a slave upsmon works this way, right?). Ok, how to achive this? Writing two different programs, client and server, is an idea, but we can think of something more modular: an hardware layer (eg. nutupsdrv), a communication and "action maker"/execution layer, and a decision layer managing shutdown orders. So, on the client side just the second layer is needed, it takes care of speaking with the server (for UPS readings too [1]) and executing shutdown and/or notify commands received by the server. Note that on this side you have to configure just a few settings. On the server side we need all the stack of components, the decision maker on top of the communication and execution layer, in turn on top of the hardware layer. The decision layer reads the configuration file(s) containing shutdown policies for all the machines (or group of machines) it can assume to control, and then, when needed, it passes orders to the lower layer. Again on the server side, the communication and execution layer dispatches informations between the hardware, the "brainless" clients and the "brain" itself. Note that this layer can be the same on both clients and server. Let's suppose we already powered down some clients and power is back, the mean layer (which is on top of the hardware) notify the event to the upper decision layer, this one orders to start an action such as executing script or restoring power on a specific programmable outlet, maybe after some time or when enough charge is reached. If "low battery" level is reached, then we trigger shutdown for everyone is still up. Well, I'm not experienced and maybe it's not a good approach, but I like it. You can think it's better to have clever clients as it is now, but at this moment upsmon is lacking the features already discussed. However, just considerations and comments are welcome. Regards, Marco Chiappero [1] The server can offer some services or information to the clients. _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
