mirror of
https://github.com/systemd/systemd
synced 2024-10-04 15:21:01 +00:00
docs: drop .md suffixes again
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
parent
8e3fee33af
commit
1b4dc2ea28
|
|
@ -145,7 +145,7 @@ as a normal executable and executed for each of the input samples under
|
|||
with sanitizers and invoked as part of the test suite (if `-Dfuzz-tests=true`
|
||||
is configured). Thirdly, fuzzers are executed through fuzzing engines that try
|
||||
to find new "interesting" inputs through coverage feedback and massive
|
||||
parallelization; see the links for oss-fuzz in [Code quality](CODE_QUALITY.md).
|
||||
parallelization; see the links for oss-fuzz in [Code quality](CODE_QUALITY).
|
||||
For testing and debugging, fuzzers can be executed as any other program,
|
||||
including under `valgrind` or `gdb`.
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ variables. All EFI variables use the vendor UUID
|
|||
* `1 << 1` → The boot loader honours `LoaderConfigTimeoutOneShot` when set.
|
||||
* `1 << 2` → The boot loader honours `LoaderEntryDefault` when set.
|
||||
* `1 << 3` → The boot loader honours `LoaderEntryOneShot` when set.
|
||||
* `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT.md).
|
||||
* `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT).
|
||||
* `1 << 5` → The boot loader supports looking for boot menu entries in the Extended Boot Loader Partition.
|
||||
* `1 << 6` → The boot loader supports passing a random seed to the OS.
|
||||
* `1 << 13` → The boot loader honours `menu-disabled` option when set.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ available functionality:
|
|||
|
||||
15. Each PR is automatically tested with [Address Sanitizer](https://clang.llvm.org/docs/AddressSanitizer.html)
|
||||
and [Undefined Behavior Sanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).
|
||||
See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS.md)
|
||||
See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS)
|
||||
for more information.
|
||||
|
||||
16. Fossies provides [source code misspelling reports](https://fossies.org/features.html#codespell).
|
||||
|
|
|
|||
|
|
@ -29,13 +29,13 @@ For older versions that are still supported by your distribution please use resp
|
|||
|
||||
## Security vulnerability reports
|
||||
|
||||
See [reporting of security vulnerabilities](SECURITY.md).
|
||||
See [reporting of security vulnerabilities](SECURITY).
|
||||
|
||||
## Posting Pull Requests
|
||||
|
||||
* Make sure to post PRs only relative to a recent tip of the `main` branch.
|
||||
* Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.
|
||||
* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.
|
||||
* Follow our [Coding Style](CODING_STYLE) when contributing code. This is a requirement for all code we merge.
|
||||
* Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING) for details on how to do this.
|
||||
* Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR if the build and tests don't pass.
|
||||
* If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.
|
||||
* After you have pushed a new version, add a comment explaining the latest changes. If you are a member of the systemd project on GitHub, remove the `reviewed/needs-rework`/`ci-fails/needs-rework`/`needs-rebase` labels.
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ it might be desirable to convert an existing, traditional user account to a
|
|||
|
||||
Before continuing, please read up on these basic concepts:
|
||||
|
||||
* [Home Directories](HOME_DIRECTORY.md)
|
||||
* [JSON User Records](USER_RECORD.md)
|
||||
* [JSON Group Records](GROUP_RECORD.md)
|
||||
* [User/Group Record Lookup API via Varlink](USER_GROUP_API.md)
|
||||
* [Home Directories](HOME_DIRECTORY)
|
||||
* [JSON User Records](USER_RECORD)
|
||||
* [JSON Group Records](GROUP_RECORD)
|
||||
* [User/Group Record Lookup API via Varlink](USER_GROUP_API)
|
||||
|
||||
## Caveat
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ purpose. Specifically, the following features are provided:
|
|||
8. Credentials are an effective way to pass parameters into services that run
|
||||
with `RootImage=` or `RootDirectory=` and thus cannot read these resources
|
||||
directly from the host directory tree.
|
||||
Specifically, [Portable Services](PORTABLE_SERVICES.md) may be
|
||||
Specifically, [Portable Services](PORTABLE_SERVICES) may be
|
||||
parameterized this way securely and robustly.
|
||||
|
||||
9. Credentials can be binary and relatively large (though currently an overall
|
||||
|
|
@ -288,7 +288,7 @@ services where they are ultimately consumed.
|
|||
invokes. [`systemd-nspawn(1)`](https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#Credentials)'s
|
||||
`--set-credential=` and `--load-credential=` switches implement this, in
|
||||
order to pass arbitrary credentials from host to container payload. Also see
|
||||
the [Container Interface](CONTAINER_INTERFACE.md) documentation.
|
||||
the [Container Interface](CONTAINER_INTERFACE) documentation.
|
||||
|
||||
2. Quite similar, VMs can be passed credentials via SMBIOS OEM strings (example
|
||||
qemu command line switch `-smbios
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
|||
# JSON Group Records
|
||||
|
||||
Long story short: JSON Group Records are to `struct group` what
|
||||
[JSON User Records](USER_RECORD.md) are to `struct passwd`.
|
||||
[JSON User Records](USER_RECORD) are to `struct passwd`.
|
||||
|
||||
Conceptually, much of what applies to JSON user records also applies to JSON
|
||||
group records. They also consist of seven sections, with similar properties and
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ We welcome all contributions to systemd. If you notice a bug or a missing
|
|||
feature, please feel invited to fix it, and submit your work as a
|
||||
[GitHub Pull Request (PR)](https://github.com/systemd/systemd/pull/new).
|
||||
|
||||
Please make sure to follow our [Coding Style](CODING_STYLE.md) when submitting
|
||||
patches. Also have a look at our [Contribution Guidelines](CONTRIBUTING.md).
|
||||
Please make sure to follow our [Coding Style](CODING_STYLE) when submitting
|
||||
patches. Also have a look at our [Contribution Guidelines](CONTRIBUTING).
|
||||
|
||||
When adding new functionality, tests should be added. For shared functionality
|
||||
(in `src/basic/` and `src/shared/`) unit tests should be sufficient. The general
|
||||
|
|
@ -23,7 +23,7 @@ test executable. For features at a higher level, tests in `src/test/` are very
|
|||
strongly recommended. If that is not possible, integration tests in `test/` are
|
||||
encouraged.
|
||||
|
||||
Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we
|
||||
Please also have a look at our list of [code quality tools](CODE_QUALITY) we
|
||||
have setup for systemd, to ensure our codebase stays in good shape.
|
||||
|
||||
Please always test your work before submitting a PR. For many of the components
|
||||
|
|
@ -148,7 +148,7 @@ distribution and can be disabled by setting `-Dmode=release`.
|
|||
|
||||
## Sanitizers in mkosi
|
||||
|
||||
See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS.md) for more information
|
||||
See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS) for more information
|
||||
on how to build with sanitizers enabled in mkosi.
|
||||
|
||||
## Fuzzers
|
||||
|
|
@ -211,7 +211,7 @@ done
|
|||
```
|
||||
|
||||
If you find a bug that impacts the security of systemd, please follow the
|
||||
guidance in [CONTRIBUTING.md](CONTRIBUTING.md) on how to report a security vulnerability.
|
||||
guidance in [CONTRIBUTING.md](CONTRIBUTING) on how to report a security vulnerability.
|
||||
|
||||
For more details on building fuzzers and integrating with OSS-Fuzz, visit:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ mechanism used.
|
|||
|
||||
Inside of the home directory a file `~/.identity` contains the JSON formatted
|
||||
user record of the user. It follows the format defined in
|
||||
[`JSON User Records`](USER_RECORD.md). It is recommended to bring the
|
||||
[`JSON User Records`](USER_RECORD). It is recommended to bring the
|
||||
record into 'normalized' form (i.e. all objects should contain their fields
|
||||
sorted alphabetically by their key) before storing it there, though this is not
|
||||
required nor enforced. Since the user record is cryptographically signed, the
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ systemd provides a fair degree of compatibility with the behavior exposed by the
|
|||
* LSB header dependency information matters. The SysV implementations on many distributions did not use the dependency information encoded in LSB init script headers, or used them only in very limited ways. Due to that they are often incorrect or incomplete. systemd however fully interprets these headers and follows them closely at runtime (and not at installation time like some implementations).
|
||||
* Timeouts apply to all init script operations in systemd. While on SysV systems a hanging init script could freeze the system on systemd all init script operations are subject to a timeout of 5min.
|
||||
* Services are executed in completely clean execution contexts, no context of the invoking user session is inherited. Not even $HOME or similar are set. Init scripts depending on these will not work correctly.
|
||||
* Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. ([details](../PASSWORD_AGENTS), [manual page](http://0pointer.de/public/systemd-man/systemd-ask-password.html))
|
||||
* Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. ([details](PASSWORD_AGENTS), [manual page](http://0pointer.de/public/systemd-man/systemd-ask-password.html))
|
||||
* Additional verbs for init scripts are not supported. If your init script traditionally supported additional verbs for your init script simply move them to an auxiliary script.
|
||||
* Additional parameters to the standard verbs (i.e. to "start", "stop" and "status") are not supported. This was an extension of SysV that never was standardized officially, and is not supported in systemd.
|
||||
* Overriding the "restart" verb is not supported. This verb is always implemented by systemd itself, and consists of a "stop" followed by a "start".
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Arch Linux initrds.
|
|||
line options, for example `--log-level=` and similar.
|
||||
|
||||
* Storage daemons run from the initrd should follow the guide on
|
||||
[systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md)
|
||||
[systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS)
|
||||
to survive properly from the boot initrd all the way to the point where
|
||||
systemd jumps back into the initrd for shutdown.
|
||||
|
||||
|
|
@ -67,4 +67,4 @@ systemd. Here are a few terse notes:
|
|||
|
||||
* The switch-root operation will result in a killing spree of all running
|
||||
processes. Some processes might need to be excluded from that, see the guide
|
||||
on [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md).
|
||||
on [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS).
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
|||
|
||||
_Note that this document describes the binary serialization format of journals only, as used for transfer across the network.
|
||||
For interfacing with web technologies there's the Journal JSON Format, described below.
|
||||
The binary format on disk is documented as the [Journal File Format](JOURNAL_FILE_FORMAT.md)._
|
||||
The binary format on disk is documented as the [Journal File Format](JOURNAL_FILE_FORMAT)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ _SOURCE_REALTIME_TIMESTAMP=1423944916372858
|
|||
|
||||
_Note that this section describes the JSON serialization format of the journal only, as used for interfacing with web technologies.
|
||||
For binary transfer of journal data across the network there's the Journal Export Format described above.
|
||||
The binary format on disk is documented as [Journal File Format](JOURNAL_FILE_FORMAT.md)._
|
||||
The binary format on disk is documented as [Journal File Format](JOURNAL_FILE_FORMAT)._
|
||||
|
||||
_Before reading on, please make sure you are aware of the [basic properties of journal entries](https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html), in particular realize that they may include binary non-text data (though usually don't), and the same field might have multiple values assigned within the same entry (though usually hasn't)._
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ _Or, to put this in other words: this low-level document is probably not what
|
|||
you want to use as base of your project. You want our [C
|
||||
API](https://www.freedesktop.org/software/systemd/man/sd-journal.html) instead!
|
||||
And if you really don't want the C API, then you want the
|
||||
[Journal Export Format or Journal JSON Format](JOURNAL_EXPORT_FORMATS.md)
|
||||
[Journal Export Format or Journal JSON Format](JOURNAL_EXPORT_FORMATS)
|
||||
instead! This document is primarily for your entertainment and education.
|
||||
Thank you!_
|
||||
|
||||
|
|
|
|||
|
|
@ -83,9 +83,9 @@ And now, here's the list of (hopefully) all APIs that we have introduced with sy
|
|||
| [hostnamed](https://www.freedesktop.org/software/systemd/man/org.freedesktop.hostname1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
|
||||
| [localed](https://www.freedesktop.org/software/systemd/man/org.freedesktop.locale1.html) | D-Bus | yes | yes | GNOME | yes | [Ubuntu](https://launchpad.net/ubuntu/+source/ubuntu-system-service), [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
|
||||
| [timedated](https://www.freedesktop.org/software/systemd/man/org.freedesktop.timedate1.html) | D-Bus | yes | yes | GNOME | yes | [Gentoo](http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml), [BSD](http://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=summary) | partially |
|
||||
| [initrd interface](INITRD_INTERFACE.md) | Environment, flag files | yes | yes | mkosi, dracut, ArchLinux | yes | ArchLinux | no |
|
||||
| [Container interface](CONTAINER_INTERFACE.md) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
|
||||
| [Boot Loader interface](BOOT_LOADER_INTERFACE.md) | EFI variables | yes | yes | gummiboot | yes | - | no |
|
||||
| [initrd interface](INITRD_INTERFACE) | Environment, flag files | yes | yes | mkosi, dracut, ArchLinux | yes | ArchLinux | no |
|
||||
| [Container interface](CONTAINER_INTERFACE) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
|
||||
| [Boot Loader interface](BOOT_LOADER_INTERFACE) | EFI variables | yes | yes | gummiboot | yes | - | no |
|
||||
| [Service bus API](https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html) | D-Bus | yes | yes | system-config-services | no | - | no |
|
||||
| [logind](https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html) | D-Bus | yes | yes | GNOME | no | - | no |
|
||||
| [sd-bus.h API](https://www.freedesktop.org/software/systemd/man/sd-bus.html) | C Library | yes | yes | - | maybe | - | maybe |
|
||||
|
|
@ -102,15 +102,15 @@ And now, here's the list of (hopefully) all APIs that we have introduced with sy
|
|||
| [$XDG_RUNTIME_DIR](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) | Environment | yes | yes | glib, GNOME | yes | - | no |
|
||||
| [$LISTEN_FDS $LISTEN_PID FD Passing](https://www.freedesktop.org/software/systemd/man/sd_listen_fds.html) | Environment | yes | yes | numerous (via sd-daemon.h) | yes | - | no |
|
||||
| [$NOTIFY_SOCKET Daemon Notifications](https://www.freedesktop.org/software/systemd/man/sd_notify.html) | Environment | yes | yes | a few, including udev | yes | - | no |
|
||||
| [argv[0][0]='@' Logic](ROOT_STORAGE_DAEMONS.md) | `/proc` marking | yes | yes | mdadm | yes | - | no |
|
||||
| [argv[0][0]='@' Logic](ROOT_STORAGE_DAEMONS) | `/proc` marking | yes | yes | mdadm | yes | - | no |
|
||||
| [Unit file format](https://www.freedesktop.org/software/systemd/man/systemd.unit.html) | File format | yes | yes | numerous | no | - | no |
|
||||
| [Network](https://www.freedesktop.org/software/systemd/man/systemd.network.html) & [Netdev file format](https://www.freedesktop.org/software/systemd/man/systemd.netdev.html) | File format | yes | yes | no | no | - | no |
|
||||
| [Link file format](https://www.freedesktop.org/software/systemd/man/systemd.link.html) | File format | yes | yes | no | no | - | no |
|
||||
| [Journal File Format](JOURNAL_FILE_FORMAT.md) | File format | yes | yes | - | maybe | - | no |
|
||||
| [Journal File Format](JOURNAL_FILE_FORMAT) | File format | yes | yes | - | maybe | - | no |
|
||||
| [Journal Export Format](JOURNAL_EXPORT_FORMATS.md#journal-export-format) | File format | yes | yes | - | yes | - | no |
|
||||
| [Journal JSON Format](JOURNAL_EXPORT_FORMATS.md#journal-json-format) | File format | yes | yes | - | yes | - | no |
|
||||
| [Cooperation in cgroup tree](https://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) | Treaty | yes | yes | libvirt | yes | libvirt | no |
|
||||
| [Password Agents](PASSWORD_AGENTS.md) | Socket+Files | yes | yes | - | yes | - | no |
|
||||
| [Password Agents](PASSWORD_AGENTS) | Socket+Files | yes | yes | - | yes | - | no |
|
||||
| [udev multi-seat properties](https://www.freedesktop.org/software/systemd/man/sd-login.html) | udev Property | yes | yes | X11, gdm | no | - | no |
|
||||
| udev session switch ACL properties | udev Property | no | no | - | no | - | no |
|
||||
| [CLI of systemctl,...](https://www.freedesktop.org/software/systemd/man/systemctl.html) | CLI | yes | yes | numerous | no | - | no |
|
||||
|
|
|
|||
|
|
@ -384,7 +384,7 @@ This primarily leaves two kind of systems in the cold:
|
|||
for an introduction why. That said, any boot loader can re-implement the
|
||||
logic described above, and can pass a random seed that systemd as PID 1
|
||||
will then upload into the kernel's entropy pool. For details see the
|
||||
[Boot Loader Interface](BOOT_LOADER_INTERFACE.md) documentation.
|
||||
[Boot Loader Interface](BOOT_LOADER_INTERFACE) documentation.
|
||||
|
||||
11. *Why not pass the boot loader random seed via kernel command line instead
|
||||
of as EFI variable?*
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ to find a different solution to your problem._
|
|||
|
||||
The recommended way to distinguish between run-from-initrd and run-from-rootfs
|
||||
for a daemon is to check for `/etc/initrd-release` (which exists on all modern
|
||||
initrd implementations, see the [initrd Interface](INITRD_INTERFACE.md) for
|
||||
initrd implementations, see the [initrd Interface](INITRD_INTERFACE) for
|
||||
details) which when exists results in `argv[0][0]` being set to `@`, and
|
||||
otherwise doesn't. Something like this:
|
||||
|
||||
|
|
@ -191,4 +191,4 @@ few additional notes for supporting these setups:
|
|||
program consult this blog story: [Socket
|
||||
Activation](https://0pointer.de/blog/projects/socket-activation.html)
|
||||
|
||||
* Consider having a look at the [initrd Interface of systemd](INITRD_INTERFACE.md).
|
||||
* Consider having a look at the [initrd Interface of systemd](INITRD_INTERFACE).
|
||||
|
|
|
|||
|
|
@ -21,10 +21,10 @@ are recommended. A few areas where that applies are discussed below.
|
|||
|
||||
Before reading on, please read up on the basic concepts, specifically:
|
||||
|
||||
* [Home Directories](HOME_DIRECTORY.md)
|
||||
* [JSON User Records](USER_RECORD.md)
|
||||
* [JSON Group Records](GROUP_RECORD.md)
|
||||
* [User/Group Record Lookup API via Varlink](USER_GROUP_API.md)
|
||||
* [Home Directories](HOME_DIRECTORY)
|
||||
* [JSON User Records](USER_RECORD)
|
||||
* [JSON Group Records](GROUP_RECORD)
|
||||
* [User/Group Record Lookup API via Varlink](USER_GROUP_API)
|
||||
|
||||
## Support for Suspending Home Directory Access during System Suspend
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ solution only.
|
|||
In case you wonder, there's no automatic mechanism for converting existing
|
||||
users registered in `/etc/passwd` or LDAP to users managed by
|
||||
`systemd-homed`. There's documentation for doing this manually though, see
|
||||
[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED.md).
|
||||
[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED).
|
||||
|
||||
## Future Additions
|
||||
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
|||
|
||||
# User/Group Record Lookup API via Varlink
|
||||
|
||||
JSON User/Group Records (as described in the [JSON User Records](USER_RECORD.md)
|
||||
and [JSON Group Records](GROUP_RECORD.md) documents) that are defined on the
|
||||
JSON User/Group Records (as described in the [JSON User Records](USER_RECORD)
|
||||
and [JSON Group Records](GROUP_RECORD) documents) that are defined on the
|
||||
local system may be queried with a [Varlink](https://varlink.org/) API. This
|
||||
API takes both the role of what
|
||||
[`getpwnam(3)`](https://man7.org/linux/man-pages/man3/getpwnam.3.html) and
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ pairs, encoded as JSON. Specifically:
|
|||
1. [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html)
|
||||
manages `human` user home directories and embeds these JSON records
|
||||
directly in the home directory images
|
||||
(see [Home Directories](HOME_DIRECTORY.md) for details).
|
||||
(see [Home Directories](HOME_DIRECTORY) for details).
|
||||
|
||||
2. [`pam_systemd`](https://www.freedesktop.org/software/systemd/man/pam_systemd.html)
|
||||
processes these JSON records for users that log in, and applies various
|
||||
|
|
@ -72,15 +72,15 @@ the following extensions are envisioned:
|
|||
4. Default parameters for backup applications and similar
|
||||
|
||||
Similar to JSON User Records there are also
|
||||
[JSON Group Records](GROUP_RECORD.md) that encapsulate UNIX groups.
|
||||
[JSON Group Records](GROUP_RECORD) that encapsulate UNIX groups.
|
||||
|
||||
JSON User Records are not suitable for storing all identity information about
|
||||
the user, such as binary data or large unstructured blobs of text. These parts
|
||||
of a user's identity should be stored in the [Blob Directories](USER_RECORD_BLOB_DIRS.md).
|
||||
of a user's identity should be stored in the [Blob Directories](USER_RECORD_BLOB_DIRS).
|
||||
|
||||
JSON User Records may be transferred or written to disk in various protocols
|
||||
and formats. To inquire about such records defined on the local system use the
|
||||
[User/Group Lookup API via Varlink](USER_GROUP_API.md). User/group records may
|
||||
[User/Group Lookup API via Varlink](USER_GROUP_API). User/group records may
|
||||
also be dropped in number of drop-in directories as files. See
|
||||
[`nss-systemd(8)`](https://www.freedesktop.org/software/systemd/man/nss-systemd.html)
|
||||
for details.
|
||||
|
|
@ -218,7 +218,7 @@ object. The following fields are currently defined:
|
|||
UNIX user name. This field is the only mandatory field, all others are
|
||||
optional. Corresponds with the `pw_name` field of `struct passwd` and the
|
||||
`sp_namp` field of `struct spwd` (i.e. the shadow user record stored in
|
||||
`/etc/shadow`). See [User/Group Name Syntax](USER_NAMES.md) for
|
||||
`/etc/shadow`). See [User/Group Name Syntax](USER_NAMES) for
|
||||
the (relaxed) rules the various systemd components enforce on user/group names.
|
||||
|
||||
`realm` → The "realm" a user is defined in. This concept allows distinguishing
|
||||
|
|
@ -235,10 +235,10 @@ user record with a realm set is never compatible (for the purpose of updates,
|
|||
see above) with a user record without one set, even if the `userName` field matches.
|
||||
|
||||
`blobDirectory` → The absolute path to a world-readable copy of the user's blob
|
||||
directory. See [Blob Directories](USER_RECORD_BLOB_DIRS.md) for more details.
|
||||
directory. See [Blob Directories](USER_RECORD_BLOB_DIRS) for more details.
|
||||
|
||||
`blobManifest` → An object, which maps valid blob directory filenames (see
|
||||
[Blob Directories](USER_RECORD_BLOB_DIRS.md) for requirements) to SHA256 hashes
|
||||
[Blob Directories](USER_RECORD_BLOB_DIRS) for requirements) to SHA256 hashes
|
||||
formatted as hex strings. This exists for the purpose of including the contents
|
||||
of the blob directory in the record's signature. Managers that support blob
|
||||
directories and utilize signed user records (like `systemd-homed`) should use
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
|
|||
# User Record Blob Directories
|
||||
|
||||
The blob directories are for storing binary or unstructured data that would
|
||||
otherwise be stored in [JSON User Records](USER_RECORD.md). For instance,
|
||||
otherwise be stored in [JSON User Records](USER_RECORD). For instance,
|
||||
this includes image files such as the user's avatar picture. This data,
|
||||
like most of the user record, will be made publicly available to the
|
||||
system.
|
||||
|
|
|
|||
Loading…
Reference in a new issue