Apple Mac Mini

Configuring a UPS

• Choosing a UPS
  • Power requirements
  • Run-time
  • Make & model
• Configuring the software

Choosing a UPS

1. The total power requirements specified in either watts (W) or volt-amps (VA).
2. The desired run-time on batter power.

Power requirements

Run-time

Make & model

1. Has a USB port to communicate with the Mini. (Historically, UPSs only had DB-9 serial ports.)
2. Works under Linux (preferably, is well-supported under Linux).

Configuring the software

    apt-get install nut nut-cgi nut-usb

    -rw-r--r--  1 root root hosts.conf
    -rw-r--r--  1 root root ups.conf
    -rw-r-----  1 root nut  upsd.conf
    -rw-r-----  1 root nut  upsd.users
    -rw-r-----  1 root nut  upsmon.conf
    -rw-r--r--  1 root root upssched.conf
    -rw-r--r--  1 root root upsset.conf
    -rw-r-----  1 root www  upsstats-single.html

The files, their purpose, and contents are:

ups.conf

This file names the UPS and specifies how to communicate with it:

    [pulsar_evolution]
        driver = newhidups
        port = auto

hosts.conf

This file specifies name of the UPS to monitor as well as a descriptive label:

    MONITOR pulsar_evolution@mini "Pulsar Evolution"

upsd.conf

This file specifies the access control, i.e., which users from which machines may monitor the UPS:

    ACL home_net 10.0.1.0/24
    ACCEPT home_net
    REJECT all

The label home_net can be anything you want and specifies that only a machine on my home 10.0.1 network may access the UPS.

upsd.users

This file specifies the users that may access the UPS:

    [admin]
        password = master-password
        allowfrom = home_net
        actions = SET
        instcmds = ALL

    [monuser]
        password = user-password
        allowfrom = home_net
        upsmon master

There should be (at least) two users: an admin user and a monitoring user that has only read-only privileges.

upsmon.conf

This file is used to configure upsmon (the UPS monitoring daemon):

    RUN_AS_USER nut
    MONITOR pulsar_evolution@mini 1 monuser user-password master
    MINSUPPLIES 1

    DEADTIME 15
    FINALDELAY 5
    HOSTSYNC 15
    NOCOMMWARNTIME 300
    NOTIFYCMD /sbin/upssched
    POLLFREQ 5
    POLLFREQALERT 5
    POWERDOWNFLAG /etc/killpower
    RBWARNTIME 43200
    SHUTDOWNCMD "/sbin/shutdown -h +0"

    NOTIFYMSG COMMBAD   "UPS communications lost"
    NOTIFYMSG COMMOK    "UPS communications established"
    NOTIFYMSG FSD       "UPS being shut down by master"
    NOTIFYMSG LOWBATT   "UPS has a low battery"
    NOTIFYMSG NOCOMM    "UPS unavailable"
    NOTIFYMSG ONBATT    "UPS on battery power"
    NOTIFYMSG ONLINE    "UPS on line power"
    NOTIFYMSG REPLBATT  "UPS battery needs replacement"
    NOTIFYMSG SHUTDOWN  "NUT shutting system down"

    NOTIFYFLAG COMMBAD  SYSLOG+EXEC
    NOTIFYFLAG COMMOK   SYSLOG+EXEC
    NOTIFYFLAG FSD      SYSLOG+EXEC
    NOTIFYFLAG LOWBATT  SYSLOG+EXEC
    NOTIFYFLAG NOCOMM   SYSLOG+EXEC
    NOTIFYFLAG ONBATT   SYSLOG+EXEC
    NOTIFYFLAG ONLINE   SYSLOG+EXEC
    NOTIFYFLAG REPLBATT SYSLOG+EXEC
    NOTIFYFLAG SHUTDOWN SYSLOG+EXEC

The second line specifies the UPS to monitor, the monitoring user monuser and password that must match what's specified in upsd.users.

The items COMBAD, COMMOK, LOWBATT, etc., are all the states that the UPS and the NUT software can be in. NOTIFYMSG allows a more-readable message to be specified when a state-change occurs and NOTIFYFLAGS specifies what to do when a state-change occurs. The values for the latter are all SYSLOG+EXEC that means (1) log the message via the syslog mechanism and (2) execute the command specified by NOTIFYCMD.

The reason the values are all SYSLOG+EXEC is because I want to defer what to do upon a state-change to the upssched program for all state-changes so there's only one place where this is specified. I think NOTIFYFLAG introduces an unnecessary level of indirection and flexibility.

upssched.conf

This file specifies what upssched should do when executed when a UPS or NUT software state-change occurs:

    CMDSCRIPT   /usr/local/sbin/upssched-cmd
    PIPEFN      /var/run/nut/upssched.pipe
    LOCKFN      /var/run/nut/upssched.lock

    AT COMMBAD  * START-TIMER COMMBAD 10
    AT COMMOK   * CANCEL-TIMER COMMBAD COMMOK
    AT FSD      * EXECUTE FSD
    AT LOWBATT  * EXECUTE LOWBATT
    AT NOCOMM   * START-TIMER COMMBAD 10
    AT ONBATT   * START-TIMER ONBATT 300
    AT ONLINE   * CANCEL-TIMER ONBATT ONLINE
    AT REPLBATT * EXECUTE REPLBATT
    AT SHUTDOWN * EXECUTE SHUTDOWN

CMDSCRIPT specifies the script to execute when appropriate. Since the Debian package didn't come with one, I wrote one: upssched-cmd.

The AT lines specify what to do for a particular state. (The * means "for any UPS.") Timers can be used to prevent immediate action. For example, if the communication between NUT and the UPS is lost (COMMBAD or NOCOMM), a "COMMBAD" timer is started and will last 10 seconds.

Timers can have any names you want. I just thought it was simpler and consistent to make timers and states have the same name.

If communication is restored (COMMOK) in under 10 seconds, then the COMMBAD timer is cancelled and no other action is taken, i.e., upssched-cmd is never called.

If communication is not restored in under 10 seconds, the COMMBAD timer will expire and upssched-cmd will be called with the single command-line argument of the timer name.

If communication is subsequently restored, upssched-cmd will be called with the single command-line argument that is the second argument to CANCEL-TIMER, in this case COMMOK.

Again for simplicity and consistency, I'm using the state name as the argument.

Similarly, a timer of 5 minutes is started when the UPS switches to battery power (ONBATT) and back to line power (ONLINE).

The upssched-cmd script is straight-forward and is easily configurable as to which UPS/NUT states notify you by what means.

upsstats-single.html

This file is an HTML template for use with the upsstats.cgi script that renders a very nice web page showing the status of a UPS. I tweaked the HTML file more to my liking (made it XHTML, added auto-refresh, and a few layout changes). Here is my version.

Yes, despite appearances, the formatting of the @ lines is correct since they must start in column 1.

    START_UPSD=yes
    START_UPSMON=yes

    START_UPSD=no
    START_UPSMON=yes