* gnome3: only maintain single GNOME 3 package set
GNOME 3 was split into 3.10 and 3.12 in #2694. Unfortunately, we barely have the resources
to update a single version of GNOME. Maintaining multiple versions just does not make sense.
Additionally, it makes viewing history using most Git tools bothersome.
This commit renames `pkgs/desktops/gnome-3/3.24` to `pkgs/desktops/gnome-3`, removes
the config variable for choosing packageset (`environment.gnome3.packageSet`), updates
the hint in maintainer script, and removes the `gnome3_24` derivation from `all-packages.nix`.
Closes: #29329
* maintainers/scripts/gnome: Use fixed GNOME 3 directory
Since we now allow only a single GNOME 3 package set, specifying
the working directory is not necessary.
This commit sets the directory to `pkgs/desktops/gnome-3`.
- add flannel support
- remove deprecated authorizationRBACSuperAdmin option
- rename from deprecated poratalNet to serviceClusterIpRange
- add nodeIp option for kubelet
- kubelet, add br_netfilter to kernelModules
- enable firewall by default
- enable dns by default on node and on master
- disable iptables for docker by default on nodes
- dns, restart on failure
- update tests
and other minor changes
1. The chmod 400 with the preset cookie prevented restarts, as
on the second boot it would fail to write to the cookie. Oops.
2. As far as I can tell, sasl logs were disabled because of the
following error:
{error,{cannot_log_to_tty,sasl_report_tty_h,not_installed}}
Not because we actually wanted to disable them. This meant the
management plugin wasn't usable due to a bug set to be fixed in
3.7.0.
This has been broken nearly all the time due to the patches needed to
iproute2 not being compatible with the newer versions we have been
shipping. As long as Ubuntu does not manage to upstream these changes
so they are maintained with iproute2 and we don't have a maintainer
updating these patches to new iproute2 versions it is not feasible to
have this available.
This reverts commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
(cherry picked from commit 23a021d12e8f939cd0bfddb1c7adeb125028c1e3)
The getty@.service unit already has an ExecStart so we cannot simply set a new
one in order to override it or we will get this error:
systemd[1]: getty@tty1.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
Instead "reset" ExecStart by setting it to empty which is the systemd way of
doing it.
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
(cherry picked from commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6)
This commit was accidentally merged to 17.09 but was intended for
master. This is the cherry-pick to master.
Previously services depending on network-online.target would wait until
dhcpcd times out if it was enabled and a static network address
configuration was used. Setting the default gateway statically is enough
for the networking to be considered online.
This also adjusts the relevant networking tests to wait for
network-online.target instead of just network.target.
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
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist
For various reasons, big Nix attrsets look ugly in the generated manual
page[1]. Use literalExample to fix it.
[1] Quotes around attribute names are lost, newlines inside multi-line
strings are shown as '\n' and attrs written on multiple lines are joined
into one.
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".
* prometheus-collectd-exporter service: init module
Supports JSON and binary (optional) protocol
of collectd.
* nixos/prometheus-collectd-exporter: submodule is not needed for collectdBinary
Update physlock to a more current version which supports PAM and
systemd-logind. Amongst others, this should work now with the slim
login manager without any additional configuration, because it does
not rely on the utmp mechanism anymore.
I realize that advanced users like to configure services with Nix
attrsets, but I don't think we should remove the option to use the
(configuration) language provided by upstream.
When keys get refreshed a folder with the permissions of the root user
get created in the home directory of the user dnscrypt-wrapper. This
prevents the service from restarting.
In addition to that the parameters of dnscrypt-wrapper have
changed in upstream and in the newly packaged software.