This led to the container test failing, which made no sense
whatsoever, until I realized nix-daemon.socket creates the socket
directory as a side effect, which systemd-nspawn then bind-mounts.
http://hydra.nixos.org/build/10397575
This has some advantages:
* You get ssh-agent regardless of how you logged in. Previously it was
only started for X11 sessions.
* All sessions of a user share the same agent. So if you added a key
on tty1, it will also be available on tty2.
* Systemd will restart ssh-agent if it dies.
* $SSH_AUTH_SOCK now points to the /run/user/<uid> directory, which is
more secure than /tmp.
For bonus points, we should patch ssh-agent to support socket-based
activation...
If you define a unit, and either systemd or a package in
systemd.packages already provides that unit, then we now generate a
file /etc/systemd/system/<unit>.d/overrides.conf. This makes it
possible to use upstream units, while allowing them to be customised
from the NixOS configuration. For instance, the module nix-daemon.nix
now uses the units provided by the Nix package. And all unit
definitions that duplicated upstream systemd units are finally gone.
This makes the baseUnit option unnecessary, so I've removed it.
This mostly upgrades transmission, and does some very minor touchups on
AppArmor support.
In particular, there is now no need to ever specify the umask as part of
the settings, as it will be mixed in by default (which is essentially
always what you want). Also, the default configuration is now more
sensible: Downloads are put in /var/lib/transmission/Downloads, and
incomplete files are put in /var/lib/transmission/.incomplete - this
also allows easy use of file syncing probrams, like BitTorrent Sync.
Finally, this unconditionally enables the AppArmor profiles for the
daemon, if AppArmor is enabled - rather than letting the user specify
profile support, it's best to default to supporting profiles for daemons
transparently in all places.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
Reverting postgres superuser changes until after stable.
This reverts commit 6cc0cc7ff6136963acb32b5107696484b6220562, reversing
changes made to 3c4be425dbe2d5a00f2923210a86ce7e7a4c516f.
This prevents errors like "Another app is currently holding the
xtables lock" if the firewall and NAT services are starting in
parallel. (Longer term, we should probably move to a single service
for managing the iptables rules.)
This allows to easily override the used PHP package, especially for
example if you want to use PHP 5.5 or if you want to override the
derivation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The postgresql module has a postStart section that waits for a database
to accept connections before continuing. However, this assumes various
properties about the database - specifically the database user
and (implicitly) the database name. This means that for old
installations, this command fails because there is no 'postgres' user,
and the service never starts.
While 7deff39 does create the 'postgres' user, a better solution is to
use `pg_isready`, who's sole purpose is to check if the database is
accepting connections. This has no dependency on users, so should be
more robust.
Old PostgreSQL installations were created using the 'root' database
user. In this case, we need to create a new 'postgres' account, as we
now assume that this is the superuser account.
Unfortunately, these machines will be left with a 'root' user as
well (which will have ownership of some databases). While PostgreSQL
does let you rename superuser accounts, you can only do that when you
are connected as a *different* database user. Thus we'd have to create a
special superuser account to do the renaming. As we default to using
ident authentication, we would have to create a system level user to do
this. This all feels rather complex, so I'm currently opting to keep the
'root' user on these old machines.
