New thin laptops don't have an ethernet port and so rely on wifi to get
access. With the minimal installer, setup wpa_supplicant can be hard if
it is the first time so here we provide an example.
This was only applicable to very specific hardware, and the only person
with an apparent interest in maintaining it (me) no longer uses the
hardware in question.
"Ejecting" from the Finder ejects the entire device which is then not available for dd. diskutil unmountDisk does the right thing. Furthermore writing to diskN instead of rdiskN failed to complete even after waiting >10 minutes.
before:
- /var/run/memcached is a bad default for a socket path, since its
parent directory must be writeable by memcached.
- Socket directory was not created by the module itself -> this was
left as a burden to the user?
- Having a static uid with a dynamic user name is not very useful.
after:
- Replace services.memcached.socket by a boolean flag. This simplifies
our code, since we do not have to check if the user specifies a
path with a parent directory that should be owned by memcached
(/run/memcached/memcached.sock -> /run/memcached).
- Remove fixed uid/gid allocation. The only file ever owned by the
daemon is the socket that will be recreated on every start.
Therefore user and group ids do not need to be static.
- only create the memcached user, if the user has not specified a
different one. The major use case for changing option is to allow
existing services (such as php-fpm) opening the local unix socket.
If we would unconditionally create a user that option would be
useless.
This allows one to specify "related packages" in NixOS that get rendered into
the configuration.nix(5) man page. The interface philosophy is pretty much
stolen from TeX bibliography.
Changed extraUsers -> users and one case of extraGroups -> groups in nixos manual chapter 7.
According to chatter on IRC these are the proper names for these configuration options nowadays.
Modified based on feedback from Jörg Talheim.
Previously only the line numbers of a giant, internally generated XML file were
printed, without any kind of debuggability.
Now at least the mentioned lines are printed with a little bit of surrounding
context (to have something to grep for).
```
manual-combined.xml:4863: element para: Relax-NG validity error : Did not expect element para there
4859 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.0" xml:id="sec-writing-modules">
4860
4861 <title>Writing NixOS Modules</title>
4862
4863 <para>NixOS has a modular system for declarative configuration. This
4864 system combines multiple <emphasis>modules</emphasis> to produce the
4865 full system configuration. One of the modules that constitute the
```
Since ssh-dss is no longer supported by default, users relying on those
keys for their login may be locked out. They should ideally use stronger
keys, but adding the support for ssh-dss back in can also be done
through extraConfig.
This reverts commit 93c54acf97.
This reopens#30517 @nbp @Ma27
Breaking people's config for this is hardly reasonable as is. If it
absolutely cannot be avoided, at the very least, we need to provide
clear instructions on what people need to upgrade in their config. I
actually had to bisect to the commit, to even find out what property I
should change or define, as the error message was useless. It didn't
even mention a property name.
Discussion on the PR seems to be ongoing, so I'm reverting this, so we
don't break people's systems on unstable.
postage is no longer maintained and has been replaced by the identical pgmanage. See:
https://github.com/workflowproducts/postage#postage-has-been-replaced-with-pgmanage
The following error is raised when a user enables the deprecated `services.postage.enable` option:
Failed assertions:
- services.postage is deprecated in favor of pgmanage. They have the same options so just substitute postage for pgmanage.
Also unifies the BIOS and UEFI installation instructions.
It's a fairly basic usage, but it makes explicity the fact that
you should at least have a main partition and a swap partition,
and will save some users a bit of internet searching while they
are getting set up.
The section was strange to read, as the initial example already used
`listOf' which is mentioned in the very first paragraph. Then you read
in a subsection about `listOf' and the exact same example is given
once again.
This is a squash commit of the joint work from:
* Jan Tojnar (@jtojnar)
* Linus Heckemann (@lheckemann)
* Ryan Mulligan (@ryantm)
* romildo (@romildo)
* Tom Hunger (@teh)
This commit readds and updates the 1.x package from 1.1.4 to 1.1.6 which
also includes the needed command for migrating to 2.x
The module is adjusted to the version change, defaulting to radicale2 if
stateVersion >= 17.09 and radicale1 otherwise. It also now uses
ExecStart instead of the script service attribute. Some missing dots at
the end of sentences were also added.
I added a paragraph in the release notes on how to update to a newer
version.
This change updates the instructions for building a NixOS ISO so that it's clear how to do it.
Previously, the instructions stated to set NIXOS_CONFIG prior to running `nix-build`, yet the example provided by-passed NIXOS_CONFIG anyway. But the *really* important missing piece is the need for nixos/default.nix. See #21840.
This change removes the NIXOS_CONFIG verbiage, and adds steps to clone nixpkgs and (most importantly) cd'ing into nixpkgs/nixos. That way, the reader may think: *Oh, so I need a default.nix and a configuration.nix. Ahhh, OK.*
I purposely added the redundant default.nix argument.
* postgresql service: make 9.6 the default version for 17.09
* postgresql service: change default superuser for 17.09
Change the default superuser from `root` to `postgres` for state
version 17.09
* postgresql service: change default data directory for 17.09
The new directory includes the schema version of the database.
This makes upgrades easier and is more consistent with other distros.
* updated nixos release notes
... because `nixos-generate-config` currently understand it's running under virtualbox, and correctly adds the configuration in `/etc/nixos/hardware-configuration.nix`
When you have a setup consisting of multiple monitors, the default is
that the first monitor detected by xrandr is set to the primary monitor.
However this may not be the monitor you need to be set as primary. In
fact this monitor set to primary may in fact be disconnected.
This has happened for the original submitter of the pull request and it
affected these programs:
* XMonad: Gets confused with Super + {w,e,r}
* SDDM: Puts the login screen on the wrong monitor, and does not
currently duplicate the login screen on all monitors
* XMobar: Puts the XMobar on the wrong monitor, as it only puts the
taskbar on the primary monitor
These changes should fix that not only by setting a primary monitor in
xrandrHeads but also make it possible to make a different monitor the
primary one.
The changes are also backwards-compatible.
The xrandrHeads option has been there since a long time, so there is no
need to advertise it as a new feature.
Instead, let's focus on just what has changed, which is that we now
assign one head to be primary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The inability to run strace or gdb is the kind of
developer-unfriendliness that we're used to from OS X, let's not do it
on NixOS.
This restriction can be re-enabled by setting
boot.kernel.sysctl."kernel.yama.ptrace_scope" = 1;
It might be nice to have a NixOS module for enabling hardened defaults.
Xref #14392.
Thanks @abbradar.
This is based on a prototype Nicolas B. Pierron worked on during a
discussion we had at FOSDEM.
A new version with a workaround for problems of the reverted original.
Discussion: https://github.com/NixOS/nixpkgs/commit/3f2566689
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
Add link to "Configuration" chapter from "Changing the Configuration" section.
Also, fix grammar error.
(cherry picked from commit a585f987fa32f2e81b3f273291971151c25f98b7)
