From aafd4b66811aaa06d4b2760ec37ce80766bcee30 Mon Sep 17 00:00:00 2001 From: Edita Kizinevic Date: Fri, 3 Dec 2021 17:08:43 +0100 Subject: [PATCH] Typos found by codespell --- README.md | 2 +- bind_paths_and_mounts.rst | 2 +- build_env.rst | 3 +-- cli.rst | 1 - cloud_library.rst | 3 +-- contributing.rst | 6 ------ definition_files.rst | 2 +- encryption.rst | 4 ++-- environment_and_metadata.rst | 4 ++-- gpu.rst | 2 +- introduction.rst | 1 - license.rst | 1 - networking.rst | 2 +- oci_runtime.rst | 2 +- pygments_json.py | 2 +- pygments_singularity.py | 1 - running_services.rst | 4 ++-- security.rst | 11 ++++------- signNverify.rst | 1 - singularity_and_docker.rst | 24 ++++++++++++------------ 20 files changed, 31 insertions(+), 47 deletions(-) diff --git a/README.md b/README.md index a23ee55d..9e2c4e5d 100755 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ pip3 install --user Sphinx sphinx-rtd-theme If your version of python 3 does not come with `pip` / `pip3`, you may need to install a `python3-pip`package with `apt` or `yum`, or you can install pip -follwing [the instructions here](https://pip.pypa.io/en/stable/installing/). +following [the instructions here](https://pip.pypa.io/en/stable/installing/). You're all set! After this you will only need to use your favorite editor to work with the RST files. diff --git a/bind_paths_and_mounts.rst b/bind_paths_and_mounts.rst index 73e0cb90..1f4b4b86 100755 --- a/bind_paths_and_mounts.rst +++ b/bind_paths_and_mounts.rst @@ -136,7 +136,7 @@ within the container. {Singularity} can often carry out this operation even in the absence of the "overlay fs" feature. However, binding paths to non-existent points within the container can result in -unexpected behavior when used in conjuction with the ``--writable`` flag, and is +unexpected behavior when used in conjunction with the ``--writable`` flag, and is therefore disallowed. If you need to specify bind paths in combination with the ``--writable`` flag, please ensure that the appropriate bind points exist within the container. If they do not already exist, it will be necessary to modify the diff --git a/build_env.rst b/build_env.rst index 09ac35b7..ae85b3cb 100644 --- a/build_env.rst +++ b/build_env.rst @@ -55,7 +55,7 @@ a location that is: .. warning:: If you are not certain that your ``$HOME`` or - ``SINGULARITY_CACHEDIR`` filesytems support atomic rename, do not + ``SINGULARITY_CACHEDIR`` filesystems support atomic rename, do not run {Singularity} in parallel using remote container URLs. Instead use ``singularity pull`` to create a local SIF image, and then run this SIF image in a parallel step. An alternative is to use the @@ -316,4 +316,3 @@ Encryption **SINGULARITY_ENCRYPTION_PASSPHRASE** Used to pass a plaintext passphrase to encrypt a container file system (with the ``--encrypt`` flag). The default is empty. **SINGULARITY_ENCRYPTION_PEM_PATH** Used to specify the location of a public key to use for container encryption (with the ``--encrypt`` flag). The default is empty. - diff --git a/cli.rst b/cli.rst index e27633e7..c0429c24 100644 --- a/cli.rst +++ b/cli.rst @@ -11,4 +11,3 @@ Below are links to the automatically generated CLI docs :glob: cli/* - diff --git a/cloud_library.rst b/cloud_library.rst index 4adf5b1c..d1221670 100644 --- a/cloud_library.rst +++ b/cloud_library.rst @@ -68,7 +68,7 @@ The ``:latest`` is the container tag. Tags are used to have different version of the same container. .. note:: - When pushing your container, theres no need to add a ``.sif`` (Singularity Image Format) to the end of the container name, (like + When pushing your container, there's no need to add a ``.sif`` (Singularity Image Format) to the end of the container name, (like on your local machine), because all containers on the library are SIF containers. Let's assume you have your container (v1.0.1), and you want to push @@ -307,4 +307,3 @@ After building, you can test your container like so: You can also use the web GUI to build containers remotely. First, go to https://cloud.sylabs.io/builder (make sure you are signed in). Then you can copy and paste, upload, or type your definition file. When you are finished, click build. Then you can download the container with the URL. - diff --git a/contributing.rst b/contributing.rst index fd3cdc78..b966bbde 100644 --- a/contributing.rst +++ b/contributing.rst @@ -203,9 +203,3 @@ will need to follow the next steps: git push origin master && # to update your fork \ git checkout new-feature && \ git merge master - - - - - - diff --git a/definition_files.rst b/definition_files.rst index a3cc21fe..f617b449 100755 --- a/definition_files.rst +++ b/definition_files.rst @@ -692,7 +692,7 @@ collection of different containers. {Singularity} implements SCIF, and you can read more about how to use it below. -SCIF is not specfic to {Singularity}. You can learn more about it at the +SCIF is not specific to {Singularity}. You can learn more about it at the project's site: ``_ which includes extended tutorials, the specification, and other information. diff --git a/encryption.rst b/encryption.rst index c8824b25..f956745d 100644 --- a/encryption.rst +++ b/encryption.rst @@ -126,7 +126,7 @@ like so: .. code-block:: none - # Generate a keypair + # Generate a key pair $ ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): rsa @@ -220,4 +220,4 @@ Running using an environment variable .. code-block:: none - $ SINGULARITY_ENCRYPTION_PEM_PATH=rsa_pri.pem singularity run encrypted.sif \ No newline at end of file + $ SINGULARITY_ENCRYPTION_PEM_PATH=rsa_pri.pem singularity run encrypted.sif diff --git a/environment_and_metadata.rst b/environment_and_metadata.rst index e025e695..0513082c 100644 --- a/environment_and_metadata.rst +++ b/environment_and_metadata.rst @@ -291,7 +291,7 @@ Manipulating ``PATH`` ``PATH`` is a special environment variable that tells a system where to look for programs that can be run. ``PATH`` contains multiple -filesytem locations (paths) separated by colons. When you ask to run a +filesystem locations (paths) separated by colons. When you ask to run a program ``myprog``, the system looks through these locations one by one, until it finds ``myprog``. @@ -758,7 +758,7 @@ the SIF file metadata descriptor. runtime, *and should not be modified* in the container. - **env**: All ``*.sh`` files in this directory are sourced in - alpha-numeric order when the container is started. For legacy + alphanumeric order when the container is started. For legacy purposes there is a symbolic link called ``/environment`` that points to ``/.singularity.d/env/90-environment.sh``. Whenever possible, avoid modifying or creating environment files manually to diff --git a/gpu.rst b/gpu.rst index e8c4670b..6ed3fac2 100644 --- a/gpu.rst +++ b/gpu.rst @@ -46,7 +46,7 @@ ensure that: * The application inside your container was compiled for a CUDA version, and device capability level, that is supported by the host card and driver. -These requirements are usually satisified by installing the NVIDIA drivers and +These requirements are usually satisfied by installing the NVIDIA drivers and CUDA packages directly from the NVIDIA website. Linux distributions may provide NVIDIA drivers and CUDA libraries, but they are often outdated which can lead to problems running applications compiled for the latest versions of CUDA. diff --git a/introduction.rst b/introduction.rst index 04f0aa0b..a7133ac7 100644 --- a/introduction.rst +++ b/introduction.rst @@ -154,4 +154,3 @@ Consolidating a work-flow into a {Singularity} container simplifies distribution and replication of scientific results. Making containers available along with published work enables other scientists to build upon (and verify) previous scientific work. - diff --git a/license.rst b/license.rst index 48ca13c5..25040ef7 100644 --- a/license.rst +++ b/license.rst @@ -6,4 +6,3 @@ This documentation is subject to the following 3-clause BSD license: .. include:: LICENSE :literal: - diff --git a/networking.rst b/networking.rst index 5faa7844..51b469c0 100644 --- a/networking.rst +++ b/networking.rst @@ -118,7 +118,7 @@ to the ``network`` configuration directory as required, and ================== The ``--network-args`` option provides a convenient way to specify arguments to -pass directly to the cni plugins. It must be used in conjuction with the +pass directly to the cni plugins. It must be used in conjunction with the ``--net`` flag. For instance, let's say you want to start an `NGINX `_ diff --git a/oci_runtime.rst b/oci_runtime.rst index 036ca200..436f72ed 100644 --- a/oci_runtime.rst +++ b/oci_runtime.rst @@ -62,7 +62,7 @@ Suppose the Singularity Image Format (SIF) file ``busybox_latest.sif`` exists lo This is one way to bootstrap creation of this image in SIF that *retains* a local copy - i.e., a local copy of the SIF file *and* a cached copy of the OCI blobs. Additional approaches and details can be found in the section :ref:`Support for Docker and OCI `). -For the purpose of boostrapping the creation of an OCI compliant container, this SIF file can be mounted as follows: +For the purpose of bootstrapping the creation of an OCI compliant container, this SIF file can be mounted as follows: .. code-block:: none diff --git a/pygments_json.py b/pygments_json.py index c0733aa6..b29afe38 100644 --- a/pygments_json.py +++ b/pygments_json.py @@ -63,7 +63,7 @@ class JSONLexer(RegexLexer): ], - # the root of a json document whould be a value + # the root of a json document would be a value 'root': [ include('value'), ], diff --git a/pygments_singularity.py b/pygments_singularity.py index 434a115e..7e9df3ad 100644 --- a/pygments_singularity.py +++ b/pygments_singularity.py @@ -31,4 +31,3 @@ class SingularityLexer(RegexLexer): (r'(.+?(?=^\s*%))|(.*)', using(BashLexer), '#pop'), ], } - diff --git a/running_services.rst b/running_services.rst index 8167dfe7..200889b8 100644 --- a/running_services.rst +++ b/running_services.rst @@ -425,7 +425,7 @@ Filesystem (SCIF) apps. {Singularity} implements SCIF, and you can read more about how to use it :ref:`apps `. - SCIF is not specfic to {Singularity}. You can learn more about it at the + SCIF is not specific to {Singularity}. You can learn more about it at the project site: `_. @@ -576,7 +576,7 @@ or another supervisor daemon installed on your host. Many init and supervisor daemons support managing processes via pid files. You can specify a `--pid-file` option to `singularity instance start` to write -the PID for an instance to the specifed file, e.g. +the PID for an instance to the specified file, e.g. .. code-block:: none diff --git a/security.rst b/security.rst index 34365140..d6fed29f 100644 --- a/security.rst +++ b/security.rst @@ -43,7 +43,7 @@ SingularityPRO - Long Term Support & Security Patches Security patches for {Singularity} are applied to the latest open-source version, so it is important to follow new releases and upgrade when -neccessary. +necessary. SingularityPRO is a professionally curated and licensed version of {Singularity} that provides added security, stability, and support @@ -72,7 +72,7 @@ privileges once they are inside of a container. The container file system is mounted using the ``nosuid`` option, and processes are started with the ``PR_NO_NEW_PRIVS`` flag set. This means that even if you run `sudo` inside your container, you won't be able to change to -another user, or gain root priveleges by other means. This approach +another user, or gain root privileges by other means. This approach provides a secure way for users to run containers and greatly simplifies things like reading and writing data to the host system with appropriate ownership. @@ -95,7 +95,7 @@ Singularity Image Format (SIF) ############################## Ensuring container security as a continuous process. {Singularity} -provides ways to ensure integrity throughout the lifecyle of a +provides ways to ensure integrity throughout the lifecycle of a container, i.e. at rest, in transit and while running. The SIF Singularity Image Format has been designed to achieve these goals. @@ -171,7 +171,7 @@ Security in the Sylabs Cloud ############################ `Sylabs Cloud `_ consists of a Remote -Builder, a Container Library, and a Keystore. Together, theses +Builder, a Container Library, and a Keystore. Together, these services provide an end-to-end solution for packaging and distributing applications in secure and trusted containers. @@ -244,6 +244,3 @@ Authentication and encryption request between the services is authenticated using the authentication token supplied by the user in the associated request. - - - diff --git a/signNverify.rst b/signNverify.rst index 8ff0472e..2a93eea6 100644 --- a/signNverify.rst +++ b/signNverify.rst @@ -342,4 +342,3 @@ container is signed, and the default ``verify`` behavior without specifying 2 |1 |NONE |JSON.Generic 3 |1 |NONE |FS Container verified: my_container.sif - diff --git a/singularity_and_docker.rst b/singularity_and_docker.rst index 2b036cc5..5519192e 100755 --- a/singularity_and_docker.rst +++ b/singularity_and_docker.rst @@ -232,7 +232,7 @@ complete contents of that image. ``pull`` is a one-time-only operation that builds a SIF file corresponding to the image retrieved from Docker Hub. Updates to the image on Docker Hub will *not* be reflected in the *local* copy. -In our example ``docker://sylabsio/lolcow``, ``sylabsio`` specifies a Docker Hub user, whereas ``lolcow`` is the name of the repository. Adding the option to specifiy an image tag, the generic version of the URI is ``docker:///[:]``. `Repositories on Docker Hub `_ provides additional details. +In our example ``docker://sylabsio/lolcow``, ``sylabsio`` specifies a Docker Hub user, whereas ``lolcow`` is the name of the repository. Adding the option to specify an image tag, the generic version of the URI is ``docker:///[:]``. `Repositories on Docker Hub `_ provides additional details. .. _sec:using_prebuilt_private_images: @@ -316,7 +316,7 @@ Based upon these exports, ``$ singularity pull docker://sylabsio/private`` allow .. note:: - This approach for authentication supports both interactive and non-interactive sessions. However, the requirement for a plain-text password assigned to an envrionment variable, is the security compromise for this flexibility. + This approach for authentication supports both interactive and non-interactive sessions. However, the requirement for a plain-text password assigned to an environment variable, is the security compromise for this flexibility. .. note:: @@ -402,7 +402,7 @@ Alternatively, for purely interactive use, ``--docker-login`` is recommended: INFO: Creating SIF file... INFO: Build complete: pytorch_18.11-py3.sif -Authentication aside, the outcome of the ``pull`` command is the {Singularity} container ``pytorch_18.11-py3.sif`` - i.e., a locally stored copy, that has been coverted to SIF. +Authentication aside, the outcome of the ``pull`` command is the {Singularity} container ``pytorch_18.11-py3.sif`` - i.e., a locally stored copy, that has been converted to SIF. -------------------------------------------------------- @@ -746,7 +746,7 @@ enables authenticated use of the private image. .. note:: - The ``-E`` option is required to preserve the user's existing environment variables upon ``sudo`` invocation - a priviledge escalation *required* to create {Singularity} containers via the ``build`` command. + The ``-E`` option is required to preserve the user's existing environment variables upon ``sudo`` invocation - a privilege escalation *required* to create {Singularity} containers via the ``build`` command. Remotely Bootstrapped and Built Containers @@ -802,7 +802,7 @@ A copy of the SIF file created by the service remains in the Sylabs Cloud {Singu .. note:: - The Sylabs Cloud is currently available as an Alpha Preview. In addition to the {Singularity} Library and Remote Builder, a Keystore service is also available. All three services make use of a *freemium* pricing model in supporting {Singularity} Community Edition. In contrast, all three services are included in SingularityPRO - an enterprise grade subscription for {Singularity} that is offered for a fee from Sylabs. For addtional details regarding the different offerings available for {Singularity}, please `consult the Sylabs website `_. + The Sylabs Cloud is currently available as an Alpha Preview. In addition to the {Singularity} Library and Remote Builder, a Keystore service is also available. All three services make use of a *freemium* pricing model in supporting {Singularity} Community Edition. In contrast, all three services are included in SingularityPRO - an enterprise grade subscription for {Singularity} that is offered for a fee from Sylabs. For additional details regarding the different offerings available for {Singularity}, please `consult the Sylabs website `_. .. _sec:mandatory_headers_docker_locally_bootstrapped_def_file: @@ -995,7 +995,7 @@ Suppose now that a {Singularity} ``%runscript`` **section** is added to the defi date -After conversion to SIF via the {Singularity} ``build`` command, exection of the resulting container produces the output: +After conversion to SIF via the {Singularity} ``build`` command, execution of the resulting container produces the output: .. code-block:: none @@ -1450,7 +1450,7 @@ The syntax for the ``oci`` bootstrap agent requires some elaboration, however. I blobs index.json oci-layout -In other words, it is the ``$OCI_BUNDLE_DIR`` containing the data and metadata that collectively comprise the image layed out in accordance with the OCI Image Layout Specification :ref:`as discussed previously ` - the same data and metadata that are assembled into a single SIF file through the ``build`` process. However, +In other words, it is the ``$OCI_BUNDLE_DIR`` containing the data and metadata that collectively comprise the image laid out in accordance with the OCI Image Layout Specification :ref:`as discussed previously ` - the same data and metadata that are assembled into a single SIF file through the ``build`` process. However, .. code-block:: none @@ -1536,7 +1536,7 @@ In the previous section, an OCI archive was created from locally available OCI b Thus ``https`` (and ``http``) are additional bootstrap agents available to seed development of containers for {Singularity}. -It is worth noting that the OCI image specfication compliant contents of this archive are: +It is worth noting that the OCI image specification compliant contents of this archive are: .. code-block:: none @@ -1668,8 +1668,8 @@ Applying ``build`` as follows results in the SIF container ``lolcow_oci_tarfile.sif``. -Working with Definition Files: Additonal Considerations -------------------------------------------------------- +Working with Definition Files: Additional Considerations +-------------------------------------------------------- In working with definition files, the following additional considerations arise: @@ -1737,7 +1737,7 @@ Best Practices Docker containers *allow for* privilege escalation. In a ``Dockerfile``, for example, the ``USER`` instruction allows for user and/or group settings to be made in the Linux operating environment. The trust model in {Singularity} is completely different: {Singularity} allows untrusted users to run untrusted containers in a trusted way. Because {Singularity} containers embodied as SIF files execute in *user* space, there is no possibility for privilege escalation. In other words, those familiar with Docker, should *not* expect access to elevated user permissions; and as a corollary, use of the ``USER`` instruction must be *avoided*. - {Singularity} does, however, allow for fine-grained control over the permissions that containers require for execution. Given that Singularilty executes in user space, it is not surprising that permissions need to be externally established *for* the container through use of the ``capability`` command. :ref:`Detailed elsewhere in this documentation `, {Singularity} allows users and/or groups to be granted/revoked authorized capabilties. Owing to {Singularity}'s trust model, this fundamental best practice can be stated as follows: + {Singularity} does, however, allow for fine-grained control over the permissions that containers require for execution. Given that Singularilty executes in user space, it is not surprising that permissions need to be externally established *for* the container through use of the ``capability`` command. :ref:`Detailed elsewhere in this documentation `, {Singularity} allows users and/or groups to be granted/revoked authorized capabilities. Owing to {Singularity}'s trust model, this fundamental best practice can be stated as follows: "Employ ``singularity capability`` to manage execution privileges for containers" @@ -1785,7 +1785,7 @@ Best Practices 8. Use of plain-text passwords for authentication - For obvious reasons, it is desireable to completely *avoid* use of plain-text passwords. Therefore, for interactive sessions requiring authentication, use of the ``--docker-login`` option for {Singularity}'s ``pull`` and ``build`` commands is *recommended*. At the present time, the *only* option available for non-interactive use is to :ref:`embed plain-text passwords into environment variables `. Because the Sylabs Cloud {Singularity} Library employs `time-limited API tokens for authentication `_, use of SIF containers hosted through this service provides a more secure means for both interactive *and* non-interactive use. This best practice is: + For obvious reasons, it is desirable to completely *avoid* use of plain-text passwords. Therefore, for interactive sessions requiring authentication, use of the ``--docker-login`` option for {Singularity}'s ``pull`` and ``build`` commands is *recommended*. At the present time, the *only* option available for non-interactive use is to :ref:`embed plain-text passwords into environment variables `. Because the Sylabs Cloud {Singularity} Library employs `time-limited API tokens for authentication `_, use of SIF containers hosted through this service provides a more secure means for both interactive *and* non-interactive use. This best practice is: "Avoid use of plain-text passwords"