spell checking, remove a lot of whitespace, rephrasing some things, reformatting texttt, fix broken link (#199)

Author: HereThereBeDragons

apx-contact.rst

@@ -4,7 +4,7 @@ Contact Information
 For support requests and bug reports, please submit a GitHub issue in our
 `issue tracker <https://github.com/cvmfs/cvmfs/issues>`_.
 
-Together with bug reports, please attach a "bugreport tarball", which is created
+Together with bug reports, please attach a "bug report tarball", which is created
 with ``sudo cvmfs_config bugreport``.
 
 Discourse Forum

apx-issues.rst

@@ -13,6 +13,6 @@ This issue is resolved in CernVM-FS 2.11.
 Publisher nodes with AUFS and XFS
 ---------------------------------
 
-If the /tmp file system is on xfs, the publisher node cannot be used with AUFS.
+If the ``/tmp`` file system is on xfs, the publisher node cannot be used with AUFS.
 On such systems, adding the mount option ``xino=/dev/shm/aufs.xino`` can be
 a workaround. In general, new repositories should use OverlayFS if available.

apx-parameters.rst

@@ -60,7 +60,7 @@ CVMFS_HTTP_PROXY                | Chain of HTTP proxy groups used by CernVM-FS.
 CVMFS_IGNORE_SIGNATURE          When set to *yes*, don't verify CernVM-FS file catalog signatures.
 CVMFS_INITIAL_GENERATION        Initial inode generation.  Used for testing.
 CVMFS_INSTRUMENT_FUSE           | When set to *true* gather performance statistics about the FUSE callbacks.
-                                | The results are displayed with `cvmfs_talk internal affairs`.
+                                | The results are displayed with ``cvmfs_talk internal affairs``.
 CVMFS_NFS_INTERLEAVED_INODES    In NFS mode, use only inodes of the form :math:`an+b`, specified as "b%a".
 CVMFS_INFLUX_EXTRA_FIELDS       Static fields always attached to the (absolute) output of the InfluxDB Telemetry Aggregator
 CVMFS_INFLUX_EXTRA_TAGS         Static tags always attached to the (absolute + delta) output of the InfluxDB Telemetry Aggregator
@@ -79,7 +79,7 @@ CVMFS_MAX_IPADDR_PER_PROXY      | Limit the number of IP addresses a proxy names
 CVMFS_MAX_RETRIES               Maximum number of retries for a given proxy/host combination.
 CVMFS_MAX_SERVERS               Limit the number of (geo sorted) stratum 1 servers that are effectively used.
 CVMFS_MAX_TTL                   Maximum file catalog TTL in minutes.  Can overwrite the TTL stored in the catalog.
-CVMFS_MEMCACHE_SIZE             Size of the CernVM-FS meta-data memory cache in Megabyte.
+CVMFS_MEMCACHE_SIZE             Size of the CernVM-FS metadata memory cache in Megabyte.
 CVMFS_MOUNT_RW                  | Mount CernVM-FS as a read/write file system.  Write operations will fail
                                 | but this option can workaround faulty ``open()`` flags.
 CVMFS_NFILES                    Maximum number of open file descriptors that can be used by the CernVM-FS process.
@@ -222,7 +222,7 @@ CVMFS_UNION_DIR                     | Mount point of the union file system for c
                                     | Here, changes to the repository are performed
                                     | (see :ref:`sct_repocreation_update`).
 CVMFS_UNION_FS_TYPE                 | Defines the union file system to be used for the repository.
-                                    | (currently `aufs` and `overlayfs` are fully supported)
+                                    | (only ``overlayfs`` is fully supported, ``aufs`` has no active support anymore)
 CVMFS_UPLOAD_STATS_DB               | Publish repository statistics data file to the Stratum 0 /stats location
 CVMFS_UPLOAD_STATS_PLOTS            | Publish repository statistics plots and webpage to the Stratum 0 /stats location (requires ROOT)
 CVMFS_UPSTREAM_STORAGE              | Upstream spooler description defining the basic upstream storage type

apx-rpms.rst

@@ -14,12 +14,12 @@ The CernVM-FS software is available in form of several packages:
     cern.ch, egi.eu, and opensciencegrid.org domains.
 
 **cvmfs-config-none**
-    Empty package to satisfy the cvmfs-config requirement of the cvmfs
+    Empty package to satisfy the ``cvmfs-config`` requirement of the cvmfs
     package without actually installing any configuration.
 
 **cvmfs**
     Contains the Fuse module and additional client tools. It has
-    dependencies to at least one of the cvmfs-config-\ :math:`\cdots`
+    dependencies to at least one of the ``cvmfs-config-...``
     packages.
 
 **cvmfs-fuse3**
@@ -50,12 +50,12 @@ The CernVM-FS software is available in form of several packages:
     on a publisher node.
 
 **cvmfs-notify**
-    Websockets frontend for used for repository update notifications. Supposed
+    WebSockets frontend for used for repository update notifications. Supposed
     to be co-located with a RabbitMQ service.
 
 **kernel-...-.aufs21**
-    Scientific Linux 6 kernel with aufs. Required for SL6 based
-    Stratum 0 servers.
+    Scientific Linux 6 kernel with ``aufs``. Required for SL6 based
+    Stratum 0 servers. (Note: no active support for ``aufs`` anymore)
 
 **cvmfs-shrinkwrap**
     Stand-alone utility to export file system trees into containers for HPC

apx-security.rst

@@ -4,47 +4,47 @@ Security Considerations
 =======================
 
 CernVM-FS provides end-to-end data integrity and authenticity using a signed
-Merkle Tree.  CernVM-FS clients verify the signature and the content hashes of
-all downloaded data.  Once a particular revision of a file system is stored in
+Merkle Tree. CernVM-FS clients verify the signature and the content hashes of
+all downloaded data. Once a particular revision of a file system is stored in
 a client's local cache, the client will not apply an older revision anymore.
 
 The public key used to ultimately verify a repository's signature needs to be
 distributed to clients through a channel different from CernVM-FS content
-distribution.  In practice, these public keys are distributed as part of the
-source code or through ``cvmfs-config-...`` packages.  One or multiple public
+distribution. In practice, these public keys are distributed as part of the
+source code or through ``cvmfs-config-...`` packages. One or multiple public
 keys can be configured for a repository (the *fully qualified repository name*),
 all repositories within a specific domain (like ``*.cern.ch``) or all
-repositories (``*``).  If multiple keys are configured, it is sufficient if any
+repositories (``*``). If multiple keys are configured, it is sufficient if any
 of them validates a signature.
 
 Besides the client, data is also verified by the replication code (Stratum 1 or
 preloaded cache) and by the release manager machine in case the repository is
 stored in S3 and not on a local file system.
 
-CernVM-FS does **not** provide data confidentiality out of the box.  By default
+CernVM-FS does **not** provide data confidentiality out of the box. By default,
 data is transferred through HTTP and thus only public data should be stored on
-CernVM-FS.  However, CernVM-FS can be operated with HTTPS data transport.  In
+CernVM-FS. However, CernVM-FS can be operated with HTTPS data transport. In
 combination with client-authentication using an authz helper (see Section
 :ref:`sct_authz`), CernVM-FS can be configured for end-to-end data
 confidentiality.
 
 Once downloaded and stored in a cache, the CernVM-FS client fully trusts the
-cache.  Data in the cache can be checked for silent corruption but no integrity
+cache. Data in the cache can be checked for silent corruption but no integrity
 re-check takes place.
 
 Signature Details
 -----------------
 
-Creating and validating a repository signature is a two-step process.  The
+Creating and validating a repository signature is a two-step process. The
 *repository manifest* (the file ``.cvmfspublished``) is signed by a private RSA
 key whose public part is stored in the form of an X.509 certificate in the
-repository.  The fingerprint of all certificates that are allowed to sign a
+repository. The fingerprint of all certificates that are allowed to sign a
 repository is stored on a *repository whitelist* (the file ``.cvmfswhitelist``).
 The whitelist is signed with a different RSA key, the *repository master key*.
 Only the public part of this master key needs to be distributed to clients.
 
 The X.509 certificate currently only serves as an envelope for the public part
-of a repository key.  No further certificate validation takes place.
+of a repository key. No further certificate validation takes place.
 
 The repository manifest contains, among other information, the content hash of
 the root file catalog, the content hash of the signing certificate, the fully
@@ -53,11 +53,11 @@ content of the manifest is hashed and encrypted with a private repository key.
 The timestamp and repository name are used prevent replay attacks.
 
 The whitelist contains the fully qualified repository name, a creation
-timestamp, an expiry timestamp, and the certificate fingerprints.  Since the
+timestamp, an expiry timestamp, and the certificate fingerprints. Since the
 whitelist expires, it needs to be regularly resigned.
 
 The private part of the repository key needs to be accessible on the release
-manager machine.  The private part of the repository master key used to sign the
+manager machine. The private part of the repository master key used to sign the
 whitelist *can* be maintained on a file on the release manager machine.
 We recommend, however, to use a smart card to store this private key.
 See section :ref:`sct_master_keys` for more details.
@@ -67,27 +67,27 @@ Content Hashes
 --------------
 
 CernVM-FS supports multiple content hash algorithms: SHA-1 (default),
-RIPEMD-160, and SHAKE-128 with 160 output bits.  The content hash algorithm
-can be changed with every repository publish operation.  Files and file catalogs
-hashed with different content hash algorithms can co-exist.  On changing the
+RIPEMD-160, and SHAKE-128 with 160 output bits. The content hash algorithm
+can be changed with every repository publish operation. Files and file catalogs
+hashed with different content hash algorithms can co-exist. On changing the
 algorithm, new and changed files are hashed with the new algorithm, existing
-data remains unchanged.  That allows seamless migration from one algorithm to
+data remains unchanged. That allows seamless migration from one algorithm to
 another.
 
 
 Local UNIX Permissions
 ----------------------
 
-Most parts of CernVM-FS do not require root privileges.  On the server side,
+Most parts of CernVM-FS do not require root privileges. On the server side,
 only creating and deleting a repository (or replica) requires root privileges.
 Repository transactions and snapshots can be performed with an unprivileged user
-account.  In order to remount a new file system revision after publishing a
-transaction, the release manager machines uses a custom suid binary.
+account. In order to remount a new file system revision after publishing a
+transaction, the release manager machine uses a custom suid binary.
 
-On client side, the CernVM-FS fuse module is normally started as root.  It drops
+On client side, the CernVM-FS fuse module is normally started as root. It drops
 root privileges and changes the persona to the ``cvmfs`` user early in the file
-system initialization.  The client RPM package installs SElinux rules for RHEL6
-and RHEL7.  The cache directory should be labeled as ``cvmfs_cache_t``.
+system initialization. The client RPM package installs SElinux rules for RHEL6
+and RHEL7. The cache directory should be labeled as ``cvmfs_cache_t``.
 
 
 .. _sct_running_client_as_normal_user:
@@ -96,15 +96,15 @@ Running the client as a normal user
 -----------------------------------
 
 The client can also be started as a normal user. In this case, the user needs
-to have access to /dev/fuse.  On Linux kernels < 4.18, mounting /dev/fuse is
+to have access to /dev/fuse. On Linux kernels < 4.18, mounting /dev/fuse is
 either performed by fuse's ``fusermount`` utility or through a pre-mounted file
 descriptor. On newer Linux kernels, the client can mount as an unprivileged
 user in a user namespace with a detached mount namespace.
 
 The easiest way to run the client as a normal user is with the
-`cvmfsexec <https://github.com/cvmfs/cvmfsexec>`_ package.  It supports
+`cvmfsexec <https://github.com/cvmfs/cvmfsexec>`_ package. It supports
 four ways to run cvmfs as an unprivileged user, depending on the
-capabilities available on the host.  See the README there for details.
+capabilities available on the host. See the README there for details.
 
 
 SETUID bit and file capabilities
@@ -120,7 +120,7 @@ and file capabilities is restored.
 CernVM-FS Software Distribution
 -------------------------------
 
-CernVM-FS software is distributed through HTTPS in packages.  There are yum and
-apt repositories for Linux and ``pkg`` packages for OS X.  Software is available
-from HTTPS servers.  The Linux packages and repositories are signed with a GPG
+CernVM-FS software is distributed through HTTPS in packages. There are yum and
+apt repositories for Linux and ``pkg`` packages for OS X. Software is available
+from HTTPS servers. The Linux packages and repositories are signed with a GPG
 key.

apx-serverinfra.rst

@@ -18,7 +18,7 @@ Prerequisites
 A CernVM-FS server installation depends on the following environment
 setup and tools to be in place:
 
--  Appropriate kernel version.  You must have ONE of the following:
+-  Appropriate kernel version. You must have ONE of the following:
 
    -   kernel 4.2.x or later.
    -   RHEL7.3 kernel (for OverlayFS)
@@ -34,7 +34,7 @@ Local Backend Storage Infrastructure
 ------------------------------------
 
 CernVM-FS stores the entire repository content (file content and
-meta-data catalogs) into a content addressable storage (CAS). This
+metadata catalogs) into a content addressable storage (CAS). This
 storage can either be a file system at ``/srv/cvmfs`` or an S3
 compatible object storage system (see ":ref:`sct_s3storagesetup`" for
 details). In the former case the contents of ``/srv/cvmfs`` are as
@@ -148,7 +148,7 @@ Repository Configuration Directory
 
 The authoritative configuration of a CernVM-FS repository is located in
 ``/etc/cvmfs/repositories.d`` and should only be writable by the
-administrator. Furthermore the repository's keychain is located in
+administrator. Furthermore, the repository's keychain is located in
 ``/etc/cvmfs/keys`` and follows the naming convention ``<fqrn>.crt`` for
 the certificate, ``<fqrn>.key`` for the repository's private key and
 ``<fqrn>.pub`` for the public key. All of those files can be symlinked
@@ -199,14 +199,14 @@ chosen backend storage type. For an S3 hosted backend storage, the
 CernVM-FS client can usually be directly pointed to the S3 bucket used
 for storage (see ":ref:`sct_s3storagesetup`" for details). In case of a
 local file system backend any web server can be used for this purpose.
-By default CernVM-FS assumes Apache and uses that automatically.
+By default, CernVM-FS assumes Apache and uses that automatically.
 
 Internally the CernVM-FS server uses a SUID binary (i.e.
 ``cvmfs_suid_helper``) to manipulate its mount points. This is necessary
 since transactional CernVM-FS commands must be accessible to the
 repository owner that is usually different from root. Both the mount
 directives for ``/var/spool/cvmfs/<fqrn>/rdonly`` and ``/cvmfs/<fqrn>``
-must be placed into ``/etc/fstab`` for this reason. By default
+must be placed into ``/etc/fstab`` for this reason. By default,
 CernVM-FS uses the following entries for these mount points:
 
 ::

conf.py

@@ -68,7 +68,7 @@
 #
 # This is also used if you do content translation via gettext catalogs.
 # Usually you set "language" from the command line for these cases.
-language = None
+language ="en"
 
 # There are two options for replacing |today|: either, you set today to some
 # non-false value, then it is used: