The OS Login package enables the following components:
AuthorizedKeysCommand to query valid SSH keys from the user's OS Login
profile during ssh authentication phase.
NSS Module to provide user and group information
PAM Module for the sshd service, providing authorization and
authentication support, allowing the system to use data stored in
Google Cloud IAM permissions to control both, the ability to log into
an instance, and to perform operations as root (sudo).
Having pam_unix set to "sufficient" means early-succeeding account
management group, as soon as pam_unix.so is succeeding.
This is not sufficient. For example, nixos modules might install nss
modules for user lookup, so pam_unix.so succeeds, and we end the stack
successfully, even though other pam account modules might want to do
more extensive checks.
Other distros seem to set pam_unix.so to 'required', so if there are
other pam modules in that management group, they get a chance to do some
validation too.
For SSSD, @PsyanticY already added a workaround knob in
https://github.com/NixOS/nixpkgs/pull/31969, while stating this should
be the default anyway.
I did some thinking in what could break - after this commit, we require
pam_unix to succeed, means we require `getent passwd $username` to
return something.
This is the case for all local users due to the passwd nss module, and
also the case for all modules installing their nss module to
nsswitch.conf - true for ldap (if not explicitly disabled) and sssd.
I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss
module loaded? Should the pam account module be placed before pam_unix?
We don't drop the `security.pam.services.<name?>.sssdStrictAccess`
option, as it's also used some lines below to tweak error behaviour
inside the pam sssd module itself (by changing it's 'control' field).
This is also required to get admin login for Google OS Login working
(#51566), as their pam_oslogin_admin accounts module takes care of sudo
configuration.
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.
This flag causes the shairport-sync server to attempt to daemonize, but it looks like systemd is already handling that. With the `-d` argument, shairport-sync immediately exits—it seems that something (systemd I'm guessing?) is sending it SIGINT or SIGTERM.
The [upstream systemd unit](https://github.com/mikebrady/shairport-sync/blob/master/scripts/shairport-sync.service.in#L10) doesn't pass `-d`.
pkgs.owncloud still pointed to owncloud 7.0.15 (from May 13 2016)
Last owncloud server update in nixpkgs was in Jun 2016.
At the same time Nextcloud forked away from it, indicating users
switched over to that.
cc @matej (original maintainer)
Systemd provides an option for allocating DynamicUsers
which we want to use in NixOS to harden service configuration.
However, we discovered that the user wasn't allocated properly
for services. After some digging this turned out to be, of course,
a cache inconsistency problem.
When a DynamicUser creation is performed, Systemd check beforehand
whether the requested user already exists statically. If it does,
it bails out. If it doesn't, systemd continues with allocating the
user.
However, by checking whether the user exists, nscd will store
the fact that the user does not exist in it's negative cache.
When the service tries to lookup what user is associated to its
uid (By calling whoami, for example), it will try to consult
libnss_systemd.so However this will read from the cache and tell
report that the user doesn't exist, and thus will return that
there is no user associated with the uid. It will continue
to do so for the cache duration time. If the service
doesn't immediately looks up its username, this bug is not
triggered, as the cache will be invalidated around this time.
However, if the service is quick enough, it might end up
in a situation where it's incorrectly reported that the
user doesn't exist.
Preferably, we would not be using nscd at all. But we need to
use it because glibc reads nss modules from /etc/nsswitch.conf
by looking relative to the global LD_LIBRARY_PATH. Because LD_LIBRARY_PATH
is not set globally (as that would lead to impurities and ABI issues),
glibc will fail to find any nss modules.
Instead, as a hack, we start up nscd with LD_LIBRARY_PATH set
for only that service. Glibc will forward all nss syscalls to
nscd, which will then respect the LD_LIBRARY_PATH and only
read from locations specified in the NixOS config.
we can load nss modules in a pure fashion.
However, I think by accident, we just copied over the default
settings of nscd, which actually caches user and group lookups.
We already disable this when sssd is enabled, as this interferes
with the correct working of libnss_sss.so as it already
does its own caching of LDAP requests.
(See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd)
Because nscd caching is now also interferring with libnss_systemd.so
and probably also with other nsss modules, lets just pre-emptively
disable caching for now for all options related to users and groups,
but keep it for caching hosts ans services lookups.
Note that we can not just put in /etc/nscd.conf:
enable-cache passwd no
As this will actually cause glibc to _not_ forward the call to nscd
at all, and thus never reach the nss modules. Instead we set
the negative and positive cache ttls to 0 seconds as a workaround.
This way, Glibc will always forward requests to nscd, but results
will never be cached.
Fixes#50273
Right now it's not at all obvious that one can override this option
using `services.logind.extraConfig`; we might as well add an option
for `killUserProcesses` directly so it's clear and documented.
Could also move kdc.conf, but this makes it inconvenient to use command line
utilities with heimdal, as it would require specifying --config-file with every
command.
Allow switching out kerberos server implementation.
Sharing config is probably sensible, but implementation is different enough to
be worth splitting into two files. Not sure this is the correct way to split an
implementation, but it works for now.
Uses the switch from config.krb5 to select implementation.
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
Instead of setting User/Group only when DynamicUser is disabled, the
previous version of the code set it only when it was enabled. This
caused services with DynamicUser enabled to actually run as nobody, and
services without DynamicUser enabled to run as root.
Regression from fbb7e0c82f.
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>
Currently there are two calls to curl in the reloadScript, neither which
check for errors. If something is misconfigured (like wrong authToken),
the only trace that something wrong happened is this log message:
Asking Jenkins to reload config
<h1>Bad Message 400</h1><pre>reason: Illegal character VCHAR='<'</pre>
The service isn't marked as failed, so it's easy to miss.
Fix it by passing --fail to curl.
While at it:
* Add $curl_opts and $jenkins_url variables to keep the curl command
lines DRY.
* Add --show-error to curl to show short error message explanation when
things go wrong (like HTTP 401 error).
* Lower-case the $CRUMB variable as upper case is for exported environment
variables.
The new behaviour, when having wrong accessToken:
Asking Jenkins to reload config
curl: (22) The requested URL returned error: 401
And the service is clearly marked as failed in `systemctl --failed`.
When privateNetwork is enabled, currently the container's interface name
is derived from the container name. However, there's a hard limit
on the size of interface names. To avoid conflicts and other issues,
we set a limit on the container name when privateNetwork is enabled.
Fixes#38509
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>
The new reuse behaviour is cool and really useful but it breaks one of
my use cases. When using kexec, I have a script which will unlock the
disks in my initrd. However, do_open_passphrase will fail if the disk is
already unlocked.
According to the dbus-launch documentation [0] "--exit-with-session"
shouldn't be used: "This option is not recommended, since it will
consume input from the terminal where it was started; it is mainly
provided for backwards compatibility." And it also states: "To start a
D-Bus session within a text-mode session, do not use dbus-launch.
Instead, see dbus-run-session(1)."
The new wrapper also avoids starting an additional D-Bus session if
DBUS_SESSION_BUS_ADDRESS is already set.
Fix#51303.
[0]: https://dbus.freedesktop.org/doc/dbus-launch.1.html
[1]: https://dbus.freedesktop.org/doc/dbus-run-session.1.html
As the comment notes, restarts/exits of dhcpcd generally require
restarting the NTP service since, if name resolution fails for a pool of
servers, the service might break itself. To be on the safe side, try
restarting Chrony in these instances, too.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Setting the server list to be empty is useful e.g. for hardware-only
or virtualized reference clocks that are passed through to the system
directly. In this case, initstepslew has no effect, so don't emit it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Part of #49783. NextCloud tracks in its `config.php` the application's
state which makes it hard for the module to modify configurations during
upgrades.
It will take time until the issue is properly fixed, therefore we
decided to warn about this in the manual.
This PR addresses two things:
* Adding a basic example for nextcloud. I figured it to be helpful to
add some basic usage instructions when adding a new manual entry.
Advanced documentation may follow later.
For now this document actively links to the service options, so users
are guided to the remaining options that can be helpful in certain
cases.
* Add a warning about upgrades and manual changes in
`/var/lib/nextcloud`. This will be fixed in the future, but it's
definetely helpful to document the current issues in the manual (as
proposed in https://github.com/NixOS/nixpkgs/issues/49783#issuecomment-439691127).
```
b Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy.
```
It seems the "less secure if a crash happens" does not need a crash to
happen.
With batch mode:
```
/[...]/.
Start (0) does not point to parent (___)
```
For pretty much everything copied in.
Without batch mode, everything passes `fsck`.
See #51150
```
b Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy.
```
It seems the "less secure if a crash happens" does not need a crash to
happen.
With batch mode:
```
/[...]/.
Start (0) does not point to parent (___)
```
For pretty much everything copied in.
Without batch mode, everything passes `fsck`.
See #51150
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.
ZFS's popularity is growing, and not including it by default is a
bit frustrating. On top of that, the base iso includes ZFS
_anyway_ due to other packages depending upon it.
I think we're in the clear to do this on the basis that Oracle
probably doesn't care, it is probably fine (the SFLC agrees) and
we're a small fish. If a copyright holder asks us to, we can
definitely revert it again.
This reverts commit 33d07c7ea9.
When reworking the rspamd workers I disallowed `proxy` as a type and
instead used `rspamd_proxy` which is the correct name for that worker
type. That change breaks peoples existing config and so I have made this
commit which allows `proxy` as a worker type again but makes it behave
as `rspamd_proxy` and prints a warning if you use it.
