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").
currently activated NixOS. This is "0.1pre-svn" when built from a
SVN tree, but contains the actual revision when installed from the
NixOS channel or from the ISO.
svn path=/nixos/trunk/; revision=33730
That's confusing and wrong: nixos-hardware-scan should just enable
support for the detected hardware, not enable lots of software (let
alone KDE).
svn path=/nixos/trunk/; revision=30325
After the change from revision 30103, nixos-rebuild suddenly consumed
freaky amounts of memory. I had to abort the process after it had
allocated well in excess of 30GB(!) of RAM. I'm not sure what is causing
this behavior, but undoing that assignment fixes the problem. The other
two commits needed to be revoked, too, because they depend on 30103.
svn path=/nixos/trunk/; revision=30127
- Added a backdoor option to the interactive run-vms script. This allows me to intergrate the virtual network approach with Disnix
- Small documentation fixes
Some explanation:
The nixos-build-vms command line tool can be used to build a virtual network of a network.nix specification.
For example, a network configuration (network.nix) could look like this:
{
test1 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
...
};
test2 =
{pkgs, config, ...}:
{
services.openssh.enable = true;
services.xserver.enable = true;
}
;
}
By typing the following instruction:
$ nixos-build-vms -n network.nix
a virtual network is built, which can be started by typing:
$ ./result/bin/run-vms
It is also possible to enable a backdoor. In this case *.socket files are stored in the current directory
which can be used by the end-user to invoke remote instruction on a VM in the network through a Unix
domain socket.
For example by building the network with the following instructions:
$ nixos-build-vms -n network.nix --use-backdoor
and launching the virtual network:
$ ./result/bin/run-vms
You can find two socket files in your current directory, namely: test1.socket and test2.socket.
These Unix domain sockets can be used to remotely administer the test1 and test2 machine
in the virtual network.
For example by running:
$ socat ./test1.socket stdio
ls /root
You can retrieve the contents of the /root directory of the virtual machine with identifier test1
svn path=/nixos/trunk/; revision=24410
{
test1 = {pkgs, config, ...}:
{
# NixOS config of machine test1
...
};
test2 = {pkgs, config, ...}:
{
# NixOS config of machine test2
...
};
}
And an infrastructure expression, e.g:
{
test1 = {
hostName = "test1.example.org";
system = "i686-linux";
};
test2 = {
hostName = "test2.example.org";
system = "x86_64-linux";
};
}
And by executing:
nixos-deploy-network -n network.nix -i infrastructure.nix
The system configurations in the network expression are built, transferred to the machines in the network and finally activated.
svn path=/nixos/trunk/; revision=24146
expose makeInfo (used by test now)
expose config hack
* Adding tests to release.nix
* fixes
* removing dependency on perl
refactoring details:
Move all configuration modules used by the NixOS installation test script
into one directory.
svn path=/nixos/trunk/; revision=18982
You can run the kvm nixos installation test by:
nix-build --no-out-link tests/test-nixos-install-from-cd.nix
It boots the installed system.
It still fails sshd isn't started (yet)
adding nixos-bootstrapping-archive:
You can install NixOS easily using any live cd now.
See README-BOOTSTRAP-NIXOS
svn path=/nixos/trunk/; revision=18950
* Change the module syntax of the example to follow Eelco's suggestions.
* Add a section "Building your own NixOS CD", which explain how to replace
configuration.nix by the configuration file of a live CD/DVD.
* Fix "Testing the installer" and "Testing the initrd" to fit the location
of derivations.
svn path=/nixos/trunk/; revision=17105
