<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Author" content="Riccardo Facchetti"> <meta name="GENERATOR" content="Mozilla/4.74 [en] (X11; U; Linux 2.4.3 i586) [Netscape]"> </head> <body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000"> <h2> Multiple UPSes controlled by a single computer</h2> <p><br>First of all when you have multiple upses connected to a computer you have to distinguish between local-powering upses and remote power lines. This is important because the do_events code will do the events only for the local ups. Local ups is a generic concept that works both on the server and on the clients. <p>Let's say that PC1 is connected to UPS1 and UPS2. <p>UPS1 is powering PC1 <br>UPS2 is powering PC2 <p>so <p>UPS1 is local to PC1 <br>UPS2 is local to PC2 <p>local is "who is powering me". This said, the apcupsd will treat hard and net-connected upses in the same way. <p>UPS1 and UPS2 are hard to PC1 <br>UPS2 is net to PC2 <p>But hard and net connections are transparent to the do_actions code so the same do_action is called on <p>PC1 (for UPS1 that is local and hard) <br>PC2 (for UPS2 that is local and net) <p>From this explanation you see that <p>PC1 must know 2 UPSES: UPS1 and UPS2, the config file must describe both UPS1 and UPS2 that are hard. <br>PC2 must know 1 UPS: UPS2, and its config file describe only UPS2 that is net. <p>This raises another matter: net must be like hard because PC2 must know the exact same infos that PC1 knows about UPS2. <br>Another matteris that net must be multi-ups because if you think at this config: <p>PC1: UPS1 (hard, local), UPS2 (hard), UPS3 (hard) <br>PC2: UPS2 (net, local) <br>PC3: UPS3 (net, local) <p>you see that net must be multi-ups. From this, if we are brave enough (and I WANT to be this way .. brave), we can think of this configuration: <p>PC1: UPS1 (hard, local), UPS2 (hard), UPS3 (hard), UPS4 (hard) <br>PC2: UPS2 (net, local) <br>PC3: UPS3 (net, local) <br>PC4: UPS4 (net, local) <br>PC5: UPS1 (net), UPS2 (net), UPS3 (net), UPS4 (net) <p>where PC5 is simply a monitor .. may be on the other side of a firewall where the 4 UPSes can be monitored, 1 hop away from the real machine. This allow us to monitor over the internet in a secure way. PC5, due to the transparency of hard/net connections, knows exactly what PC1 knows and can give any info over the net. In fact PC5 do not have any local ups: it works only as an "apcupsd gateway" of information about the upses. And look .. the difference between hard and net in the config file is: <p>hard: DEVICE /dev/ttyS4 <br>net: DEVICE 192.168.1.31:7777 <p>no special switches in config file, net and hard devices are only devices, no matter if one is serial wire and the other is ethernet wire. <p>The implementation comes directly from this design. <br> <h3> Notes about the implementation</h3> <p><br>The config file for multi ups is divided in two sections. <br> <ul> <li> global section for all the global parameters not pertaining to any ups</li> <li> upses sections for ups-specific config directives</li> </ul> <p><br>My config file do have this layout: <p><global parameters> <br>upsstart <name> <br><ups parameters> <br>upsend <name> <p>This allows us to add as many upses as we want. On the other side, when a single ups is connected, upsstart/upsend is still needed. I didn't wanted to make a special case for single ups to avoid this pair. If you don't like this, I'm sure we can write a special-case for single ups where we don't require upsstart/upsend. <p>As I said, network must be reviewed. When you connect to the net server you have to ask for one of the upses it knows. So I have decided to rewrite network from scratch to use a much cleaner concept of client/server instead of master/slave. Single daemon, net connections always opened, character based interface (sendmail, pop3, nntpd, control connection of ftp .. you see we have many examples of this), multi-ups support, id/pw authentication, tcp wrappers, selection of net interfaces for listening. All things that with the old networking was a bit difficult to handle. Now they are, but if you don't like this way of handling network, I'm sure we can accomodate the old networking for handling all of these (except character based interface that is a design choice). <p>The old cgi code is still working but with time I want to rewrite it to make use of the new network interface: no need to have many servers. But of course it's no problem in keeping the old cgi networking forever .. but even this must be changed to handle multi-ups. <br> </body> </html>
