The default, which is /tmp, has a few issues associated with it:
One being that it makes it easy for users on the system to spoof a
PostgreSQL server if it's not running, causing applications to connect
to their provided sockets instead of just failing to connect.
Another one is that it makes sandboxing of PostgreSQL and other services
unnecessarily difficult. This is already the case if only PrivateTmp is
used in a systemd service, so in order for such a service to be able to
connect to PostgreSQL, a bind mount needs to be done from /tmp to some
other path, so the service can access it. This pretty much defeats the
whole purpose of PrivateTmp.
We regularily run into issues with this in the past already (one example
would be https://github.com/NixOS/nixpkgs/pull/24317) and with the new
systemd-confinement mode upcoming in
https://github.com/NixOS/nixpkgs/pull/57519, it makes it even more
tedious to sandbox services.
I've tested this change against all the postgresql NixOS VM tests and
they still succeed and I also grepped through the source tree to replace
other occasions where we might have /tmp hardcoded. Luckily there were
very few occasions.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ocharles, @thoughtpolice, @danbst
The default galera_new_cluster script tries to set this environment
variable using systemctl set-environment which doesn't work if the
variable is not being used in the unit file ;)
Although the package itself builds fine, the module fails because it
tries to log into a non-existant file in `/var/log` which breaks the
service. Patching to default config to log to stdout by default fixes
the issue. Additionally this is the better solution as NixOS heavily
relies on systemd (and thus journald) for logging.
Also, the runtime relies on `/etc/localtime` to start, as it's not
required by the module system we set UTC as sensitive default when using
the module.
To ensure that the service's basic functionality is available, a simple
NixOS test has been added.
As cassandra start script hardcodes the location of logback
configuration to `CASSANDRA_CONF_DIR/logback.xml` there is no way to
pass an alternate file via `$JVM_OPTS` for example.
Also, without logback configuration DEBUG level is used which is not
necessary for standard usage.
With this commit a default logback configuration is set with log level
INFO.
Configuration borrowed from:
https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configLoggingLevels.html
This cleans up the CockroachDB expression, with a few suggestions from
@aszlig.
However, it brought up the note of using systemd's StateDirectory=
directive, which is a nice feature for managing long-term data files,
especially for UID/GID assigned services. However, it can only manage
directories under /var/lib (for global services), so it has to introduce
a special path to make use of it at all in the case someone wants a path
at a different root.
While the dataDir directive at the NixOS level is _occasionally_ useful,
I've gone ahead and removed it for now, as this expression is so new,
and it makes the expression cleaner, while other kinks can be worked out
and people can test drive it.
CockroachDB's dataDir directive, instead, has been replaced with
systemd's StateDirectory management to place the data under
/var/lib/cockroachdb for all uses.
There's an included RequiresMountsFor= clause like usual though, so if
people want dependencies for any kind of mounted device at boot
time/before database startup, it's easy to specify using their own
mount/filesystems clause.
This can also be reverted if necessary, but, we can see if anyone ever
actually wants that later on before doing it -- it's a backwards
compatible change, anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This also includes a full end-to-end CockroachDB clustering test to
ensure everything basically works. However, this test is not currently
enabled by default, though it can be run manually. See the included
comments in the test for more information.
Closes#51306. Closes#38665.
Co-authored-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This allows, finally, proper detection when postgresql is ready to
accept connections. Until now, it was possible that services depending
on postgresql would fail in a race condition trying to connect
to postgresql.
While this seems silly at first (it's already given as start parameter
to mysqld), it seems like xtrabackup needs that sometimes.
Without it, a Galera cluster cannot be run using the xtrabackup
replication method.
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...
1) Change start-type to ```notify``` when running MariaDB so that we don't have to busy-wait for the
socket to appear.
2) Do not manually create the directory under /run as we can get systemd to do
that for us. This opens up the possibility later for not having to launch as root.
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
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.
Comparing packages via equality will lead to different results when package and module are from different
`nixpkgs` checkouts.
Also, because MariaDB is actually supported, added a note to option description to make this knowledge more discover-able.
`nixos-option` evals the description and the '`' is used to
define shell commands.
Due to this, the following error appears:
```
$ nixos-option services.postgresql.superUser
Value:
"root"
Default:
"root"
Description:
/run/current-system/sw/bin/nixos-option: line 294: root: command not found
/run/current-system/sw/bin/nixos-option: line 294: postgres: command not found
NixOS traditionally used as superuser, most other distros use .
From 17.09 we also try to follow this standard. Internal since changing this value
would lead to breakage while setting up databases.
```
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.
* 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
Version 2.0.0 is installed as a separate package called "couchdb2".
When setting the config option "package" attribute to pkgs.couchdb2, a
corresponding service configuration will be generated. If a previous
1.6 installation exists, the databases can still be found on the local
port (default: 5986) and can be replicated from there.
Note that single-node or cluster setup still needs to be configured
manually, as described in
http://docs.couchdb.org/en/2.0.0/install/index.html.
riak-cs: added to all-packages
Added Riak CS nix file to pkgs
Added service file for Riak CS
Removed Erlang_basho specific bindings from the Riak CS repo
riak-cs: changed description
riak-cs: added license
riak-cs: added maintainer
riak_cs: chgned indentations
riak-cs: removed overly complex srcs mechanism
riak-cs: added systemd module
riak-cs: changed Erlang module to Basho-specific version
riak-cs: made modular form
riak-cs: Added a default package in service options
riak-cs: Fixed default package in service options
riak-cs: Patched Makefile
riak_cs: added to module-list
riak_cs: changed from string to actual package in modules
riak-cs: changed example
riak-cs: removed default
riak-cs: changed to defaultText
stanchion: changed default option to defaultText
riak-cs: added defaults; changed types to str
riak-cs: added to all-packages
Added Riak CS nix file to pkgs
Added service file for Riak CS
Removed Erlang_basho specific bindings from the Riak CS repo
riak-cs: changed description
riak-cs: added license
riak-cs: added maintainer
riak_cs: chgned indentations
riak-cs: removed overly complex srcs mechanism
riak-cs: added systemd module
riak-cs: changed Erlang module to Basho-specific version
riak-cs: made modular form
riak-cs: Added a default package in service options
riak-cs: Fixed default package in service options
riak-cs: Patched Makefile
riak_cs: added to module-list
riak_cs: changed from string to actual package in modules
* influxdb module: add postStart
* cadvisor module: increase TimeoutStartSec
Under high load, the cadvisor module can take longer than the default 90
seconds to start. This change should hopefully fix the test on Hydra.
Systemd upstream provides targets for networking. This also includes a target network-online.target.
In this PR I remove / replace most occurrences since some of them were even wrong and could delay startup.
Fixes#15512 and #16032
With the multi output, postgresql cannot find at runtime what is its
basedir when looking for libdir and pkglibdir. This commit fixes that.
Previously it was only set once, now it is enforced on each start-up of
redis.service. Also set _ownership_ recursively, so that the
/var/lib/redis/dump.rdb file is guaranteed to be accessible by the
currently configured redis user.
Fixes issue #9687, where redis wouldn't start because /var/lib/redis had
wrong owner.
The module will configure a Cassandra server with common options being
tweakable. Included is also a test which will spin up 3 nodes and
verify that the cluster can be formed, broken, and repaired.
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Regression introduced by b21fd5d066.
The initialScript is only executed whenever there is a .first-startup in
the dataDir, so silently dropping the file essentially breaks
initialScript functionality.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Authentication methods are tried in order, so if another NixOS module
defines a specific ident mapping like
local hydra all ident map=hydra-users
it should appear before the generic
local all all ident
When starting from a clean slate, the couchdb service fails.
First, the pre-start script fails because it tries to chown the uriFile,
which doesn't exist. It also doesn't ensure that the directory in which
the uriFIle is placed is writeable by couchdb, which could also cause
failure (though I didn't observe this).
Additionally, the log file's default location isn't a directory owned by
couchdb, nor is the file guaranteed to exist, nor is it guaranteed to be
chowned to the appropriate user. All of which can cause unexpected
failure.
As a bonus I made a small change in the description of the configFile
attribute, in the hopes of making it a little more obvious why it
existed.
