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](https://systemd.io/CODE_QUALITY). For testing and debugging, fuzzers
-can be executed as any other program, including under `valgrind` or `gdb`.
+parallelization; see the links for oss-fuzz in [Code quality](CODE_QUALITY.md).
+For testing and debugging, fuzzers can be executed as any other program,
+including under `valgrind` or `gdb`.
## Integration Tests
version of the OS or kernel in case the system consistently fails to boot. This
support is built into various of its components. When used together these
components provide a complete solution on UEFI systems, built as add-on to the
-[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION).
+[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md).
However, the different components may also be used independently, and in
combination with other software, to implement similar schemes, for example with
other boot loaders or for non-UEFI systems. Here's a brief overview of the
* `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](https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT).
+ * `1 << 4` → The boot loader supports boot counting as described in [Automatic Boot Assessment](AUTOMATIC_BOOT_ASSESSMENT.md).
* `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.
`LoaderEntryOneShot`, `LoaderEntrySelected`, and possibly show nicely localized
names for them in UIs.
-1. When boot loader entries are defined through [Boot Loader
- Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION) drop-in files
+1. When boot loader entries are defined through
+ [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md) drop-in files
the identifier should be derived directly from the drop-in snippet name, but
with the `.conf` (or `.efi` in case of Type #2 entries) suffix removed.
## Links
-[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<br>
-[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
+[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md)<br>
+[Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br>
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
[`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
## Links
[GUID Partition Table](https://en.wikipedia.org/wiki/GUID_Partition_Table)<br>
-[Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)<br>
-[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
+[Boot Loader Interface](BOOT_LOADER_INTERFACE.md)<br>
+[Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br>
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
[`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
The
[`kernel-install(8)`](https://www.freedesktop.org/software/systemd/man/kernel-install.html)
-logic used to generate [Boot Loader Specification Type
-1](https://systemd.io/BOOT_LOADER_SPECIFICATION) entries by default uses the
-machine ID as stored in `/etc/machine-id` for naming boot menu entries and the
-directories in the ESP to place kernel images in. This is done in order to
-allow multiple installations of the same OS on the same system without
-conflicts. However, this is problematic if the machine ID shall be generated
-automatically on first boot: if the ID is not known before the first boot it
-cannot be used to name the most basic resources required for the boot process
-to complete.
+logic used to generate
+[Boot Loader Specification Type 1](BOOT_LOADER_SPECIFICATION.md) entries by
+default uses the machine ID as stored in `/etc/machine-id` for naming boot menu
+entries and the directories in the ESP to place kernel images in. This is done
+in order to allow multiple installations of the same OS on the same system
+without conflicts. However, this is problematic if the machine ID shall be
+generated automatically on first boot: if the ID is not known before the first
+boot it cannot be used to name the most basic resources required for the boot
+process to complete.
Thus, for images that shall acquire their identity on first boot only, it is
required to use a different identifier for naming boot menu entries. To allow
in. The `x-systemd.growfs` mount option in `/etc/fstab` is sufficient to
enable this logic for specific mounts. Alternatively appropriately set up
partitions can set GPT partition flag 59 to request this behaviour, see the
- [Discoverable Partitions
- Specification](https://systemd.io/DISCOVERABLE_PARTITIONS) for details. If
- the file system is already grown it executes no operation.
+ [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md) for
+ details. If the file system is already grown it executes no operation.
3. Similar, the `systemd-makefs@.service` and `systemd-makeswap@.service`
services can format file systems and swap spaces before first use, if they
[`machine-id(5)`](https://www.freedesktop.org/software/systemd/man/machine-id.html)<br>
[`systemd-random-seed(8)`](https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html)<br>
[`os-release(5)`](https://www.freedesktop.org/software/systemd/man/os-release.html)<br>
-[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<br>
-[Discoverable Partitions Specification](https://systemd.io/DISCOVERABLE_PARTITIONS)<br>
+[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md)<br>
+[Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md)<br>
[`mkosi`](https://github.com/systemd/mkosi)<br>
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[`systemd-repart(8)`](https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html)<br>
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](https://systemd.io/TESTING_WITH_SANITIZERS)
+ See [Testing systemd using sanitizers](TESTING_WITH_SANITIZERS.md)
for more information.
16. Fossies provides [source code misspelling reports](https://fossies.org/features.html#codespell).
Before continuing, please read up on these basic concepts:
-* [Home Directories](https://systemd.io/HOME_DIRECTORY)
-* [JSON User Records](https://systemd.io/USER_RECORD)
-* [JSON Group Records](https://systemd.io/GROUP_RECORD)
-* [User/Group Record Lookup API via Varlink](https://systemd.io/USER_GROUP_API)
+* [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)
## Caveat
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](https://systemd.io/PORTABLE_SERVICES) may be parameterized this
- way securely and robustly.
+ directly from the host directory tree.
+ Specifically, [Portable Services](PORTABLE_SERVICES.md) may be
+ parameterized this way securely and robustly.
9. Credentials can be binary and relatively large (though currently an overall
size limit of 1M per service is enforced).
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](https://systemd.io/CONTAINER_INTERFACE)
+ the [Container Interface](CONTAINER_INTERFACE.md)
documentation.
2. Quite similar, qemu VMs can be invoked with `-fw_cfg
[systemd](https://systemd.io/) 211 and newer in the
[systemd-gpt-auto-generator(8)](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
generator tool. Note that automatic discovery of the root only works if the
-boot loader communicates this information to the OS, by implementing the [Boot
-Loader
-Interface](https://systemd.io/BOOT_LOADER_INTERFACE).
+boot loader communicates this information to the OS, by implementing the
+[Boot Loader Interface](BOOT_LOADER_INTERFACE.md).
## Defined Partition Type UUIDs
| _`/usr/` Verity Signature Partition (amd64/x86_64)_ | `e7bb33fb-06cf-4e81-8273-e543b413e2e2` | ditto | ditto |
| _`/usr/` Verity Signature Partition (x86)_ | `974a71c0-de41-43c3-be5d-5c5ccd1ad2c0` | ditto | ditto |
| _EFI System Partition_ | `c12a7328-f81f-11d2-ba4b-00a0c93ec93b` | VFAT | The ESP used for the current boot is automatically mounted to `/efi/` (or `/boot/` as fallback), unless a different partition is mounted there (possibly via `/etc/fstab`, or because the Extended Boot Loader Partition — see below — exists) or the directory is non-empty on the root disk. This partition type is defined by the [UEFI Specification](http://www.uefi.org/specifications). |
-| _Extended Boot Loader Partition_ | `bc13c2ff-59e6-4262-a352-b275fd6f7172` | Typically VFAT | The Extended Boot Loader Partition (XBOOTLDR) used for the current boot is automatically mounted to `/boot/`, unless a different partition is mounted there (possibly via `/etc/fstab`) or the directory is non-empty on the root disk. This partition type is defined by the [Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION). |
+| _Extended Boot Loader Partition_ | `bc13c2ff-59e6-4262-a352-b275fd6f7172` | Typically VFAT | The Extended Boot Loader Partition (XBOOTLDR) used for the current boot is automatically mounted to `/boot/`, unless a different partition is mounted there (possibly via `/etc/fstab`) or the directory is non-empty on the root disk. This partition type is defined by the [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md). |
| _Swap_ | `0657fd6d-a4ab-43c4-84e5-0933c84b4f4f` | Swap, optionally in LUKS | All swap partitions on the disk containing the root partition are automatically enabled. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/swap`. This partition type predates the Discoverable Partitions Specification. |
| _Home Partition_ | `933ac7e1-2eb4-4f13-b844-0e14e2aef915` | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/home/`. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/home`. |
| _Server Data Partition_ | `3b8f8425-20e0-4f3b-907f-1a25a76f98e8` | Any native, optionally in LUKS | The first partition with this type UUID on the disk containing the root partition is automatically mounted to `/srv/`. If the partition is encrypted with LUKS, the device mapper file will be named `/dev/mapper/srv`. |
## Links
-[Boot Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION)<br>
-[Boot Loader Interface](https://systemd.io/BOOT_LOADER_INTERFACE)<br>
-[Safely Building Images](https://systemd.io/BUILDING_IMAGES)<br>
+[Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md)<br>
+[Boot Loader Interface](BOOT_LOADER_INTERFACE.md)<br>
+[Safely Building Images](BUILDING_IMAGES.md)<br>
[`systemd-boot(7)`](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)<br>
[`bootctl(1)`](https://www.freedesktop.org/software/systemd/man/bootctl.html)<br>
[`systemd-gpt-auto-generator(8)`](https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html)
requested. The file contains the requested boot loader entry identifier. This
file may be checked for by services run during system shutdown in order to
request the appropriate operation from the boot loader in an alternative
- fashion. Note that by default only boot loader entries which follow the [Boot
- Loader Specification](https://systemd.io/BOOT_LOADER_SPECIFICATION) and are
+ fashion. Note that by default only boot loader entries which follow the
+ [Boot Loader Specification](BOOT_LOADER_SPECIFICATION.md) and are
placed in the ESP or the Extended Boot Loader partition may be selected this
way. However, if a directory `/run/boot-loader-entries/` exists, the entries
are loaded from there instead. The directory should contain the usual
to load the embedded Verity signature data. If enabled (which is the
default), Verity root hash information and a suitable signature is
automatically acquired from a signature partition, following the
- [Discoverable Partitions
- Specification](https://systemd.io/DISCOVERABLE_PARTITIONS). If disabled any
- such partition is ignored. Note that this only disables discovery of the root
- hash and its signature, the Verity data partition itself is still searched in
- the GPT image.
+ [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md).
+ If disabled any such partition is ignored. Note that this only disables
+ discovery of the root hash and its signature, the Verity data partition
+ itself is still searched in the GPT image.
* `$SYSTEMD_DISSECT_VERITY_SIGNATURE` — takes a boolean, which controls whether
to validate the signature of the Verity root hash if available. If enabled
# JSON Group Records
-Long story short: JSON Group Records are to `struct group` what [JSON User
-Records](https://systemd.io/USER_RECORD) are to `struct passwd`.
+Long story short: JSON Group Records are to `struct group` what
+[JSON User Records](USER_RECORD.md) 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
## General Structure
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`](https://systemd.io/USER_RECORD). It is recommended to bring the
+user record of the user. It follows the format defined in
+[`JSON User Records`](USER_RECORD.md). 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
optionally followed (in `argv[2]`, `argv[3]`, … systemd's original command
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](https://systemd.io/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.
+* Storage daemons run from the initrd should follow the guide on
+ [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md)
+ to survive properly from the boot initrd all the way to the point where
+ systemd jumps back into the initrd for shutdown.
One last clarification: we use the term _initrd_ very generically here
describing any kind of early boot file system, regardless whether that might be
* 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](https://systemd.io/ROOT_STORAGE_DAEMONS).
+ on [systemd and Storage Daemons for the Root File System](ROOT_STORAGE_DAEMONS.md).
_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](https://systemd.io/JOURNAL_FILE_FORMAT/)._
+The binary format on disk is documented as the [Journal File Format](JOURNAL_FILE_FORMAT.md)._
_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)._
_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](https://systemd.io/JOURNAL_FILE_FORMAT)._
+The binary format on disk is documented as [Journal File Format](JOURNAL_FILE_FORMAT.md)._
_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)._
# Journal File Format
_Note that this document describes the binary on-disk format of journals only.
-For interfacing with web technologies there's the [Journal JSON Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format).
-For transfer of journal data across the network there's the [Journal Export Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format)._
+For interfacing with web technologies there's the [Journal JSON Format](JOURNAL_EXPORT_FORMATS.md#journal-json-format).
+For transfer of journal data across the network there's the [Journal Export Format](JOURNAL_EXPORT_FORMATS.md#journal-export-format)._
The systemd journal stores log data in a binary format with several features:
_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](https://systemd.io/JOURNAL_EXPORT_FORMATS) instead!
-This document is primarily for your entertainment and education. Thank you!_
+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)
+instead! This document is primarily for your entertainment and education.
+Thank you!_
This document assumes you have a basic understanding of the journal concepts,
the properties of a journal entry and so on. If not, please go and read up,
| [hostnamed](https://www.freedesktop.org/wiki/Software/systemd/hostnamed) | 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/wiki/Software/systemd/localed) | 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/wiki/Software/systemd/timedated) | 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](https://systemd.io/INITRD_INTERFACE) | Environment, flag files | yes | yes | dracut, ArchLinux | yes | ArchLinux | no |
-| [Container interface](https://systemd.io/CONTAINER_INTERFACE) | Environment, Mounts | yes | yes | libvirt/LXC | yes | - | no |
-| [Boot Loader interface](https://systemd.io/BOOT_LOADER_INTERFACE) | EFI variables | yes | yes | gummiboot | yes | - | no |
+| [initrd interface](INITRD_INTERFACE.md) | Environment, flag files | yes | yes | 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 |
| [Service bus API](https://www.freedesktop.org/wiki/Software/systemd/dbus) | D-Bus | yes | yes | system-config-services | no | - | no |
| [logind](https://www.freedesktop.org/wiki/Software/systemd/logind) | D-Bus | yes | yes | GNOME | no | - | no |
| [sd-login.h API](https://www.freedesktop.org/software/systemd/man/sd-login.html) | C Library | yes | yes | GNOME, polkit, ... | no | - | no |
| [$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](https://systemd.io/ROOT_STORAGE_DAEMONS) | `/proc` marking | yes | yes | mdadm | yes | - | no |
+| [argv[0][0]='@' Logic](ROOT_STORAGE_DAEMONS.md) | `/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](https://systemd.io/JOURNAL_FILE_FORMAT) | File format | yes | yes | - | maybe | - | no |
-| [Journal Export Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format) | File format | yes | yes | - | yes | - | no |
-| [Journal JSON Format](https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format) | File format | yes | yes | - | yes | - | no |
+| [Journal File Format](JOURNAL_FILE_FORMAT.md) | 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](https://systemd.io/PASSWORD_AGENTS) | Socket+Files | yes | yes | - | yes | - | no |
+| [Password Agents](PASSWORD_AGENTS.md) | 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 |
must be a raw disk image either containing only one, naked file system, or
an image with a partition table understood by the Linux kernel with only a
single partition defined, or alternatively, a GPT partition table with a set
- of properly marked partitions following the [Discoverable Partitions
- Specification](https://systemd.io/DISCOVERABLE_PARTITIONS).
+ of properly marked partitions following the
+ [Discoverable Partitions Specification](DISCOVERABLE_PARTITIONS.md).
3. The image must at least contain one matching unit file, with the right name
prefix and suffix (see above). The unit file is searched in the usual paths,
[systemd-boot(7)](https://www.freedesktop.org/software/systemd/man/systemd-boot.html)
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](https://systemd.io/BOOT_LOADER_INTERFACE) documentation.
+ will then upload into the kernel's entropy pool. For details see the
+ [Boot Loader Interface](BOOT_LOADER_INTERFACE.md) documentation.
11. *Why not pass the boot loader random seed via kernel command line instead
of as EFI variable?*
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](https://systemd.io/INITRD_INTERFACE) for details) which when exists
-results in `argv[0][0]` being set to `@`, and otherwise doesn't. Something like
-this:
+initrd implementations, see the [initrd Interface](INITRD_INTERFACE.md) for
+details) which when exists results in `argv[0][0]` being set to `@`, and
+otherwise doesn't. Something like this:
```c
#include <unistd.h>
program consult this blog story: [Socket
Activation](http://0pointer.de/blog/projects/socket-activation.html)
-* Consider having a look at the [initrd Interface of systemd](https://systemd.io/INITRD_INTERFACE).
+* Consider having a look at the [initrd Interface of systemd](INITRD_INTERFACE.md).
Before reading on, please read up on the basic concepts, specifically:
-* [Home Directories](https://systemd.io/HOME_DIRECTORY)
-* [JSON User Records](https://systemd.io/USER_RECORD)
-* [JSON Group Records](https://systemd.io/GROUP_RECORD)
-* [User/Group Record Lookup API via Varlink](https://systemd.io/USER_GROUP_API)
+* [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)
## Support for Suspending Home Directory Access during System Suspend
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](https://systemd.io/CONVERTING_TO_HOMED).
+[Converting Existing Users to systemd-homed managed Users](CONVERTING_TO_HOMED.md).
## Future Additions
# User/Group Record Lookup API via Varlink
-JSON User/Group Records (as described in the [JSON User
-Records](https://systemd.io/USER_RECORD) and [JSON Group
-Records](https://systemd.io/GROUP_RECORD) documents) that are defined on the
+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
local system may be queried with a [Varlink](https://varlink.org/) API. This
API takes both the role of what
[`getpwnam(3)`](http://man7.org/linux/man-pages/man3/getpwnam.3.html) and
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](https://systemd.io/HOME_DIRECTORY) for details).
+ directly in the home directory images
+ (see [Home Directories](HOME_DIRECTORY.md) 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
4. Default parameters for backup applications and similar
-Similar to JSON User Records there are also [JSON Group
-Records](https://systemd.io/GROUP_RECORD) that encapsulate UNIX groups.
+Similar to JSON User Records there are also
+[JSON Group Records](GROUP_RECORD.md) that encapsulate UNIX groups.
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](https://systemd.io/USER_GROUP_API). User/group records may also be
-dropped in number of drop-in directories as files. See
+[User/Group Lookup API via Varlink](USER_GROUP_API.md). 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.
UNIX user name. This field is the only mandatory field, all others are
optional. Corresponds with the `pw_name` field of 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](https://systemd.io/USER_NAMES) for
+`/etc/shadow`). See [User/Group Name Syntax](USER_NAMES.md) 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
projects / thirdparty / systemd.git / commitdiff
