TODO

@@ -104,7 +104,7 @@ Features:
   device node of current system, /usr device node, and matching verity, so that
   an installer can be made a "copy" installer of the booted OS
 
-* systemd-repart: make it a static checker during early boot for existence and
+* systemd-repart: make it a static checker during early boot for existance and
   absence of other partitions for trusted boot environments
 
 * systemd-repart: when no configuration is found, exit early do not check
@@ -114,7 +114,7 @@ Features:
 
 * userdb: allow username prefix searches in varlink API
 
-* userdb: allow existence checks
+* userdb: allow existance checks
 
 * pid: activation by journal search expression
 

docs/HOME_DIRECTORY.md

@@ -18,7 +18,7 @@ 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`](https://systemd.io/USER_RECORD). It is recommended to bring the
+Records`](https://systemd.io/USER_RECORDS). 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

docs/USER_RECORD.md

@@ -71,11 +71,11 @@ the following extensions are envisioned:
 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.
+Records](https://systemd.io/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 Lookup API via Varlink](https://systemd.io/USER_GROUP_API.md).
 
 ## Why JSON?
 
@@ -184,7 +184,7 @@ does not need to to be concerned with the `secret` section of user records, as
 the fields included therein are only useful when executing authentication
 operations natively against JSON user records.
 
-The `systemd-homed` manager uses all seven sections for various
+The `systemd-homed' manager uses all seven sections for various
 purposes. Inside the home directories (and if the LUKS2 backend is used, also
 in the LUKS2 header) a user record containing the `regular`, `privileged`,
 `perMachine` and `signature` sections is stored. `systemd-homed` also stores a

man/homectl.xml

@@ -39,19 +39,18 @@
     which manages home directories of users.</para>
 
     <para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus
-    include the user's full metadata record in the home's data storage itself, making them easy to migrate
+    include the user's full metadata record in the home's data storage itself, making them easily migratable
-    between machines. In particular, a home directory describes a matching user record, and every user record
+    between machines. In particular a home directory in itself describes a matching user record, and every
-    managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
+    user record managed by <filename>systemd-homed.service</filename> also implies existance and
-    directory. The user account and home directory become the same concept.</para>
+    encapsulation of a home directory. The user account and home directory hence become the same concept. The
-
+    following backing storage mechanisms are supported:</para>
-    <para>The following backing storage mechanisms are supported:</para>
 
     <itemizedlist>
-      <listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
+      <listitem><para>Individual LUKS2 encrypted loopback files for each user, located in
-      <filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
+      <filename>/home/*.home</filename>. At login the file systems contained in these files are mounted,
-      the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption
+      after the LUKS2 encrypted volume is attached. The user's password is identical to the encryption
       passphrase of the LUKS2 volume. Access to data without preceeding user authentication is thus not
-      possible, even for the system administrator. This storage mechanism provides the strongest data
+      possible, not even for the systems administrator. This storage mechanism provides the strongest data
       security and is thus recommended.</para></listitem>
 
       <listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such
@@ -62,7 +61,7 @@
       <listitem><para>An encrypted directory using <literal>fscrypt</literal> on file systems that support it
       (at the moment this is primarily <literal>ext4</literal>), located in
       <filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially
-      weaker than LUKS2, as most file system metadata is unprotected. Moreover
+      weaker than the two mechanisms described above, as most file system metadata is unprotected. Moreover
       it currently does not support changing user passwords once the home directory has been
       created.</para></listitem>
 
@@ -98,7 +97,7 @@
     <para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two
     states, or in a transition state between them: when <literal>active</literal> they are unlocked and
     mounted, and thus accessible to the system and its programs; when <literal>inactive</literal> they are
-    not mounted and thus not accessible. Activation happens automatically at login of the user and usually
+    not mounted and thus not accessible. Activation happens automatically at log-in of the user and usually
     can only complete after a password (or other authentication token) has been supplied. Deactivation
     happens after the user fully logged out. A home directory remains active as long as the user is logged in
     at least once, i.e. has at least one login session. When the user logs in a second time simultaneously
@@ -156,10 +155,10 @@
         user on another host. <option>-E</option> is equivalent to <option>-j --export-format=stripped</option>,
         <option>-EE</option> to <option>-j --export-format=minimal</option>. Note that when replicating user
         accounts user records acquired in <literal>stripped</literal> mode will retain the original
-        cryptographic signatures and thus may only be modified when the private key to update them is available
+        cryptographic signatures and thus may only modified when the private key to update them is available
-        on the destination machine. When replicating users in <literal>minimal</literal> mode, the signature
+        on the destination machine. When replicating users in <literal>minimal</literal> mode the signature
-        is removed during the replication and thus the record will be implicitly signed with the key of the destination
+        is remove during the replication and thus it is implicitly signed with the key of the destination
-        machine and may be updated there without any private key replication.</para></listitem>
+        machine and thus may be updated there without any private key replication.</para></listitem>
       </varlistentry>
 
       <xi:include href="user-system-options.xml" xpointer="host" />

man/pam_systemd_home.xml

@@ -47,12 +47,11 @@
         <listitem><para>Takes a boolean argument. If true, the home directory of the user will be suspended
         automatically during system suspend; if false it will remain active. Automatic suspending of the home
         directory improves security substantially as secret key material is automatically removed from memory
-        before the system is put to sleep and must be re-acquired (through user re-authentication) when
+        before the system is put to sleep and must be re-acquired (by user re-authentication) when coming
-        coming back from suspend. It is recommended to set this parameter for all PAM applications that have
+        back from suspend. It is recommended to set this parameter for all PAM applications that have support
-        support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
+        for automatically re-authenticating via PAM on system resume. If multiple sessions of the same user
-        same user are open in parallel the user's home directory will be left unsuspended on system suspend
+        are open in parallel the user's home directory will be left unsuspended on system suspend as soon as
-        as long as at least one of the sessions does not set this parameter. Defaults to
+        at least one of the sessions does not set this parameter. Defaults to off.</para></listitem>
-        off.</para></listitem>
       </varlistentry>
 
       <varlistentry>

meson_options.txt

@@ -98,7 +98,7 @@ option('portabled', type : 'boolean',
        description : 'install the systemd-portabled stack')
 option('userdb', type : 'boolean',
        description : 'install the systemd-userdbd stack')
-option('homed', type : 'combo', choices : ['auto', 'true', 'false'],
+option('homed', type : 'boolean',
        description : 'install the systemd-homed stack')
 option('networkd', type : 'boolean',
        description : 'install the systemd-networkd stack')

po/POTFILES.in

@@ -1,5 +1,4 @@
 src/core/org.freedesktop.systemd1.policy.in
-src/home/org.freedesktop.home1.policy
 src/hostname/org.freedesktop.hostname1.policy
 src/import/org.freedesktop.import1.policy
 src/locale/org.freedesktop.locale1.policy

po/fr.po

@@ -547,7 +547,7 @@ msgid "Change Session"
 msgstr "Changer de Session"
 
 #: src/login/org.freedesktop.login1.policy:396
-msgid "Authentication is required to change the virtual terminal."
+msgid "Authentication is required for changing the virtual terminal."
 msgstr "Authentification requise pour changer de terminal virtuel."
 
 #: src/machine/org.freedesktop.machine1.policy:22

po/pl.po

@@ -527,7 +527,7 @@ msgid "Change Session"
 msgstr "Zmiana sesji"
 
 #: src/login/org.freedesktop.login1.policy:396
-msgid "Authentication is required to change the virtual terminal."
+msgid "Authentication is required for changing the virtual terminal."
 msgstr "Wymagane jest uwierzytelnienie, aby zmienić terminal wirtualny."
 
 #: src/machine/org.freedesktop.machine1.policy:22

src/home/home-util.c

@@ -12,10 +12,10 @@
 
 bool suitable_user_name(const char *name) {
 
-        /* Checks whether the specified name is suitable for management via homed. Note that client-side we
+        /* Checks whether the specified name is suitable for management via homed. Note that our client side
-         * usually validate with the simple valid_user_group_name(), while server-side we are a bit more
+         * usually validate susing a simple valid_user_group_name(), while server side we are a bit more
-         * restrictive, so that we can change the rules server-side without having to update things
+         * restrictive, so that we can change the rules server side without having to update things client
-         * client-side too. */
+         * side, too. */
 
         if (!valid_user_group_name(name))
                 return false;

src/login/org.freedesktop.login1.policy

@@ -393,7 +393,7 @@
 
         <action id="org.freedesktop.login1.chvt">
                 <description gettext-domain="systemd">Change Session</description>
-                <message gettext-domain="systemd">Authentication is required to change the virtual terminal.</message>
+                <message gettext-domain="systemd">Authentication is required for changing the virtual terminal.</message>
                 <defaults>
                         <allow_any>auth_admin_keep</allow_any>
                         <allow_inactive>auth_admin_keep</allow_inactive>

src/shared/userdb.c

@@ -1246,7 +1246,7 @@ static int userdb_thread_sockaddr(struct sockaddr_un *ret_sa, socklen_t *ret_sal
         assert(ret_sa);
         assert(ret_salen);
 
-        /* This calculates an AF_UNIX socket address in the abstract namespace whose existence works as an
+        /* This calculates an AF_UNIX socket address in the abstract namespace whose existance works as an
          * indicator whether to emulate NSS records for complex user records that are also available via the
          * varlink protocol. The name of the socket is picked in a way so that:
          *