environment.sessionVariables cannot refer to the values of env vars,
and as a result this has caused problems in a variety of scenarios.
One use for these is that they're injected into /etc/profile,
elewhere these are used to populate an 'envfile' for pam
(`pam 5 pam_env.conf`) which mentions use of HOME being
potentially problematic.
Anyway if the goal is to make things easier for users,
simply do the NIX_PATH modification as extraInit.
This fixes the annoying problems generated by the current approach
(#40165 and others) while hopefully serving the original goal.
One way to check if things are borked is to try:
$ sudo env | grep NIX_PATH
Which (before this change) prints NIX_PATH variable with
an unexpanded $HOME in the value.
-------
This does mean the following won't contain user channels for 'will':
$ sudo -u will nix-instantiate --eval -E builtins.nixPath
However AFAICT currently they won't be present either,
due to unescaped $HOME. Unsure if similar situation for other users
of sessionVariables (not sudo) work with current situation
(if they exist they will regress after this change AFAIK).
Introduced by 0f3b89bbed.
If services.nixosManual.showManual is enabled and
documentation.nixos.enable is not, there is no
config.system.build.manual available, so evaluation fails. For example
this is the case for the installer tests.
There is however an assertion which should catch exactly this, but it
isn't thrown because the usage of config.system.build.manual is
evaluated earlier than the assertions.
So I split the assertion off into a separate mkIf to make sure it is
shown appropriately and also fixed the installation-device profile to
enable documentation.nixos.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij
This reverts commit 67c8c49177.
'nix run nixos.firefox' is *not* supposed to work - the Nix 2.x
interface attempts to standardize on nixpkgs.*, to get rid of the
nixos/nixpkgs confusion that existed with the channels interface. So
let's not bring that confusion back.
Because when I see "config.system.build.manual.manual" after I forgot
what it means I ask "Why do I need that second `.manual` there again?".
Doesn't happen with `config.system.build.manual.manualHTML`.
This adds several improvements the previously introduced
`services.weechat` module:
* Dropped `services.weechat.init` as the initialization script can now
be done on package-level since 2af41719bc using the `configure`
function.
* Added `sessionName` option to explicitly configure a name for the
`screen` session (by default: weechat-screen).
* Added `binary` option to configure the binary name (e.g.
`weechat-headless`).
* Added docs regarding `screen` session and `weechat.service`.
This fixes a regression introduced in commit
700e21d6da
nix needs ssh on path for the SSH substituter functionality,
not only the distributed builds functionality.
Signed-off-by: Niklas Hambüchen <mail@nh2.me>
This is the semantics as understood by `xdg-open`. Using these semantics
on a non-colon-separated variable works because it acts as if it was a
one element long list.
This fixes an issue where it would try to exec
`google-chrome-beta:google-chrome:chromium:firefox` on a system
configured with these semantics in mind.
This prevents issues when gitea adds new locales etc. And if they
change locale values in future versions. Or if you rollback to a
previous version of gitea it might be a good idea to use the previous
locale files.
Broke evaluation of the nixos options.
The option `services.dysnomia' defined in `.../nixos/modules/rename.nix' does not exist.
This reverts commit 5c897b4eff.
It seems like Gitlab doesn't pick up GITLAB_UPLOADS_PATH. The internal uploads
folder is already symlinked to /run/gitlab/uploads by the gitlab package. Here
we symlink this further to ${statePath}/uploads, since /run is (usually) a tmpfs.
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
The `.service` file defining the `systemd` unit for `autorandr.service`
which is bundled with the package itself uses `--default default` in the
`ExecStart` section. This can be an issue when having multiple layouts
(e.g. `default` as workstation layout I mostly work on and `mobile` when
I go somewhere else).
When the service gets restarted and `--default` can't be applied,
however the current layout can't be detected (e.g. when working with an
unknown beamer) the service silently fails with a message like this:
```
Jun 22 18:44:46 hauptshuhle autorandr[3168]: /nix/store/h83b72ffm68nm8fyjnppljchp456a94r-xrandr-1.5.0/bin/xrandr: ca>
Jun 22 18:44:46 hauptshuhle autorandr[3168]: Failed to apply profile 'default' (line 718):
Jun 22 18:44:46 hauptshuhle autorandr[3168]: Command failed: /nix/store/h83b72ffm68nm8fyjnppljchp456a94r-xrandr-1.>
```
As discussed in the IRC (see https://botbot.me/freenode/nixos/2018-07-05/?msg=101791455&page=6)
it's a bad long-term solution in terms of maintenance to manually patch
the service file bundled with the derivation, instead the service shall
be configured declaratively. Additionally this makes possible overrides
from the user-space way easier.
The `udev` rule (in `$out/etc/udev/rules.d`) won't' be affected, it
simply runs `systemctl start autorandr.service` when e.g. a new display
is added, so now `udev` communicates with the NixOS systemd unit.
The hooks directory contains now one level deep subdirectories which
need to be updated as well.
If you use gitea via ssh, ~/.ssh/authorized_keys also needs to be
updated because of the hardcoded path to gitea in the "command" option.
Ideally I'd like the whole `nixos`/`nixpkgs` channel distinction to disappear, but this is a step along that path. After a while being in this state, we can stop creating the magic `nixpkgs -> .` symlink inside our `nixos` channel tarballs and simplify that whole mess a bit.
If docker is enabled, start mesos-slave.service after docker.service
to avoid a race condition that could result in mesos-slave to fail
with "Failed to create docker: Timed out getting docker version"
The following changes have been applied:
- the property `http.headers.X-Content-Type-Options` must a list of
strings rather than a serialized list
- instead of `/etc/docker/registry/config.yml` the configuration will be
written with `pkgs.writeText` and the store path will be used to run
the registry. This reduces the risk of possible impurities by relying
on the Nix store only.
- cleaned up the property paths to easy readability and reduce the
verbosity.
- enhanced the testcase to ensure that digests can be deleted as well
- the `services.docker-registry.extraConfig` object will be merged with
`registryConfig`
/cc @ironpinguin
* checks using package providing the nix-daemon that we'll be using
* made optional (unlike some other config checks) "just in case":
since this requires running the new Nix on the builder, this
won't work in a few (AFAIK very uncommon) situations such as
cross-compiling NixOS or using `include` directives in nix.conf
This does rely on Nix2 but not by the builder.
Since we only offer Nix2+ in-tree this should be fine,
and may otherwise be required anyway.
HA doesn't mind the configuration being JSON instead of YAML but since YAML is
the official language, use that as it allows users to easily exchange config
data with other parties in the community.
Additionally, some settings based on NixOS configuation is set via defaultConfig
which is then merged with the user provided configration.
For now that just means http port and time zone but others can easily be added.
- `localSystem` is added, it strictly supercedes system
- `crossSystem`'s description mentions `localSystem` (and vice versa).
- No more weird special casing I don't even understand
TEMP
service-runner had a backwards incompatible update, and parsoid 0.9.0
doesn't work with current stable MediaWiki. Instead use as a source
a repository with 0.8.0 and pinned service-runner version.
Without `ROOT_PATH` set, `gogs serv` tries to open logs in writing in
its store directory. This blocks cloning or pushing over ssh, and
results in a gogs internal error.
The working directory needs the x flag, otherwise executors (e.g. sparks executor) are unable to cd into their sandbox and create e.g. temporary files.
Using gitea over ssh had two isses:
1. No shell was set for the user
2. Gitea tried to write logs to
/nix/store/x83q12kyd9gw1pay036dxz2dq0apf17h-gitea-1.3.2-bin/log when
serving the ssh usage.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
* The environment variables NIX_CONF_DIR, NIX_BUILD_HOOK and
NIX_REMOTE are no longer needed.
* A /bin/sh (from busybox) is provided by default in sandboxes.
* Various options were renamed.
This allows to configure additional configuration files for Synapse. This way
secrets can be kept in a secure place on the file system without a need to go
through the Nix store.
This makes the commonHook option work also for (read-only) Nix store
paths. Currently it fails on the second activation, because the
destination is read-only.
If neither database.password or database.passwordFile were provided,
it would try and fail to coerce null to a string.
This fixes the situation where there is no password for the database.
Resolves#27950
It doesn't look good when the initial admin user is named
"<hash>-gitolite-admin" and the key stored as
"<hash>-gitolite-admin.pub". Instead, make it simply "gitolite-admin"
and "gitolite-admin.pub".
Exhibitor tests the auto-manage-instances config value to see if it's a
non-zero integer, rather than a true/false string, which was getting
put into the config before. This now causes autoManageInstances to
behave correctly.
The previous package didn't build properly due to a bug in the build
script, and the nixos module didn't evaluate due to missing descriptions
in the options. This fixes both issues.
It also adds missing command-line options that weren't able to be set
and properly converts bools to the strings exhibitor expects.
The helper tool had a very early check whether the automatically created
CA key/cert are available and thus it would abort if the key was
unavailable even though we don't need or even want to have the CA key.
Unfortunately our NixOS test didn't catch this, because it was just
switching from a configuration with an automatically created CA to a
manual configuration without deleting the generated keys and certs.
This is done now in the tests and it's also fixed in the helper tool.
Reported-by: @jpotier
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
