Fixes #112834 where incorrect documentation of options was reported.
customIni used to replace the entire default configuration while the
new settings option is merged in with the default configuration
and still allows overriding options when needed.
Since the upstream graylogctl script will prefer finding its java
executable based on JAVA_HOME, we now set this instead of PATH in
order to allow it to find the JRE. By setting it conditionally on it
not already being set, we allow selecting a different JRE at runtime.
We also explicitly use openjdk11, which supports the
UseConcMarkSweepGC option which graylog insists on using.
This allows for shared hledger installations, where the web interface is
available via network and multiple user share a SSH access to the
hledger user.
Also added `--serve` to the CLI options, as hledger-web tries to open a
webbrowser otherwise:
hledger-web: xdg-open: rawSystem: runInteractiveProcess: exec: does not
exist (No such file or directory)
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
Maximum password length per cjdns code is somehwhere less than that, see
ecd01e7681/client/AdminClient.c (L80)
Currently we generate 96 char long passwords that don't work
This changes it so password length is just 32 chars long
This is useful when the config doesn't entirely live in the Nix store,
but is configured to include mutable config files written at runtime.
Co-Authored-By: Puck Meerburg <puck@puck.moe>
This fixes a class of errors seen on aarch64 during coredns import where content was seen to be missing ("digest xxx not found") or "failed to get reader from content store" depending on which coredns version was being imported.
Reverted https://github.com/NixOS/nixpkgs/pull/115228 for kodi to avoid conflict.
It does not look like unzip would be used but not investigating now to speed up merge conflict resolution.
If `openFirewall = true`, but no `firewallFilter` is set, the evaluation
fails with the following error:
The option `services.prometheus.exporters.node.firewallFilter` is defined both null and
not null, in `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'
and `/home/ma27/Projects/nixpkgs/nixos/modules/services/monitoring/prometheus/exporters.nix'.
Originally introduced by me in #115185. The problem is that
`mkOptionDefault` has - as its name suggests - the same priority as the
default-value of the option `firewallFilter` and thus it conflicts if
this declaration and the actual default value are set which is the case
if `firewallFilter` isn't specified somewhere else.
In the latest release of mautrix-telegram not all secrets can be set
using environment variables (see https://github.com/tulir/mautrix-telegram/issues/584).
This change allows these secret values to be set without ending up in
the Nix store.
This adds a new internal option, services.slurm.etcSlurm such
that other modules can access slurm's config files. This is
needed, for example, when a service wants to run a slurm command.
This is a major rewrite of the Privoxy module:
- As per RFC0042, remove privoxy.extraConfig and replace it
with a privoxy.settings option, which maps a NixOS freeform
submodule to the Privoxy configuration format.
- Move all top-level options that mirrored a setting to
the real ones in privoxy.settings. This still keeps the
type-checking, default values and examples in places.
- Add two convenience options: userActions and userFilters, which
simplify the operation of creating a file with pkgs.writeText,
converting it to a string and adding it to the actionsfile/
filterfile list.
- Add a privoxy.inspectHttps option to automagically setup TLS
decryption support. I don't know how long have been waiting
for this feature: can't believe it has just happened.
- Also add a privoxy.certsLifetime to control the periodical
cleanup of the temporary certificates generate by Privoxy.
The notification daemon is just one part of XFCE that is, to the best of
my understanding, not particularly related to it being desktop or not —
for instance, not more related than the session manager or the like.
We are running over 6000 tests by now and they take around 5 minutes
on faster machines and tests alot of components that endusers will not
actually be using. It is sufficient if we run them on package upgrades
and in the passthrough test.
This will make it easier to track specifically where queries are being
made from (assuming a `log_line_prefix` that includes `%a` in the
postgres configuration).
- Actually run tcsd as tss/tss
- Install a udev rule to set /dev/tpm* permissions
- Remove systemd-udev-settle dependency, use dev-tpm0.device instead
- Use systemd-tmpfiles to set up the state directory
- Add documentation URI to tcsd.service
This module cannot be easily tested with a NixOS test due to the TPM
dependency. Technically, one could be emulated using swtpm[1], but this
is not packaged in Nixpkgs. If you computer has a real TPM you can do a
passthrough in Qemu, but this requires running the VM as root and of
course it's not determinstic:
$ nix build -f nixos vm --arg configuration '
{
virtualisation.qemu.options = [
"-tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/sys/class/tpm/tpm0/cancel"
"-device tpm-tis,tpmdev=tpm0"
];
users.users.root.hashedPassword = "";
services.tcsd.enable = true;
}'
After starting the VM, log in as root, you can check the service has
started with `systemctl status tcsd`.
[1]: https://github.com/stefanberger/swtpm
- Use --netlink to avoid systemd-udev-settle[1]
- Run daemon in foreground which is preferred with systemd
- Add unit documentation
- Write ExecStart directly, no need for a script
[1]: 52bbd2b80b
To make it easier to start and stop all GitLab services, introduce
`gitlab.target` which wants all services (meaning they will start with
it) and which all services are part of (meaning they will stop with
it).
Make the config initialization script run in gitlab.service's PreStart
section into two new services, `gitlab-config.service` and
`gitlab-db-config.service`. Other services can then depend on the
config scripts they need instead of unnecessarily depending on
`gitlab.service`. This makes the reason for the configured service
dependencies much clearer and should also reduce the restart time of
the `gitlab` service quite a lot, when triggered manually.
Also, set up stricter service dependencies, using `bindsTo`, to ensure
that if a service fails or is stopped, its dependants are also
stopped. For example, if we're using the `postgresql` service and it's
stopped, `gitlab.service` and `gitlab-sidekiq.service`, which depend on
it to function, should also be stopped.
A function is more appropriate for this use. See
http://mywiki.wooledge.org/BashFAQ/050 for reference.
Also, we don't need to run the service as root: since we essentially
run all commands as `services.postgresql.superUser` anyway, the whole
service can just run as that user instead.
Change the default SMTP port to `25`, to better match the default
address `localhost`. This gets rid of some error outputs in the test,
where it fails to connect to localhost:465.
Also, don't enable postfix by default unless it's actually useful to
us.
This removes all the subdirectories in `config` on start.
From one version of GitLab to the next, the files in the `config`
directory changes. Since we're only overwriting the existing files
with ones from the repo, cruft sometimes gets left behind,
occationally causing issues.
Ideally, all configuration put in the `config` directory is declared
by NixOS options and we could just remove the whole directory on
start, but I'm not sure if that's the case. It would also require a
little bit of additional rework and testing. The subdirectories,
however, should seldom contain user configuration and the ones that
frequently does, `initializers`, is already removed on start.
ChangeLog: https://nextcloud.com/changelog/#latest21
* Packaged 21.0.0, test-deployed it to my personal instance and tested
the most basic functionality (`davfs2`-mount, {card,cal}dav sync, file
management).
* Bumped the default version for unstable/21.05 to `nextcloud21`. Since
`nextcloud20` was added after the release of 20.09 (and thus the
default on 20.09 is still `nextcloud19`), it's now needed to upgrade
across two majors.
This is not a problem though since it's possible to upgrade to v20 on
20.09 already and if not, the module will guard the administrator
through the upgrade with eval warnings as it's the case since 20.03.
* Dropped `nextcloud17` attribute and marked `nextcloud18` as EOL.
Say this 10 times so I don't forget:
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
- just because something has been tested and confirmed working, doesn't
mean that a trivial change can go in without testing simply because
it looks OK. test, test, test.
I'm sorry guys.
4255954d97 set the StateDirectory to 0750,
but nginx wasn't in the Mastodon group. This commit also deletes a line,
that probably was intended to serve this purpose, but makes no sense.
Why should the Mastodon user be added as an extraGroup to the nginx
user?
The `--apis=` command line parameter passed to Jitsi Videobridge is
required to monitor a Jitsi Meet instance for example via the prometheus
exporter [jitsiexporter](https://git.xsfx.dev/prometheus/jitsiexporter).
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
Account for the fact that, when creating a lua package without the
"withPackages" helper, we dont get an extra "lua" attribute in the
package.
Therefore we need to distinguish between the "withPackages" case and the
direct ( or "empty" ) lua package.
For example with this nixos config:
```nix
{
services.httpd = {
enable = true;
package = pkgs.apacheHttpd.override {
luaSupport = true;
lua5 = pkgs.lua5_3.withPackages (ps: with ps; [ luafilesystem ] );
};
};
}
```
Here we say that we want to have apache to use a lua, packaged with the
`luafilesystem` module so that we can `require` that in scripts to
render http responses. There, the set that gets assigned to `lua5 ` does
not have a `luaversion` attribute, rather it has a `lua` attribute
wherein lies a `luaversion` attribute. If we dont package additional
modules, then we dont have that `lua` attribute in between and rather
directly have to use `luaversion` directly.
For sa-update we care about two successful codes:
* 1 -> no updates available: exit successfully
* 0 -> updates have been installed: run sa-compile and pass
through its return code
sa-compile speeds up processing the rules by compiling them from Perl to
C. This needs to be run after every update and is saved in the local
state directory by Perl and SpamAssassin version.
Let systemd create SpamAssassin's state directory and populate it using the
regular updater service. Depend on the updater service on boot but do not
propagate failure to the main service.
spamd's commands to start and reload the service are still executed as
root but user/group are set to properly chown the state directory to the
target user. spamd drops privileges itself for its runner children but
preserves root on the main daemon (to listen and re-exec).
sa-update currently runs as part of the pre-start script of spamd. The
network is not guaranteed to be online at that point and even if we
were to depend on that, it makes the bootup brittle, as there is a
reliance on SpamAssassin's update server as a startup dependency on
boot.
Refactor the setup to move the pre-start script into its own unit.
This allows to perform the setup task only once. Continuous updates
are already done by sa-update.service triggered by sa-update.timer.
Only run sa-update in case /var/lib/spamassassin is empty.
While we are on it, let sa-update.service depend on the network being
online.
Fixes redirection after signing in when you use a single oauth2_proxy
instance for multiple domains.
X-Auth-Request-Redirect header is used to decide which URL to redirect
to after signing in. Specifying `request_uri` is enough in case you
need to redirect to the same domain that serves oauth2 callback
endpoint, but with multiple domains the you should include the scheme
and the host.
