kelvin/warewulf
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

feat(docs): New documentation

Browse Source 
Convert docs to mkdocs, move back into repo, publish to repo
This commit is contained in:
Brian Clemens
2022-09-15 21:00:17 +09:00
committed by GitHub
parent 8c0710e412
commit 04ee8cc967
34 changed files with 2482 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
.github/workflows/documentation.yml vendored Normal file
View File

@@ -0,0 +1,60 @@
---
name: publish_docs
on:
push:
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
submodules: recursive
- name: Update repositories
run: |
sudo apt update
- name: Install LaTeX dependencies
run: |
sudo apt-get install -f -y texlive-latex-extra latexmk
- name: Setup Python
uses: actions/setup-python@v1
- name: Install Sphinx
run: |
pip install --user --upgrade --upgrade-strategy eager sphinx sphinx-rtd-theme restructuredtext_lint pygments
- name: Build web documentation
run: |
cd userdocs
make html
- name: Install SSH key
env:
SSH_AUTH_SOCK: /tmp/ssh_agent.sock
run: |
mkdir -p ~/.ssh
ssh-keyscan github.com >> ~/.ssh/known_hosts
echo "${{ secrets.GH_DEPLOY_KEY }}" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
cat <<EOT >> ~/.ssh/config
Host github.com
HostName github.com
IdentityFile ~/.ssh/id_rsa
EOT
git config --global user.email "actions@github.com"
git config --global user.name "gh-actions"
- name: Update website repo
run: |
git clone git@github.com:hpcng/warewulf-web.git ~/warewulf-web
mkdir -p ~/warewulf-web/src/static/docs
rm -rf ~/warewulf-web/src/static/docs/${GITHUB_REF##*/}
cp -r userdocs/_build/html ~/warewulf-web/src/static/docs/${GITHUB_REF##*/}
cd ~/warewulf-web
git add src/static/docs/${GITHUB_REF##*/}
git commit -m "Update ${GITHUB_REF##*/} docs"
git push

1
.gitignore vendored
View File

@@ -33,3 +33,4 @@ Defaults.mk
/etc/wwapic.config
/etc/wwapird.config
.dist/
userdocs/_*

20
userdocs/Makefile Normal file
View File

@@ -0,0 +1,20 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line, and also
# from the environment for the first two.
SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
SOURCEDIR = .
BUILDDIR = _build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

48
userdocs/conf.py Normal file
View File

@@ -0,0 +1,48 @@
# Configuration file for the Sphinx documentation builder.
#
# For the full list of built-in configuration values, see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html
# -- Project information -----------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
project = 'Warewulf User Guide'
copyright = '2022, Warewulf Project Contributors'
author = 'Warewulf Project Contributors'
release = 'development'
# -- General configuration ---------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
extensions = []
templates_path = ['_templates']
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
# -- Options for HTML output -------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
html_theme = 'sphinx_rtd_theme'
html_static_path = ['_static']
html_theme_options = {
'sticky_navigation': True,
'includehidden': True,
'navigation_depth': 5,
'prev_next_buttons_location': 'bottom',
'style_external_links': True,
}
html_context = {
'display_github': True,
'github_user': 'hpcng',
'github_repo': 'warewulf',
'github_version': 'development',
'conf_py_path': '/userdocs/',
}
html_logo = 'logo.png'
html_favicon = 'favicon.png'
html_show_copyright = False

18
userdocs/contents/background.rst Normal file
View File

@@ -0,0 +1,18 @@
==========
Background
==========
Warewulf is based on the design of the original Beowulf Cluster design (and thus the name, soft\ **WARE** implementation of the beo\ **WULF**)
The `Beowulf Cluster <https://en.wikipedia.org/wiki/Beowulf_cluster>`_ design was developed in 1996 by Dr. Thomas Sterling and Dr. Donald Becker at NASA. The architecture is defined as a group of similar compute worker nodes all connected together using standard commodity equipment on a private network segment. The control node (historically referred to as the "master" or "head" node) is dual homed (has two network interface cards) with one of these network interface cards attached to the upstream public network and the other connected to a private network which connects to all of the compute worker nodes (as seen in the figure below).
.. image:: beowulf_architecture.png
:alt: Beowulf architecture
This simple topology is the foundation for creating every scalable HPC cluster resource. Even today, almost 30 years after the inception of this architecture, this is the baseline architecture that traditional HPC systems are built to.
Other considerations for a working HPC-type cluster are storage, scheduling and resource management, monitoring, interactive systems, etc. For smaller systems, much of these requirements can be managed all from a single control node, but as the system scales, it may need to have groups of nodes dedicated to these different services.
Warewulf is easily capable of building simple and turnkey HPC clusters, to giant massive complex multi-purpose computing clusters, through next generation computing platforms.
Anytime a cluster of systems is needed, Warewulf is your tool!

BIN
userdocs/contents/beowulf_architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

136
userdocs/contents/configuration.rst Normal file
View File

@@ -0,0 +1,136 @@
======================
Warewulf Configuration
======================
The default installation of Warewulf will put all of the configuration
files into ``/etc/warewulf/``. In that directory, you will find the
primary configuration files needed by Warewulf.
warewulf.conf
=============
The Warewulf configuration exists as follows in the current version of
Warewulf (4.3.0):
.. code-block:: yaml
WW_INTERNAL: 43
ipaddr: 192.168.200.1
netmask: 255.255.255.0
network: 192.168.200.0
warewulf:
port: 9873
secure: false
update interval: 60
autobuild overlays: true
host overlay: true
syslog: false
dhcp:
enabled: true
range start: 192.168.200.50
range end: 192.168.200.99
systemd name: dhcpd
tftp:
enabled: true
systemd name: tftp
nfs:
enabled: true
export paths:
- path: /home
export options: rw,sync
mount options: defaults
mount: true
- path: /opt
export options: ro,sync,no_root_squash
mount options: defaults
mount: false
systemd name: nfs-server
Generally you can leave this file as is, as long as you set the
appropriate networking information. Specifically the following
configurations:
* ``ipaddr``: This is the control node's networking interface connecting
to the cluster's **PRIVATE** network. This configuration must match
the host's network IP address for the cluster's private interface.
* ``netmask``: Similar to the ``ipaddr``, this is the subnet mask for the
cluster's **PRIVATE** network and it must also match the host's
subnet mask for the cluster's private interface.
* ``dhcp:range start`` and ``dhcp:range end``: This address range must
exist in the network defined above. If it is outside of this
network, failures will occur. This specifies the range of addresses
you want DHCP to use.
.. note::
The network configuration listed above assumes the network
layout in the [Background](background.md) portion of the
documentation.
The other configuration options are usually not touched, but they are
explained as follows:
* ``*:enabled``: This disables Warewulf's control of an external
service. This is useful if you want to manage that service directly.
* ``*:systemd name``: This is so Warewulf can control some of the host's
services. For the distributions that we've built and tested this on,
these will require no changes.
* ``warewulf:port``: This is the port that the Warewulf web server will
be listening on. It is recommended not to change this so there is no
misalignment with node's expectations of how to contact the Warewulf
service.
* ``warewulf:secure``: When ``true``, this limits the Warewulf server to
only respond to runtime overlay requests originating from a
privileged report port. This makes it so that only the ``root`` user
on a compute node can request the runtime overlay. While generally
there is nothing super "secure" in these overlays, this adds the
necessary protection that the user's can not obtain this
information.
* ``warewulf:update interval``: This defines the frequency (in seconds)
with which the Warewulf client on the compute node fetches overlay
updates.
* ``warewulf:autobuild overlays``: This determines whether per-node
overlays will automatically be rebuilt, e.g., when an underlying
overlay is changed.
* ``warewulf:host overlay``: This determines whether the special ``host``
overlay is applied to the Warewulf server during configuration. (The
host overlay is used to configure the dependent services.)
* ``warewulf:syslog``: This determines whether Warewulf server logs go
to syslog or are written directly to a log file. (e.g.,
``/var/log/warewulfd.log``)
* ``nfs:export paths``: Warewulf will automatically set up the NFS
exports if you wish for it to do this.
nodes.conf
==========
The ``nodes.conf`` is the primary database file for all compute
nodes. It is a flat text YAML configuration file that is managed by
the ``wwctl`` command, but some sites manage the compute nodes and
infrastructure via configuration management. This file being flat text
and very light weight makes management of the node configurations very
easy no matter what your configuration paradigm is.
For the purpose of this document, we will not go into the detailed
format of this file as it is recommended to edit with the ``wwctl``
command.
.. note::
This configuration is not written at install time, but the
first time you attempt to run ``wwctl``, this file will be generated
if it does not exist already.
Directories
===========
The ``/etc/warewulf/ipxe/`` contains *text/templates* that are used by
the Warewulf configuration process to configure the ``ipxe`` service.

155
userdocs/contents/containers.rst Normal file
View File

@@ -0,0 +1,155 @@
====================
Container Management
====================
Since the inception of Warewulf over 20 years ago, Warewulf has used the model of the "Virtual Node File System" (VNFS) as a template image for the compute nodes. This is similar to a golden master image, except that the node file system exists within a directory on the Warewulf control node (e.g. a `chroot()`).
In hindsight, we've been using containers all along, but the buzzword just didn't exist. Over the last 5-6 years, the enterprise has created a lot of tooling and standards around defining, building, distributing, securing, and managing containers, so Warewulf (as of v4.0) now integrates directly within the container ecosystem to facilitate the process of VNFS image management.
If you are not currently leveraging the container ecosystem in any other way, you can still build your own chroot directories and use Warewulf as you always have.
It is important to understand that Warewulf is not running a container runtime on the nodes. While that is absolutely possible to run containers from the booted hosts, Warewulf is provisioning the container image to the bare metal and booting it. This container will be used as the base operating system and by default it will run stateless in memory. This means when you reboot the node, the node persists no information about Warewulf or how it booted.
Container Tools
===============
There are different container managment tools available. Docker is probably the most recognizable one in the enterprise. Podman is another one that is gaining traction on the RHEL platforms. In HPC, Singularity is the most utilized container management tool. You can use any of these to create and manage the containers to be later imported into Warewulf.
Importing From A Registry
=========================
Warewulf supports importing an image from any OCI compliant registry. This means you can import from a public registry or from a private registry.
Here is an example of importing from Docker Hub.
.. code-block:: bash
$ sudo wwctl container import docker://warewulf/rocky rocky-8
Getting image source signatures
Copying blob d7f16ed6f451 done
Copying config da2ca70704 done
Writing manifest to image destination
Storing signatures
[LOG] info unpack layer: sha256:d7f16ed6f45129c7f4adb3773412def4ba2bf9902de42e86e77379a65d90a984
Updating the container's /etc/resolv.conf
Building container: rocky-8
.. note::
Most containers in Docker Hub are not "bootable", in that, they have a limited version of Systemd to make them lighter weight for container purposes. For this reason, don't expect any base Docker container (e.g. ``docker://rockylinux`` or ``docker://debian``) to boot properly. They will not, as they will get stuck into a single user mode. The containers in `https://hub.docker.com/u/warewulf <https://hub.docker.com/u/warewulf>`_ are not limited and thus they boot as you would expect.
Private Registry
----------------
It is possible to use a private registry that is password protected or does not have the requirement for TLS. In order to do so, you have two choices for handling the credentials.
* Set environmental variables
* Use ``docker login`` or ``podman login`` which will store the credentials locally
Please note, there is no requirement to install and use docker or podman on your control node just for importing images into Warewulf.
Here are the environmental variables that can be used.
.. code-block:: bash
WAREWULF_OCI_USERNAME
WAREWULF_OCI_PASSWORD
WAREWULF_OCI_NOHTTPS
Here is an example:
.. code-block:: bash
export WAREWULF_OCI_USERNAME=privateuser
export WAREWULF_OCI_PASSWORD=super-secret-password-or-token
sudo -E wwctl import docker://ghcr.io/privatereg/rocky:8
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. You would not want these showing up in bash history or logs.
Listing All Imported Containers
===============================
Once the container has been imported, you can list them all with the following command:
.. code-block:: bash
$ sudo wwctl container list
CONTAINER NAME BUILT NODES
rocky-8 true 0
Once a container has been imported and showing up in this list you can configure it to boot compute nodes.
Making Changes To Containers
============================
Warewulf has a minimal container runtime built into it. This means you can run commands inside of any of the containers and make changes to them as follows:
.. code-block:: bash
$ sudo wwctl container exec rocky-8 /bin/sh
[rocky-8] Warewulf> cat /etc/rocky-release
Rocky Linux release 8.4 (Green Obsidian)
[rocky-8] Warewulf> exit
Rebuilding container...
[INFO] Skipping (VNFS is current)
You can also ``--bind`` directories from your host into the container when using the exec command. This works as follows:
.. code-block:: bash
$ sudo wwctl container exec --bind /tmp:/mnt rocky-8 /bin/sh
[rocky-8] Warewulf>
.. note::
As with any mount command, both the source and the target must exist. This is why the example uses the ``/mnt/`` directory location, as it is almost always present and empty in every Linux distribution (as prescribed by the LSB file hierarchy standard).
When the command completes, if anything within the container changed, the container will be rebuilt into a bootable static object automatically.
Creating Containers From Scratch
================================
You can also create containers from scratch and import those containers into Warewulf as previous versions of Warewulf did.
Building A Container From Your Host
-----------------------------------
RPM based distributions, as well as Debian variants can all bootstrap mini ``chroot()`` directories which can then be used to bootstrap your node's container.
For example, on an RPM based Linux distribution with YUM or DNF, you can do something like the following:
.. code-block:: bash
$ sudo yum install --installroot /tmp/newroot basesystem bash \
chkconfig coreutils e2fsprogs ethtool filesystem findutils \
gawk grep initscripts iproute iputils net-tools nfs-utils pam \
psmisc rsync sed setup shadow-utils rsyslog tzdata util-linux \
words zlib tar less gzip which util-linux openssh-clients \
openssh-server dhclient pciutils vim-minimal shadow-utils \
strace cronie crontabs cpio wget rocky-release ipmitool yum \
NetworkManager
You can do something similar with Debian-based distributions:
.. code-block:: bash
sudo apt-get install debootstrap
sudo debootstrap stable /tmp/newroot http://ftp.us.debian.org/debian
Once you have created and modified your new ``chroot()``, you can import it into Warewulf with the following command:
.. code-block:: bash
sudo wwctl container import /tmp/newroot containername
Building A Container Using Singularity
--------------------------------------
Singularity, a container platform for HPC and performance intensive applications, can also be used to create node containers for Warewulf. There are several Singularity container recipes in the ``containers/Singularity/`` directory and can be found on GitHub at `https://github.com/hpcng/warewulf/tree/main/containers/Singularity <https://github.com/hpcng/warewulf/tree/main/containers/Singularity>`_.
You can use these as starting points and adding any additional steps you want in the ``%post`` section of the recipe file. Once you've done that, installing Singularity, building a container sandbox and importing into Warewulf can be done with the following steps:
.. code-block:: bash
sudo yum install epel-release
sudo yum install singularity
sudo singularity build --sandbox /tmp/newroot /path/to/Singularity/recipe.def
sudo wwctl container import /tmp/newroot containername

45
userdocs/contents/initialization.rst Normal file
View File

@@ -0,0 +1,45 @@
=======================
Warewulf Initialization
=======================
System Services
===============
Once Warewulf has been installed and configured, it is ready to be initialized and have the associated system services started. To do this, start by configuring the system services that Warewulf depends on for operation. To do that, run the following command:
.. code-block:: bash
sudo wwctl configure --all
This command will configure the system for Warewulf to run properly. Here are the things it will do:
* **dhcp**: (re)Write the DHCP configuration and restart the service from the configured template in ``/etc/warewulf/dhcp/`` and enable the system service.
* **hostfile**: Update the system's /etc/hosts file based on the template ``/etc/warewulf/hosts.tmpl``.
* **nfs**: Configure the NFS server on the control node as well as the ``/etc/fstab`` in the system overlay based on the configuration in ``/etc/warewulf/warewulf.conf`` and enable the system service.
* **ssh**: Create the appropriate host keys (stored in ``/etc/warewulf/keys/``) and user keys for passwordless ``ssh`` into the nodes.
* **tftp**: Write the appropriate binary PXE/iPXE blobs to the TFTP root directory and enable the system service.
This command will quickly setup the system services per the Warewulf configuration. Watch this output carefully for errors and resolve them in the configuration portion of this manual.
Warewulf Service
================
The Warewulf installation attempts to register the Warewulf service with Systemd, so it should be as easy to start/stop/check as any other Systemd service:
.. code-block:: bash
sudo systemctl enable --now warewulfd
You can also check and control the Warewulf service using the `wwctl` command line program as follows:
.. code-block:: bash
sudo wwctl server status
.. note::
If the Warewulf service is running via Systemd, restarting stopping, and starting it from the ``wwctl`` command may result in unexpected results.
Logs
----
The Warewulf server logs are by default written to ``/var/log/warewulfd.log``.

79
userdocs/contents/installation.rst Normal file
View File

@@ -0,0 +1,79 @@
#####################
Warewulf Installation
#####################
There are multiple methods to install Warewulf, this page describes the installation process of multiple methods:
Binary RPMs
===========
While the Warewulf project does not build binary RPMs, you can obtain them from `CIQ <https://www.ctrliq.com/>`_ and use them for non-production use from their public YUM and DNF repositories at: `https://repo.ctrliq.com <https://repo.ctrliq.com/>`_
This is the easiest method to install Warewulf and can be done as follows:
.. code-block:: bash
sudo yum install -y https://repo.ctrliq.com/rhel/8/ciq-release.rpm
sudo yum install -y warewulf
> note: as mentioned, these binaries are part of CIQ's commercial support offering but they can be used for non-production and testing uses. If you are interested in using these binaries for production, please contact CIQ at: `info@ctrliq.com <mailto:info@ctrliq.com>`_.
Compiled Source code
====================
Before you build the Warewulf source code you will first need to install the build dependencies:
* ``make``: This should be available via your Linux distribution's package manager (e.g. ``dnf install make``)
* ``go``: Golang is also available on most current Linux distributions, but if you wish to install the most recent version, you can find that here: `https://golang.org/dl/ <https://golang.org/dl/>`_
* Depending on your Linux Distribution, you may need to install other development packages. Typically it is recommended to install the entire development group like ``dnf groupinstall "Development Tools"``
Once these dependencies are installed, you can obtain and build the source code as follows:
Release Tarball
---------------
When the Warewulf project releases stable versions, they are available via source form here:
`https://github.com/hpcng/warewulf/tags <https://github.com/hpcng/warewulf/tags/>`_
Select the version you wish to install and download the tarball to any location on the server, then follow these directions making the appropriate substitutions:
.. code-block:: bash
# EDIT HERE
VERSION=4.2.0
DOWNLOAD=/tmp/warewulf-${4.2.0}.tar.gz
# COPY/PASTE THIS
mkdir ~/src
cd ~/src
tar xvf ${DOWNLOAD}
cd warewulf-${VERSION}
make all && sudo make install
Git
---
Warewulf is developed in "Git", a source code management platform that allows collaborative development and revision control. From the Git repository, you can download different versions of the project either from tags or branches. By default, when you go to the GitHub page, you will find the default branch entitled ``main``. The ``main`` branch is where most of the active development occurs, so if you want to obtain the latest and greatest version of Warewulf, this is where to go. But be forewarned, using a snapshot from ``main`` is not guaranteed to be stable or generally supported for production. If you are building for production, it is best to download a release tarball from the main site, the GitHub releases page, or from a Git tag.
.. code-block:: bash
mkdir ~/git
cd ~/git
git clone https://github.com/hpcng/warewulf.git
cd warewulf
git checkout main # or switch to a tag like '4.2.0'
make all && sudo make install
Runtime Dependencies
--------------------
In Warewulf's default configuration, it will require some operating system provided services. Generally these are provided by your installation vendor and can be installed over the network.
These are the services you will need to install:
* ``dhcp-server``
* ``tftp-server``
* ``nfs-utils``
If you are using an Enterprise Linux compatible distribution you can install them with: ``yum install dhcp-server tftp-server nfs-utils``

36
userdocs/contents/introduction.rst Normal file
View File

@@ -0,0 +1,36 @@
============
Introduction
============
The Warewulf Vision
===================
Warewulf has had a number of iterations over the last 20 years, but its design tenets have always remained the same: a simple, scalable, stateless (however some versions were able to provision stateful), and very flexible operating system provisioning system for all types of clusters. This is an overview of how Warewulf works.
About Warewulf
==============
Warewulf is an operating system provisioning platform for Linux that is designed to produce secure, scalable, turnkey cluster deployments that maintain flexibility and simplicity.
Since its initial release in 2001, Warewulf has become the most popular open source and vendor-agnostic provisioning system within the global HPC community. Warewulf is known for its massive scalability and simple management of stateless (disk optional) provisioning.
Warewulf leverages a simple administrative model centralizing administration around virtual node images which are used to provision out to the cluster nodes. This means you can have hundreds or thousands of cluster nodes all booting and running on the same, identical virtual node file system image. As of Warewulf v4, the virtual node image is a standard container image which means all compute resources within a cluster can be managed using any existing container tooling and/or CI pipelines that are being used. 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 large scalable stateless clusters.
While Warewulf's roots are in HPC, it has been used for many different types of tasks and use cases. Everything from clustered web servers, to rendering farms, and even Kubernetes and cloud deployments, Warewulf brings benefit in experience of general operating system management at scale.
Features
========
* **Lightweight**: Warewulf provisions stateless operating system images and then gets out of the way. There should be no underlying system dependencies or changes to the provisioned cluster node operating systems.
* **Simple**: Warewulf is used by hobbyists, researchers, scientists, engineers and systems administrators because it is easy, lightweight, and simple.
* **Flexible**: Warewulf is highly flexible and can address the needs of any environment-- from a computer lab with graphical workstations, to under-the-desk clusters, to massive supercomputing centers providing traditional HPC capabilities to thousands of users.
* **Agnostic**: From the Linux distribution of choice to the underlying hardware, Warewulf is agnostic and standards compliant. From ARM to x86, Atos to Dell, Debian, SuSE, Rocky, CentOS, and RHEL, Warewulf can do it all.
* **Secure**: Warewulf is the only stateless provisioning system that will support SELinux out of the box. Just enable your node operating system container to support SELinux, and Warewulf do the rest!
* **Open Source**: For the last 20 years, Warewulf has remained open source and continues to be the golden standard for cluster provisioning.

145
userdocs/contents/ipmi.rst Normal file
View File

@@ -0,0 +1,145 @@
====
IPMI
====
It is possible to control the power or connect a console to your nodes being managed by Warewulf by connecting to the BMC through the use of IPMI. We will discuss how to set this up below.
IPMI Settings
=============
The common settings for the IPMI interfaces on all nodes can be set on a Profile level. The only field that would need to be assigned to each individual node would be the IP address.
If an individual node has different settings, you can set the IPMI settings for that specific node, overriding the default settings.
Here is a table outlining the fields on a Profile and Node level, along with the parameters that can be used when running ``wwctl profile set`` or ``wwctl node set``.
============= =============== ======== ======= ================== =============
Field Parameter Profile Node Valid Values Default Value
============= =============== ======== ======= ================== =============
IpmiIpaddr --ipmi X
IpmiNetmask --ipminetmask X X
IpmiPort --ipmiport X X 623
IpmiGateway --ipmigateway X X
IpmiUserName --ipmiuser X X
IpmiPassword --ipmipass X X
IpmiInterface --ipmiinterface X X 'lan' or 'lanplus' lan
============= =============== ======== ======= ================== =============
Reviewing Settings
==================
There are multiple ways to review the IPMI settings. They can be reviewed from a Profile level, all the way down to a specific Node.
Profile View
------------
.. code-block:: bash
$ sudo wwctl profile list -a
################################################################################
PROFILE NAME FIELD VALUE
default Id default
default Comment This profile is automatically included for each node
default Cluster --
default Container rocky
default Kernel 4.18.0-348.2.1.el8_5.x86_64
default KernelArgs --
default Init --
default Root --
default RuntimeOverlay --
default SystemOverlay --
default Ipxe --
default IpmiNetmask 255.255.255.0
default IpmiPort --
default IpmiGateway 192.168.99.1
default IpmiUserName admin
default IpmiInterface lanplus
default eth0:IPADDR --
default eth0:NETMASK 255.255.240.0
default eth0:GATEWAY 10.1.96.6
default eth0:HWADDR --
default eth0:TYPE --
default eth0:DEFAULT false
Node View
---------
.. code-block:: bash
$ sudo wwctl node list node0001 -a
################################################################################
NODE FIELD PROFILE VALUE
node0001 Id -- node0001
node0001 Comment default This profile is automatically included for each node
node0001 Cluster -- --
node0001 Profiles -- default
node0001 Discoverable -- false
node0001 Container default rocky
node0001 Kernel default 4.18.0-348.2.1.el8_5.x86_64
node0001 KernelArgs -- (quiet crashkernel=no vga=791 rootfstype=rootfs)
node0001 RuntimeOverlay -- (default)
node0001 SystemOverlay -- (default)
node0001 Ipxe -- (default)
node0001 Init -- (/sbin/init)
node0001 Root -- (initramfs)
node0001 IpmiIpaddr -- 192.168.99.10
node0001 IpmiNetmask -- 255.255.255.0
node0001 IpmiPort -- --
node0001 IpmiGateway -- 192.168.99.1
node0001 IpmiUserName default admin
node0001 IpmiInterface default lanplus
node0001 eth0:HWADDR -- 52:54:00:1a:08:60
node0001 eth0:IPADDR -- 192.168.100.152
node0001 eth0:NETMASK default 255.255.255.0
node0001 eth0:GATEWAY default 192.168.100.1
node0001 eth0:TYPE -- --
node0001 eth0:DEFAULT -- false
Review Only IPMI Settings
-------------------------
The above views show you everything that is set on a Profile or Node level. That is a lot of detail. If you want to view key IPMI connecton details for a node or all nodes, you can do the following.
.. code-block:: bash
$ sudo wwctl node list -i
NODE NAME IPMI IPADDR IPMI PORT IPMI USERNAME IPMI PASSWORD IPMI INTERFACE
============================================================================================================
node0001 192.168.99.10 -- admin supersecret lanplus
node0002 192.168.99.11 -- admin supersecret lanplus
node0003 192.168.99.12 -- admin supersecret lanplus
Power Commands
==============
The ``power`` command can be used to manage the current power state of your nodes through IPMI.
``wwctl power [command]`` where ``[command]`` is one of:
cycle
Turns the power off and then on
off
Turns the power off
on
Turns the power on
reset
Issues a reset
soft
Shutdown gracefully
status
Shows current power status
Console
=======
If your node is setup to use serial over lan (SOL), Warewulf can connect a console to the node.
``sudo wwctl node console node0001``

53
userdocs/contents/kernel.rst Normal file
View File

@@ -0,0 +1,53 @@
=================
Kernel Management
=================
Node Kernels
============
Warewulf nodes require a Linux kernel to boot. There are multiple ways to do this, but the default, and easiest way is to install the kernel you wish to use for a particular container, into the container.
Warewulf will locate the kernel automatically within the container and by default use that kernel for any node configured to use that container image.
You can see what kernel is included in a container by using the ``wwctl container list`` command:
.. code-block:: bash
$ sudo wwctl container list
CONTAINER NAME NODES KERNEL VERSION
alpine 0
rocky 0 4.18.0-348.12.2.el8_5.x86_64
rocky_updated 1 4.18.0-348.23.1.el8_5.x86_64
Here you will notice the alpine contianer that was imported has no kernel within it, and each of the rocky containers include a kernel.
This model was introduced in Warewulf 4.3.0. Previously, Warewulf managed the kernel and the container separately, which made it hard to build and distribute containers that have custom drivers and/or configurations included (e.g. OFED, GPUs, etc.).
Kernel Overrides
================
It is still possible to specify a kernel to a container if it doesn't include it's own kernel, or if you wish to override the default kernel by using the ``kernel override`` capability.
You can specify this option either within the ``nodes.conf`` directly or via the command line with the ``--kerneloverride`` option to ``wwctl node set`` or ``wwctl profile set`` commands.
In this case you will also need to import a kernel specifically into Warewulf for this purpose using the ``wwctl kernel import`` command as follows:
.. code-block:: bash
$ sudo wwctl kernel import $(uname -r)
4.18.0-305.3.1.el8_4.x86_64: Done
This process will import not only the kernel image itself, but also all of the kernel modules and firmware associated to this kernel.
Listing All Imported Kernels
----------------------------
Once the kernel has been imported, you can list them all with the following command:
.. code-block:: bash
$ sudo wwctl kernel list
VNFS NAME NODES
4.18.0-305.3.1.el8_4.x86_64 0
Once a kernel has been imported and showing up in this list you can configure it to boot compute nodes.

202
userdocs/contents/nodeconfig.rst Normal file
View File

@@ -0,0 +1,202 @@
==================
Node Configuration
==================
The Node Configuration DB
=========================
As mentioned in the [Configuration](configuration) section, node
configs are persisted to the ``nodes.conf`` YAML file, but generally it
is best not to edit this file directly (however that is supported, it
is just prone to errors).
This method of using a YAML configuration file as a backend datastore
is both scalable and very lightweight. We've tested this out to over
10,000 node entries which yielded update latencies under 1 second,
which we felt was both tolerable and advantageous.
Adding a New Node
=================
Creating a new node is as simple as running the following command:
.. code-block:: bash
$ sudo wwctl node add n0000
Added node: n0000
Node Names
----------
For small clusters, you can use simple names (e.g. ``n0000``); but for
larger, more complicated clusters that are comprised of multiple
clusters and roles it is highly recommended to use node names that
include a cluster descriptor. In Warewulf, this is generally done by
using a domain name (e.g. ``n0000.cluster01``). Warewulf will
automatically assume that the domain is the equivalent of the cluster
name.
This also means that you can address groups of nodes by the cluster
descriptor with globs. For example, you are able to refer to all nodes
in "cluster01" with the following string: ``*.cluster01`` which is
valuable for other ``wwctl`` commands.
Listing Nodes
=============
Once you have configured one or more nodes, you can list them and
their attributes as follows:
.. code-block:: bash
$ sudo wwctl node list
NODE NAME PROFILES NETWORK
================================================================================
n0000 default
You can also see the node's full attribute list by specifying the ``-a``
option (all):
.. code-block:: bash
$ sudo wwctl node list -a
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment default This profile is automatically included for each node
n0000 Cluster -- --
n0000 Profiles -- default
n0000 Discoverable -- false
n0000 Container -- --
n0000 KernelOverride -- --
n0000 KernelArgs -- (quiet crashkernel=no vga=791 rootfstype=rootfs)
n0000 RuntimeOverlay -- (default)
n0000 SystemOverlay -- (default)
n0000 Ipxe -- (default)
n0000 Init -- (/sbin/init)
n0000 Root -- (initramfs)
n0000 IpmiIpaddr -- --
n0000 IpmiNetmask -- --
n0000 IpmiPort -- --
n0000 IpmiGateway -- --
n0000 IpmiUserName -- --
n0000 IpmiInterface -- --
n0000 IpmiWrite -- --
.. note::
The attribute values in parenthesis are default values and can
be overridden in the next section, granted, the default values are
generally usable.
Setting Node Attributes
=======================
In the above output we can see that there is no kernel or container
defined for this node. To provision a node, the minimum requirements
are a kernel and container, and for that node to be useful, we will
also need to configure the network so the nodes are reachable after
they boot.
Node configurations are set using the ``wwctl node set`` command. To see
a list of all configuration attributes, use the command ``wwctl node
set --help``.
Configuring the Node's Container Image
======================================
.. code-block:: bash
$ sudo wwctl node set --container rocky-8 n0000
Are you sure you want to modify 1 nodes(s): y
And you can check that the container name is set for ``n0000``:
.. code-block:: bash
$ sudo wwctl node list -a n0000 | grep Container
n0000 Container -- rocky-8
Configuring the Node's Kernel
-----------------------------
While the recommended method for assigning a kernel in 4.3 and beyond
is to include it in the container / node image, a kernel can still be
specified as an override at the node or profile.
.. code-block:: bash
$ sudo wwctl node set --kerneloverride $(uname -r) n0000
Are you sure you want to modify 1 nodes(s): y
$ sudo wwctl node list -a n0000 | grep KernelOverride
n0000 KernelOverride -- 4.18.0-305.3.1.el8_4.x86_64
Configuring the Node's Network
------------------------------
To configure the network, we have to pick a network device name and
provide the network information as follows:
.. code-block:: bash
$ sudo wwctl node set --netdev eth0 --hwaddr 11:22:33:44:55:66 --ipaddr 10.0.2.1 --netmask 255.255.252.0 n0000
Are you sure you want to modify 1 nodes(s): y
You can now see that the node contains configuration attributes for
container, kernel, and network:
.. code-block:: bash
$ sudo wwctl node list -a n0000
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment default This profile is automatically included for each node
n0000 Cluster -- --
n0000 Profiles -- default
n0000 Discoverable -- false
n0000 Container -- rocky-8
n0000 Kernel -- 4.18.0-305.3.1.el8_4.x86_64
n0000 KernelArgs -- (quiet crashkernel=no vga=791 rootfstype=rootfs)
n0000 RuntimeOverlay -- (default)
n0000 SystemOverlay -- (default)
n0000 Ipxe -- (default)
n0000 Init -- (/sbin/init)
n0000 Root -- (initramfs)
n0000 IpmiIpaddr -- --
n0000 IpmiNetmask -- --
n0000 IpmiPort -- --
n0000 IpmiGateway -- --
n0000 IpmiUserName -- --
n0000 IpmiInterface -- --
n0000 default:DEVICE -- eth0
n0000 default:HWADDR -- 11:22:33:44:55:66
n0000 default:IPADDR -- 10.0.2.1
n0000 default:NETMASK -- 255.255.252.0
n0000 default:GATEWAY -- --
n0000 default:TYPE -- --
n0000 default:DEFAULT -- false
Un-setting Node Attributes
==========================
If you wish to ``unset`` a particular value, set the value to
``UNDEF``. For example:
.. code-block:: bash
$ sudo wwctl node set --cluster cluster01 n0000
Are you sure you want to modify 1 nodes(s): y
$ sudo wwctl node list -a n0000 | grep Cluster
n0000 Cluster -- cluster01
And to unset this configuration attribute:
.. code-block:: bash
$ sudo wwctl node set --cluster UNDEF n0000
Are you sure you want to modify 1 nodes(s): y
$ sudo wwctl node list -a n0000 | grep Cluster
n0000 Cluster -- --

141
userdocs/contents/overlays.rst Normal file
View File

@@ -0,0 +1,141 @@
=================
Warewulf Overlays
=================
So at this point, we have discussed how Warewulf is designed to scalably provision and manage thousands of cluster nodes by utilizing identical stateless boot images. And there-in lies a problem to solve. If these boot images are completely identical, then how do we configure things like hostnames? IP addresses? Or any other node specific custom configurations?
While some of this can be managed by services like DHCP, and other bits by configuration management, which can absolutely be done with Warewulf and many people choose to do, these are heavy-weight solutions to a simple problem to solve.
Warewulf solves this with overlays and uses overlays in different ways through the provisioning process. Two of these overlays are exposed to the users, the **system overlay** and the **runtime overlay**.
.. note::
Another overlay that isn't directly exposed is the **kmods overlay** which contains all of the kernel modules to match the configured kernel. Because this overlay is used "behind the scenes" it is outside the scope of this document.
System Overlay
==============
The System Overlay is used by the core of Warewulf to setup the environment on the node necessary for provisioning. The default system overlay is called ``wwinit``. Generally speaking, it will not be necessary to make changes to this overlay, but it is possible to change or configure this overlay to meet site specific needs if necessary.
Runtime Overlay
===============
The Runtime Overlay is the overlay that is responsible for most of the typical system administration configurations. Here you will make changes necessary to support your operating system as well as application configurations.
Once the system is provisioned and booted, the ``wwclient`` program (which is provisioned as part of the ``wwinit`` system overlay) will continuously update the node with updates in the runtime overlay.
Templates
=========
Templates allow you to create dynamic content such that the files downloaded for each node will be customized for that node. Templates allow you to insert everything from variables, to including files from the control node, as well as conditional content and loops.
Warewulf uses the ``text/template`` engine to facilitate implementing dynamic content in a simple and standardized manner.
All template files will end with the suffix of ``.ww``. That tells Warewulf that when building a file, that it should parse that file as a template. When it does that, the resulting file is static and can have node customizations that are obtained from the node configuration attributes.
.. note::
When the file is persisted within the built overlay, the ``.ww`` will be dropped, so ``/etc/hosts.ww`` will end up being ``/etc/hosts``.
Using Overlays
==============
Warewulf includes a command group for manipulating overlays (``wwctl overlay``). With this you can add, edit, remove, change ownership, permissions, etc.
The general syntax is as follows:
.. code-block:: bash
wwctl overlay [action] [overlay name] ...
* **action**: the overlay subcommand you are invoking
* **overlay name**: the name of the overlay in question within a given type
* **...**: additional arguments are action specific
By default there is one overlay in each of the system and runtime overlay types. Both overlays are called "default". To say it differently, there are two default overlays, one is a system overlay and one is a runtime overlay.
Viewing the Files Within an Overlay
===================================
Overlays can be viewed with the command ``wwctl overlay list``. You can see the files within an overlay by adding the ``-a`` or ``-l`` options as follows:
.. code-block:: bash
$ sudo wwctl overlay list -l generic
PERM MODE UID GID OVERLAY FILE PATH
-rwxr-xr-x 0 0 generic /etc/
-rw-r--r-- 0 0 generic /etc/group.ww
-rw-r--r-- 0 0 generic /etc/hosts.ww
-rw-r--r-- 0 0 generic /etc/passwd.ww
-rwxr-xr-x 0 0 generic /root/
-rwxr-xr-x 0 0 generic /root/.ssh/
-rw-r--r-- 0 0 generic /root/.ssh/authorized_keys.ww
Creating a New File Within an Overlay
=====================================
Just like any file on the system, you can create and edit a file at the same time. So to do that, you simple ``edit`` a new file as follows:
.. code-block:: bash
$ sudo wwctl overlay edit [overlay name] [file path]
For example:
.. code-block:: bash
$ sudo wwctl overlay edit generic /etc/testfile
and you can validate that the file is there with the ``list`` command:
.. code-block:: bash
$ sudo wwctl overlay list generic -l
PERM MODE UID GID RUNTIME-OVERLAY FILE PATH
-rwxr-xr-x 0 0 generic /etc/
-rw-r--r-- 0 0 generic /etc/group.ww
-rw-r--r-- 0 0 generic /etc/hosts.ww
-rw-r--r-- 0 0 generic /etc/passwd.ww
-rwxr-xr-x 0 0 generic /etc/testfile
-rwxr-xr-x 0 0 generic /root/
-rwxr-xr-x 0 0 generic /root/.ssh/
-rw-r--r-- 0 0 generic /root/.ssh/authorized_keys.ww
.. note::
To create a template file, simply name the file with the suffix ``.ww``. This suffix will tell Warewulf that the file should be parsed by the templating engine and written into the overlay with the suffix stripped off.
Building Overlays
=================
By default Warewulf will build/update and cache overlays as needed (configurable in the ``warewulf.conf``).
You can however build overlays by hand, and in some cases this will be advantageous (like if you are freshly booting thousands of compute nodes in parallel). The command to do that is:
.. code-block:: bash
# wwctl overlay build n00[00-10]
Building overlays for n0000: [wwinit, generic]
Building overlays for n0001: [wwinit, generic]
Building overlays for n0002: [wwinit, generic]
Building overlays for n0003: [wwinit, generic]
Building overlays for n0004: [wwinit, generic]
Building overlays for n0005: [wwinit, generic]
Building overlays for n0006: [wwinit, generic]
Building overlays for n0007: [wwinit, generic]
Building overlays for n0008: [wwinit, generic]
Building overlays for n0009: [wwinit, generic]
Building overlays for n0010: [wwinit, generic]
Other Overlay Actions
=====================
Warewulf includes a number of overlay action commands to interact with the overlays in a programmatic and controlled manner. All of the commands use very similar usage structure and work as the above examples do. A summary of all of the overlay actions are as follows:
* **build**: (Re)build an overlay
* **chmod**: Change file permissions within an overlay
* **chown**: Change file ownership within an overlay
* **create**: Initialize a new Overlay
* **delete**: Delete Warewulf Overlay or files
* **edit**: Edit/Create a file within a Warewulf Overlay
* **import**: Import a file into a Warewulf Overlay
* **list**: List Warewulf Overlays and files
* **mkdir**: Create a new directory within an Overlay
* **show**: Show (cat) a file within a Warewulf Overlay

162
userdocs/contents/profiles.rst Normal file
View File

@@ -0,0 +1,162 @@
#############
Node Profiles
#############
Profiles provide a way to scalably group node configurations together. Instead of redundant configurations for each node, you can put that into a profile and the nodes will inherit these configurations. This is very handy if you have groups of node specific customizations. For example, a few hundred nodes that are running a particular container or kernel, and another group of nodes that are running a different kernel or container.
Any node configuration attributes can be applied to a profile, but there are always going to be some node configurations which must be specific to a node, like a network HW/MAC address or an IP address.
An Introduction To Profiles
==============================
Every new node is automatically added to a profile called ``default``. You can view the configuration attributes of this profile by using the ``wwctl profile list`` command. Like the ``wwctl node list`` command, this will provide a summary, but you can see **all** configuration attributes by using the ``--all`` or ``-a`` flag as follows:
.. code-block:: bash
$ sudo wwctl profile list
PROFILE NAME COMMENT/DESCRIPTION
================================================================================
default This profile is automatically included for each node
And with the ``-a`` flag:
.. code-block:: bash
$ sudo wwctl profile list -a
################################################################################
PROFILE NAME FIELD VALUE
default Id default
default Comment This profile is automatically included for each node
default Cluster --
default Container --
default Kernel --
default KernelArgs --
default Init --
default Root --
default RuntimeOverlay --
default SystemOverlay --
default Ipxe --
default IpmiIpaddr --
default IpmiNetmask --
default IpmiPort --
default IpmiGateway --
default IpmiUserName --
default IpmiInterface --
As you can see here, there is only one attribute set by default in this profile, and that is the "Comment" field. That Comment is inherited by any nodes that are configured to use this profile. So if we look at the node we configured in the last section, we can see that configuration attribute there:
.. code-block:: bash
$ sudo wwctl node list -a | head -n 5
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment default This profile is automatically included for each node
n0000 Cluster -- --
Here you can see that the "Comment" attribute was inherited by this node, and it also provides you with the information of which profile this attribute was inherited from. This is very useful information as nodes can be part of multiple profiles with inheritance being cascading.
Multiple Profiles
=================
For demonstration purposes, let's create another profile and demonstrate how to use this second profile.
.. code-block:: bash
$ sudo wwctl profile add test_profile
$ sudo wwctl profile list
PROFILE NAME COMMENT/DESCRIPTION
================================================================================
default This profile is automatically included for each node
test_profile --
Now that we've created a new profile, let's create a configuration attribute in this profile:
.. code-block:: bash
$ sudo wwctl profile set --cluster cluster01 test_profile
? Are you sure you want to modify 1 profile(s)? [y/N] y█
$ sudo wwctl profile list -a test_profile | grep Cluster
test_profile Cluster cluster01
Lastly we just need to configure this profile to our node(s):
.. code-block:: bash
$ sudo wwctl node set --addprofile test_profile n0000
Are you sure you want to modify 1 nodes(s): y
And you can now verify that the node has both profile configurations:
.. code-block:: bash
$ sudo wwctl node list -a | head -n 6
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment default This profile is automatically included for each node
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
Cascading Profiles
==================
In the previous example, we set a single node to have two profile configurations. We can also overwrite configurations as follows:
.. code-block:: bash
$ sudo wwctl profile set --comment "test comment" test_profile
Are you sure you want to modify 1 profile(s): y
$ sudo wwctl node list -a | head -n 6
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment test_profile test comment
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
And if we delete the superseded profile attribute from ``test_profile`` we can now see the previous configuration:
.. code-block:: bash
$ sudo wwctl profile set --comment UNDEF test_profile
Are you sure you want to modify 1 profile(s): y
$ sudo wwctl node list -a | head -n 6
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment default This profile is automatically included for each node
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
This is a very useful feature for dealing with many groups of cluster nodes and/or testing new configurations on smaller subsets of cluster nodes. For example, you can use this method to run a different kernel on only a subset or group of cluster nodes without changing any other node attributes.
Overriding Profiles
===================
All profile configurations can be overwritten by a node configuration as can be seen here:
.. code-block:: bash
$ sudo wwctl node set --comment "This value takes precedent" n0000
Are you sure you want to modify 1 nodes(s): y
$ sudo wwctl node list -a | head -n 6
################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment SUPERSEDED This value takes precedent
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
How To Use Profiles Effectively
===============================
There are a lot of ways to use profiles to facilitate the management of large cluster node attributes, but there is nothing inherent in the design of Warewulf that requires use of them for anything. It is completely reasonable to not use profiles at all to help with node configuration attributes.
But if you do wish to use profiles, the best way to use them is to manage "fixed" configurations of groups of cluster nodes. For example, if you have multiple sub-clusters in your cluster, it might be advantageous to have a ``cluster_name`` profile which includes things like network configurations, and/or a specific kernel, container, boot arguments, etc.
Node specific information, like HW/MAC addresses and IP addresses should always be put in a node configuration rather than a profile configuration.

43
userdocs/contents/provisioning.rst Normal file
View File

@@ -0,0 +1,43 @@
=================
Node Provisioning
=================
Once the nodes are configured in Warewulf, they are ready to boot.
Node Hardware Setup
===================
The only thing that Warewulf requires to provision is that the node is set to PXE boot. You may need to change the boot order if there is a local disk present and bootable. This is a configuration change you will have to make in the BIOS of the cluster node.
Each vendor does this differently and as a result we won't go into the setup specifics here and if you can not find information on how to PXE boot your nodes, please contact your hardware vendor support.
.. note::
If you find that you are going to use Warewulf, or any other cluster provisioning tool, it is very helpful to require that hardware vendors preconfigure your cluster nodes with values of your choosing, and ask them to provide a text file that includes all of the HW/MAC addresses of the compute nodes in the order they are racked (which most creditable vendors will do). You can also ask them to certify their computing stack for the operating system you wish to use and the provisioning system. This helps hardware vendors to ensure their stack works with open source projects like Warewulf, Debian, OpenSuSE, and Rocky Linux.
The Provisioning Process
========================
When the cluster node boots, the following order of operations will occur:
#. BIOS:
#. The system BIOS will bootstrap the initialization of the hardware
#. The network card will register its option ROM into the BIOS
#. The BIOS will run through all of its functions and finish with boot devices
#. The boot devices are attempted in order
#. When it gets to the network boot device, PXE is run from the firmware on the network card
#. PXE:
#. PXE will request a BOOTP/DHCP address on the network
#. The Warewulf controller's DHCP server will respond with a network configuration and filename to try and boot
#. PXE will attempt to download the filename referred to in the DHCP response via TFTP
#. The downloaded file will execute an iPXE stack which will reach out to the Warewulf server for it's configuration
#. Bootstrap:
#. The Warewulf server will generate the iPXE configuration which will include directions of what else is necessary to download and how to boot.
#. The kernel, container image, kernel modules, and system overlay are all downloaded over REST HTTP from the Warewulf Server
#. iPXE executes the kernel and processes the overlays to provide a unified root file system
#. Warewulf bootstraps the initialization of cluster node's operating system
#. File System (re)configuration
#. SELinux
#. ``wwclient`` is called as a background daemon and sleeps until network is ready
#. The Warewulf bootstrap execs the container's ``/sbin/init``
#. Container:
#. The container now boots exactly as any operating system would expect

36
userdocs/contents/security.rst Normal file
View File

@@ -0,0 +1,36 @@
========
Security
========
Historically, most HPC clusters utilize a security model that is "hard on the exterior and soft and gushy on the interior". It is not that a user has free roam once logged in, but rather we tend to rely on just simple POSIX security models on the inside. For example, one of the common practices is to completely disable SELinux on a new cluster setup. Just kill it because it gets in the way.
For that reason, most critical HPC clusters leverage VPNs and/or bastion hosts with multi-factor authentication (MFA) to help secure it on the outside. But even with MFA and secure ssh connections through a bastion host, it is still possible for malicious users to gain access to these systems. Security being like layers of an onion is accurate, but on an HPC system, those layers are predominately on the outside of the cluster, not the inside.
Warewulf was written and designed from the ground up to go a bit further. And while certain parallelization and high performance library capabilities still require lowering the security threshold, Warewulf strives to not be a blocker here.
SELinux
=======
The Warewulf server itself was developed with SELinux enabled in "targeted" and "enforcing" mode and with the firewall active.
Additionally, the provisioning process fully supports SELinux by default. In previous versions you had to enable a switch to support SELinux, but in Warewulf v4 and above, it is always enabled, but you do have to make some configuration changes.
#. The first thing to do is to change the provision "Root" option. By default this is ``initramfs`` which means, take whatever file system the kernel hands us. By default this is a ``ramfs`` type file system (however this may not always be the case) and this format does not support extended file attributes which are required for SELinux. Instead you must configure Warewulf to use ``tmpfs`` for the provisioning file system. That change is made like: ``$ sudo wwctl profile set --root tmpfs default``.
#. That is all you have to do to ensure that Warewulf will probably support SELinux. Once that is done, you just need to enable SELinux in ``/etc/sysconfig/selinux`` and install the appropriate profiles into the container.
Provisioning Security
=====================
Provisioning in generally is known to be rather "insecure" because when a user lands on a compute node, there is generally nothing stopping them from spoofing a provision request and downloading the provisioned raw materials for inspection.
In Warewulf there are two ways to secure the provisioning process:
#. The provisioning connections and transfers are not secure due to not being able to manage a secure root of trust through a PXE process. The best way to secure the provisioning process is to enact a vLAN used specifically for provisioning. Warewulf supports this but you must consult your switch documentation and features to implement a default vLAN for provisioning and ensure that the runtime operating system is configured for a different tagged vLAN once booted.
#. Warewulf will leverage hardware "asset tags" which almost all vendors support. It is a configurable string that is configured in firmware and accessible only via root or physical access. During provisioning (as well as post provisioning via ``wwclient``) Warewulf, can use the asset tag as a secure token. If you have setup your hardware with an asset tag, you simply need to tell Warewulf what that asset tag is. When the asset tag is defined in Warewulf (``wwctl node set --assetkey "..."``), it will only provision and communicate with requests from that system matching that asset tag.
Summary
=======
Warewulf does not limit the security posture of a cluster at all, and perhaps it increases it as not all provisioners work with firewalls and SELinux enabled and enforcing. But even with that, cluster security is always up to the system manager and organizational policies. Our job is just to ensure that we don't limit those policies in any way.

38
userdocs/contents/setup.rst Normal file
View File

@@ -0,0 +1,38 @@
====================
Control Server Setup
====================
Operating System Installation
=============================
Warewulf has almost no predetermined or required configurations aside from a base architecture networking layout. Install your Linux distribution of choice as you would like, but do pay attention to the cluster's private network configuration.
Network
=======
A clustered resource depends on a private management network. This network can be either persistent (it is always "up" even after provisioning) to temporary which might only be used for provisioning and/or out of band system control and management e.g. IPMI).
It is important for this management network to be private to the compute resource because Warewulf requires network services on that network which may conflict with services on the production/public network (e.g. DHCP). It is also important from a security perspective as the management network for typical HPC systems have an implied trust level associated with it and generally there is no firewalling or network monitoring occurring on these networks.
Usually, the control node is "dual homed" which means it has at least two interface cards, one connected to the private cluster network and one dedicated to the public network (as the figure above demonstrates).
> note: It is possible to omit the public network interface with a reverse NAT. Warewulf can operate in this configuration but it extends beyond the scope of this documentation.
Many clusters have more then one private network. This is common for performance critical HPC clusters that implement a high speed and low latency network like InfiniBand. In this case, this network is used for high speed data transfers for inter-process communication between compute nodes and file system IO.
Warewulf will need to be configured to use the private cluster management network. Warewulf will use this network for booting the nodes over PXE. There are three network protocols used to accomplish this DHCP/BOOT, TFTP, and HTTP on port ``9873``. Warewulf will use the operating system's provided version of DHCP (ISC-DHCP) and TFTP for the PXE bootstrap to iPXE, and then iPXE will use Warewulf's internal HTTP services to transfer the larger files for provisioning.
Addressing
==========
The addressing scheme of your private cluster network is 100% up to the system integrator, but for large clusters, many organizations like to organize the address allocations. Below is a recommended IP addressing scheme which we will use for the rest of this document.
* ``10.0.0.1``: Private network address IP
* ``255.255.252.0``: Private network subnet mask
Here is an example of how the cluster's address can be divided for a 255 node cluster:
* ``10.0.0.1 - 10.0.0.255``: Cluster infrastructure including this host, schedulers, file systems, routers, switches, etc.
* ``10.0.1.1 - 10.0.1.255``: DHCP range for booting nodes
* ``10.0.2.1 - 10.0.2.255``: Static node addresses
* ``10.0.3.1 - 10.0.3.255``: IPMI and/or out of band addresses for the compute nodes

40
userdocs/contents/stateless.rst Normal file
View File

@@ -0,0 +1,40 @@
======================
Stateless Provisioning
======================
Why is Provisioning Important
=============================
Clusters are pools of servers bundled together to do a particular job or set of jobs. While there are a number of different use cases for clustering today, Warewulf was originally designed out of necessity.
Back in 2000, when Linux clustering was growing up for HPC, the issues of scale became apparent. Of course in HPC, there are many scalability factors which needed to be overcome as we continued to scale up clusters. Pretty early on was the "administrative scaling" which is the factor that full time systems administrators could only maintain so many servers. While homogenous configurations were able to help that, we still had the problem that every installed server became a point of administration, version creep, and debugging. The larger the cluster, the harder this problem was to solve.
Warewulf was created to help with exactly this.
Provisioning Overview
=====================
Provisioning in this definition is the process of putting an operating system onto a system. There are many ways to provision operating system images, from copying hard drives, to scripted installs, to automated installs. There are many valuable tools to facilitate this and they all helped to solve this problem.
In a cluster environment, this means one could group all of the nodes together, to be installed in bulk. Previous to cluster provisioning system administrators would go around to each cluster node, and install it from scratch, with an ISO or USB thumb drive. This obviously is not scalable. But being able to automatically install hundreds or thousands of computers in parallel and automate the management of these systems completely changed the paradigm.
There were several cluster provision and management toolkits already available when Warewulf was created and while these tools absolutely helped, there was even more optimization to be had. Stateless computing.
Stateless Provisioning
======================
The next step past automated installs is to just skip the installation completely; boot directly into the runtime operating system without ever doing an installation.
This is Warewulf.
Stateless provisioning is realizing you never have to install another compute node. Think of it like booting a LiveOS or LiveISO on nodes over the network. This means that no node individually is a point of system administration, but rather the entire cluster, inclusively is administrated as a single unit.
If all cluster nodes are booting the same OS image (or set of OS images), then any individual nodes that have problems is hardware. Debugging software and doing system administration in single points within a cluster is not needed. There is no version drift, because it is not possible for nodes to fall out of sync. Every reboot makes it exactly the same as its neighbors.
Warewulf provisions the operating system by default to system memory. There is no need for hard drives with Warewulf.
Previous versions of Warewulf had the ability to write the operating system to hard disk as well as do hybrid provisioning (the core operating system in memory, other pieces overlaid over NFS) but these have been obsoleted in Warewulf v4 as there are easier ways to accomplish the same thing (e.g. use of swap space).
> note: If you wish to provision to the hard drive, we might add that feature back based on user requests but in the mean time, you may wish to look at an automated or scripted installation platform instead of a cluster provisioning system.
In our experience, the Warewulf provisioning model is by far the most advantageous, simplest, and most flexible and scalable cluster provisioning platform available.

49
userdocs/contents/templating.rst Normal file
View File

@@ -0,0 +1,49 @@
==========
Templating
==========
Warewulf uses the ``text/template`` engine to convert dynamic content into static content and auto-populate files with the appropriate data on demand.
In Warewulf, you can find templates both for the provisioning services (e.g. ``/etc/warewulf/ipxe/``, ``/etc/warewulf/dhcp/``, and ``/etc/warewulf/hosts.tmpl``) as well as within the runtime and system overlays.
(more documentation coming soon)
Examples
========
range
-----
iterate over elements of an array
.. code-block:: go
{{ range $devname, $netdev := .NetDevs }}
# netdev = {{ $netdev.Hwaddr }}
{{ end }}
increment variable in loop
^^^^^^^^^^^^^^^^^^^^^^^^^^
iterate over elements of an array and increment ``i`` each loop cycle
.. code-block:: go
{{ $i := 0 }}
{{ range $devname, $netdev := .NetDevs }}
# netdev{{$i}} = {{ $netdev.Hwaddr }}
{{ $i = inc $i }}
{{ end }}
decrement
^^^^^^^^^
iterate over elements of an array and decrement ``i`` each loop cycle
.. code-block:: go
{{ $i := 10 }}
{{ range $devname, $netdev := .NetDevs }}
# netdev{{$i}} = {{ $netdev.Hwaddr }}
{{ $i = dec $i }}
{{ end }}

110
userdocs/contributing/contributing.rst Normal file
View File

@@ -0,0 +1,110 @@
============
Contributing
============
Warewulf is an open source project, meaning we have the challenge of limited resources. We are grateful for any support that you can offer. Helping other users, raising issues, helping write documentation, or contributing code are all ways to help!
Join the community
==================
This is a huge endeavor, and your help would be greatly appreciated! Post to online communities about Warewulf, and request that your distribution vendor, service provider, and system administrators include Warewulf for you!
Warewulf on Slack
-----------------
Many of our users come to Slack for quick help with an issue. You can find us at `HPCng <https://join.slack.com/t/hpcng/shared_invite/zt-k9atb2dj-rnlPjSh5Os3Ks6vlDEOyAA>`_.
Raise an Issue
==============
For general bugs/issues, you can open an issue `at the GitHub repo <https://github.com/hpcng/warewulf/issues/new>`_. However, if you find a security related issue/problem, please email HPCng directly at `security@hpcng.org <mailto:security@hpcng.org>`_. More information about the HPCng security policies and procedures can be found `here <https://hpcng.org/security-policy>`_.
Contribute to the code
======================
We use the traditional `GitHub Flow <https://guides.github.com/introduction/flow>`_ to develop. This means that you fork the main repo, create a new branch to make changes, and submit a pull request (PR) to the master branch.
Check out our official `CONTRIBUTING.md <https://github.com/hpcng/warewulf/blob/master/CONTRIBUTING.md>`_ document, which also includes a `code of conduct <https://github.com/hpcng/warewulf/blob/master/CONTRIBUTING.md#code-of-conduct>`_.
Step 1. Fork the repo
---------------------
To contribute to Warewulf, you should obtain a GitHub account and fork the `Warewulf <https://github.com/hpcng/warewulf>`_ repository. Once forked, clone your fork of the repo to your computer. (Obviously, you should replace ``your-username`` with your GitHub username.)
.. code-block:: bash
git clone https://github.com/your-username/warewulf.git
cd warewulf
Step 2. Checkout a new branch
-----------------------------
`Branches <https://guides.github.com/introduction/flow>`_` are a way of
isolating your features from the main branch. Given that we’ve just cloned the
repo, we will probably want to make a new branch from master in which to work on
our new feature. Lets call that branch ``new-feature``:
.. code-block:: bash
git checkout master
git checkout -b new-feature
.. note::
You can always check which branch you are in by running ``git branch``.
Step 3. Make your changes
-------------------------
On your new branch, go nuts! Make changes, test them, and when you are happy commit the changes to the branch:
.. code-block:: bash
git add file-changed1 file-changed2...
git commit -m "what changed?"
This commit message is important - it should describe exactly the changes that you have made. Good commit messages read like so:
.. code-block:: bash
git commit -m "changed function getConfig in functions.go to output csv to fix #2"
git commit -m "updated docs about shell to close #10"
The tags ``close #10`` and ``fix #2`` are referencing issues that are posted on the upstream repo where you will direct your pull request. When your PR is merged into the master branch, these messages will automatically close the issues, and further, they will link your commits directly to the issues they intend to fix. This will help future maintainers understand your contribution, or (hopefully not) revert the code back to a previous version if necessary.
Step 4. Push your branch to your fork
-------------------------------------
When you are done with your commits, you should push your branch to your fork (and you can also continuously push commits here as you work):
.. code-block:: bash
git push origin new-feature
Note that you should always check the status of your branches to see what has been pushed (or not):
.. code-block:: bash
git status
Step 5. Submit a Pull Request
-----------------------------
Once you have pushed your branch, then you can go to your fork (in the web GUI on GitHub) and `submit a Pull Request <https://help.github.com/articles/creating-a-pull-request>`_. Regardless of the name of your branch, your PR should be submitted to the ``main`` branch. Submitting your PR will open a conversation thread for the maintainers of Warewulf to discuss your contribution. At this time, the continuous integration that is linked with the code base will also be executed. If there is an issue, or if the maintainers suggest changes, you can continue to push commits to your branch and they will update the Pull Request.
Step 6. Keep your branch in sync
--------------------------------
Cloning the repo will create an exact copy of the Warewulf repository at that moment. As you work, your branch may become out of date as others merge changesinto the upstream master. In the event that you need to update a branch, you will need to follow the next steps:
.. code-block:: bash
# add a new remote named "upstream"
git remote add upstream https://github.com/hpcng/warewulf.git
# or another branch to be updated
git checkout master
git pull upstream master
# to update your fork
git push origin master
git checkout new-feature
git merge master

128
userdocs/contributing/development-environment-kvm.rst Normal file
View File

@@ -0,0 +1,128 @@
=============================
Development Environment (KVM)
=============================
Create CentOS 7 development virtual machine under KVM
=====================================================
.. code-block:: bash
# KVM is running on server called master1 which is not my desktop
ssh -X master1
# On master1 server
wget -P /global/downloads/centos http://mirror.mobap.edu/centos/7.8.2003/isos/x86_64/CentOS-7-x86_64-Everything-2003.iso
qemu-img create -o preallocation=metadata -f qcow2 /global/images/centos-7.qcow2 32G
# install wwdev Centos 7 development VM
sudo virt-install --virt-type kvm --name centos7-wwdev --ram 8192 \
--disk /global/images/centos-7.qcow2,format=qcow2 \
--network network=default \
--graphics vnc,listen=0.0.0.0 --noautoconsole \
--os-type=linux --os-variant=rhel7.0 \
--location=/global/downloads/centos/CentOS-7-x86_64-Everything-2003.iso
# Complete installation using virt-manager
# To start virt-manager on non-local server
ssh -X master1
sudo -E virt-manager
# Login to VM and install @development group and go language
ssh root@wwdev
# Disable selinux by modifying /etc/sysconfig/selinux
vi /etc/sysconfig/selinux
SELINUX=disabled
# disable firewall
systemctl stop firewalld
systemctl disable firewalld
Turn off default network dhcp on server master1
===============================================
.. code-block:: bash
# shutdown all VMs
sudo virsh net-destroy default
sudo virsh net-edit default
# remove dhcp lines from XML
sudo virsh net-start default
Build and install warewulf on wwdev
===================================
.. code-block:: bash
ssh wwdev
# Fedora prerequisites
sudo dnf -y install tftp-server tftp
sudo dnf -y install dhcp
sudo dnf -y install ipmitool
sudo dnf install singularity
sudo dnf install gpgme-devel
sudo dnf install libassuan.x86_64 libassuan-devel.x86_64
sudo dnf golang
sudo dnf nfs-utils
# Centos prerequisites
sudo yum -y install tftp-server tftp
sudo yum -y install dhcp
sudo yum -y install ipmitool
sudo yum install http://repo.ctrliq.com/packages/rhel7/ctrl-release.rpm
sudo yum install singularityplus
sudo yum install gpgme-devel
sudo yum install libassuan.x86_64 libassuan-devel.x86_64
sudo yum install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
sudo yum install golang
sudo yum install nfs-utils
# Install Warewulf and dependencies
git clone https://github.com/hpcng/warewulf.git
cd warewulf
make all
sudo make install
# Configure the controller
Edit the file /etc/warewulf/warewulf.conf and ensure that you've ser the approprite configuration parameters
# Configure system service automatically
sudo wwctl configure dhcp # Create the default dhcpd.conf file and start/enable service
sudo wwctl configure tftp # Install the base tftp/PXE boot files and start/enable service
sudo wwctl configure nfs # Configure the exports and create an fstab in the default system overlay
sudo wwctl configure ssh # Build the basic ssh keys to be included by the default system overlay
# Pull and build the VNFS container and kernel
sudo wwctl container import docker://warewulf/centos-8 centos-8 --setdefault
sudo wwctl kernel import build $(uname -r) --setdefault
# Set up the default node profile
sudo wwctl profile set default -K $(uname -r) -C centos-7
sudo wwctl profile set default --netdev eth0 -M WW_server_subnet_mask -G WW_server_ip
sudo wwctl profile list
# Add a node and build node specific overlays
sudo wwctl node add n0000.cluster --netdev eth0 -I n0000_ip --discoverable
sudo wwctl node list -a n0000
# Review Warewulf overlays
sudo wwctl overlay list -l
sudo wwctl overlay list -ls
sudo wwctl overlay edit default /etc/hello_world.ww
sudo wwctl overlay build -a
# Start the Warewulf daemon
sudo wwctl ready
sudo wwctl server start
sudo wwctl server status
Boot your node and watch the bash and the output of the Warewulfd process

147
userdocs/contributing/development-environment-vbox.rst Normal file
View File

@@ -0,0 +1,147 @@
====================================
Development Environment (VirtualBox)
====================================
I have VirtualBox running on my desktop.
1. Create a NAT Network (a private vlan) to be used for the Warewlf Server and compute nodes inside the VirtualBox. Make sure to turnoff DHCP service within this NAT Network.
.. code-block:: console
# On the host with VirtualBox execute below. In my example using 10.0.8.0/24 as the private vlan for my experiment with Warewulf
VBoxManage natnetwork add --netname wwnatnetwork --network "10.0.8.0/24" --enable --dhcp off
2. Create a Centos 7 development Virtual machine (wwdev) to be used as the Warewulf Server. Enable two Network adapters one with a standard NAT and SSH port mapping such that you can access this VM from the host machine. Assign the second network adapter to the NAT Network created in step #1. Assign sufficient memory (e.g: 4GB) to the VM.
.. code-block:: console
# Download a Centos7 or SL7 ISO and mount it to the optical drive to boot and install OS for the wwdev VM.
# Attach Network adapter #1 of the wwdev VM to the standard NAT via VM Settings -> Network option.
# By default VirtualBox puts the Network Adapter into 10.0.2.0/24 network and assigns 10.0.2.15 IP address.
# Also add a rule to the port forwarding table under the standard NAT configuration to allow SSH
# from localhost (127.0.0.1) some high port e.g 2222 to the guest IP 10.0.2.15 port 22 such that
# you can SSH from your host/desktop to the wwdev VM.
# Next attach the second Network adapter #2 to the NAT Network and you should be able to choose
# the 'wwnatnetwork' created above in step #1 from the drop down list.
3. Build and install warewulf on wwdev
.. code-block:: console
# Login to wwdev VM and install @development group and go language
ssh localhost -p 2222 #(should prompt for a user account password on wwdev VM)
# Disable selinux by modifying /etc/sysconfig/selinux
vi /etc/sysconfig/selinux
SELINUX=disabled
# Disable firewall
systemctl stop firewalld
systemctl disable firewalld
# Centos prerequisites
sudo yum -y install tftp-server tftp
sudo yum -y install dhcp
sudo yum -y install ipmitool
sudo yum install http://repo.ctrliq.com/packages/rhel7/ctrl-release.rpm
sudo yum install singularityplus
sudo yum install gpgme-devel
sudo yum install libassuan.x86_64 libassuan-devel.x86_64
# Upgrade git to v2+
sudo yum install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
sudo yum install git
sudo yum install golang
sudo yum install nfs-utils
# Install Warewulf and dependencies
git clone https://github.com/hpcng/warewulf.git
cd warewulf
make all
sudo make install
# Static assign an IP to adapter #2 which is in the wwnatnetwork.
$ Edit the file /etc/sysconfig/networking-scripts/ifcfg-enp0s9 # adapter name at the end might be different for you
# Add lines like to below to assign an ip in 10.0.8.0/24 wwnatnetwork, I choose 10.0.8.4
BOOTPROTO=static
ONBOOT=yes
NAME=enp0s9
DEVICE=enp0s9
IPADDR=10.0.8.4
NETMASK=255.255.255.0
GATEWAY=10.0.8.1
# Bring the enp0s9 interface online and verify ip assignment
# Configure the Warewulf controller
$ Edit the file /etc/warewulf/warewulf.conf and ensure that you've set the approprite configuration parameters.
# My conf file looks like below:
ipaddr: 10.0.8.4
netmask: 255.255.255.0
warewulf:
port: 9873
secure: true
update interval: 60
dhcp:
enabled: true
range start: 10.0.8.150
range end: 10.0.8.200
template: default
systemd name: dhcpd
tftp:
enabled: true
tftproot: /var/lib/tftpboot
systemd name: tftp
nfs:
systemd name: nfs-server
exports:
- /home
- /var/warewulf
# Configure system service automatically
sudo wwctl configure dhcp --persist # Create the default dhcpd.conf file and start/enable service
sudo wwctl configure tftp --persist # Install the base tftp/PXE boot files and start/enable service
sudo wwctl configure nfs --persist # Configure the exports and create an fstab in the default system overlay
sudo wwctl configure ssh --persist # Build the basic ssh keys to be included by the default system overlay
# Pull and build the VNFS container and kernel
sudo wwctl container import docker://warewulf/centos-7 centos-7 --setdefault
sudo wwctl kernel import build $(uname -r) --setdefault
# Set up the default node profile
sudo wwctl profile set default -K $(uname -r) -C centos-7
sudo wwctl profile set default --netdev eth0 -M 255.255.255.0 -G 10.0.8.4
sudo wwctl profile list
# Add a node and build node specific overlays
# IP address of my nodes start from 150 as set in the warewulf.conf file above
sudo wwctl node add n0000.cluster --netdev eth0 -I 10.0.8.150 --discoverable
sudo wwctl node list -a n0000
# Review Warewulf overlays
sudo wwctl overlay list -l
sudo wwctl overlay list -ls
sudo wwctl overlay edit default /etc/hello_world.ww
sudo wwctl overlay build -a
# Start the Warewulf daemon
sudo wwctl ready
sudo wwctl server start
sudo wwctl server status
4. Create a new guest VM instance inside the VirtualBox to be the warewulf client/compute node. Under the system configuration make sure to select the optical and network options only for the boot order. The default iPXE used by VirtualBox does not come with bzImage capability which is needed for warewulf. Download the ipxe.iso available at ipxe.org and mount the ipxe.iso to the optical drive. Enable one Network adapter for this VM and assign it to the NAT Network created in step #1 above.
.. code-block:: console
# Download ipxe.so available at http://boot.ipxe.org/ipxe.iso
# VM Settings -> System disable Floppy, Hard Disk from Boot order. Enable Optical and Network options.
# VM Settings -> Storage and mount the above download ipxe.so to the Optical Drive.
# VM Settings -> Network Enable adapter #1, attach to 'Nat Network' and choose 'wwnatnetwork' from the drop down list.
Boot your node and watch the console and the output of the Warewulfd process

11
userdocs/contributing/documentation.rst Normal file
View File

@@ -0,0 +1,11 @@
=============
Documentation
=============
We (like almost all open source software providers) have a documentation dilemma… We tend to focus on the code features and functionality before working on documentation. And there is very good reason for this: we want to share the love so nobody feels left out!
You can contribute to the documentation by `raising an issue to suggest an improvement <https://github.com/hpcng/warewulf-web/issues/new>`_ or by sending a `pull request <https://github.com/hpcng/warewulf-web/compare>`_ on `our repository <https://github.com/hpcng/warewulf-web>`_.
The current documentation is generated with `Docusaurus <https://v2.docusaurus.io/docs/>`_.
For more information on using Git and GitHub to create a pull request suggesting additions and edits to the docs, see the `section on contributing to the code <contributing>`_. The procedure is identical for contributions to the documentation and the code base.

28
userdocs/debian/Dockerfile Normal file
View File

@@ -0,0 +1,28 @@
FROM debian
# Disclaimer:
# this is WIP and subject to change, ant feedback is highly appreciated
# squelsh apt-get
ENV DEBIAN_FRONTEND noninteractive
ENV RUNLEVEL 1
# ----- install vital packages -----
# 'dbus' might makes sense as well
RUN apt-get update && apt-get install -y --no-install-recommends \
kmod \
systemd-sysv \
openssh-client \
openssh-server \
isc-dhcp-client \
pciutils \
strace \
nfs-common \
ethtool\
ifupdown \
linux-image-amd64 \
ifmetric \
netbase && \
rm -rf /var/lib/apt/lists/*
ENV DEBIAN_FRONTEND teletype

21
userdocs/debian/debian.md Normal file
View File

@@ -0,0 +1,21 @@
# Debian, Buster
## Docker container
### build and push
> PSI specific, change for upstream
change into your docker build directory
```bash
docker build -t docker.psi.ch:5000/debian:buster-slim .
docker push docker.psi.ch:5000/debian:buster-slim
```
### import docker container into warewulf
```bash
wwctl container import docker://docker.psi.ch:5000/debian:buster-slim debian-10:slim
```

BIN
userdocs/favicon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

49
userdocs/index.rst Normal file
View File

@@ -0,0 +1,49 @@
==========
User Guide
==========
Welcome to the Warewulf User Guide!
.. toctree::
:maxdepth: 2
:caption: Contents
Introduction <contents/introduction>
Background <contents/background>
Stateless Provisioning <contents/stateless>
Control Server Setup <contents/setup>
Warewulf Installation <contents/installation>
Warewulf Configuration <contents/configuration>
Warewulf Initialization <contents/initialization>
Container Management <contents/containers>
Kernel Management <contents/kernel>
Node Configuration <contents/nodeconfig>
Node Profiles <contents/profiles>
Warewulf Overlays <contents/overlays>
Node Provisioning <contents/provisioning>
IPMI <contents/ipmi>
Security <contents/security>
Templating <contents/templating>
.. toctree::
:maxdepth: 2
:caption: Quickstart
EL7 (CentOS and RHEL) <quickstart/el7>
EL8 (Rocky Linux and RHEL) <quickstart/el8>
openSUSE Leap and SLES 15 <quickstart/suse15>
.. toctree::
:maxdepth: 2
:caption: Contributing
Contributing <contributing/contributing>
Documentation <contributing/documentation>
Development Environment (KVM) <contributing/development-environment-kvm>
Development Environment (VirtualBox) <contributing/development-environment-vbox>
.. toctree::
:maxdepth: 2
:caption: Reference
Glossary <reference/glossary>

BIN
userdocs/logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

127
userdocs/quickstart/el7.rst Normal file
View File

@@ -0,0 +1,127 @@
================================
EL7 Quickstart (CentOS and RHEL)
================================
Install Warewulf and dependencies
=================================
.. code-block:: bash
sudo yum install -y golang tftp-server dhcp nfs-utils
git clone https://github.com/hpcng/warewulf.git
cd warewulf
make all
sudo make install
Configure firewalld
===================
Restart firewalld to register the added service file, add the service to the default zone, and reload.
.. code-block:: bash
sudo systemctl restart firewalld
sudo firewall-cmd --permanent --add-service warewulf
sudo firewall-cmd --permanent --add-service nfs
sudo firewall-cmd --permanent --add-service tftp
sudo firewall-cmd --reload
Configure the controller
========================
Edit the file ``/etc/warewulf/warewulf.conf`` and ensure that you've 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:
.. code-block:: yaml
ipaddr: 192.168.200.1
netmask: 255.255.255.0
warewulf:
port: 9873
secure: false
update interval: 60
dhcp:
enabled: true
range start: 192.168.200.10
range end: 192.168.200.99
template: default
systemd name: dhcpd
tftp:
enabled: true
tftproot: /var/lib/tftpboot
systemd name: tftp
nfs:
systemd name: nfs-server
exports:
- /home
- /var/warewulf
.. note::
The DHCP range ends at `192.168.200.99` and as you will see below, the first node static IP
address (post boot) is configured to `192.168.200.100`.
Start and enable the Warewulf service
=====================================
.. code-block:: bash
# Start and enable the warewulfd service
sudo systemctl enable --now warewulfd
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.
.. code-block:: bash
sudo wwctl configure --all
.. note::
If you just installed the system fresh and have SELinux enforcing, you may need to reboot the system at this stage to properly set the contexts of the TFTP contents. After rebooting, you might also need to run ``$ sudo restorecon -Rv /var/lib/tftpboot/`` if there are errors with TFTP still.
Pull and build the VNFS container and kernel
============================================
This will pull a basic VNFS container from Docker Hub and import the default running kernel from the controller node and set both in the "default" node profile.
.. code-block:: bash
sudo wwctl container import docker://warewulf/centos-7 centos-7 --setdefault
sudo wwctl kernel import $(uname -r) --setdefault
Set up the default node profile
===============================
The ``--setdefault`` arguments above will automatically set those entries in the default profile, but if you wanted to set them by hand to something different, you can do the following:
.. code-block:: bash
sudo wwctl profile set -y default -K $(uname -r) -C centos-7
Next we set some default networking configurations for the first ethernet device. On modern Linux distributions, the name of the device is not critical, as it will be setup according to the HW address. Because all nodes will share the netmask and gateway configuration, we can set them in the default profile as follows:
.. code-block:: bash
sudo wwctl profile set -y default --netname default --netmask 255.255.255.0 --gateway 192.168.200.1
sudo wwctl profile list
Add a node
==========
Adding nodes can be done while setting configurations in one command. Here we are setting the IP address of ``eth0`` and setting this node to be discoverable, which will then automatically have the HW address added to the configuration as the node boots.
Node names must be unique. If you have node groups and/or multiple clusters, designate them using dot notation.
Note that the full node configuration comes from both cascading profiles and node configurations which always supersede profile configurations.
.. code-block:: bash
sudo wwctl node add n0000.cluster --netname default -I 192.168.200.100 --discoverable
sudo wwctl node list -a n0000
Turn on your compute node and watch it boot!

151
userdocs/quickstart/el8.rst Normal file
View File

@@ -0,0 +1,151 @@
=====================================
EL8 Quickstart (Rocky Linux and RHEL)
=====================================
Install Warewulf and dependencies
=================================
.. code-block:: bash
sudo dnf groupinstall "Development Tools"
sudo dnf install epel-release
sudo dnf install golang tftp-server dhcp-server nfs-utils
git clone https://github.com/hpcng/warewulf.git
cd warewulf
make all
sudo make install
Configure firewalld
===================
Restart firewalld to register the added service file, add the service to the default zone, and reload.
.. code-block:: bash
sudo systemctl restart firewalld
sudo firewall-cmd --permanent --add-service warewulf
sudo firewall-cmd --permanent --add-service nfs
sudo firewall-cmd --permanent --add-service tftp
sudo firewall-cmd --reload
Configure the controller
========================
Edit the file ``/etc/warewulf/warewulf.conf`` and ensure that you've 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:
.. code-block:: yaml
ipaddr: 192.168.200.1
netmask: 255.255.255.0
warewulf:
port: 9873
secure: false
update interval: 60
dhcp:
enabled: true
range start: 192.168.200.10
range end: 192.168.200.99
template: default
systemd name: dhcpd
tftp:
enabled: true
tftproot: /var/lib/tftpboot
systemd name: tftp
nfs:
systemd name: nfs-server
exports:
- /home
- /var/warewulf
.. note::
The DHCP range ends at ``192.168.200.99`` and as you will see below, the first node static IP
address (post boot) is configured to ``192.168.200.100``.
Start and enable the Warewulf service
=====================================
.. code-block:: bash
# Start and enable the warewulfd service
sudo systemctl enable --now warewulfd
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.
.. code-block:: bash
sudo wwctl configure --all
.. note::
If you just installed the system fresh and have SELinux enforcing, you may need to reboot the system at this stage to properly set the contexts of the TFTP contents. After rebooting, you might also need to run ``$ sudo restorecon -Rv /var/lib/tftpboot/`` if there are errors with TFTP still.
Pull and build the VNFS container (including the kernel)
========================================================
This will pull a basic VNFS container from Docker Hub and import the default running
kernel from the controller node and set both in the "default" node profile.
.. code-block:: bash
sudo wwctl container import docker://warewulf/rocky:8 rocky-8
Set up the default node profile
===============================
Node configurations can be set via node profiles. Each node by default is configured to
be part of the ``default`` node profile, so any changes you make to that profile will
affect all nodes.
The following command will set the container we just imported above to the ``default`` node profile:
.. code-block:: bash
sudo wwctl profile set --yes --container rocky-8 "default"
Next we set some default networking configurations for the first ethernet device. On
modern Linux distributions, the name of the device is not critical, as it will be setup
according to the HW address. Because all nodes will share the netmask and gateway
configuration, we can set them in the default profile as follows:
.. code-block:: bash
sudo wwctl profile set --yes --netdev eth0 --netmask 255.255.255.0 --gateway 192.168.200.1 "default"
Once those configurations have been set, you can view the changes by listing the profiles as follows:
.. code-block:: bash
sudo wwctl profile list -a
Add a node
==========
Adding nodes can be done while setting configurations in one command. Here we are setting
the IP address of ``eth0`` and setting this node to be discoverable, which will then
automatically have the HW address added to the configuration as the node boots.
Node names must be unique. If you have node groups and/or multiple clusters, designate
them using dot notation.
Note that the full node configuration comes from both cascading profiles and node
configurations which always supersede profile configurations.
.. code-block:: bash
sudo wwctl node add n0000.cluster --ipaddr 192.168.200.100 --discoverable
At this point you can view the basic configuration of this node by typing the following:
.. code-block:: bash
sudo wwctl node list -a n0000.cluster
Turn on your compute node and watch it boot!

183
userdocs/quickstart/suse15.rst Normal file
View File

@@ -0,0 +1,183 @@
====================================
openSUSE Leap and SLES 15 Quickstart
====================================
Install Warewulf and dependencies
=================================
.. code-block:: bash
sudo zypper install -t pattern devel_basis
sudo zypper install go
sudo zypper install tftp dhcp-server nfs-kernel-server
sudo systemctl stop firewalld
sudo systemctl disable firewalld
git clone https://github.com/hpcng/warewulf.git
cd warewulf
PREFIX=/usr SYSCONFDIR=/etc TFTPDIR=/srv/tftproot LOCALSTATEDIR=/var/lib make genconfig
make all
sudo make install
The standard configuration template for the dhcpd service is installed at the wrong location, you have to fix this with
.. code-block:: bash
mv /var/lib/warewulf/overlays/host/etc/dhcp/dhcpd.conf.ww /var/lib/warewulf/overlays/host/etc/dhcpd.conf.ww
Install Warewulf from the open build service
============================================
You can also just install the 'warewulf4' package with ``zypper`` from the openbuild service. Up to date versions are available on the devel project
``https://build.opensuse.org/project/show/network:cluster``
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 defaults for reference assuming that ``192.168.200.1``
is the IP address of your cluster's private network interface:
.. code-block:: yaml
ipaddr: 192.168.200.1
netmask: 255.255.255.0
warewulf:
port: 9873
secure: false
update interval: 60
autobuild overlays: true
host overlay: true
dhcp:
enabled: true
range start: 192.168.200.10
range end: 192.168.200.99
template: default
systemd name: dhcpd
tftp:
enabled: true
tftproot: /var/lib/tftpboot
systemd name: tftp
nfs:
enabled: true
export paths:
- path: /home
export options: rw,sync
mount options: defaults
mount: true
- path: /opt
export options: ro,sync,no_root_squash
mount options: defaults
mount: false
systemd name: nfs-server
.. note::
The DHCP range ends at ``192.168.200.99`` and as you will see below, the first node static IP
address (post boot) is configured to ``192.168.200.100``.
Start and enable the Warewulf service
=====================================
.. code-block:: bash
# Start and enable the warewulfd service
sudo systemctl enable --now warewulfd
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.
.. note::
If the ``dhcpd`` service was not used before you will have to add the interface on which
the cluster network is running to the ``DHCP_INTERFACE`` in the file ``/etc/sysconfig/dhcpd``.
.. code-block:: bash
sudo wwctl configure --all
Pull and build the VNFS container and kernel
============================================
This will pull a basic VNFS container from Docker Hub and import the default running
kernel from the controller node and set both in the "default" node profile.
.. code-block:: bash
$ sudo wwctl container import docker://registry.opensuse.org/science/warewulf/leap-15.4/containers/kernel:latest leap15.4 --setdefault
Set up the default node profile
===============================
The ``--setdefault`` arguments above will automatically set those entries in the default
profile, but if you wanted to set them by hand to something different, you can do the
following:
.. code-block:: bash
sudo wwctl profile set -y -C leap15.4
Next we set some default networking configurations for the first ethernet device. On
modern Linux distributions, the name of the device is not critical, as it will be setup
according to the HW address. Because all nodes will share the netmask and gateway
configuration, we can set them in the default profile as follows:
.. code-block:: bash
sudo wwctl profile set -y default --netname default --netmask 255.255.255.0 --gateway 192.168.200.1
sudo wwctl profile list -a
Add a node
==========
Adding nodes can be done while setting configurations in one command. Here we are setting
the IP address of ``eth0`` and setting this node to be discoverable, which will then
automatically have the HW address added to the configuration as the node boots.
Node names must be unique. If you have node groups and/or multiple clusters, designate
them using dot notation.
Note that the full node configuration comes from both cascading profiles and node
configurations which always supersede profile configurations.
.. code-block:: bash
sudo wwctl node add n0000.cluster --netdev eth0 -I 192.168.200.100 --discoverable
sudo wwctl node list -a n0000.cluster
Warewulf Overlays
=================
There are two types of overlays: system and runtime overlays.
System overlays are provisioned to the node before ``/sbin/init`` is called. This enables us
to prepopulate node configurations with content that is node specific like networking and
service configurations.
Runtime overlays are provisioned after the node has booted and periodically during the
normal runtime of the node. Because these overlays are provisioned at periodic intervals,
they are very useful for content that changes, like users and groups.
Overlays are generated from a template structure that is viewed using the ``wwctl overlay``
commands. Files that end in the ``.ww`` suffix are templates and abide by standard
text/template rules. This supports loops, arrays, variables, and functions making overlays
extremely flexible.
All overlays are compiled before being provisioned. This accelerates the provisioning
process because there is less to do when nodes are being managed at scale.
Here are some of the common ``overlay`` commands:
.. code-block:: bash
sudo wwctl overlay list -l
sudo wwctl overlay list -ls
sudo wwctl overlay edit default /etc/hello_world.ww
sudo wwctl overlay build -a
Boot your compute node and watch it boot!

20
userdocs/reference/glossary.rst Normal file
View File

@@ -0,0 +1,20 @@
========
Glossary
========
Container
Containers are used by Warewulf as the template for the VNFS image. Warewulf containers can be any type of OCI or Singularity standard image formats but maintained on disk as an "OCI bundle". Warewulf integrates with Docker, Docker Hub, any OCI registery, Singularity, standard chroots, etc.
Controller
The controller node(s) are the resources responsible for management, control, and administration of the cluster. Historically these systems have been called "master", "head", or "administrative" nodes, but we feel the term "controller" is more appropriate and descriptive of the role of this system.
Initramfs
Kernel
Overlays
Virtual Node File System (VNFS)
Workers
Worker nodes are the systems that are being provisioned by Warewulf. The roles of these systems could be "compute", "storage", "GPU", "IO", etc. which would typically be used as a prefix, for example: "**compute worker node**"