systemd中文文档

- 启动: http://systemd.cn/docs/Booting/
- 自动启动评估: http://systemd.cn/docs/Booting/AUTOMATIC_BOOT_ASSESSMENT/
- 启动组件和根文件系统探测: http://systemd.cn/docs/Booting/ROOTFS_DISCOVERY/
- 引导加载程序接口: http://systemd.cn/docs/Booting/BOOT_LOADER_INTERFACE/
- 恢复出厂设置: http://systemd.cn/docs/Booting/FACTORY_RESET/
- 挂载点可用性要求: http://systemd.cn/docs/Booting/MOUNT_REQUIREMENTS/
- TPM2 PCR测量: http://systemd.cn/docs/Booting/TPM2_PCR_MEASUREMENTS/
- Boot Loader Specification: http://systemd.cn/docs/BOOT_LOADER_SPECIFICATION/
- Discoverable Partitions: http://systemd.cn/docs/DISCOVERABLE_PARTITIONS/
- Elf Dlopen Metadata: http://systemd.cn/docs/ELF_DLOPEN_METADATA/
- Osc Context: http://systemd.cn/docs/OSC_CONTEXT/
- Package Metadata for Executable Files: http://systemd.cn/docs/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/
- API File Systems: http://systemd.cn/docs/API_FILE_SYSTEMS/
- Appstream Bundle: http://systemd.cn/docs/APPSTREAM_BUNDLE/
- Backports: http://systemd.cn/docs/BACKPORTS/
- Booting Without /usr is Broken: http://systemd.cn/docs/SEPARATE_USR_IS_BROKEN/
- Code Quality Tools: http://systemd.cn/docs/CODE_QUALITY/
- Coding Style: http://systemd.cn/docs/CODING_STYLE/
- Compatibility with SysV: http://systemd.cn/docs/INCOMPATIBILITIES/
- Container Interface: http://systemd.cn/docs/CONTAINER_INTERFACE/
- Contributing: http://systemd.cn/docs/CONTRIBUTING/
- Control Group APIs and Delegation: http://systemd.cn/docs/CGROUP_DELEGATION/
- Converting Existing Users to systemd-homed: http://systemd.cn/docs/CONVERTING_TO_HOMED/
- Credentials: http://systemd.cn/docs/CREDENTIALS/
- Desktop Environment Integration: http://systemd.cn/docs/DESKTOP_ENVIRONMENTS/
- Diagnosing Boot Problems: http://systemd.cn/docs/DEBUGGING/
- File Descriptor Store: http://systemd.cn/docs/FILE_DESCRIPTOR_STORE/
- Frequently Asked Questions: http://systemd.cn/docs/FAQ/
- Governance: http://systemd.cn/docs/GOVERNANCE/
- Hacking on systemd: http://systemd.cn/docs/HACKING/
- Home Directories: http://systemd.cn/docs/HOME_DIRECTORY/
- Inhibitor Locks: http://systemd.cn/docs/INHIBITOR_LOCKS/
- Initrd Interface: http://systemd.cn/docs/INITRD_INTERFACE/
- Journal Export Formats: http://systemd.cn/docs/JOURNAL_EXPORT_FORMATS/
- Journal File Format: http://systemd.cn/docs/JOURNAL_FILE_FORMAT/
- Journal Message Catalogs: http://systemd.cn/docs/CATALOG/
- JSON Group Records: http://systemd.cn/docs/GROUP_RECORD/
- JSON User Records: http://systemd.cn/docs/USER_RECORD/
- Known Environment Variables: http://systemd.cn/docs/ENVIRONMENT/
- Locking Block Device Access: http://systemd.cn/docs/BLOCK_DEVICE_LOCKING/
- Minimal Builds: http://systemd.cn/docs/MINIMAL_BUILDS/
- My Service Can't Get Realtime!: http://systemd.cn/docs/MY_SERVICE_CANT_GET_REALTIME/
- Native Journal Protocol: http://systemd.cn/docs/JOURNAL_NATIVE_PROTOCOL/
- New Control Group Interfaces: http://systemd.cn/docs/CONTROL_GROUP_INTERFACE/
- Notes for Translators: http://systemd.cn/docs/TRANSLATORS/
- Password Agents: http://systemd.cn/docs/PASSWORD_AGENTS/
- Pax Controla Groupiana: http://systemd.cn/docs/PAX_CONTROL_GROUPS/
- Portability and Stability: http://systemd.cn/docs/PORTABILITY_AND_STABILITY/
- Portable Services Introduction: http://systemd.cn/docs/PORTABLE_SERVICES/
- Porting systemd To New Distributions: http://systemd.cn/docs/DISTRO_PORTING/
- Porting to New Architectures: http://systemd.cn/docs/PORTING_TO_NEW_ARCHITECTURES/
- Predictable Network Interface Names: http://systemd.cn/docs/PREDICTABLE_INTERFACE_NAMES/
- Presets: http://systemd.cn/docs/PRESET/
- Project IDs for Disk Quotas on Exec Directories: http://systemd.cn/docs/DISK-QUOTAS-PROJECTIDS/
- Random Seeds: http://systemd.cn/docs/RANDOM_SEEDS/
- Reporting of Security Vulnerabilities: http://systemd.cn/docs/SECURITY/
- Resource Pressure Handling: http://systemd.cn/docs/PRESSURE/
- Running Services After the Network Is Up: http://systemd.cn/docs/NETWORK_ONLINE/
- Safely Building Images: http://systemd.cn/docs/BUILDING_IMAGES/
- Socket Activation with Popular Daemons: http://systemd.cn/docs/DAEMON_SOCKET_ACTIVATION/
- Steps to a Successful Release: http://systemd.cn/docs/RELEASE/
- Storage Daemons for the Root File System: http://systemd.cn/docs/ROOT_STORAGE_DAEMONS/
- systemd Community Conduct Guidelines: http://systemd.cn/docs/CODE_OF_CONDUCT/
- systemd Coredump Handling: http://systemd.cn/docs/COREDUMP/
- systemd File Hierarchy Requirements: http://systemd.cn/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS/
- systemd Optimizations: http://systemd.cn/docs/OPTIMIZATIONS/
- systemd Repository Architecture: http://systemd.cn/docs/ARCHITECTURE/
- systemd-boot UEFI Boot Manager: http://systemd.cn/docs/BOOT/
- systemd-homed and JSON User/Group Record Support in Desktop Environments: http://systemd.cn/docs/USERDB_AND_DESKTOPS/
- systemd-resolved and VPNs: http://systemd.cn/docs/RESOLVED-VPNS/
- Testing systemd Using Sanitizers: http://systemd.cn/docs/TESTING_WITH_SANITIZERS/
- The Case for the /usr Merge: http://systemd.cn/docs/THE_CASE_FOR_THE_USR_MERGE/
- Tips And Tricks: http://systemd.cn/docs/TIPS_AND_TRICKS/
- User Record Blob Directories: http://systemd.cn/docs/USER_RECORD_BLOB_DIRS/
- User/Group Name Syntax: http://systemd.cn/docs/USER_NAMES/
- User/Group Record Lookup API via Varlink: http://systemd.cn/docs/USER_GROUP_API/
- Users, Groups, UIDs and GIDs on systemd Systems: http://systemd.cn/docs/UIDS-GIDS/
- Using /tmp/ and /var/tmp/ Safely: http://systemd.cn/docs/TEMPORARY_DIRECTORIES/
- Varlink API Style: http://systemd.cn/docs/VARLINK/
- VM Interface: http://systemd.cn/docs/VM_INTERFACE/
- What Settings Are Currently Available For Transient Units?: http://systemd.cn/docs/TRANSIENT-SETTINGS/
- Writing Desktop Environments: http://systemd.cn/docs/WRITING_DESKTOP_ENVIRONMENTS/
- Writing Display Managers: http://systemd.cn/docs/WRITING_DISPLAY_MANAGERS/
- Writing Network Configuration Managers: http://systemd.cn/docs/WRITING_NETWORK_CONFIGURATION_MANAGERS/
- Writing Resolver Clients: http://systemd.cn/docs/WRITING_RESOLVER_CLIENTS/
- Writing syslog Daemons Which Cooperate Nicely With systemd: http://systemd.cn/docs/SYSLOG/
- Writing VM and Container Managers: http://systemd.cn/docs/WRITING_VM_AND_CONTAINER_MANAGERS/


# JSON Group Records

Long story short: JSON Group Records are to `struct group` what
[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
they carry some identical (or at least very similar) fields.

## Fields in the `regular` section

`groupName` → A string with the UNIX group name.
Matches the `gr_name` field of UNIX/glibc NSS `struct group`,
or the shadow structure `struct sgrp`'s `sg_namp` field.

`uuid` -> A string containing a lowercase UUID that identifies this group.
The same considerations apply to this field as they do to the corresponding field of user records.
Users and groups MUST NOT share the same UUID unless they are semantically
the same security principal, e.g. if a system synthesizes a single-user group from
user records to be the user's primary group.

`realm` → The "realm" the group belongs to, conceptually identical to the same field of user records.
A string in DNS domain name syntax.

`description` → A descriptive string for the group.
This is similar to the `realName` field of user records, and accepts arbitrary strings, as long as
they follow the same GECOS syntax requirements as `realName`.

`disposition` → The disposition of the group, conceptually identical to the
same field of user records. A string.

`service` → A string, an identifier for the service managing this group record
(this field is typically in reverse domain name syntax.)

`lastChangeUSec` → An unsigned 64-bit integer, a timestamp
(in µs since the UNIX epoch 1970) of the last time the group record has been modified.
(Covers only the `regular`, `perMachine` and `privileged` sections).

`gid` → An unsigned integer in the range 0…4294967295: the numeric UNIX group ID (GID) to use for the group.
This corresponds to the `gr_gid` field of `struct group`.

`members` → An array of strings, listing user names that are members of this group.
Note that JSON user records also contain a `memberOf` field, or in other
words a group membership can either be denoted in the JSON user record or in
the JSON group record, or in both.

The list of memberships should be determined as the combination of both lists (plus optionally others).
If a user is listed as member of a group and doesn't exist it should be ignored.
This field corresponds to the `gr_mem` field of `struct group` and the `sg_mem` field of `struct sgrp`.

`administrators` → Similarly, an array of strings, listing user names that shall be considered "administrators" of this group.
This field corresponds to the `sg_adm` field of `struct sgrp`.

`privileged`/`perMachine`/`binding`/`status`/`signature`/`secret` → The
objects/arrays for the other six group record sections.
These are organized the same way as for the JSON user records, and have the same semantics.

## Fields in the `privileged` section

The following fields are defined:

`hashedPassword` → An array of strings with UNIX hashed passwords;
see the matching field for user records for details.
This field corresponds to the `sg_passwd` field of `struct sgrp` (and `gr_passwd` of `struct group` in a way).

## Fields in the `perMachine` section

`matchMachineId`/`matchHostname` → Strings, match expressions similar as for
user records, see the user record documentation for details.

The following fields are defined for the `perMachine` section and are defined
equivalent to the fields of the same name in the `regular` section, and
override those:

`gid`, `members`, `administrators`

## Fields in the `binding` section

The following fields are defined for the `binding` section, and are equivalent
to the fields of the same name in the `regular` and `perMachine` sections:

`gid`

## Fields in the `status` section

The following fields are defined in the `status` section, and are mostly
equivalent to the fields of the same name in the `regular` section, though with
slightly different conceptual semantics, see the same fields in the user record
documentation:

`service`

## Fields in the `signature` section

The fields in this section are defined identically to those in the matching
section in the user record.

## Fields in the `secret` section

Currently no fields are defined in this section for group records.

## Mapping to `struct group` and `struct sgrp`

When mapping classic UNIX group records (i.e. `struct group` and `struct sgrp`)
to JSON group records the following mappings should be applied:

| Structure      | Field       | Section      | Field            | Condition                  |
|----------------|-------------|--------------|------------------|----------------------------|
| `struct group` | `gr_name`   | `regular`    | `groupName`      |                            |
| `struct group` | `gr_passwd` | `privileged` | `password`       | (See notes below)          |
| `struct group` | `gr_gid`    | `regular`    | `gid`            |                            |
| `struct group` | `gr_mem`    | `regular`    | `members`        |                            |
| `struct sgrp`  | `sg_namp`   | `regular`    | `groupName`      |                            |
| `struct sgrp`  | `sg_passwd` | `privileged` | `password`       | (See notes below)          |
| `struct sgrp`  | `sg_adm`    | `regular`    | `administrators` |                            |
| `struct sgrp`  | `sg_mem`    | `regular`    | `members`        |                            |

At this time almost all Linux machines employ shadow passwords, thus the
`gr_passwd` field in `struct group` is set to `"x"`, and the actual password
is stored in the shadow entry `struct sgrp`'s field `sg_passwd`.

## Extending These Records

The same logic and recommendations apply as for JSON user records.

## Examples

A reasonable group record for a system group might look like this:

```json
{
	"groupName" : "systemd-resolve",
	"gid" : 193,
	"status" : {
		"6b18704270e94aa896b003b4340978f1" : {
			"service" : "io.systemd.NameServiceSwitch"
		}
	}
}
```

And here's a more complete one for a regular group:

```json
{
	"groupName" : "grobie",
	"binding" : {
		"6b18704270e94aa896b003b4340978f1" : {
			"gid" : 60232
		}
	},
	"disposition" : "regular",
	"status" : {
		"6b18704270e94aa896b003b4340978f1" : {
			"service" : "io.systemd.Home"
		}
	}
}
```