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.
This allows to define systemd.path(5) units, for example like this:
{
systemd = let
description = "Set Key Permissions for xyz.key";
in {
paths.set-key-perms = {
inherit description;
before = [ "network.target" ];
wantedBy = [ "multi-user.target" ];
pathConfig.PathChanged = "/run/keys/xyz.key";
};
services.set-key-perms = {
inherit description;
serviceConfig.Type = "oneshot";
script = "chown myspecialkeyuser /run/keys/xyz.key";
};
};
}
The example here is actually useful in order to set permissions for the
NixOps keys target to ensure those permisisons aren't reset whenever the
key file is reuploaded.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
as per postgresql manual, interactions with psql should be carried
out with the postgresql system user and postgresql db user by default.
ensure it happens in postStart.
This reverts commit f7d5e83abb. It
breaks the Firefox and Xfce tests:
in job ‘tests.firefox.x86_64-linux’:
cannot coerce a boolean to a string
in job ‘tests.xfce.x86_64-linux’:
infinite recursion encountered
Update VirtualBox (and implicitly VirtualBox Guest Additions) to 4.3.6
and Oracle VM VirtualBox Extension Pack to 91406
Conflicts due to minor upgrade in the mean time
Conflicts:
nixos/modules/virtualisation/virtualbox-guest.nix
pkgs/applications/virtualization/virtualbox/default.nix
pkgs/applications/virtualization/virtualbox/guest-additions/default.nix
Needed for the installer tests, since otherwise mounting a filesystem
may fail as it has a last-mounted date in the future.
http://hydra.nixos.org/build/9846712
Latest update to udisks in 344f2e65 broke it for me. Fix it by doing the
following:
- Add udisks.service to /etc/systemd/system (via systemd.packages)
- Fix path to udisks-daemon in udisks.service (libexec/ instead of lib/)
- Make dhcp work, use dhcpcd without udev in container
- Make login shell work, patch getty to not wait for /dev/tty0
- Make ssh work, sshd/pam do not start session
The command nixos-container can now create containers. For instance,
the following creates and starts a container named ‘database’:
$ nixos-container create database
The configuration of the container is stored in
/var/lib/containers/<name>/etc/nixos/configuration.nix. After editing
the configuration, you can make the changes take effect by doing
$ nixos-container update database
The container can also be destroyed:
$ nixos-container destroy database
Containers are now executed using a template unit,
‘container@.service’, so the unit in this example would be
‘container@database.service’.
According to the MySQL manual, this is a perfectly legal way of
shutting down the server. The shutdown logs also looks fine:
systemd[1]: Stopping MySQL Server...
mysqld[5114]: 140319 8:36:12 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Normal shutdown
mysqld[5114]: 140319 8:36:12 [Note] Event Scheduler: Purging the queue. 0 events
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: FTS optimize thread exiting.
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: Starting shutdown...
mysqld[5114]: 140319 8:36:14 [Note] InnoDB: Shutdown completed; log sequence number 1619078
mysqld[5114]: 140319 8:36:14 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Shutdown complete
systemd[1]: Stopped MySQL Server.
This reverts commit 4e6eae45ee. It
breaks running the test driver interactively (in that it causes all
VMs to be started immediately, which is not always what you wnat).
For example, the following sets up a container named ‘foo’. The
container will have a single network interface eth0, with IP address
10.231.136.2. The host will have an interface c-foo with IP address
10.231.136.1.
systemd.containers.foo =
{ privateNetwork = true;
hostAddress = "10.231.136.1";
localAddress = "10.231.136.2";
config =
{ services.openssh.enable = true; };
};
With ‘privateNetwork = true’, the container has the CAP_NET_ADMIN
capability, allowing it to do arbitrary network configuration, such as
setting up firewall rules. This is secure because it cannot touch the
interfaces of the host.
The helper program ‘run-in-netns’ is needed at the moment because ‘ip
netns exec’ doesn't quite do the right thing (it remounts /sys without
bind-mounting the original /sys/fs/cgroups).
These are stored on the host in
/nix/var/nix/{profiles,gcroots}/per-container/<container-name> to
ensure that container profiles/roots are not garbage-collected.
This has the unintended side-effect of restarting httpd every time we
run switch-to-configuration, even if httpd hasn't changed (because
we're doing a "stop keys.target" now). So use a "Wants" dependency
instead.
On the host, you can run
$ socat unix:<path-to-container>/var/lib/login.socket -,echo=0,raw
to get a login prompt. So this allows logging in even if the
container has no SSH access enabled.
You can also do
$ socat unix:<path-to-container>/var/lib/root-shell.socket -
to get a plain root shell. (This socket is only accessible by root,
obviously.) This makes it easy to execute commands in the container,
e.g.
$ echo reboot | socat unix:<path-to-container>/var/lib/root-shell.socket -
This reverts commit b792394119.
Starting the manual on tty8 was intended as a convenience during
installation, not as a general purpose thing. In fact, given that w3m
runs as root, this is highly insecure!
