So instead of:
boot.systemd.services."foo".serviceConfig =
''
StartLimitInterval=10
CPUShare=500
'';
you can say:
boot.systemd.services."foo".serviceConfig.StartLimitInterval = 10;
boot.systemd.services."foo".serviceConfig.CPUShare = 500;
This way all unit options are available and users can set/override
options in configuration.nix.
This makes it easier for systemd to track it and avoids race conditions such as
this one:
systemd[1]: PID file /run/sshd.pid not readable (yet?) after start.
systemd[1]: Failed to start SSH Daemon.
systemd[1]: Unit sshd.service entered failed state.
systemd[1]: sshd.service holdoff time over, scheduling restart.
systemd[1]: Stopping SSH Daemon...
systemd[1]: Starting SSH Daemon...
sshd[2315]: Server listening on 0.0.0.0 port 22.
sshd[2315]: Server listening on :: port 22.
sshd[2335]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
sshd[2335]: error: Bind to port 22 on :: failed: Address already in use.
sshd[2335]: fatal: Cannot bind any address.
systemd[1]: Started SSH Daemon.
Logind sessions are more generally useful than for device ownership.
For instances, ssh logins can be put in their own session (and thus
their own cgroup).
Ugly hack to get around the error "a string that refers to a store
path cannot be appended to a path". The underlying problem is that
you cannot do
"${./file1} ${./file2}"
but you can do
" ${./file1} ${./file2}"
Obviously we should allow the first case as well.
Enabled a bunch of units that ship with systemd. Also added an option
‘boot.systemd.units’ that can be used to define additional units
(e.g. ‘sshd.service’).
lines below a certain marker. This is undesirable because commands
like "ssh-copy-id" add keys to the end of the file. Instead mark
all automatically added lines individually.
svn path=/nixos/trunk/; revision=33918
challenge-response is an authentication method that does not need the
plain text password to be emitted over the (encrypted) connection.
This is nice if you don't fully trust the server.
It is enabled (upstream) by default.
To the end user, it still looks like normal password authentication,
but instead of sending it, it is used to hash some challenge.
This means that if you don't want passwords to be used ever at all,
and just stick to public key authentication, you probably want to
disable this option too.
svn path=/nixos/trunk/; revision=33513
You can now set the forwardX11 config option for the ssh client and server separately.
For server, the option means "allow clients to request X11 forwarding".
For client, the option means "request X11 forwarding by default on all connections".
I don't think it made sense to couple them. I might not even run the server on some machines.
Also, I ssh to a lot of machines, and rarely want X11 forwarding. The times I want it,
I use the -X/-Y option, or set it in my ~/.ssh/config.
I also decoupled the 'XAuthLocation' logic from forwardX11.
For my case where ssh client doesn't want forwarding by default, it still wants to set the path for the cases I do need it.
As this flag is the one that pulls in X11 dependencies, I changed the minimal profile and the no-x-libs config to check that instead now.
svn path=/nixos/trunk/; revision=33407
well because elements could be paths, e.g.
users.extraUsers.root.openssh.authorizedKeys.keyFiles =
[ ./id_key.pub ];
So disable the type check for now.
svn path=/nixos/trunk/; revision=32558
Setting both of these options to 'false' configures the OpenSSH daemon to
reject password authentication, i.e. users must have an appropriate key in
~/.ssh/authorized_keys in order to be able to log in.
svn path=/nixos/trunk/; revision=27732
requieres a patch in openssh that I just commited to nixpkgs)
Before this, in the shell spawned, backspace could not work over UTF-8 strings in the readline.
svn path=/nixos/trunk/; revision=21679
"sshd" because changing it to "opensshd" causes breakage (like the
activation script saying "useradd: UID 2 is not unique."). Also,
OpenSSH requires it to be named "sshd", I think.
svn path=/nixos/trunk/; revision=20577
qemu_kvm. Installation doesn't take place yet. VM is started
printing a remote controlled "Hello".
This serves as example how to run a vm within a bulid job.
svn path=/nixos/trunk/; revision=18887
machine containing a replica (minus the state) of the system
configuration. This is mostly useful for testing configuration
changes prior to doing an actual "nixos-rebuild switch" (or even
"nixos-rebuild test"). The VM can be started as follows:
$ nixos-rebuild build-vm
$ ./result/bin/run-*-vm
which starts a KVM/QEMU instance. Additional QEMU options can be
passed through the QEMU_OPTS environment variable
(e.g. QEMU_OPTS="-redir tcp:8080::80" to forward a host port to the
guest). The fileSystem attribute of the regular system
configuration is ignored (using mkOverride), because obviously we
can't allow the VM to access the host's block devices. Instead, at
startup the VM creates an empty disk image in ./<hostname>.qcow2 to
store the VM's root filesystem.
Building a VM in this way is efficient because the VM shares its Nix
store with the host (through a CIFS mount). However, because the
Nix store of the host is mounted read-only in the guest, you cannot
run Nix build actions inside the VM. Therefore the VM can only be
reconfigured by re-running "nixos-rebuild build-vm" on the host and
restarting the VM.
svn path=/nixos/trunk/; revision=16662
those that run daemons) to modules/services. This probably broke
some things since there are a few relative paths in modules
(e.g. imports of system/ids.nix).
* Moved some PAM modules out of etc/pam.d to the directories of NixOS
modules that use them.
svn path=/nixos/branches/modular-nixos/; revision=15717
