hardware scan was generating a hardware.nix containing
"pkgs.linuxPackages" without having "pkgs" in scope. Also, it
shouldn't define boot.kernelPackages.
svn path=/nixos/trunk/; revision=25192
attribute name of the machine in the model. This allows
networking.hostName and deployment.targetHost to be omitted for
typical networks.
svn path=/nixos/trunk/; revision=25125
- implemented --no-out-link option so that invoking these tools from scripts leave no garbage behind
- some misc. cleanups
svn path=/nixos/trunk/; revision=25019
- 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
devices. These are used to replace hand made listings in the basic
installation CD.
The configuration file, which is generated by nixos-hardware-scan, enables
not-detected devices by default.
svn path=/nixos/trunk/; revision=23911
like `build-vm', but boots using the regular boot loader (i.e. GRUB
1 or 2) rather than booting directly from the kernel/initrd. Thus
it allows testing of GRUB.
svn path=/nixos/trunk/; revision=23747
is done by instantiating a webserver that simulates nixos.org.
Using nix-push we create a channel that contains some stuff (namely
the GNU Hello source tarball and the rlwrap program). This was a
bit tricky because nix-push requires a writable Nix store. Using
AUFS this is possible, but not on recent Linux kernels (AUFS1 over
CIFS fails).
svn path=/nixos/trunk/; revision=19327
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
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
(e.g. --install-grub instead of $NIXOS_INSTALL_GRUB). Also support
some nix-build options (e.g. --show-trace and -j).
svn path=/nixos/branches/modular-nixos/; revision=16560
