The Warewulf configuration exists as follows in the current version of -Warewulf (4.3.0):
+Warewulf (4.4.0):WW_INTERNAL: 43
-ipaddr: 192.168.200.1
-netmask: 255.255.255.0
-network: 192.168.200.0
+ipaddr: 10.0.0.1
+netmask: 255.255.252.0
+network: 10.0.0.0
warewulf:
port: 9873
secure: false
@@ -140,8 +140,8 @@ warewulf.conf syslog: false
dhcp:
enabled: true
- range start: 192.168.200.50
- range end: 192.168.200.99
+ range start: 10.0.1.1
+ range end: 10.0.1.255
systemd name: dhcpd
tftp:
enabled: true
@@ -158,6 +158,10 @@ warewulf.conf mount options: defaults
mount: false
systemd name: nfs-server
+container mounts:
+ - source: /etc/resolv.conf
+ dest: /etc/resolv.conf
+ readonly: true
Generally you can leave this file as is, as long as you set the @@ -176,16 +180,12 @@
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.
*:enabled: This can be used to disable Warewulf’s control of a
+system 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.
/var/log/warewulfd.log)
-nfs:export paths: Warewulf will automatically set up the NFS
-exports if you wish for it to do this.
nfs:export paths: Warewulf can automatically set up these NFS
+exports.
container mounts: These paths are mounted into the container
+during container exec or container shell, typically to allow
+them to operate in the host environment prior to deployment.
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.
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.
The defaults.conf file configures default values used when none
-are specified. For example: if a node does not have a “runtime
-overlay” specified, the respective value from defaultnode is
-used. If a network device does not specify a “device,” the device
-value of the dummy device is used.
nodes.conf. For example: if a node does not have
+a “runtime overlay” specified, the respective value from
+defaultnode is used. If a network device does not specify a
+“device,” the device value of the dummy device is used.
If defaults.conf does not exist, the following values are used as
compiled into Warewulf at build-time:
--
diff --git a/static/docs/main/contents/containers.html b/static/docs/main/contents/containers.html
index 6523ad84..e8ecd7f6 100644
--- a/static/docs/main/contents/containers.html
+++ b/static/docs/main/contents/containers.html
@@ -145,19 +145,19 @@ Container ManagementIn 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.
+distributing, securing, and managing containers, so Warewulf v4 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.
+Warewulf as before.
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.
+runtime on cluster nodes. While it is absolutely possible to run
+containers on cluster nodes, 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 entirely in
+memory. This means that when you reboot the node, the node retains no
+information about Warewulf or how it booted.
Container Tools
There are different container managment tools available. Docker is
diff --git a/static/docs/main/contents/initialization.html b/static/docs/main/contents/initialization.html
index b515af76..e9d2b67a 100644
--- a/static/docs/main/contents/initialization.html
+++ b/static/docs/main/contents/initialization.html
@@ -157,8 +157,8 @@
System Services
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:
+with systemd, so it should be as easy to start/stop/check as any other
+systemd service:
# systemctl enable --now warewulfd
@@ -169,7 +169,7 @@ Warewulf Service
Note
-If the Warewulf service is running via Systemd, restarting
+
If the Warewulf service is running via systemd, restarting
stopping, and starting it from the wwctl command may result in
unexpected results.
There are multiple methods to install Warewulf, this page describes -the installation process of multiple methods:
+There are multiple methods to install Warewulf. This page describes +the installation process for some of those methods.
The Warewulf project builds binary RPMs as part of its CI/CD @@ -165,20 +165,14 @@
When the Warewulf project releases stable versions, they are available -via source form here:
-https://github.com/warewulf/warewulf/tags
+The Warewulf project releases source distributions alongside its +binary RPMs. You can obtain them from the GitHub releases page.
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:
-# EDIT HERE
-VERSION=4.2.0
-DOWNLOAD=/tmp/warewulf-${4.2.0}.tar.gz
-
-# COPY/PASTE THIS
-mkdir ~/src
-cd ~/src
-tar xvf ${DOWNLOAD}
+VERSION=4.4.0
+curl -LO https://github.com/hpcng/warewulf/releases/download/v${VERSION}/warewulf-${VERSION}.tar.gz
+tar -xf warewulf-${VERSION}.tar.gz
cd warewulf-${VERSION}
make all && sudo make install
@@ -186,22 +180,24 @@ Release Tarball
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.
-mkdir ~/git
-cd ~/git
-git clone https://github.com/warewulf/warewulf.git
+Warewulf is developed in GitHub, 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 development. The
+development 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
+development is not guaranteed to be stable or generally supported
+for production.
+Alternatively, the main branch is more stable and is used as a
+staging area for pending releases.
+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.
+git clone https://github.com/hpcng/warewulf.git
cd warewulf
-git checkout main # or switch to a tag like '4.2.0'
+git checkout development # or switch to a tag like 'v4.4.0'
make all && sudo make install
diff --git a/static/docs/main/contents/kernel.html b/static/docs/main/contents/kernel.html
index 9f3dad70..ffb13c7c 100644
--- a/static/docs/main/contents/kernel.html
+++ b/static/docs/main/contents/kernel.html
@@ -124,34 +124,32 @@ 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.
+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:
# 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
+ CONTAINER NAME NODES KERNEL VERSION CREATION TIME MODIFICATION TIME SIZE
+ alpine 0 05 Jun 23 20:02 MDT 05 Jun 23 20:02 MDT 17.9 MiB
+ rocky-8 1 4.18.0-372.13.1.el8_6.x86_64 17 Jan 23 23:48 MST 06 Apr 23 09:40 MDT 2.4 GiB
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
+kernel within it, and the rocky container includes a kernel.
+This model was introduced in Warewulf v4.3. 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
+
It is still possible to specify a kernel for 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
+
You can specify this option 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
@@ -161,7 +159,7 @@
Kernel Overrides
Listing All Imported Kernels
Once the kernel has been imported, you can list them all with the
@@ -169,10 +167,14 @@
Listing All Imported Kernels# wwctl kernel list
VNFS NAME NODES
4.18.0-305.3.1.el8_4.x86_64 0
+
+# wwctl kernel list
+KERNEL NAME KERNEL VERSION 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.
+Once a kernel has been imported you can configure it to boot compute
+nodes.
diff --git a/static/docs/main/contents/nodeconfig.html b/static/docs/main/contents/nodeconfig.html
index 9e9ade44..44a3d3cb 100644
--- a/static/docs/main/contents/nodeconfig.html
+++ b/static/docs/main/contents/nodeconfig.html
@@ -146,7 +146,7 @@ The Node Configuration DB
Adding a New Node
Creating a new node is as simple as running the following command:
-# wwctl node add n001 -I 172.16.1.11
+# wwctl node add n001 -I 10.0.2.1
Added node: n001
@@ -154,18 +154,17 @@ Adding a New Node
Several nodes can be added with a single command if a node range is
given. An additional IP address will incremented. So the command
-# wwctl node add n00[2-4] -I 172.16.1.12
+# wwctl node add n00[2-4] -I 10.0.2.2
Added node: n002
Added node: n003
Added node: n004
# wwctl node list -n n00[1-4]
NODE NAME NAME HWADDR IPADDR GATEWAY DEVICE
-==========================================================================================
-n001 default -- 172.16.1.11 -- (eth0)
-n002 default -- 172.16.1.12 -- (eth0)
-n003 default -- 172.16.1.13 -- (eth0)
-n004 default -- 172.16.1.14 -- (eth0)
+n001 default -- 10.0.2.1 -- (eth0)
+n002 default -- 10.0.2.2 -- (eth0)
+n003 default -- 10.0.2.3 -- (eth0)
+n004 default -- 10.0.2.4 -- (eth0)
has added 4 nodes with the incremented IP addresses.
@@ -191,47 +190,45 @@ Listing Nodes# wwctl node list
NODE NAME PROFILES NETWORK
-================================================================================
-n001 default
+n001 default
You can also see the node’s full attribute list by specifying the
-a option (all):
-# wwctl node list -a n001
-NODE FIELD PROFILE VALUE
-=====================================================================================
-n001 Id -- n001
-n001 comment default This profile is automatically included for each node
-n001 cluster -- --
-n001 container default sle-micro-5.3
-n001 ipxe -- (default)
-n001 runtime -- (generic)
-n001 wwinit -- (wwinit)
-n001 root -- (initramfs)
-n001 discoverable -- --
-n001 init -- (/sbin/init)
-n001 asset -- --
-n001 kerneloverride -- --
-n001 kernelargs -- (quiet crashkernel=no vga=791 net.naming-scheme=v238)
-n001 ipmiaddr -- --
-n001 ipminetmask -- --
-n001 ipmiport -- --
-n001 ipmigateway -- --
-n001 ipmiuser -- --
-n001 ipmipass -- --
-n001 ipmiinterface -- --
-n001 ipmiwrite -- --
-n001 profile -- default
-n001 default:type -- (ethernet)
-n001 default:onboot -- --
-n001 default:netdev -- (eth0)
-n001 default:hwaddr -- --
-n001 default:ipaddr -- 172.16.1.11
-n001 default:ipaddr6 -- --
-n001 default:netmask -- (255.255.255.0)
-n001 default:gateway -- --
-n001 default:mtu -- --
-n001 default:primary -- true
+# wwctl node list -a n001
+NODE FIELD PROFILE VALUE
+n001 Id -- n001
+n001 comment default This profile is automatically included for each node
+n001 cluster -- --
+n001 container default sle-micro-5.3
+n001 ipxe -- (default)
+n001 runtime -- (generic)
+n001 wwinit -- (wwinit)
+n001 root -- (initramfs)
+n001 discoverable -- --
+n001 init -- (/sbin/init)
+n001 asset -- --
+n001 kerneloverride -- --
+n001 kernelargs -- (quiet crashkernel=no vga=791 net.naming-scheme=v238)
+n001 ipmiaddr -- --
+n001 ipminetmask -- --
+n001 ipmiport -- --
+n001 ipmigateway -- --
+n001 ipmiuser -- --
+n001 ipmipass -- --
+n001 ipmiinterface -- --
+n001 ipmiwrite -- --
+n001 profile -- default
+n001 default:type -- (ethernet)
+n001 default:onboot -- --
+n001 default:netdev -- (eth0)
+n001 default:hwaddr -- --
+n001 default:ipaddr -- 172.16.1.11
+n001 default:ipaddr6 -- --
+n001 default:netmask -- (255.255.255.0)
+n001 default:gateway -- --
+n001 default:mtu -- --
+n001 default:primary -- true
@@ -265,7 +262,7 @@ Configuring the Node’s Container Image
Configuring the Node’s Kernel
-While the recommended method for assigning a kernel in 4.3 and beyond
+
While the recommended method for assigning a kernel in v4.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. To illustrate this,
we import the most recent kernel from a openSUSE Tumbleweed release.
@@ -293,7 +290,7 @@ Configuring the Node’s Network# wwctl node list -a n001
-=====================================================================================
+NODE FIELD PROFILE VALUE
n001 Id -- n001
n001 comment default This profile is automatically included for each node
n001 cluster -- --
@@ -360,7 +357,7 @@ Additional networks
Node Discovery
The hwaddr of a node can be automatically discovered by setting
-–discoverable on a node. If a node attempts to provision against
+--discoverable on a node. If a node attempts to provision against
Warewulf using an interface that is unknown to Warewulf, that address
is associated with the first discoverable node. (Multiple discoverable
nodes are sorted lexically, first by cluster, then by ID.)
diff --git a/static/docs/main/contents/profiles.html b/static/docs/main/contents/profiles.html
index 4c19140d..48ec8a4a 100644
--- a/static/docs/main/contents/profiles.html
+++ b/static/docs/main/contents/profiles.html
@@ -141,31 +141,29 @@ An Introduction To Profiles# wwctl profile list
PROFILE NAME COMMENT/DESCRIPTION
-================================================================================
default This profile is automatically included for each node
And with the -a flag:
# 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 --
+PROFILE FIELD PROFILE 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
@@ -174,7 +172,6 @@
An Introduction To Profiles# 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
@@ -194,7 +191,6 @@ Multiple Profiles# wwctl profile add test_profile
# wwctl profile list
PROFILE NAME COMMENT/DESCRIPTION
-================================================================================
default This profile is automatically included for each node
test_profile --
@@ -215,7 +211,6 @@ Multiple Profiles# 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
@@ -232,7 +227,6 @@ Cascading ProfilesAre you sure you want to modify 1 profile(s): y
# wwctl node list -a | head -n 6
-################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment test_profile test comment
@@ -246,7 +240,6 @@ Cascading ProfilesAre you sure you want to modify 1 profile(s): y
# 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
@@ -268,7 +261,6 @@ Overriding ProfilesAre you sure you want to modify 1 nodes(s): y
# wwctl node list -a | head -n 6
-################################################################################
NODE FIELD PROFILE VALUE
n0000 Id -- n0000
n0000 Comment SUPERSEDED This value takes precedent
diff --git a/static/docs/main/contents/setup.html b/static/docs/main/contents/setup.html
index 25ac9c0d..d87e9c5e 100644
--- a/static/docs/main/contents/setup.html
+++ b/static/docs/main/contents/setup.html
@@ -171,7 +171,7 @@ Addressing
10.0.0.1: Private network address IP
255.255.252.0: Private network subnet mask
255.255.252.0: Private network subnet mask (10.0.0.0/22)
Here is an example of how the cluster’s address can be divided for a
255 node cluster:
diff --git a/static/docs/main/contents/stateless.html b/static/docs/main/contents/stateless.html
index e2f519ee..f0ec8c9a 100644
--- a/static/docs/main/contents/stateless.html
+++ b/static/docs/main/contents/stateless.html
@@ -129,9 +129,9 @@ Why is Provisioning Important
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.
+helped, there was even more optimization to be had.
Why Stateless Provisioning
@@ -163,8 +162,8 @@ Why Stateless Provisioningwwctl command. This command has sub-commands for each major
component of Warewulf’s functionality.
-configure configures external services that Warewulf depends on
configure configures system services that Warewulf depends on
container configures containers (node images)
kernel configures override kernels
node manages nodes in the cluster