mirror of
https://github.com/systemd/systemd.git
synced 2024-11-23 18:23:32 +08:00
Luca Boccassi
GitHub
commit
b0003b86fb
36
TODO
36
TODO
@ -496,11 +496,11 @@ Features:
|
||||
|
||||
* add a new EFI tool "sd-fetch" or so. It looks in a PE section ".url" for an
|
||||
URL, then downloads the file from it using UEFI HTTP APIs, and executes it.
|
||||
Usecase: provide a minimal ESP with sd-boot and a couple of these sd-fetch
|
||||
Use case: provide a minimal ESP with sd-boot and a couple of these sd-fetch
|
||||
binaries in place of UKIs, and download them on-the-fly.
|
||||
|
||||
* maybe: systemd-loop-generator that sets up loopback devices if requested via kernel
|
||||
cmdline. usecase: include encrypted/verity root fs in UKI.
|
||||
cmdline. use case: include encrypted/verity root fs in UKI.
|
||||
|
||||
* systemd-gpt-auto-generator: add kernel cmdline option to override block
|
||||
device to dissect. also support dissecting a regular file. useccase: include
|
||||
@ -573,7 +573,7 @@ Features:
|
||||
subsequent boots?
|
||||
|
||||
* provide an API (probably IPC) to apps to encrypt/decrypt
|
||||
credentials. usecase: allow bluez bluetooth daemon to pass pairings to initrd
|
||||
credentials. use case: allow bluez bluetooth daemon to pass pairings to initrd
|
||||
that way, without shelling out to our tools.
|
||||
|
||||
* revisit default PCR bindings in cryptenroll and systemd-creds. Currently they
|
||||
@ -631,7 +631,7 @@ Features:
|
||||
|
||||
* systemd-repart: in addition to the existing "factory reset" mode (which
|
||||
simply empties existing partitions marked for that). add a mode where
|
||||
partitions marked for it are entirely removed. Usecase: remove secondary OS
|
||||
partitions marked for it are entirely removed. Use case: remove secondary OS
|
||||
copy, and redundant partitions entirely, and recreate them anew.
|
||||
|
||||
* systemd-boot: maybe add support for collapsing menu entries of the same OS
|
||||
@ -677,7 +677,7 @@ Features:
|
||||
* add support for asymmetric LUKS2 TPM based encryption. i.e. allow preparing
|
||||
an encrypted image on some host given a public key belonging to a specific
|
||||
other host, so that only hosts possessing the private key in the TPM2 chip
|
||||
can decrypt the volume key and activate the volume. Usecase: systemd-confext
|
||||
can decrypt the volume key and activate the volume. Use case: systemd-confext
|
||||
for a central orchestrator to generate confext images securely that can only
|
||||
be activated on one specific host (which can be used for installing a bunch
|
||||
of creds in /etc/credstore/ for example). Extending on this: allow binding
|
||||
@ -690,7 +690,7 @@ Features:
|
||||
current system state, i.e. a combination of PCR information, local system
|
||||
time and TPM clock, running services, recent high-priority log
|
||||
messages/coredumps, system load/PSI, signed by the local TPM chip, to form an
|
||||
enhanced remote attestation quote. Usecase: a simple orchestrator could use
|
||||
enhanced remote attestation quote. Use case: a simple orchestrator could use
|
||||
this: have the report tool upload these reports every 3min somewhere. Then
|
||||
have the orchestrator collect these reports centrally over a 3min time
|
||||
window, and use them to determine what which node should now start/stop what,
|
||||
@ -745,7 +745,7 @@ Features:
|
||||
* Add "purpose" flag to partition flags in discoverable partition spec that
|
||||
indicate if partition is intended for sysext, for portable service, for
|
||||
booting and so on. Then, when dissecting DDI allow specifying a purpose to
|
||||
use as additional search condition. Usecase: images that combined a sysext
|
||||
use as additional search condition. Use case: images that combined a sysext
|
||||
partition with a portable service partition in one.
|
||||
|
||||
* On boot, auto-generate an asymmetric key pair from the TPM,
|
||||
@ -861,7 +861,7 @@ Features:
|
||||
usr=
|
||||
• systemd-homed: when initializing, look for a credential
|
||||
systemd.homed.register or so with JSON user records to automatically
|
||||
register if not registered yet. Usecase: deploy a system, and add an
|
||||
register if not registered yet. Use case: deploy a system, and add an
|
||||
account one can directly log into.
|
||||
• in gpt-auto-generator: check partition uuids against such uuids supplied via
|
||||
sd-stub credentials. That way, we can support parallel OS installations with
|
||||
@ -887,7 +887,7 @@ Features:
|
||||
|
||||
* sd-boot: instead of unconditionally deriving the ESP to search boot loader
|
||||
spec entries in from the paths of sd-boot binary, let's optionally allow it
|
||||
to be configured on sd-boot cmdline + efi var. Usecase: embed sd-boot in the
|
||||
to be configured on sd-boot cmdline + efi var. Use case: embed sd-boot in the
|
||||
UEFI firmware (for example, ovmf supports that via qemu cmdline option), and
|
||||
use it to load stuff from the ESP.
|
||||
|
||||
@ -927,7 +927,7 @@ Features:
|
||||
* homed/userdb: maybe define a "companion" dir for home directories where apps
|
||||
can safely put privileged stuff in. Would not be writable by the user, but
|
||||
still conceptually belong to the user. Would be included in user's quota if
|
||||
possible, even if files are not owned by UID of user. Usecase: container
|
||||
possible, even if files are not owned by UID of user. Use case: container
|
||||
images that owned by arbitrary UIDs, and are owned/managed by the users, but
|
||||
are not directly belonging to the user's UID. Goal: we shouldn't place more
|
||||
privileged dirs inside of unprivileged dirs, and thus containers really
|
||||
@ -1032,7 +1032,7 @@ Features:
|
||||
look for right in the sd-boot binary. i.e. take inspiration from sd-stub
|
||||
logic: allow combining sd-boot via ukify with kernels to enumerate, .conf
|
||||
files, drivers, keys to enroll and so on. Then, add whatever we find that way
|
||||
to the menu. Usecase: allow building a single PE image you can boot into via
|
||||
to the menu. Use case: allow building a single PE image you can boot into via
|
||||
UEFI HTTP boot.
|
||||
|
||||
* maybe add a new UEFI stub binary "sd-http". It works similar to sd-stub, but
|
||||
@ -1053,7 +1053,7 @@ Features:
|
||||
* maybe add a generator that reads /proc/cmdline, looks for
|
||||
systemd.pull-raw-portable=, systemd-pull-raw-sysext= and similar switches
|
||||
that take a URL as parameter. It then generates service units for
|
||||
systemd-pull calls that download these URLs if not installed yet. usecase:
|
||||
systemd-pull calls that download these URLs if not installed yet. Use case:
|
||||
invoke a VM or nspawn container in a way it automatically deploys/runs these
|
||||
images as OS payloads. i.e. have a generic OS image you can point to any
|
||||
payload you like, which is then downloaded, securely verified and run.
|
||||
@ -1152,9 +1152,9 @@ Features:
|
||||
|
||||
* add tiny service that decrypts encrypted user records passed via initrd
|
||||
credential logic and drops them into /run where nss-systemd can pick them up,
|
||||
similar to /run/host/userdb/. Usecase: drop a root user JSON record there,
|
||||
similar to /run/host/userdb/. Use case: drop a root user JSON record there,
|
||||
and use it in the initrd to log in as root with locally selected password,
|
||||
for debugging purposes. Other usecase: boot into qemu with regular user
|
||||
for debugging purposes. Other use case: boot into qemu with regular user
|
||||
mounted from host. maybe put this in systemd-user-sessions.service?
|
||||
|
||||
* drop dependency on libcap, replace by direct syscalls based on
|
||||
@ -1262,7 +1262,7 @@ Features:
|
||||
the resulting fd to the service program via socket activation proto.
|
||||
|
||||
* Add a concept of ListenStream=anonymous to socket units: listen on a socket
|
||||
that is deleted in the fs. Usecase would be with ConnectSocket= above.
|
||||
that is deleted in the fs. Use case would be with ConnectSocket= above.
|
||||
|
||||
* importd: support image signature verification with PKCS#7 + OpenBSD signify
|
||||
logic, as alternative to crummy gpg
|
||||
@ -1552,7 +1552,7 @@ Features:
|
||||
else. Similar, ManagerSlice= should exist so that PID1's own scope unit could
|
||||
be moved somewhere else too. Finally machined and logind should get similar
|
||||
options so that it is possible to move user session scopes and machines to a
|
||||
different slice too by default. Usecase: people who want to put resources on
|
||||
different slice too by default. Use case: people who want to put resources on
|
||||
the entire system, with the exception of one specific service. See:
|
||||
https://lists.freedesktop.org/archives/systemd-devel/2018-February/040369.html
|
||||
|
||||
@ -1852,7 +1852,7 @@ Features:
|
||||
- generate better errors when people try to set transient properties
|
||||
that are not supported...
|
||||
https://lists.freedesktop.org/archives/systemd-devel/2015-February/028076.html
|
||||
- maybe introduce WantsMountsFor=? Usecase:
|
||||
- maybe introduce WantsMountsFor=? Use case:
|
||||
https://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
|
||||
- recreate systemd's D-Bus private socket file on SIGUSR2
|
||||
- move PAM code into its own binary
|
||||
@ -1924,7 +1924,7 @@ Features:
|
||||
* BootLoaderSpec: Define a way how an installer can figure out whether a BLS
|
||||
compliant boot loader is installed.
|
||||
|
||||
* think about requeuing jobs when daemon-reload is issued? usecase:
|
||||
* think about requeuing jobs when daemon-reload is issued? use case:
|
||||
the initrd issues a reload after fstab from the host is accessible
|
||||
and we might want to requeue the mounts local-fs acquired through
|
||||
that automatically.
|
||||
|
||||
@ -32,7 +32,7 @@ maintains a duplicate of it (in the sense of UNIX
|
||||
also in possession of the service itself, and it may (and is expected to)
|
||||
invoke any operations on it that it likes.
|
||||
|
||||
The primary usecase of this logic is to permit services to restart seamlessly
|
||||
The primary use case of this logic is to permit services to restart seamlessly
|
||||
(for example to update them to a newer version), without losing execution
|
||||
context, dropping pinned resources, terminating established connections or even
|
||||
just momentarily losing connectivity. In fact, as the file descriptors can be
|
||||
@ -81,7 +81,7 @@ And that's already the gist of it.
|
||||
A system service that provides a client-facing interface that shall be able to
|
||||
seamlessly restart can make use of this in a scheme like the following:
|
||||
whenever a new connection comes in it uploads its fd immediately into its
|
||||
fdstore. At approporate times it also serializes its state into a memfd it
|
||||
fdstore. At appropriate times it also serializes its state into a memfd it
|
||||
uploads to the service manager — either whenever the state changed
|
||||
sufficiently, or simply right before it terminates. (The latter of course means
|
||||
that state only survives on *clean* restarts and abnormal termination implies the
|
||||
@ -104,7 +104,7 @@ lifecycle management (i.e. `KillMode=none` must be set), which disables large
|
||||
parts of the service managers state tracking, resource management (as resource
|
||||
counters cannot start at zero during service activation anymore, since the old
|
||||
processes remaining skew them), security policies (as processes with possibly
|
||||
out-of-date security policies – selinux, AppArmor, any LSM, seccomp, BPF — in
|
||||
out-of-date security policies – SElinux, AppArmor, any LSM, seccomp, BPF — in
|
||||
effect remain), and similar.
|
||||
|
||||
# File Descriptor Store Lifecycle
|
||||
@ -176,7 +176,7 @@ This mechanism can be enabled either by making sure the service survives until
|
||||
the very end (i.e. by setting `DefaultDependencies=no` so that it keeps running
|
||||
for the whole system lifetime without being regularly deactivated at shutdown)
|
||||
or by setting `FileDescriptorStorePresever=yes` (and referencing the unit
|
||||
continously).
|
||||
continuously).
|
||||
|
||||
# Debugging
|
||||
|
||||
|
||||
@ -512,7 +512,7 @@
|
||||
together the former is applied first. If a directory listed already exists no operation is executed
|
||||
(in particular, the ownership/access mode of the directories is left as is).</para>
|
||||
|
||||
<para>The primary usecase for this option is to create a minimal set of directories that may be
|
||||
<para>The primary use case for this option is to create a minimal set of directories that may be
|
||||
mounted over by other partitions contained in the same disk image. For example, a disk image where
|
||||
the root file system is formatted at first boot might want to automatically pre-create
|
||||
<filename>/usr/</filename> in it this way, so that the <literal>usr</literal> partition may
|
||||
|
||||
@ -114,7 +114,7 @@
|
||||
for details. For file descriptors pushed into the file descriptor
|
||||
store (see above), the name is set via the
|
||||
<varname>FDNAME=</varname> field transmitted via
|
||||
<function>sd_pid_notify_with_fds()</function>. The primary usecase
|
||||
<function>sd_pid_notify_with_fds()</function>. The primary use case
|
||||
for these names are services which accept a variety of file
|
||||
descriptors which are not recognizable with functions like
|
||||
<function>sd_is_socket()</function> alone, and thus require
|
||||
|
||||
@ -1485,11 +1485,11 @@ After=sys-subsystem-net-devices-ens1.device</programlisting>
|
||||
multiple times for creating multiple independent bind mount points.</para>
|
||||
|
||||
<para>Mount options are comma-separated. <option>rbind</option> and <option>norbind</option> control whether
|
||||
to create a recursive or a regular bind mount. Defaults to "rbind". <option>noidmap</option>,
|
||||
to create a recursive or a regular bind mount. Defaults to <option>rbind</option>. <option>noidmap</option>,
|
||||
<option>idmap</option>, and <option>rootidmap</option> control ID mapping.</para>
|
||||
|
||||
<para>Using <option>idmap</option> or <option>rootidmap</option> requires support by the source filesystem
|
||||
for user/group ID mapped mounts. Defaults to "noidmap". With <option>x</option> being the container's UID range
|
||||
for user/group ID mapped mounts. Defaults to <option>noidmap</option>. With <option>x</option> being the container's UID range
|
||||
offset, <option>y</option> being the length of the container's UID range, and <option>p</option> being the
|
||||
owner UID of the bind mount source inode on the host:
|
||||
|
||||
|
||||
@ -135,7 +135,7 @@
|
||||
after sending the signal configured with
|
||||
<varname>KillSignal=</varname>. This is useful to indicate to
|
||||
shells and shell-like programs that their connection has been
|
||||
severed. Takes a boolean value. Defaults to "no".
|
||||
severed. Takes a boolean value. Defaults to <literal>no</literal>.
|
||||
</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v207"/></listitem>
|
||||
@ -151,7 +151,7 @@
|
||||
<varname>KillMode=</varname> of <constant>control-group</constant>
|
||||
or <constant>mixed</constant> service will not restart if
|
||||
processes from prior services exist within the control group.
|
||||
Takes a boolean value. Defaults to "yes".
|
||||
Takes a boolean value. Defaults to <literal>yes</literal>.
|
||||
</para>
|
||||
|
||||
<xi:include href="version-info.xml" xpointer="v187"/></listitem>
|
||||
|
||||
@ -797,7 +797,7 @@ CPUWeight=20 DisableControllers=cpu / \
|
||||
not applied to any sockets passed into the service via socket activation. Thus, it is usually a
|
||||
good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless,
|
||||
it may make sense to maintain one list more open and the other one more restricted, depending on
|
||||
the usecase.</para>
|
||||
the use case.</para>
|
||||
|
||||
<para>If these settings are used multiple times in the same unit the specified lists are combined. If an
|
||||
empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para>
|
||||
@ -1041,7 +1041,7 @@ RestrictNetworkInterfaces=~eth1</programlisting>
|
||||
for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into
|
||||
the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both
|
||||
the socket and the service unit, however it often makes sense to maintain one configuration more open and the other
|
||||
one more restricted, depending on the usecase.</para>
|
||||
one more restricted, depending on the use case.</para>
|
||||
|
||||
<para>Note that these settings might not be supported on some systems (for example if eBPF control group
|
||||
support is not enabled in the underlying kernel or container manager). These settings will fail the service in
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
|
||||
/* Note: on GCC "no_sanitize_address" is a function attribute only, on llvm it may also be applied to global
|
||||
* variables. We define a specific macro which knows this. Note that on GCC we don't need this decorator so much, since
|
||||
* our primary usecase for this attribute is registration structures placed in named ELF sections which shall not be
|
||||
* our primary use case for this attribute is registration structures placed in named ELF sections which shall not be
|
||||
* padded, but GCC doesn't pad those anyway if AddressSanitizer is enabled. */
|
||||
#if HAS_FEATURE_ADDRESS_SANITIZER && defined(__clang__)
|
||||
#define _variable_no_sanitize_address_ __attribute__((__no_sanitize_address__))
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
|
||||
#include "macro.h"
|
||||
|
||||
/* An embeddable structure carrying a reference to a process. Supposed to be used when tracking processes continously. */
|
||||
/* An embeddable structure carrying a reference to a process. Supposed to be used when tracking processes continuously. */
|
||||
typedef struct PidRef {
|
||||
pid_t pid; /* always valid */
|
||||
int fd; /* only valid if pidfd are available in the kernel, and we manage to get an fd */
|
||||
|
||||
@ -57,7 +57,7 @@
|
||||
* Rules regarding adding further high level targets like the above:
|
||||
*
|
||||
* - Be conservative, only add more of these when we really need
|
||||
* them. We need strong usecases for further additions.
|
||||
* them. We need strong use cases for further additions.
|
||||
*
|
||||
* - When there can be multiple implementations running side-by-side,
|
||||
* it needs to be a .target unit which can pull in all
|
||||
|
||||
@ -42,7 +42,7 @@ assert_cc(offsetof(BaseBlock, type) == 28);
|
||||
assert_cc(offsetof(BaseBlock, root_cell_offset) == 36);
|
||||
|
||||
/* All offsets are relative to the base block and technically point to a hive
|
||||
* cell struct. But for our usecase we don't need to bother about that one,
|
||||
* cell struct. But for our use case we don't need to bother about that one,
|
||||
* so skip over the cell_size uint32_t. */
|
||||
#define HIVE_CELL_OFFSET (sizeof(BaseBlock) + 4)
|
||||
|
||||
|
||||
@ -139,7 +139,7 @@ static bool is_root_cgroup(const char *path) {
|
||||
*
|
||||
* Note that checking for a container environment is kinda ugly, since in theory people could use cgtop from
|
||||
* inside a container where cgroup namespacing is turned off to watch the host system. However, that's mostly a
|
||||
* theoretic usecase, and if people actually try all they'll lose is accounting for the top-level cgroup. Which
|
||||
* theoretic use case, and if people actually try all they'll lose is accounting for the top-level cgroup. Which
|
||||
* isn't too bad. */
|
||||
|
||||
if (detect_container() > 0)
|
||||
|
||||
@ -2453,7 +2453,7 @@ int bus_exec_context_set_transient_property(
|
||||
* and we should not "lose precision" in our types on the way. That said, I am pretty sure
|
||||
* actually encoding binary data as unit metadata is not a good idea. Hence we actually refuse
|
||||
* any actual binary data, and only accept UTF-8. This allows us to eventually lift this
|
||||
* limitation, should a good, valid usecase arise. */
|
||||
* limitation, should a good, valid use case arise. */
|
||||
|
||||
r = sd_bus_message_read_array(message, 'y', &p, &sz);
|
||||
if (r < 0)
|
||||
|
||||
@ -737,7 +737,7 @@ static int parse_argv(int argc, char *argv[]) {
|
||||
if (streq(optarg, "-"))
|
||||
/* An undocumented feature: we can read journal files from STDIN. We don't document
|
||||
* this though, since after all we only support this for mmap-able, seekable files, and
|
||||
* not for example pipes which are probably the primary usecase for reading things from
|
||||
* not for example pipes which are probably the primary use case for reading things from
|
||||
* STDIN. To avoid confusion we hence don't document this feature. */
|
||||
arg_file_stdin = true;
|
||||
else {
|
||||
|
||||
@ -148,7 +148,7 @@ int device_set_syspath(sd_device *device, const char *_syspath, bool verify) {
|
||||
_cleanup_close_ int fd = -EBADF;
|
||||
|
||||
/* The input path maybe a symlink located outside of /sys. Let's try to chase the symlink at first.
|
||||
* The primary usecase is that e.g. /proc/device-tree is a symlink to /sys/firmware/devicetree/base.
|
||||
* The primary use case is that e.g. /proc/device-tree is a symlink to /sys/firmware/devicetree/base.
|
||||
* By chasing symlinks in the path at first, we can call sd_device_new_from_path() with such path. */
|
||||
r = chase(_syspath, NULL, 0, &syspath, &fd);
|
||||
if (r == -ENOENT)
|
||||
|
||||
@ -816,7 +816,7 @@ static void dns_transaction_cache_answer(DnsTransaction *t) {
|
||||
t->answer_rcode,
|
||||
t->answer,
|
||||
DNS_PACKET_CD(t->received) ? t->received : NULL, /* only cache full packets with CD on,
|
||||
* since our usecase for caching them
|
||||
* since our use case for caching them
|
||||
* is "bypass" mode which is only
|
||||
* enabled for CD packets. */
|
||||
t->answer_query_flags,
|
||||
|
||||
@ -1825,7 +1825,7 @@ int partition_pick_mount_options(
|
||||
* anymore (since in some cases the kernel implementations will refuse mounting when corrupted,
|
||||
* read-only and "norecovery" is specified). But I think for the case of automatically determined
|
||||
* mount options for loopback devices this is the right choice, since otherwise using the same
|
||||
* loopback file twice even in read-only mode, is going to fail badly sooner or later. The usecase of
|
||||
* loopback file twice even in read-only mode, is going to fail badly sooner or later. The use case of
|
||||
* making reuse of the immutable images "just work" is more relevant to us than having read-only
|
||||
* access that actually modifies stuff work on such image files. Or to say this differently: if
|
||||
* people want their file systems to be fixed up they should just open them in writable mode, where
|
||||
|
||||
@ -54,7 +54,7 @@ struct ImagePolicy {
|
||||
PartitionPolicy policies[]; /* sorted by designator, hence suitable for binary search */
|
||||
};
|
||||
|
||||
/* Default policies for various usecases */
|
||||
/* Default policies for various use cases */
|
||||
extern const ImagePolicy image_policy_allow;
|
||||
extern const ImagePolicy image_policy_deny;
|
||||
extern const ImagePolicy image_policy_ignore;
|
||||
|
||||
@ -18,7 +18,7 @@ int fs_make_very_read_only(int fd) {
|
||||
|
||||
assert(fd >= 0);
|
||||
|
||||
/* Tries to make the specified fd "comprehensively" read-only. Primary usecase for this is OS images,
|
||||
/* Tries to make the specified fd "comprehensively" read-only. Primary use case for this is OS images,
|
||||
* i.e. either loopback files or larger directory hierarchies. Depending on the inode type and
|
||||
* backing file system this means something different:
|
||||
*
|
||||
|
||||
@ -3278,7 +3278,7 @@ static int patch_var_run(const char *fname, unsigned line, char **path) {
|
||||
* might create the paths that are intermediary to the listed paths. We can't really cover the generic case,
|
||||
* but the least we can do is cover the specific case of /var/run vs. /run, as /var/run is a legacy name for
|
||||
* /run only, and we explicitly document that and require that on systemd systems the former is a symlink to
|
||||
* the latter. Moreover files below this path are by far the primary usecase for tmpfiles.d/. */
|
||||
* the latter. Moreover files below this path are by far the primary use case for tmpfiles.d/. */
|
||||
|
||||
k = path_startswith(*path, "/var/run/");
|
||||
if (isempty(k)) /* Don't complain about other paths than /var/run, and not about /var/run itself either. */
|
||||
|
||||
@ -12,9 +12,9 @@ Description=Wait Until Kernel Time Synchronized
|
||||
Documentation=man:systemd-time-wait-sync.service(8)
|
||||
|
||||
# Note that this tool doesn't need CAP_SYS_TIME itself, but its primary
|
||||
# usecase is to run in conjunction with a local NTP service such as
|
||||
# use case is to run in conjunction with a local NTP service such as
|
||||
# systemd-timesyncd.service, which is conditioned this way. There might be
|
||||
# niche usecases where running this service independently is desired, but let's
|
||||
# niche use cases where running this service independently is desired, but let's
|
||||
# make this all "just work" for the general case, and leave it to local
|
||||
# modifications to make it work in the remaining cases.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user