Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

Apcupsd

From Livedoc - The Documentation Repository
Revision as of 14:02, 21 July 2013 by 2017sdamashe (talk | contribs) (Configuration: Pre for commands)
Jump to: navigation, search

This page is a stub. Please consider expanding the article so it is complete.

apcupsd is a daemon that can run on a system to communicate and interact with a UPS.

Configuration

To configure apcupsd on gentoo is a fairly straightforward process. (Note: Most of these commands need to be run as root) First, emerge apcupsd.

After that, connect to the UPS and ensure that in Control Console>Network>SNMP>SNMPv1 Specific Settings that one of the SNMPv1 Access Control settings has a community named apc with access Read and NMS IP 0.0.0.0 (which allows access from all).

If not, select an Access Control with Access Disabled and set the Community Name to apc, Access Type to Read, and NMS IP/Name to 0.0.0.0. This is VERY IMPORTANT.

After you verify the server has access to the UPC above, you can configure apcupsd to connect to the UPS via SNMP. In your favorite text editor, open up /etc/apcupsd/apcupsd.conf and edit the following lines as shown:

UPSNAME (hostname of UPS)
UPSCABLE ether
UPSTYPE snmp
DEVICE (hostname of UPS):161:APC:apc

At this time, apcupsd should be able to poll the UPS. Save and restart apcupsd

/etc/init.d/apcupsd restart

and wait at least one minute for apcupsd to make its initial poll to the UPS. Then to make sure everything is working, run apcaccess status. If you get a "Connection refused" error, keep waiting, apcupsd hasn't attempted to poll the UPS yet. If you see STATUS : COMMLOST, either you misconfigured apcupsd.conf or apcupsd doesn't have permissions to access the UPS (which you should have configured earlier in Access Control). If you see STATUS : SUCCESS and lots of UPS statistics, apcupsd is configured correctly and you can move on. Right now, the server successfully polls the UPS every 60 seconds, however it won't do anything beyond email root if there is a power outage. To make apcupsd shut down the server if there is a power outage, add the powerfail service to the shutdown runlevel like so:

rc-update add apcupsd.powerfail shutdown

.

If you want to execute commands on power failure instead of shutting down, replace /etc/apcupsd/onbattery with a bash script with said commands. (By default, it emails root saying there was a power failure) If you want to execute commands when the power failure is over, edit /etc/apcupsd/offbattery with said commands.

The server should be all configured and ready to go now. If you have any issues during the install, don't be afraid to ask.

Servers

Linux

We are currently testing apcupsd on Rockhopper and Waitaha and if there are no issues, will implement apcupsd on all UPS connected servers.

One possible action of apcupsd on a Linux server other than simply shutting down cleanly would be to initiate an AFS fileserver shutdown early during a power outage to reduce the chance of needing to conduct a lengthy salvage of AFS volumes.

Suns

Currently apcupsd is in use on all Sun servers. Depending on the server, upon a power outage and after a configured timeout has passed, the server will:

  • sync its disks and do nothing
  • fully power off
  • shutdown to OBP (so it will automatically power on if the UPS dies and then power comes back later)

All of the Sun servers communicate with networked UPSes, of which there are currently six. The general rule currently used for servers that are redundantly connected to two UPSes is that half of the servers connected to the pair will communicate with one UPS, while the other half will communicate with the other. The benefit of this is that if TJ experiences a partial power outage affecting only one of the two UPSes in the redundant pair, only half of the machines will believe it is a true power outage and shutoff (also preventing an overload situation on the other UPS after the first UPS is drained if the overall load was above 50%). If we know that one UPS in the pair can fully support the load, it is also possible to suppress the automated shutdown by killing apcupsd on the affected servers, or by disconnecting the network from the UPS that has lost line power (if the server loses communication with its UPS, it will fall back to the default assumption of online).

In the event that a system's UPS is not networked, that system can be

  • directly connected to the UPS via serial or USB and then use apcupsd's NIS master/slave setup (reportedly much more reliable than the previous master/slave system used in older versions) to make sure other systems on that UPS also get status notifications about the UPS through the directly connected machine.
  • configured to query another networked UPS that it is not powered from. If this option is picked, try to pick a UPS that is on the same circuit or phase (if known) so that a partial outage does not trigger unnecessary shutdowns. For instance, currently the Sun Ultra 45 workstations communicate with the switch UPS since they are plugged into a non-networked UPS that uses the same 120V outlet block (which should mean the same circuit and phase).

Workstations

Once a long time ago...and then there were no UPSes for workstations!

Music cart

The music cart Sun Rays are connected via serial to the UPS on the cart. This allows remote querying and control of the UPS as long as the Sun Ray retains a connection to a Sun Ray server, although there currently is no daemon running to constantly monitor these UPSes. It should be possible to configure a secondary daemon to run on a server to monitor these UPSes for battery usage and load to get a sense of how they are being used.