diff --git a/userdocs/contributing/contributing.rst b/userdocs/contributing/contributing.rst index 38f7d47c..9f3d0f6b 100644 --- a/userdocs/contributing/contributing.rst +++ b/userdocs/contributing/contributing.rst @@ -9,7 +9,7 @@ contributing code are all ways to help! Join the community ================== -Whether you develop Warewulf or use it to deploy clusters, we hope ypu'll spread +Whether you develop Warewulf or use it to deploy clusters, we hope you'll spread the word! Share your experiences online. Ask your distribution to include support for Warewulf. Consider giving a talk at a conference or meetup! diff --git a/userdocs/contributing/development-environment.rst b/userdocs/contributing/development-environment.rst index b3c14c92..b48c6274 100644 --- a/userdocs/contributing/development-environment.rst +++ b/userdocs/contributing/development-environment.rst @@ -4,7 +4,7 @@ Development Environment To develop and test the Warewulf server, you need a single system (typically a virtual machine) to serve as a test server deployment. To actually test -provisioning your development server also needs a dedicated network that it can +provisioning, your development server also needs a dedicated network that it can run DHCP on. This can typically be provisioned as a virtual network bridge in virtual machine software. @@ -17,7 +17,7 @@ Options include: A Warewulf development environment should likely use Rocky Linux 9 or openSUSE LEAP 15, though there are ongoing development efforts using Debian and Ubuntu as -well.) +well. Compiling Warewulf for a Development Server =========================================== @@ -80,7 +80,7 @@ More information: * `The golang testing package `_ * `Table Driven Tests `_ -* `Testift assert `_ +* `Testify assert `_ * `Warewulf testenv `_ Using a Dev Container @@ -90,7 +90,7 @@ Visual Studio Code (VSC) can utilize a Dev Container for a self-contained environment that has all the necessary tools and dependencies to build and test Warewulf. The Dev Container is based on the Rocky 9 image and is built using the ``devcontainer.json`` file in the ``.devcontainer`` directory of the Warewulf -repository. To use this working Docker/Podman and VSC installations are +repository. To use this, working Docker/Podman and VSC installations are required. To use the Dev Container, click the "Open a Remote Window" button on the bottom left of the editor (``><`` icon) and select "Reopen in Container". This will build the container and open a new VSC window with the container as @@ -100,6 +100,6 @@ Using Vagrant and Libvirt ========================= Vagrant can be used to quickly spin up a test/development environment for Warewulf. -A ``Vagrantfile`` is provided in ``vagrant`` directory of the Warewulf repository. +A ``Vagrantfile`` is provided in the ``vagrant`` directory of the Warewulf repository. See the `README.md `_ for more details. \ No newline at end of file diff --git a/userdocs/getting-started/debian-quickstart.rst b/userdocs/getting-started/debian-quickstart.rst index 28c538d4..64f6aebe 100644 --- a/userdocs/getting-started/debian-quickstart.rst +++ b/userdocs/getting-started/debian-quickstart.rst @@ -14,7 +14,7 @@ Install the basic services .. note:: If you get an error message concerning *isc-dhcp-server.service* you - probably need to configure the network intarface that isc-dhcp-server + probably need to configure the network interface that isc-dhcp-server will listen to. Run ``sudo dpkg-reconfigure isc-dhcp-server`` and enter the name of your cluster's private network interface (e.g. enp2s0). After that, you might also need to run ``sudo systemctl enable isc-dhcp-server``. @@ -104,8 +104,8 @@ Configure system services automatically There are a number of services and configurations that Warewulf relies on to operate. If you wish to configure all services, you can do so -individually (omitting the ``--all``) will print a help and usage -instructions. +with the following command. Running ``wwctl configure`` individually +(omitting the ``--all``) will print help and usage instructions. .. code-block:: bash diff --git a/userdocs/getting-started/el-quickstart.rst b/userdocs/getting-started/el-quickstart.rst index 0ebbafbf..112c4e3a 100644 --- a/userdocs/getting-started/el-quickstart.rst +++ b/userdocs/getting-started/el-quickstart.rst @@ -9,7 +9,7 @@ Install Warewulf ================ The preferred way to install Warewulf on Enterprise Linux is using the -the RPMs published in `GitHub releases`_. For example, to install the +RPMs published in `GitHub releases`_. For example, to install the v4.6.5 release on Enterprise Linux 9: .. code-block:: bash @@ -153,7 +153,7 @@ configure --all``. If you just installed the system fresh and have SELinux enforcing, you may need to run ``restorecon -Rv /var/lib/tftpboot/`` to label - files written to q`tftpboot``. + files written to ``tftpboot``. Add a base node image ===================== diff --git a/userdocs/getting-started/glossary.rst b/userdocs/getting-started/glossary.rst index 3d693228..dca5d241 100644 --- a/userdocs/getting-started/glossary.rst +++ b/userdocs/getting-started/glossary.rst @@ -9,7 +9,7 @@ Cluster network External services The Warewulf server can configure external services to support the provisioning process. For example, the Warewulf server typically deploys and - configures a DHCP server (either ISC DHCP or dnsqmasq) and a TFTP server. + configures a DHCP server (either ISC DHCP or dnsmasq) and a TFTP server. Image The node images that Warewulf manages and provisions. Images may be imported diff --git a/userdocs/getting-started/introduction.rst b/userdocs/getting-started/introduction.rst index 4e82c558..8a1d5500 100644 --- a/userdocs/getting-started/introduction.rst +++ b/userdocs/getting-started/introduction.rst @@ -15,7 +15,7 @@ running on the same node image. As of Warewulf v4, the node image can be managed using industry-standard container tooling and/or CI/CD pipelines. This can be as simple as DockerHub or your own private GitLab CI infrastructure. With this architecture, Warewulf combines the best of High Performance Computing (HPC), -Cloud, Hyperscale, and Enterprise deployment principals to create and maintain +Cloud, Hyperscale, and Enterprise deployment principles to create and maintain large scalable stateless clusters. Warewulf is used most prominently in High Performance Computing (HPC) clusters, @@ -46,7 +46,7 @@ flexible provisioning system for all types of clusters. to Dell, Debian, SUSE, Rocky, CentOS, and RHEL, Warewulf can be used in most any environment. -* **Secure**: Warewulf support SELinux out-of-the-box. Just install SELinux in +* **Secure**: Warewulf supports SELinux out-of-the-box. Just install SELinux in your node image and let Warewulf do the rest! * **Open Source**: Warewulf is and has always been open source. It can be used diff --git a/userdocs/getting-started/network.rst b/userdocs/getting-started/network.rst index d824bc40..baf789eb 100644 --- a/userdocs/getting-started/network.rst +++ b/userdocs/getting-started/network.rst @@ -63,7 +63,7 @@ the management of ``dhcpd`` and ``tftp``. There are two ways to achieve this: The first method is relatively trivial. The second method is described below. -As first the first step, add the dummy node. +As the first step, add the dummy node. .. code-block:: shell @@ -87,8 +87,8 @@ Add the delivery networks to this node. --nettagadd network=10.0.30.0,dynstart=10.10.30.10,dynend=10.10.30.50 \ deliverynet -The ip address is used as the network address of host in the delivery network -and an additional tags is used for definition of the network itself and the +The IP address is used as the network address of the host in the delivery network +and an additional tag is used for the definition of the network itself and the dynamic dhcp range. You can check the result with ``wwctl node list``. .. code-block:: console diff --git a/userdocs/getting-started/provisioning.rst b/userdocs/getting-started/provisioning.rst index a0f5b7d4..cd48faba 100644 --- a/userdocs/getting-started/provisioning.rst +++ b/userdocs/getting-started/provisioning.rst @@ -10,7 +10,7 @@ version and configuration drift, eventually becoming a point of discrete administration and debugging. The larger the cluster, the harder this problem is to solve. -This is the problem that Warewulf was created solve. +This is the problem that Warewulf was created to solve. Provisioning Overview ===================== @@ -78,7 +78,7 @@ When a cluster node boots from Warewulf, the following process occurs: * In a single-stage provisioning configuration, the desired image and overlays are combined and provisioned immediately by the bootloader as the - kernel's initial root file system. This is straightfoward, but does not + kernel's initial root file system. This is straightforward, but does not work in all environments: some systems have memory layouts that are not handled properly by either iPXE or GRUB for sufficiently large image sizes, leading to strange, unpredictable results. diff --git a/userdocs/getting-started/suse-quickstart.rst b/userdocs/getting-started/suse-quickstart.rst index 7e95822c..0f5f9fca 100644 --- a/userdocs/getting-started/suse-quickstart.rst +++ b/userdocs/getting-started/suse-quickstart.rst @@ -42,7 +42,7 @@ Configure the controller ======================== Edit the file ``/etc/warewulf/warewulf.conf`` and ensure that you've -set the appropriate configuration paramaters. Here are some of the +set the appropriate configuration parameters. Here are some of the defaults for reference assuming that ``192.168.200.1`` is the IP address of your cluster's private network interface: @@ -97,8 +97,8 @@ Configure system services automatically There are a number of services and configurations that Warewulf relies on to operate. If you wish to configure all services, you can do so -individually (omitting the ``--all``) will print a help and usage -instructions. +with the following command. Running ``wwctl configure`` individually +(omitting the ``--all``) will print help and usage instructions. .. note:: diff --git a/userdocs/images/images.rst b/userdocs/images/images.rst index 90399439..aa223a69 100644 --- a/userdocs/images/images.rst +++ b/userdocs/images/images.rst @@ -82,7 +82,7 @@ You can import node images from an OCI registry, public or private. The Warewulf project maintains a set of `example node images `_ that are configured to boot when used with Warewulf. These images can be imported directly into - Warewulf or used as base images for local custom image. + Warewulf or used as base images for local custom images. A few environmental variables can be used to control communication with the OCI registry: @@ -118,7 +118,7 @@ See ProxyFromEnvironment_ for more information. The above is just an example. Consideration should be done before doing it this way if you are in a security sensitive environment or shared environments as -this command line wil show up in the process table. +this command line will show up in the process table. Local OCI Archive ----------------- @@ -313,7 +313,7 @@ Defining New Images It is absolutely possible to import a base image into Warewulf and make all changes interactively with ``wwctl image shell``; but it is often better to define new images with a container image definition file. This can be done using -the OCI and Singularity (Apptainer) ecoystems. +the OCI and Singularity (Apptainer) ecosystems. Podman ------ diff --git a/userdocs/images/syncuser.rst b/userdocs/images/syncuser.rst index 8ab9fa13..289d90ee 100644 --- a/userdocs/images/syncuser.rst +++ b/userdocs/images/syncuser.rst @@ -13,7 +13,7 @@ an LDAP server). Combined with the "syncuser" overlay, Warewulf syncuser also supports defining local users on the Warewulf server for synchronization to cluster nodes. -If there is mismatch between the server and the image, the import command will +If there is a mismatch between the server and the image, the import command will generate a warning. Syncuser may be invoked during image import, exec, shell, or build. diff --git a/userdocs/nodes/disks.rst b/userdocs/nodes/disks.rst index 85e29839..5e5a84f9 100644 --- a/userdocs/nodes/disks.rst +++ b/userdocs/nodes/disks.rst @@ -103,7 +103,7 @@ by the ``ignition`` overlay. Example disk configurations =========================== -This command formats a btrfs file system on a "scratch" partion of +This command formats a btrfs file system on a "scratch" partition of "vda" and mounts it at ``/scratch``. .. code-block:: shell @@ -139,7 +139,7 @@ file systems once, you may * wipe the existing data with tools like ``wipefs`` or ``dd`` [#]_; or * set the ``--fswipe`` flag and remove it after one reboot. -.. [#] With ``wipefs`` you have to remove the filesystem *and* parition +.. [#] With ``wipefs`` you have to remove the filesystem *and* partition information. E.g., use ``wipefs -fa /dev/vda*`` to remove all file system information and partition information. diff --git a/userdocs/nodes/nodes.rst b/userdocs/nodes/nodes.rst index 06d895ba..4bd139c0 100644 --- a/userdocs/nodes/nodes.rst +++ b/userdocs/nodes/nodes.rst @@ -8,8 +8,8 @@ supported; but it is often better to manage it using the ``wwctl`` command. .. note:: - The ``nodes.conf`` file is YAML document that can be edited directly or - managed with configuation management; but its internal structure is + The ``nodes.conf`` file is a YAML document that can be edited directly or + managed with configuration management; but its internal structure is technically undocumented and subject to change between versions. After Warewulf v4.6.0, the ``wwctl upgrade nodes`` command can be used to update a ``nodes.conf`` from a previous Warewulf v4 version. @@ -99,7 +99,7 @@ edit``. List values ----------- -Some node fields, such as overlays and kernel aruments, accept a list of values. +Some node fields, such as overlays and kernel arguments, accept a list of values. These may be specified as a comma-separated list or as multiple arguments. To include an explicit comma in the value, enclose the value in inner-quotes. diff --git a/userdocs/overlays/overlays.rst b/userdocs/overlays/overlays.rst index f2ab8c35..a95c0d1c 100644 --- a/userdocs/overlays/overlays.rst +++ b/userdocs/overlays/overlays.rst @@ -7,7 +7,7 @@ are collections of files and :ref:`templates` that are rendered and built per-node and then applied over the image during the provisioning process. -Overlays are the primary mechanism for adding functionality Warewulf. Much of +Overlays are the primary mechanism for adding functionality to Warewulf. Much of even core functionality in Warewulf is implemented as distribution overlays, and this flexibility is also available for local, custom overlays. By combining templates with tags, network tags, and resources, the node registry @@ -84,7 +84,7 @@ A node or profile can configure an overlay in two different ways: wwctl profile set default \ --system-overlays="wwinit,wwclient,fstab,hostname,ssh.host_keys,systemd.netname,NetworkManager" \ - --runime-overlays="hosts,ssh.authorized_keys" + --runtime-overlays="hosts,ssh.authorized_keys" Multiple overlays can be applied to a single node, and overlays from multiple profiles are appended together when applied to a single node. @@ -92,7 +92,7 @@ profiles are appended together when applied to a single node. Building Overlays ================= -Overlays are built (e.g., with ``wwctl overly build``) into compressed overlay +Overlays are built (e.g., with ``wwctl overlay build``) into compressed overlay images for distribution to cluster nodes. These images typically match these two use cases: system and runtime. As such, each cluster node typically has two overlay images. @@ -107,7 +107,7 @@ overlay images. Created image for n1 runtime overlay: /var/lib/warewulf/provision/overlays/n1/__RUNTIME__.img Compressed image for n1 runtime overlay: /var/lib/warewulf/provision/overlays/n1/__RUNTIME__.img.gz -Overlay images for multiple node are built in parallel. By default, each CPU in +Overlay images for multiple nodes are built in parallel. By default, each CPU in the Warewulf server will build overlays independently. The number of workers can be specified with the ``--workers`` option. @@ -342,7 +342,7 @@ resource. It also creates entries for file systems defined by Ignition. ssh --- -Two SSH overlays configure host keys (one set for all node in the cluster) and +Two SSH overlays configure host keys (one set for all nodes in the cluster) and ``authorized_keys`` for the root account. - ssh.authorized_keys @@ -585,7 +585,7 @@ Once configured, the NVIDIA MIG instances can be mapped to Slurm GRES entries backed by ``/dev/nvidia-caps/capXX`` device files. To generate the mapping of MIG instances to ``/dev/nvidia-caps/capXX`` device files -for Slurm's ``gres.conf`` file, use the script provided by this overlay on on the node: +for Slurm's ``gres.conf`` file, use the script provided by this overlay on the node: .. code-block:: shell @@ -603,7 +603,7 @@ run. (Subsequent use of the host overlay won't overwrite existing The following services get configuration files via the host overlay: -* ssh keys are created with the scrips ``ssh_setup.sh`` and +* ssh keys are created with the scripts ``ssh_setup.sh`` and ``ssh_setup.csh`` * hosts entries are created by manipulating ``/etc/hosts`` with the template ``hosts.ww`` diff --git a/userdocs/overlays/templates.rst b/userdocs/overlays/templates.rst index 71604dfd..b3a69d9d 100644 --- a/userdocs/overlays/templates.rst +++ b/userdocs/overlays/templates.rst @@ -215,7 +215,7 @@ nobackup UniqueField ----------- -Returns a filtered version of a multi-line input string. input is expected to be +Returns a filtered version of a multi-line input string. Input is expected to be a field-separated format with one record per line (terminated by ``\n``). Order of lines is preserved, with the first matching line taking precedence. diff --git a/userdocs/release/v4.6.0.rst b/userdocs/release/v4.6.0.rst index 25297856..a8df7aab 100644 --- a/userdocs/release/v4.6.0.rst +++ b/userdocs/release/v4.6.0.rst @@ -20,7 +20,7 @@ well, and the reorganization and deduplication supports better documentation maintenance in the future. The documentation also now includes complete and automatically-generated -references for all ``wwctl`` commands, sub-comands, and options. +references for all ``wwctl`` commands, sub-commands, and options. .. _user documentation: https://warewulf.org/docs/ @@ -92,7 +92,7 @@ Warewulf "containers" have never been "virtualized" or executed with a container runtime. Rather, the name "container" was selected to imply the integration in v4 with the container ecosystem of tooling for defining, building, storing, and testing node images. But this terminology ended up causing persistent confusion, -so a more industry-standard "node image" terminology has been adopted in stead. +so a more industry-standard "node image" terminology has been adopted instead. The ``wwctl container`` command is retained as an alias for the new ``wwctl image`` command. The variables ``.Container`` and ``.ContainerName`` are also @@ -228,7 +228,7 @@ Profiles ======== Node profiles now support profiles themselves, allowing for complex nested -hierarchies of nested profiles. +hierarchies of profiles. .. code-block:: yaml @@ -363,7 +363,7 @@ expressions and globs) are no longer supported. in YAML and JSON format, and ``wwctl node export`` has been updated to match, including indicating node IDs. -``wwctl`` now return a non-zero exit code on error. +``wwctl`` now returns a non-zero exit code on error. There are smaller changes to ``wwctl``, as well: diff --git a/userdocs/release/v4.6.1.rst b/userdocs/release/v4.6.1.rst index 32398191..5932a465 100644 --- a/userdocs/release/v4.6.1.rst +++ b/userdocs/release/v4.6.1.rst @@ -36,7 +36,7 @@ A couple new ``wwctl`` options have been added: - ``wwctl overlay import --overwrite`` overwrites existing overlay files during import. -- ``wwctl node import --yes`` skips the interactive confirmaton dialog and +- ``wwctl node import --yes`` skips the interactive confirmation dialog and assumes a "yes" answer. New tags diff --git a/userdocs/release/v4.6.2.rst b/userdocs/release/v4.6.2.rst index 1bb540e9..623dffc1 100644 --- a/userdocs/release/v4.6.2.rst +++ b/userdocs/release/v4.6.2.rst @@ -23,10 +23,10 @@ Disks may be provisioned using ``ignition``, as before; but may now also be provisioned using new ``sfdisk``, ``mkfs``, and ``mkswap`` overlays, and to mount configured file systems using ``systemd.mount`` and ``systemd.swap`` overlays. These overlays may also each be configured using overlay-specific -"resources", which may additional control compared to Warewulf's built-in disk, +"resources", which may provide additional control compared to Warewulf's built-in disk, partition, and file system configuration. -To support more complext partition layouts, ``wwctl set +To support more complex partition layouts, ``wwctl set --parttype`` has been added to specify non-default partition types. This is particularly useful when creating an EFI partition, which may be used in a future release to configure serverless local booting. diff --git a/userdocs/release/v4.6.3.rst b/userdocs/release/v4.6.3.rst index 07c4937c..09a45765 100644 --- a/userdocs/release/v4.6.3.rst +++ b/userdocs/release/v4.6.3.rst @@ -35,7 +35,7 @@ Overlay Autobuild The Warewulf server (when "autobuild overlays" is enabled) now automatically rebuilds overlays after node discovery, which resolves an issue where overlays were out-of-sync with the newly-discovered configuration. This is one step in a -more general effort to imrpove overlay autobuild so that manual overlay builds +more general effort to improve overlay autobuild so that manual overlay builds are less often required. Warewulf server configuration @@ -50,7 +50,7 @@ Ubuntu and Debian Support The ``netplan`` overlay is now much more feature-complete, with relative parity to the other network configuration overlays. This is one step in a more general -effort to support Wareewulf in Ubuntu and Debian environments. +effort to support Warewulf in Ubuntu and Debian environments. Other fixes =========== diff --git a/userdocs/release/v4.6.5.rst b/userdocs/release/v4.6.5.rst index 8479f777..8a3ca000 100644 --- a/userdocs/release/v4.6.5.rst +++ b/userdocs/release/v4.6.5.rst @@ -40,12 +40,12 @@ Other variables and the overlay itself can also be documented explicitly within .. code-block:: text {{/* wwdoc: Configures chronyd to synchronize time with a specific time server. */}} - {{/* .Tags.ntp_server: the NTP server to synchonize with */}} + {{/* .Tags.ntp_server: the NTP server to synchronize with */}} wwctl image import --update =========================== -The ``wwctl image import`` come has included an ``--update`` option since +The ``wwctl image import`` command has included an ``--update`` option since v4.6.0, but it has not been functional. The option now imports an image on-top-of an existing image and is meant to be used to update an existing image with new files from an updated upstream or external image (e.g., by importing a @@ -88,7 +88,7 @@ development environment with libvirt. warewulf-dracut =============== -A bug between ``warewulf-dracut`` and the ``ignition`` overlay previously caused +A bug between ``warewulf-dracut`` and the ``ignition`` overlay previously prevented non-root filesystems from mounting when provisioning the image to disk. A fix in ``warewulf-dracut`` prevents ignition from running twice, allowing all file systems to mount properly. The ``wwinit`` dracut module also no longer runs the diff --git a/userdocs/server/api.rst b/userdocs/server/api.rst index 4b9053b4..fdc618e9 100644 --- a/userdocs/server/api.rst +++ b/userdocs/server/api.rst @@ -27,7 +27,7 @@ and passwords able to authenticate to the API. - name: admin password hash: $2b$05$5QVWDpiWE7L4SDL9CYdi3O/l6HnbNOLoXgY2sa1bQQ7aSBKdSqvsC -Passwords are stored as bcrypt2 hashses, which can be generated with ``mkpasswd``. +Passwords are stored as bcrypt2 hashes, which can be generated with ``mkpasswd``. .. code-block:: console diff --git a/userdocs/server/bootloaders.rst b/userdocs/server/bootloaders.rst index bb7cf463..01f15c88 100644 --- a/userdocs/server/bootloaders.rst +++ b/userdocs/server/bootloaders.rst @@ -36,7 +36,7 @@ the Warewulf configuration process to configure the ``ipxe`` service. ipxe_cfg->kernel[ltail=cluster0,label="http"]; } -Starting in v4.5.0, Warewulf no longer includes an iPXE binary. In stead, by +Starting in v4.5.0, Warewulf no longer includes an iPXE binary. Instead, by default Warewulf uses the iPXE that comes with the host OS. Unfortunately, we’ve encountered a few instances where bugs in the OS-provided @@ -325,7 +325,7 @@ Two-stage boot: dracut ====================== Some systems, typically due to limitations in their BIOS or EFI firmware, are -unable to load image of a certain size directly with a traditional bootloader, +unable to load an image of a certain size directly with a traditional bootloader, either iPXE or GRUB. As a workaround for such systems, Warewulf can be configured to load a dracut initramfs from the image and to use that initramfs to load the full image. diff --git a/userdocs/server/configuration.rst b/userdocs/server/configuration.rst index 4e2a6029..9f66d3f6 100644 --- a/userdocs/server/configuration.rst +++ b/userdocs/server/configuration.rst @@ -4,7 +4,7 @@ Server Configuration By default, the Warewulf server configuration is located at ``/etc/warewulf/warewulf.conf``. This is a YAML-formatted configuration file -used by to configured the Warewulf server itself and its external services. +used to configure the Warewulf server itself and its external services. An initial ``warewulf.conf`` is packaged with Warewulf. Each section is covered in detail below. @@ -232,7 +232,7 @@ ssh *New in Warewulf v4.5.1* -SSH key types to generate during ``wwctl configure ssh``. This create the +SSH key types to generate during ``wwctl configure ssh``. This creates the appropriate host keys (stored in ``/etc/warewulf/keys/``) and authentication keys for passwordless ``ssh`` to cluster nodes. It also installs shell profiles ``/etc/profile.d/ssh_setup.csh`` and ``/etc/profile.d/ssh_setup.sh`` to @@ -248,7 +248,7 @@ Warewulf server. - rsa - dsa -* ``ssh:key types``: Warewulf generate host keys for each listed key type. +* ``ssh:key types``: Warewulf generates host keys for each listed key type. The first listed key type is used to generate authentication ssh keys. @@ -359,7 +359,7 @@ hostfile There are no explicit "hostfile" configuration options in ``warewulf.conf``; but ``wwctl configure hostfile`` updates the Warewulf server's ``/etc/hosts`` file to include expected configuration for the server itself as well as the known -names of the cluster nodes and thier interfaces. +names of the cluster nodes and their interfaces. Entries from the Warewulf server's ``/etc/hosts`` file are distributed to cluster nodes by the "hosts" overlay. diff --git a/userdocs/server/dnsmasq.rst b/userdocs/server/dnsmasq.rst index b182ee8d..01a98458 100644 --- a/userdocs/server/dnsmasq.rst +++ b/userdocs/server/dnsmasq.rst @@ -5,7 +5,7 @@ Using dnsmasq As an experimental feature, it is possible to use ``dnsmasq`` instead of the ISC ``dhcpd`` server and ``TFTP`` server. -In order to keep the file ``/etc/dnsmasq.d/ww4-hosts.conf`` is created and must +In order to keep the configuration manageable, the file ``/etc/dnsmasq.d/ww4-hosts.conf`` is created and must be included in the main ``dnsmasq.conf`` via the ``conf-dir=/etc/dnsmasq.d`` option. diff --git a/userdocs/server/installation.rst b/userdocs/server/installation.rst index d4bb4d37..ea4c36ef 100644 --- a/userdocs/server/installation.rst +++ b/userdocs/server/installation.rst @@ -32,7 +32,7 @@ Container images Warewulf can be built in a Linux container. This can be especially useful for testing and development, or to replace traditional package installation. It is -also possible to only use the container for building and the install it in the +also possible to only use the container for building and then install it in the host system afterwards. For that look at the INSTALL, UNINSTALL and PURGE labels inside the `Dockerfile`_ diff --git a/userdocs/server/wwctl.rst b/userdocs/server/wwctl.rst index 53f0cc10..904764ab 100644 --- a/userdocs/server/wwctl.rst +++ b/userdocs/server/wwctl.rst @@ -25,7 +25,7 @@ built-in help with either ``wwctl help`` or ``--help``. Hostlists ========= -Many of the commands (e.g., ``wwctl node list`` support a "hostlist" +Many of the commands (e.g., ``wwctl node list``) support a "hostlist" syntax for referring to multiple nodes at once. Hostlist expressions support both ranges and comma-separated numerical lists. diff --git a/userdocs/troubleshooting/known-issues.rst b/userdocs/troubleshooting/known-issues.rst index bdc13e5d..c0fa97c2 100644 --- a/userdocs/troubleshooting/known-issues.rst +++ b/userdocs/troubleshooting/known-issues.rst @@ -93,7 +93,7 @@ gigabytes. Workarounds exist for these issues in most circumstances: decompress the image rather than the kernel. * Some BIOS / firmware retain a "memory hole" feature for legacy devices, e.g., - reserving a 1MB block of memory at the 15MB-16MB address range. this feature + reserving a 1MB block of memory at the 15MB-16MB address range. This feature can interfere with booting stateless node images. If you are still getting "Not enough memory" or "No space left on device" diff --git a/userdocs/troubleshooting/troubleshooting.rst b/userdocs/troubleshooting/troubleshooting.rst index 5ffc5f6d..e2842dc4 100644 --- a/userdocs/troubleshooting/troubleshooting.rst +++ b/userdocs/troubleshooting/troubleshooting.rst @@ -66,10 +66,10 @@ cluster node's MAC address in place of 00:00:00:00:00:00.) - The ``kernel`` command fetches a kernel for later booting. - The ``imgextract`` command fetches and decompresses the images that will make - up the booted noe image. In a typical environment this is used to load a + up the booted node image. In a typical environment this is used to load a minimal "initial ramdisk" which, then, boots the rest of the system. Warewulf, by default, loads the entire image as an initial ramdisk, and also loads the - system and runtime overlays at this time time. + system and runtime overlays at this time. - The ``boot`` command tells iPXE to boot the system with the given kernel and ramdisks. @@ -127,7 +127,7 @@ the port number if you have changed it from the default of 9873.) a typical environment this is used to load a minimal "initial ramdisk" which, then, boots the rest of the system. Warewulf, by default, loads the entire image as an initial ramdisk, and also loads the system and runtime overlays at - this time time. + this time. - The ``boot`` command tells GRUB to boot the system with the previously-defined configuration.