apcupsd is a daemon for controlling APC UPSes. It is very simple to
configure. If you have an USB based UPS, the default settings should be
useable without further adjustments:
services.apcupsd.enable = true;
This will give you autodetection of USB UPSes, network access limited to
localhost (for security) and the shutdown sequence will be started when
the system when the battery level is below 50 percent, or when the UPS
has calculated that it has 5 minutes or less of remaining power-on time.
You can provide your own configuration file contents with this option:
services.apcupsd.configText = "contents of apcupsd.conf";
Bug/annoyance 1: When apcupsd calls "wall" (on powerfail etc. events),
it prints an error message because stdout is not connected to a tty (it
is connected to the journal):
wall: cannot get tty name: Inappropriate ioctl for device
The message still gets through though, to ctrl-alt-f[1-6] terminals.
Bug/annoyance 2: apcupsd tries to call "mail" (on powerfail etc.
events), and that fails because I'm not passing in any mail program at
the moment (because that would require more configuration options). A
solution to this would be to simply let the user fully configure the
apcupsd event handling logic in nix.
This is in preparation of making a stable release/branch. The version
number is <YY>.<MM>, Ubuntu style, denoting the intended release
year/month. It also has a release codename ("Aardvark").
Otherwise clients get a "Stale NFS handle" error after the server
reboots. Not clear why this is the case, since the fsid shouldn't
change across reboots...
The README of nfs-utils explains that we must not notify clients
before nfsd is running, otherwise they may fail to reclaim their
locks. OTOH it's allowed but not required to start "rpc.statd
--no-notify" before nfsd. So for simplicity we do both after starting
nfsd.
Turns out that remote-fs-pre.target is not actually "wanted" anywhere,
so statd is not started before remote filesystems are mounted. But
remote filesystems do "want" network-online.target, so we can use that
to pull in statd and idmapd.
Not sure if this is really the right thing to do, but it works for
now. Background:
https://bugzilla.redhat.com/show_bug.cgi?id=787314http://hydra.nixos.org/build/5542230
When nixos-rebuild grabs a new kernel, it will build new spl/zfs
modules, which will change the service. On completion nixos will try and
restart the services which will try and import pools again, and
generally will fail.
The pools are already imported, we don't need to do it again..
Just like in the MySQL service module it really makes sense to provide a
way to inject SQL on the first start of the database cluster.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should integrate the logging more tightly into systemd, so for
example "systemctl status mysql" actually gives an overview about what's
actually going on.
This removes the logError option attribute, so in case you still want to
write into a logfile, I've introduced an option called extraOptions, so
you can use something like:
services.mysql*.extraOptions = ''
log-error = /var/log/mysql_err.log
'';
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Grub uses mdadm to find out the device it is on, especially when mdadm itself
resides in a separate boot partition. When bootstrapping from a NixOS
installation CD, it's not a big issue because usually the paths from the Nix
store of the installation CD are matching with the ones in the chrooted
environment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
