Fix some markdown style issues.

.markdownlint.yaml

@@ -1,4 +1,4 @@
-# See https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml
+# See [rules](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml)
 
 # Default state for all rules
 default: true
@@ -27,12 +27,4 @@ MD036: false
   
 # MD043/required-headings : Required heading structure : 
 # https://github.com/DavidAnson/markdownlint/blob/v0.37.4/doc/md043.md
-MD043:
+MD043: false
-  # List of headings
-  headings:   [
-      "# Head",
-      "## Item",
-      "### Detail"
-  ]
-  # Match case of headings
-  match_case: false

package.json

@@ -7,6 +7,7 @@
         "documentation": "^14.0.1",
         "install": "^0.13.0",
         "jsdoc": "^4.0.2",
+        "markdownlint": "^0.37.4",
         "node-sass": "^9.0.0",
         "npm": "^8.11.0",
         "rollup": "^4.1.5",
@@ -22,8 +23,8 @@
         "typescript": "^5.2.2"
     },
     "overrides": {
-      "node-gyp": "^10.1.0",
+        "node-gyp": "^10.1.0",
-      "glob": "^9.0.0"
+        "glob": "^9.0.0"
     },
     "eslintConfig": {
         "root": true,
@@ -34,5 +35,8 @@
     },
     "eslintIgnore": [
         "node_modules/**"
-    ]
+    ],
+    "dependencies": {
+        "markdownlint-cli": "^0.44.0"
+    }
 }

webpages/admin-gui.md

@@ -19,4 +19,3 @@ the VMs and adjust the CPU and RAM usages (modifies the definition
 in kubernetes).
 
 ![VM-Operator GUI](VM-Operator-GUI-view.png)
-

webpages/auto-login.md

@@ -11,14 +11,14 @@ When users log into the web GUI, they have already authenticated with the
 VM-Operator. In some environments, requiring an additional login on the
 guest OS can be cumbersome. To enhance the user experience, the VM-Operator
 supports automatic login on the guest operating system, thus eliminating
-the need for multiple logins. However, this feature requires specific 
+the need for multiple logins. However, this feature requires specific
 support from the guest OS.
 
 ## Prepare the VM
 
 Automatic login requires an agent running inside the guest OS. Similar
 to QEMU's standard guest agent, the VM-Operator agent communicates with
-the host via a tty device (`/dev/virtio-ports/org.jdrupes.vmop_agent.0`). On 
+the host via a tty device (`/dev/virtio-ports/org.jdrupes.vmop_agent.0`). On
 modern Linux systems, `udev` can detect this device and trigger the start
 of an associated systemd service.
 
@@ -30,7 +30,7 @@ Copy
   * `vmop-agent` → `/usr/local/libexec/vmop-agent` and
   * `vmop-agent.service` → `/usr/local/lib/systemd/system/vmop-agent.service`.
 
-Some of these target directories may not exist by default and must be 
+Some of these target directories may not exist by default and must be
 created manually. If your system uses SELinux, run `restorecon` to apply
 the correct security contexts.
 

webpages/index.md

@@ -27,6 +27,7 @@ If you just want to try out things, you can skip the remainder of this
 page and proceed to "[the manager](manager.html)".
 
 ## Motivation
+
 The project was triggered by a remark in the discussion about RedHat
 [dropping SPICE support](https://bugzilla.redhat.com/show_bug.cgi?id=2030592)
 from the RHEL packages. Which means that you have to run Qemu in a
@@ -55,9 +56,11 @@ close to simply deploying the pod (you get the restart and some PVC
 management "for free").
 
 A second look, however, reveals that Kubernetes has more to offer.
-* It has a well defined API for managing resources.
+
-* It provides access to different kinds of managed storage for the VMs.
+  * It has a well defined API for managing resources.
-* Its managing features *are* useful for running the component that
+  * It provides access to different kinds of managed storage for the VMs.
+  * Its managing features *are* useful for running the component that
+  
 manages the pods with the VMs.
 
 And if you use Kubernetes anyway, well then the VMs within Kubernetes

webpages/manager.md

@@ -40,7 +40,8 @@ default files for creating these resources using the default namespace
 can be found in the
 [deploy](https://github.com/mnlipp/VM-Operator/tree/main/deploy)
 directory. I recommend to use
-[kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/) to create your own configuration.
+[kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)
+to create your own configuration.
 
 ## Initial Configuration
 

webpages/pools.md

@@ -76,7 +76,7 @@ provide access to a pool instead of to a specific VM.
 
 Assignment happens when the "Start" icon is clicked. If the assigned VM
 is not already running, it will be started automatically. The assigned
-VM's name apears in the widget above the action icons. 
+VM's name apears in the widget above the action icons.
 
 ![VM Access via pool](PoolAccess-preview.png)
 

webpages/runner.md

@@ -44,9 +44,9 @@ A sample configuration file with annotated options can be found
 As the runner implementation uses the
 [JGrapes](https://jgrapes.org/) framework, the file
 follows the framework's
-[conventions](https://jgrapes.org/latest-release/javadoc/org/jgrapes/util/YamlConfigurationStore.html). The top level "`/Runner`" selects
+[conventions](https://jgrapes.org/latest-release/javadoc/org/jgrapes/util/YamlConfigurationStore.html).
-the component to be configured. Nested within is the information
+The top level "`/Runner`" selects the component to be configured. Nested
-to be applied to the component.
+within is the information to be applied to the component.
 
 The main entries in the configuration file are the "template" and
 the "vm" information. The runner processes the
@@ -58,8 +58,8 @@ defines a particular VM type, i.e. it contains the "nasty details"
 that do not need to be modified for some given set of VM instances.
 
 The templates provided with the runner can be found
-[here](https://github.com/mnlipp/VM-Operator/tree/main/org.jdrupes.vmoperator.runner.qemu/templates). When details
+[here](https://github.com/mnlipp/VM-Operator/tree/main/org.jdrupes.vmoperator.runner.qemu/templates).
-of the VM configuration need modification, a new VM type
+When details of the VM configuration need modification, a new VM type
 (i.e. a new template) has to be defined. Authoring a new
 template requires some knowledge about the
 [qemu invocation](https://www.qemu.org/docs/master/system/invocation.html).
@@ -92,7 +92,8 @@ which may be used in a stand-alone development configuration.
 The runner supports adaption to changes of the RAM size (using the
 balloon device) and to changes of the number of CPUs. Note that
 in order to get new CPUs online on Linux guests, you need a
-[udev rule](https://docs.kernel.org/core-api/cpu_hotplug.html#user-space-notification) which is not installed by default[^simplest].
+[udev rule](https://docs.kernel.org/core-api/cpu_hotplug.html#user-space-notification)
+which is not installed by default[^simplest].
 
 The runner also changes the images loaded in CDROM drives. If the
 drive is locked, i.e. if it doesn't respond to the "open tray" command
@@ -101,7 +102,8 @@ the change will be suspended until the VM opens the tray.
 Finally, `powerdownTimeout` can be changed while the qemu process runs.
 
 [^simplest]: The simplest form of the rule is probably:
-    ```
+
+    ```txt
     ACTION=="add", SUBSYSTEM=="cpu", ATTR{online}="1"
     ```
 

webpages/user-gui.md

@@ -77,7 +77,8 @@ objects that either specify a role or a user.
 ## Console access
 
 Access to the VM's console is implemented by generating a
-[connection file](https://manpages.debian.org/testing/virt-viewer/remote-viewer.1.en.html#CONNECTION_FILE) for virt-viewer when the user clicks on
+[connection file](https://manpages.debian.org/testing/virt-viewer/remote-viewer.1.en.html#CONNECTION_FILE)
+for virt-viewer when the user clicks on
 the console icon. If automatic open is enabled for this kind of
 files in the browser, the console opens without further user action.