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
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).
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!
This module adds the security.duosec attributes, which you can use to
enable simple two-factor authentication for NixOS logins.
The module currently provides PAM and SSH support, although the PAM unix
system configuration isn't automatically dealt with (although the
configuration is automatically built).
Enabling it is as easy as saying:
security.duosec.ssh.enable = true;
security.duosec.ikey = "XXXXXXXX...";
security.duosec.skey = "XXXXXXXX...";
security.duosec.host = "api-XXXXXXX.duosecurity.com";
security.duosec.group = "duosec";
which will enforce two-factor authentication for SSH logins for users in
the 'duosec' group.
This requires uid/gid support in the environment.etc module.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This has the nice side-effect of making gpsd actually run!
Old behaviour (debugLevel=2):
systemd[1]: gpsd.service holdoff time over, scheduling restart.
systemd[1]: Stopping GPSD daemon...
systemd[1]: Starting GPSD daemon...
systemd[1]: gpsd.service start request repeated too quickly, refusing to start.
systemd[1]: Failed to start GPSD daemon.
systemd[1]: Unit gpsd.service entered failed state.
New behaviour (debugLevel=2):
gpsd[945]: gpsd: launching (Version 2.95)
systemd[1]: Started GPSD daemon.
gpsd[945]: gpsd: listening on port 2947
gpsd[945]: gpsd: running with effective group ID 27
gpsd[945]: gpsd: running with effective user ID 23
gpsd[945]: gpsd: stashing device /dev/ttyUSB0 at slot 0
Uses standard NixOS user config merging.
Work in progress: The slave config does not actually start the slave agent. This just configures a
jenkins user if required. Bare minimum to enable a nice jenkins SSH slave.
By default the jenkins server is executed under the user "jenkins". Which can be configured using
users.jenkins.* options. If a different user is requested by changing services.jenkins.user then
none of the users.jenkins options apply.
This patch does not include jenkins slave configuration. Some config options will probably change
when this is implemented.
Aspects like the user and environment are typically identical between slave and master. The service
configs are different. The design is for users.jenkins to cover the shared aspects while
services.jenkins and services.jenkins-slave cover the master and slave specific aspects,
respectively.
Another option would be to place everything under services.jenkins and have a config that selects
master vs slave.
