Various typo fixes and grammar corrections

diff --git a/TODO b/TODO
index 35bd4b12b7e8971279071fd4715e1573adca5924..bad3a7047b41406e3908e4f30ee58dbb0d28777f 100644 (file)
--- a/TODO
+++ b/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 existance and
+* systemd-repart: make it a static checker during early boot for existence 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 existance checks
+* userdb: allow existence checks
 
 * pid: activation by journal search expression
 

diff --git a/man/homectl.xml b/man/homectl.xml
index a2c4e4a253266c3fd38a3fd5959282d61bf1f7af..ae502c8ebbb132530dc760168b80ccf7d70c1422 100644 (file)
--- a/man/homectl.xml
+++ b/man/homectl.xml
@@ -39,18 +39,19 @@
     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 easily migratable
-    between machines. In particular a home directory in itself describes a matching user record, and every
-    user record managed by <filename>systemd-homed.service</filename> also implies existance and
-    encapsulation of a home directory. The user account and home directory hence become the same concept. The
-    following backing storage mechanisms are supported:</para>
+    include the user's full metadata record in the home's data storage itself, making them easy to migrate
+    between machines. In particular, a home directory describes a matching user record, and every user record
+    managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
+    directory. The user account and home directory become the same concept.</para>
+
+    <para>The following backing storage mechanisms are supported:</para>
 
     <itemizedlist>
-      <listitem><para>Individual LUKS2 encrypted loopback files for each user, located in
-      <filename>/home/*.home</filename>. At login the file systems contained in these files are mounted,
-      after the LUKS2 encrypted volume is attached. The user's password is identical to the encryption
+      <listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
+      <filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
+      the LUKS2 encrypted volume has been 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, not even for the systems administrator. This storage mechanism provides the strongest data
+      possible, even for the system 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
@@ -61,7 +62,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 the two mechanisms described above, as most file system metadata is unprotected. Moreover
+      weaker than LUKS2, 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>
 
@@ -97,7 +98,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 log-in of the user and usually
+    not mounted and thus not accessible. Activation happens automatically at login 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
@@ -155,10 +156,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 modified when the private key to update them is available
-        on the destination machine. When replicating users in <literal>minimal</literal> mode the signature
-        is remove during the replication and thus it is implicitly signed with the key of the destination
-        machine and thus may be updated there without any private key replication.</para></listitem>
+        cryptographic signatures and thus may only be modified when the private key to update them is available
+        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
+        machine and may be updated there without any private key replication.</para></listitem>
       </varlistentry>
 
       <xi:include href="user-system-options.xml" xpointer="host" />

diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml
index 8b8890db766804aadcae1a032253e79f89c4858d..72a6d091bfcab3f0dbc5b41be8581237ef285d8a 100644 (file)
--- a/man/pam_systemd_home.xml
+++ b/man/pam_systemd_home.xml
@@ -47,11 +47,12 @@
         <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 (by user re-authentication) when coming
-        back from suspend. It is recommended to set this parameter for all PAM applications that have support
-        for automatically re-authenticating via PAM on system resume. If multiple sessions of the same user
-        are open in parallel the user's home directory will be left unsuspended on system suspend as soon as
-        at least one of the sessions does not set this parameter. Defaults to off.</para></listitem>
+        before the system is put to sleep and must be re-acquired (through user re-authentication) when
+        coming back from suspend. It is recommended to set this parameter for all PAM applications that have
+        support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
+        same user are open in parallel the user's home directory will be left unsuspended on system suspend
+        as long as at least one of the sessions does not set this parameter. Defaults to
+        off.</para></listitem>
       </varlistentry>
 
       <varlistentry>

diff --git a/src/home/home-util.c b/src/home/home-util.c
index bf4f238099c685dd322f694cee6380e9bac38d12..82c50a6b515a19bc01b98b111346c36312d8aadf 100644 (file)
--- a/src/home/home-util.c
+++ b/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 our client side
-         * 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 client
-         * side, too. */
+        /* Checks whether the specified name is suitable for management via homed. Note that client-side we
+         * usually validate with the 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
+         * client-side too. */
 
         if (!valid_user_group_name(name))
                 return false;

diff --git a/src/shared/userdb.c b/src/shared/userdb.c
index af2a1cc76fcb9c06523ef1b9271f84c7e1b45700..215e17db9b6b55de4da507568d011ca505b3c22d 100644 (file)
--- a/src/shared/userdb.c
+++ b/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 existance works as an
+        /* This calculates an AF_UNIX socket address in the abstract namespace whose existence 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:
          *