"nixos-install --chroot" runs a command (by default a login shell) in
a chroot inside the NixOS installation in /mnt. This might useful for
poking around a new installation.
By setting a line like
MACVLANS="eno1"
in /etc/containers/<name>.conf, the container will get an Ethernet
interface named mv-eno1, which represents an additional MAC address on
the physical eno1 interface. Thus the container has direct access to
the physical network. You can specify multiple interfaces in MACVLANS.
Unfortunately, you can't do this with wireless interfaces.
Note that dhcpcd is disabled in containers by default, so you'll
probably want to set
networking.useDHCP = true;
in the container, or configure a static IP address.
To do: add a containers.* option for this, and a flag for
"nixos-container create".
Personal information management application that provides integrated mail,
calendaring and address book functionality
https://wiki.gnome.org/Apps/Evolution
This overhauls the Datadog module a bit to be much more useful. In
particular, it adds support for nginx and postgresql monitoring
integrations to dd-agent. These have to exist in separate files under
/etc/dd-agent, so the module just exposes then as separate options. In
the future, more integrations could be added this way.
In the process of doing this, I also had to rename the dd-agent user to
datadog. Note the UIDs did not change, so this is strictly backwards
compatible. The reason for this is to make it easier to create a
'datadog' postgres user with access to pg_stats, as 'dd-agent' typically
isn't a valid username. This allows the out of the box configurations to
be used.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
If /boot is a btrfs subvolume, it will be on a different device than /
but not be at the root from grub's perspective. This should be fixed in
a nicer way by #2449, but that can't go into 14.04.
Hopefully fixes failures like:
http://hydra.nixos.org/build/10712833
This shouldn't be necessary, but it might be that the use of unionfs
is interfering with a clean shutdown.
Dmidecode fails in our EFI test with the error "SMBIOS entry point
missing". But we don't need dmidecode because we have already have
systemd-detect-virt.
NixOS has a pervasive dependency on bash. For instance, the X11
session script sources /etc/profile to get a reasonable
environment. Thus we should not provide an option to disable bash.
Also, enabling zsh no longer sets ‘users.defaultUserShell’ to zsh, to
prevent a collision with bash's definition of the same
option. (Changing the default shell is also something that should be
left to the user.)
Previously all card-specific stuff was scattered across xserver.nix
and opengl.nix, which is ugly. Now it can be kept together in a single
card-specific module. This required the addition of a few internal
options:
- services.xserver.drivers: A list of { name, driverName, modules,
libPath } sets.
- hardware.opengl.package: The OpenGL implementation. Note that there
can be only one OpenGL implementation at a time in a system
configuration (i.e. no dynamic detection).
- hardware.opengl.package32: The 32-bit OpenGL implementation.
Fixes#2379.
The new name was a misnomer because the values really are X11 video
drivers (e.g. ‘cirrus’ or ‘nvidia’), not OpenGL implementations. That
it's also used to set an OpenGL implementation for kmscon is just
confusing overloading.
release.nix and release-combined.nix current hardcode the systems which
they are built for. This change introduces an argument to the
expressions called supportedSystems, which allows the builder to choose
which architectures he wants to build. By default, this uses the same
linux x86_64 and i686 architectures.
The Tarsnap module is now far more flexible, allowing individual
archives with individual options to be specified at will, allowing
granular backup schedules, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This reverts commit 6eaced3582. Doesn't
work very well, e.g. if you actually have the FUSE module loaded. And
in any case it's already fixed in NixOps.
Otherwise, when switching from systemd 203 to 212, you get errors like:
Failed to stop remote-fs.target: Bad message
Failed to stop systemd-udevd-control.socket: Bad message
...
These fail to mount if you don't have the appropriate kernel support,
and this confuses NixOps' ‘check’ command. We should teach NixOps not
to complain about non-essential mount points, but in the meantime it's
better to turn them off.
