Index: wikisrc/tutorials/cpu_frequency_scaling.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/cpu_frequency_scaling.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/tutorials/cpu_frequency_scaling.mdwn	5 Aug 2026 07:18:34 -0000	1.3
+++ wikisrc/tutorials/cpu_frequency_scaling.mdwn	5 Aug 2026 07:23:14 -0000	1.4
@@ -1,4 +1,9 @@
-Support is enabled in GENERIC kernels by default. sysctl and sysutils/estd do the rest. 
+Support for throttling the CPU is enabled in GENERIC kernels by
+default, and available on a range of architectures, including
+evbarm, amd64, macppc, and i386. CPU speed can be changed by
+adjusting the [sysctl](//man.NetBSD.org/sysctl.8) variable
+or using sysutils/estd to do so dynamically depending on
+system load.
 
 Please refer to the relevant
 [power management](//www.NetBSD.org/docs/guide/en/chap-power.html#chap-power-adjusting-cpu-freq)

Index: wikisrc/tutorials/cpu_frequency_scaling.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/cpu_frequency_scaling.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/tutorials/cpu_frequency_scaling.mdwn	5 Feb 2012 07:14:36 -0000	1.2
+++ wikisrc/tutorials/cpu_frequency_scaling.mdwn	5 Aug 2026 07:18:34 -0000	1.3
@@ -1,136 +1,5 @@
-How to throttle your CPU 
-
-Basic support is in generic kernels by default. sysctl and sysutils/estd do the rest. 
-
-**Contents**
-
-[[!toc levels=3]]
-
-#  i386 
-
-##  AMD PowerNow! 
-    
-      options 	POWERNOW_K7
-    
-
-or 
-    
-      options 	POWERNOW_K8
-    
-
-accessible through e.g. 
-    
-      sysctl machdep.powernow.frequency.current
-      sysctl machdep.powernow.frequency.available 
-      sysctl -w machdep.powernow.frequency.target=600
-    
-
-##  Intel Speedstep 
-    
-      options 	ENHANCED_SPEEDSTEP
-    
-
-accessible through e.g. 
-    
-      sysctl machdep.est.frequency.current
-      sysctl machdep.est.frequency.available
-      sysctl -w machdep.est.frequency.target=600
-    
-
-##  speedstep-ich 
-
-  * Available since NetBSD 2.0 
-    
-      ichlpcib* at pci? dev ? function ?
-      isa0 at ichlpcib?
-    
-
-accessible through 
-    
-      sysctl -w machdep.speedstep_state=[0/1]
-    
-
-where 0 is a low state and 1 is a high state. 
-
-##  speedstep-smi 
-
-  * Available since NetBSD 4.0 
-    
-      piixpcib* at pci? dev ? function ?
-      isa0 at piixpcib?
-    
-
-also accessible through 
-    
-      sysctl -w machdep.speedstep_state=[0/1]
-    
-
-##  Transmeta longrun 
-
-  * Should be activated by default 
-
-accessible through 
-    
-      machdep.tm_longrun_mode
-      machdep.tm_longrun_frequency
-      machdep.tm_longrun_voltage
-      machdep.tm_percentage
-    
-
-#  amd64 
-
-##  Cool'n'Quiet 
-
-Same procedure as with PowerNow!: 
-    
-      options 	POWERNOW_K8
-    
-
-accessible through e.g. 
-    
-      sysctl machdep.powernow.frequency.current
-      sysctl machdep.powernow.frequency.available 
-      sysctl -w machdep.powernow.frequency.target=600
-    
-
-#  Setting up estd for automatic scaling 
-
-The estd daemon dynamically sets the frequency on SpeedStep and PowerNow!-enabled CPUs depending on current CPU-utilization. It is written for systems running NetBSD or DragonFly. 
-    
-      cd /usr/pkgsrc/sysutils/estd
-      make install clean
-    
-
-To make it start at boot-time 
-    
-      cp /usr/pkg/share/examples/rc.d/estd /etc/rc.d/
-      chmod +x /etc/rc.d/estd
-    
-
-and add to /etc/rc.conf 
-    
-      estd="yes"
-      estd_flags=""
-    
-
-then as root 
-    
-      /etc/rc.d/estd restart
-    
-
-  * Examples 
-
-Maximize battery lifetime by limiting CPU-frequency to 1000 MHz and switching to lower speeds fast: 
-    
-      estd_flags="-d -b -M 1000"
-    
-
-Maximize performance by running at least at 1400MHz and switching to higher speeds real fast: 
-    
-      estd_flags="-d -a -m 1400"
-    
-
-Alternatively, you can start estd directly from /etc/rc.local instead of rc.conf/rc.d. 
-
-More in the manual. 
+Support is enabled in GENERIC kernels by default. sysctl and sysutils/estd do the rest. 
 
+Please refer to the relevant
+[power management](//www.NetBSD.org/docs/guide/en/chap-power.html#chap-power-adjusting-cpu-freq)
+section in the NetBSD Guide.

Index: wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	27 Jul 2026 18:56:40 -0000	1.7
+++ wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	2 Aug 2026 17:22:24 -0000	1.8
@@ -25,6 +25,7 @@
 Stephen | `sborrill@` | yes | 10th or 11th, please
 Adrian | `ast@` | yes | n/a
 Yuri | `yurix@` | yes | n/a
+Leonardo | `leot@` | yes | vegetarian
 """]]
 
 ## Planning to present something?

Index: wikisrc/ports/cats/gxemul_cats.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/cats/gxemul_cats.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/ports/cats/gxemul_cats.mdwn	5 Oct 2025 12:29:48 -0000	1.7
+++ wikisrc/ports/cats/gxemul_cats.mdwn	2 Aug 2026 13:55:10 -0000	1.8
@@ -1,10 +1,10 @@
 [[!meta title="NetBSD/cats in GXemul"]]
 
-As of October 2024, GXemul runs all versions of NetBSD/cats, including all releases and -current.  Note that at the time of this writing, the latest GXemul release (0.7.0) has a bug that prevents builds compiled with GCC 10 (NetBSD 10.0 and later releases and -current after June 2021 and) from booting.  To run such a release either install GXemul from pkgsrc or apply the patch linked below.
+As of October 2024, GXemul runs all versions of NetBSD/cats, including all releases and -current.  Note that at the time of this writing, the latest GXemul release (0.7.0) has a bug that prevents builds compiled with GCC >= 10 (NetBSD 10.0 and later releases and -current after June 2021) from booting.  To run such a release either install GXemul from pkgsrc or apply the patch linked below.
 
 # Requirements
 * GXemul from pkgsrc (otherwise make sure it contains [this patch](https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/emulators/gxemul/patches/patch-src_cpus_cpu__arm__instr__dpi.c?rev=1.1;content-type=text%2Fplain))
-* an installation .iso, e.g., [NetBSD-10.1-cats.iso](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/iso/NetBSD-10.1-cats.iso) and corresponding [kernel](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/cats/binary/kernel/netbsd-GENERIC.gz)
+* an installation .iso, e.g., [NetBSD-11.0-cats.iso](https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/iso/NetBSD-11.0-cats.iso) and corresponding [kernel](https://cdn.netbsd.org/pub/NetBSD/NetBSD-11.0/cats/binary/kernel/netbsd-GENERIC.gz)
 
 # Creating a disk image
 
@@ -12,7 +12,7 @@
 
 # Installing NetBSD/cats in GXemul
 
-    $ gxemul -E cats -q -d c:NetBSD-10.1-cats.iso -d d:hdd.img -j 'NETBSD.;1'
+    $ gxemul -E cats -q -d c:NetBSD-11.0-cats.iso -d d:hdd.img -j 'NETBSD.;1'
 
 Go through a standard NetBSD installation.  At the end, when configuring the networking, use the following settings:
 

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/laptops.mdwn	2 Aug 2026 09:50:52 -0000	1.41
+++ wikisrc/laptops.mdwn	2 Aug 2026 10:41:53 -0000	1.42
@@ -62,13 +62,9 @@
 [[!template id=man name="iwn" section="4"]] for older models.
 Atheros 11n miniPCIe cards are supported by the
 [[!template id=man name="athn" section="4"]] driver.
-Since December 2025, iwm(4) is more stable and faster in the
--current kernel for most users. These changes have not yet
-made it to a stable branch.
-
-See the
-[[!template id=man name="afterboot" section="8"]] man page for details
-on connecting to WiFi networks.
+Since December 2025, iwm(4) is more stable and performant in the
+-current kernel (for most users). These changes have not yet
+been pulled to a stable branch.
 
 USB 11n WiFi adapters such as
 [[!template id=man name="urtwn" section="4"]] and
@@ -82,6 +78,10 @@
 with NetBSD over USB using
 [[!template id=man name="urndis" section="4"]].
 
+See the
+[[!template id=man name="afterboot" section="8"]] man page for details
+on connecting to WiFi networks.
+
 Unfortunately, WiFi hardware is not particularly standardized compared
 to most other aspects of modern laptops.
 

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- wikisrc/laptops.mdwn	2 Aug 2026 09:47:37 -0000	1.40
+++ wikisrc/laptops.mdwn	2 Aug 2026 09:50:52 -0000	1.41
@@ -62,6 +62,9 @@
 [[!template id=man name="iwn" section="4"]] for older models.
 Atheros 11n miniPCIe cards are supported by the
 [[!template id=man name="athn" section="4"]] driver.
+Since December 2025, iwm(4) is more stable and faster in the
+-current kernel for most users. These changes have not yet
+made it to a stable branch.
 
 See the
 [[!template id=man name="afterboot" section="8"]] man page for details
@@ -71,8 +74,13 @@
 [[!template id=man name="urtwn" section="4"]] and
 [[!template id=man name="run" section="4"]] can also be used,
 and most/all generic USB ethernet adapters are also well supported.
+USB adapters generally have the most mature drivers and are
+the best way to get wireless networking out of your NetBSD machine.
 For a fairly complete list, see 
 [[!template id=man name="usb" section="4"]].
+Most modern smartphones can also share their internet connection
+with NetBSD over USB using
+[[!template id=man name="urndis" section="4"]].
 
 Unfortunately, WiFi hardware is not particularly standardized compared
 to most other aspects of modern laptops.

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/laptops.mdwn	2 Aug 2026 09:39:23 -0000	1.39
+++ wikisrc/laptops.mdwn	2 Aug 2026 09:47:37 -0000	1.40
@@ -13,17 +13,18 @@
 
 ## Graphics
 
-NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake, Nvidia
-graphics up to Pascal,, and AMD graphics up to GCNv1 (with radeon).
-The amdgpu driver for post-GCNv1 GPUs is experimental.
+NetBSD 10.0 has full acceleration with Intel integrated graphics up to
+Tiger Lake, Nvidia graphics up to Pascal, and AMD graphics up to
+GCNv1 (with radeon). The amdgpu driver for post-GCNv1 GPUs is
+experimental. The support includes connecting external monitors
+over HDMI, DisplayPort, and DisplayPort over USB-C.
 There is no change in the supported GPUs in 11.0.
 
 Anything newer than this will work, but will use `llvmpipe`
-instead of hardware acceleration for OpenGL. See
-[using wsfb with unsupported GPUs](../tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer).
-
-The support includes connecting external monitors over HDMI,
-DisplayPort, and DisplayPort over USB-C.
+instead of hardware acceleration for OpenGL, and the video
+mode will be fixed at boot. See
+[using wsfb with unsupported GPUs](../tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer) for details on how to change the video mode
+and configure X.Org.
 
 For the Intel driver, there may be slight graphical corruptions
 when using X11 without a compositor. Xfce/MATE include their own

Index: wikisrc/laptops.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/laptops.mdwn,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- wikisrc/laptops.mdwn	6 Aug 2024 18:35:28 -0000	1.38
+++ wikisrc/laptops.mdwn	2 Aug 2026 09:39:23 -0000	1.39
@@ -13,13 +13,14 @@
 
 ## Graphics
 
-NetBSD 9.0 supports Intel integrated graphics up to (including)
-Kaby Lake, Nvidia graphics up to Maxwell, and AMD graphics up to GCNv1.
-NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake
-and Nvidia graphics up to Pascal.
+NetBSD 10.0 supports Intel integrated graphics up to Tiger Lake, Nvidia
+graphics up to Pascal,, and AMD graphics up to GCNv1 (with radeon).
+The amdgpu driver for post-GCNv1 GPUs is experimental.
+There is no change in the supported GPUs in 11.0.
 
 Anything newer than this will work, but will use `llvmpipe`
-instead of hardware acceleration for OpenGL.
+instead of hardware acceleration for OpenGL. See
+[using wsfb with unsupported GPUs](../tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer).
 
 The support includes connecting external monitors over HDMI,
 DisplayPort, and DisplayPort over USB-C.

Index: wikisrc/releng.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng.mdwn,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -r1.61 -r1.62
--- wikisrc/releng.mdwn	26 Jul 2026 08:36:40 -0000	1.61
+++ wikisrc/releng.mdwn	1 Aug 2026 17:43:48 -0000	1.62
@@ -6,19 +6,22 @@
 
 ## Next Major Release
 
-The next major release will be NetBSD 11.0.
+The next major release will be NetBSD 12.0.
 
-* currently in RC1 state, 11.0 release expected before the end of february 2026.
-  + CVS branch tag: <code>netbsd-11</code>
-* [Current pull-up queue for the netbsd-11 branch](http://releng.netbsd.org/cgi-bin/req-11.cgi)
-* open issues to solve [before the 11.0 release](netbsd-11)
+* not branched yet, no timeline.
 
 
 ## Active Major Releases
 
+### NetBSD 11.x
+
+* Next minor release: NetBSD 11.1 (ETA end of September 2026)
+  + CVS branch tag: <code>netbsd-11</code>
+* [Current pull-up queue for the netbsd-11 branch](http://releng.netbsd.org/cgi-bin/req-11.cgi)
+
 ### NetBSD 10.x
 
-* Next minor release: NetBSD 10.2 (early in 2026, about a month after the 11.0 release)
+* Next minor release: NetBSD 10.2 (ETA end of August 2026)
   + CVS branch tag: <code>netbsd-10</code>
 * [Current pull-up queue for the netbsd-10 branch](http://releng.netbsd.org/cgi-bin/req-10.cgi)
 
@@ -27,7 +30,7 @@
 * Next minor release would be NetBSD 9.5, but is unlikely to happen.
   + CVS branch tag: <code>netbsd-9</code>
 * [Current pull-up queue for the netbsd-9 branch](http://releng.netbsd.org/cgi-bin/req-9.cgi)
-* end of support for netbsd-9 in first quarter 2026
+* end of support for netbsd-9 end of August 2026
 
 
 ## Automated Status Information
Index: wikisrc/ports/aarch64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/aarch64.mdwn,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- wikisrc/ports/aarch64.mdwn	15 Jan 2025 23:25:30 -0000	1.20
+++ wikisrc/ports/aarch64.mdwn	1 Aug 2026 17:43:48 -0000	1.21
@@ -8,11 +8,11 @@
 changes_port="evbarm64"
 port_alt="arm"
 iso_image="true"
-future_rel="11.0"
-changes_future="11.0"
-cur_rel="10.1"
-changes_cur="10.0"
-pkg_rel="10.0"
+future_rel="12.0"
+changes_future="12.0"
+cur_rel="11.0"
+changes_cur="11.0"
+pkg_rel="11.0"
 about="""
 NetBSD/aarch64 is a port to Arm's 64-bit CPUs and other compatible
 machines.
Index: wikisrc/ports/acorn26.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/acorn26.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/ports/acorn26.mdwn	2 Jun 2019 13:32:38 -0000	1.18
+++ wikisrc/ports/acorn26.mdwn	1 Aug 2026 17:43:48 -0000	1.19
@@ -1,8 +1,8 @@
 [[!template id=port
 port="acorn26"
-cur_rel="8.1"
-pkg_rel="6.1"
-changes_cur="8.1"
+cur_rel="11.0"
+pkg_rel="11.0"
+changes_cur="11.0"
 thumbnail="//www.netbsd.org/images/ports/arm26/arch310.gif"
 about="""
 NetBSD/acorn26 was the port of NetBSD to ARMv2 and ARMv2a machines, primarily the
Index: wikisrc/ports/acorn32.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/acorn32.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/ports/acorn32.mdwn	15 Jan 2025 23:25:30 -0000	1.23
+++ wikisrc/ports/acorn32.mdwn	1 Aug 2026 17:43:48 -0000	1.24
@@ -1,10 +1,10 @@
 [[!template id=port
 port="acorn32"
 iso_image="true"
-cur_rel="10.1"
-future_rel="11.0"
-changes_cur="10.0"
-changes_future="11.0"
+cur_rel="11.0"
+future_rel="12.0"
+changes_cur="11.0"
+changes_future="12.0"
 thumbnail="//www.netbsd.org/images/ports/acorn32/riscpc.gif"
 about="""
 NetBSD/acorn32 is a port to ARM- and StrongARM-powered Acorn RiscPC compatible
Index: wikisrc/ports/algor.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/algor.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/ports/algor.mdwn	15 Jan 2025 23:25:30 -0000	1.28
+++ wikisrc/ports/algor.mdwn	1 Aug 2026 17:43:48 -0000	1.29
@@ -1,10 +1,10 @@
 [[!template id=port
 port="algor"
-cur_rel="10.1"
-future_rel="11.0"
-pkg_rel="9.4"
-changes_cur="10.0"
-changes_future="11.0"
+cur_rel="11.0"
+future_rel="12.0"
+pkg_rel="11.0"
+changes_cur="11.0"
+changes_future="12.0"
 thumbnail="//www.netbsd.org/images/ports/algor/alogo2.gif"
 no_install_notes="defined"
 about="""
Index: wikisrc/ports/alpha.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/alpha.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/ports/alpha.mdwn	15 Jan 2025 23:25:30 -0000	1.28
+++ wikisrc/ports/alpha.mdwn	1 Aug 2026 17:43:48 -0000	1.29
@@ -1,11 +1,11 @@
 [[!template id=port
 port="alpha"
 iso_image="true"
-cur_rel="10.1"
-pkg_rel="10.0"
-future_rel="11.0"
-changes_cur="10.0"
-changes_future="11.0"
+cur_rel="11.0"
+pkg_rel="11.0"
+future_rel="12.0"
+changes_cur="11.0"
+changes_future="12.0"
 thumbnail="//www.netbsd.org/images/ports/alpha/au-1000.gif"
 about="""
 NetBSD/alpha is a true 64-bit system that fully implements the LP64 architecture,
Index: wikisrc/ports/amd64.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amd64.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/ports/amd64.mdwn	15 Jan 2025 23:25:30 -0000	1.43
+++ wikisrc/ports/amd64.mdwn	1 Aug 2026 17:43:48 -0000	1.44
@@ -2,11 +2,11 @@
 port="amd64"
 iso_image="true"
 install_image="install"
-cur_rel="10.1"
-future_rel="11.0"
-pkg_rel="10.0"
-changes_cur="10.0"
-changes_future="11.0"
+cur_rel="11.0"
+future_rel="12.0"
+pkg_rel="11.0"
+changes_cur="11.0"
+changes_future="12.0"
 thumbnail="//www.netbsd.org/images/ports/amd64/AMD_Opteron.gif"
 about="""
 NetBSD/amd64 is a port to the AMD64 family of processors; it
Index: wikisrc/ports/amiga.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/amiga.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/ports/amiga.mdwn	15 Jan 2025 23:25:30 -0000	1.41
+++ wikisrc/ports/amiga.mdwn	1 Aug 2026 17:43:48 -0000	1.42
@@ -1,11 +1,11 @@
 [[!template id=port
 port="amiga"
 iso_image="true"

(Diff truncated)

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 20:23:20 -0000	1.49
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	1 Aug 2026 16:03:36 -0000	1.50
@@ -8,24 +8,38 @@
 in time.  If you take a snapshot of a file system, and later create a
 new file or modify an existing one or make any other changes to the
 file system, the snapshot will still have the old version of the file
-system without the changes.
+system without the changes.  A snapshot can be mounted as a file system
+to give a read-only view of a past state of the file system it's a
+snapshot of.
 
 Unlike copies, snapshots use space on disk only for data that have been
 overwritten since the snapshot was taken, and can be taken for a whole
 file system at once without any cooperation from applications to
 suspend their activity.
 
-Snapshots are often used to take backups.  For example, the
-[[!template id=man name="dump" section="8"]] tool for taking a backup
-of an ffs file system will use a snapshot with the “`-X`”
-or &ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
-sqlite3 databases aren't concurrently modified while it is trying to
-read them; without snapshots, such files can be backed up reliably only
-with application-specific cooperation like [sqlite3
-backup](https://sqlite.org/backup.html).  Snapshots can also be mounted
-like regular file systems to give read-only views of past states of
-file systems.  (See [caveat about incremental backups and
-mtimes](#caveat-mtime), though.)
+Snapshots are often used to [take backups](#snap-backups).  This
+ensures that files such as sqlite3 databases aren't concurrently
+modified while the backup is being taken.  Without snapshots, such
+files can be backed up reliably only with application-specific
+cooperation like [sqlite3 backup](https://sqlite.org/backup.html), or
+while applications are not running.  Caveats:
+
+- Snapshots don't magically make application data consistent.  If
+  interrupting an application suddenly, e.g. with SIGKILL or a
+  spontaneous system reboot, would leave corrupt application data in
+  the file system, then a snapshot taken at the same moment will also
+  have corrupt application data.
+
+  But for live applications that are resilient to interruption, such as
+  [sqlite3](https://sqlite.org/atomiccommit.html), a backup taken
+  without a snapshot may *still* corrupt their data, while a backup
+  taken with a snapshot will not.  (Taking a backup without a snapshot
+  is a [standard technique for corrupting sqlite3
+  databases](https://sqlite.org/howtocorrupt.html#_backup_or_restore_while_a_transaction_is_active)!)
+
+- Incremental backup tools that try to avoid reprocessing unchanged
+  files the next time around must [handle mtimes
+  carefully](#caveat-mtime).
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
 **persistent**: you can take a snapshot, stored in the file system
@@ -296,6 +310,7 @@
 # zfs destroy -r rpool/home@20260706
 """]]
 
+<a name="snap-backups"></a>
 ### Taking backups with snapshots
 
 A snapshot of a file system won't help you recover if the disk it is

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 15:56:00 -0000	1.48
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 20:23:20 -0000	1.49
@@ -212,7 +212,8 @@
 `<pool>/<datasetpath>@<snapname>`, and can be listed with
 &ldquo;`zfs list -t snap <pool>/<datasetpath>`&rdquo;.  Datasets can be
 rolled back to a snapshot with &ldquo;`zfs rollback`&rdquo;, or cloned
-from a snapshot with &ldquo;`zfs clone`&rdquo;.
+from a snapshot with &ldquo;`zfs clone`&rdquo;.  All snapshots in zfs
+are persistent until deleted with &ldquo;`zfs destroy`&rdquo;.
 
 The snapshots of a file system are automounted on demand as
 subdirectories of its `.zfs/snapshot/` directory, at the root of the
@@ -249,7 +250,7 @@
 # zfs rollback rpool/home/jruser@20260706
 """]]
 
-#### Discarding a persistent snapshot
+#### Discarding a snapshot
 
 When done with a snapshot, you can destroy it with
 &ldquo;`zfs destroy`&rdquo;:

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 14:57:26 -0000	1.47
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 15:56:00 -0000	1.48
@@ -438,9 +438,9 @@
 unchanged files the next time around.  Although backing up a snapshot
 rather than the live file system avoids writing corrupted live
 application data into the backup (at least from applications that can
-recover from interruption), mtime-based incremental backups may have a
-subtle race condition that can lead to data loss if you are not
-careful.
+recover from interruption), **mtime-based incremental backups may have
+a subtle race condition that can lead to data loss if you are not
+careful.**
 
 Suppose:
 
@@ -460,11 +460,11 @@
 
 The tarsnap
 &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
-option avoids this problem by treating any file with an mtime equal
-to or newer than the ctime *t* of `<reference>` as if it had an mtime
-of *t* &minus; 1 when comparing mtimes on the next run.  Other backup
-tools may have&mdash;or may not have, but may need!&mdash;similar
-options to reliably take incremental backups.
+option avoids this problem by treating any file with an mtime equal to
+or newer than the ctime *t* of `<reference>` *as if* it had an mtime of
+*t* &minus; 1 in this run when comparing mtimes on the next run.  Other
+backup tools may have&mdash;or may not have, but may
+need!&mdash;similar options to reliably take incremental backups.
 
 The [[!template id=man name="dump" section="8"]] options
 &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also avoid this

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 14:54:11 -0000	1.46
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 14:57:26 -0000	1.47
@@ -31,13 +31,13 @@
 **persistent**: you can take a snapshot, stored in the file system
 itself, and it will persist until it is explicitly deleted, even if the
 system is rebooted.  All disk-backed file systems in NetBSD, such as
-msdos and ext2fs, also support external but non-persistent snapshots.
+ext2fs and msdosfs, also support external but non-persistent snapshots.
 
 ### Persistent snapshots in ffs
 
-*Persistent snapshots are currently supported for ffs file systems
-only—not to be confused with the fss file system snapshot
-device used to manage them.*
+*Persistent snapshots with [[!template id=man name=fss section=4]] are
+currently supported for ffs file systems only—not to be confused
+with the fss file system snapshot device used to manage them.*
 
 A persistent snapshot of a file system is represented by a file inside
 the file system (with a special flag so it can't be read or written
@@ -148,24 +148,21 @@
 
 ### External snapshots with any disk-backed file system
 
-Any file system mounted from a disk device, such as ext2fs and msdosfs,
-supports snapshots with [[!template id=man name="fss" section="4"]].
-
-An external (non-persistent)
-[[!template id=man name="fss" section="4"]] snapshot of a file system
-requires a backing store *outside* the file system, where any existing
-data in the file system will be saved if later overwritten while the
-snapshot is active.  The backing store can be either a raw character
-disk device or a regular file in another file system.  Active snapshots
-are managed with the [[!template id=man name=fssconfig section=8]]
-command.
+**Any file system mounted from a disk device, such as ext2fs and
+msdosfs, supports external (non-persistent) snapshots with
+[[!template id=man name="fss" section="4"]].**  This requires a backing
+store *outside* the file system, where any existing data in the file
+system will be saved if later overwritten while the snapshot is active.
+The backing store can be either a raw character disk device or a
+regular file in another file system.  Active snapshots are managed with
+the [[!template id=man name=fssconfig section=8]] command.
 
 [[!template id=man name="fss" section="4"]] only supports file systems
 mounted from disk devices, so it does not support, for example:
 
 - memory-backed file systems such as tmpfs
 - virtual file systems such as procfs, ptyfs, or nullfs
-- zfs
+- zfs (which manages disk devices differently through zpools of vdevs)
 - nfs
 - fuse/puffs
 

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.45->1.46 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 13:18:26 -0000	1.45
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 14:54:11 -0000	1.46
@@ -33,7 +33,7 @@
 system is rebooted.  All disk-backed file systems in NetBSD, such as
 msdos and ext2fs, also support external but non-persistent snapshots.
 
-### Persistent snapshots with [[!template id=man name="fss" section="4"]]
+### Persistent snapshots in ffs
 
 *Persistent snapshots are currently supported for ffs file systems
 only—not to be confused with the fss file system snapshot
@@ -146,7 +146,7 @@
 # rm /home/.snap/20260706.store
 """]]
 
-### External snapshots with [[!template id=man name="fss" section="4"]]
+### External snapshots with any disk-backed file system
 
 Any file system mounted from a disk device, such as ext2fs and msdosfs,
 supports snapshots with [[!template id=man name="fss" section="4"]].

Members: 
	ports/xen/howto.mdwn:1.299->1.300 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.299
retrieving revision 1.300
diff -u -r1.299 -r1.300
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:06:07 -0000	1.299
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:50:30 -0000	1.300
@@ -1,5 +1,7 @@
 [[!meta title="Xen Status and HowTo"]]
 
+[[!template id=note text="[[!toc levels=2]]"]]
+
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the
 CPU, memory and console, a dom0 operating system which mediates access to
@@ -24,8 +26,6 @@
 See also an [earlier Xen tutorial](http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/)
 which should perhaps be folded into this HOWTO.
 
-[[!toc]]
-
 # Overview
 
 The basic concept of Xen is that the hypervisor (xenkernel) runs on
@@ -202,8 +202,6 @@
 [scripts to run the tests](https://ftp.netbsd.org/pub/NetBSD/misc/bouyer/nbsd-tests/)
 as a source of configuration hints.
 
-[[!template id=note text="[[!toc startlevel=2]]"]]
-
 # Creating a NetBSD dom0
 
 In order to install a NetBSD as a dom0, one first installs a normal

Members: 
	ports/xen/howto.mdwn:1.298->1.299 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.298
retrieving revision 1.299
diff -u -r1.298 -r1.299
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:04:11 -0000	1.298
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:06:07 -0000	1.299
@@ -24,7 +24,7 @@
 See also an [earlier Xen tutorial](http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/)
 which should perhaps be folded into this HOWTO.
 
-[[!template id=note text="[[!toc]]"]]
+[[!toc]]
 
 # Overview
 

Members: 
	ports/xen/howto.mdwn:1.297->1.298 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.297
retrieving revision 1.298
diff -u -r1.297 -r1.298
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:00:04 -0000	1.297
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:04:11 -0000	1.298
@@ -1,7 +1,5 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc startlevel=1 levels=1]]"]]
-
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the
 CPU, memory and console, a dom0 operating system which mediates access to
@@ -26,6 +24,8 @@
 See also an [earlier Xen tutorial](http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/)
 which should perhaps be folded into this HOWTO.
 
+[[!template id=note text="[[!toc]]"]]
+
 # Overview
 
 The basic concept of Xen is that the hypervisor (xenkernel) runs on

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.296
retrieving revision 1.297
diff -u -r1.296 -r1.297
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:32:49 -0000	1.296
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 14:00:04 -0000	1.297
@@ -1,6 +1,6 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc startlevel=1]]"]]
+[[!template id=note text="[[!toc startlevel=1 levels=1]]"]]
 
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.295
retrieving revision 1.296
diff -u -r1.295 -r1.296
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:26:36 -0000	1.295
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:32:49 -0000	1.296
@@ -1,6 +1,6 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc]]"]]
+[[!template id=note text="[[!toc startlevel=1]]"]]
 
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the

Members: 
	ports/xen/howto.mdwn:1.294->1.295 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.294
retrieving revision 1.295
diff -u -r1.294 -r1.295
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:22:44 -0000	1.294
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:26:36 -0000	1.295
@@ -1,6 +1,6 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc startlevel=0 levels=3]]"]]
+[[!template id=note text="[[!toc]]"]]
 
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.293
retrieving revision 1.294
diff -u -r1.293 -r1.294
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:19:43 -0000	1.293
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:22:44 -0000	1.294
@@ -1,6 +1,6 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc startlevel=1 levels=2]]"]]
+[[!template id=note text="[[!toc startlevel=0 levels=3]]"]]
 
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.292
retrieving revision 1.293
diff -u -r1.292 -r1.293
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:14:03 -0000	1.292
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:19:43 -0000	1.293
@@ -1,6 +1,6 @@
 [[!meta title="Xen Status and HowTo"]]
 
-[[!template id=note text="[[!toc levels=2]]"]]
+[[!template id=note text="[[!toc startlevel=1 levels=2]]"]]
 
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 05:27:39 -0000	1.44
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 13:18:26 -0000	1.45
@@ -1,3 +1,5 @@
+[[!meta title="How to use file system snapshots in NetBSD"]]
+
 [[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
 
 ### Overview

Members: 
	tutorials/kerberos_client.mdwn:1.13->1.14 
	tutorials/kerberos_realm.mdwn:1.16->1.17 
	tutorials/kerberos_services.mdwn:1.15->1.16 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/tutorials/kerberos_client.mdwn	31 Jul 2026 04:28:49 -0000	1.13
+++ wikisrc/tutorials/kerberos_client.mdwn	31 Jul 2026 13:17:56 -0000	1.14
@@ -1,6 +1,6 @@
-[[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
+[[!meta title="How to use Kerberos for single sign-on in a NetBSD client"]]
 
-## How to use Kerberos for single sign-on in a NetBSD client
+[[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
 
 Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM.
 You have a login password for the principal jruser@EXAMPLE.COM.
Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/tutorials/kerberos_realm.mdwn	31 Jul 2026 04:23:56 -0000	1.16
+++ wikisrc/tutorials/kerberos_realm.mdwn	31 Jul 2026 13:17:56 -0000	1.17
@@ -1,4 +1,4 @@
-## How to create a Kerberos realm for single sign-on running on NetBSD
+[[!meta title="How to create a Kerberos realm for single sign-on running on NetBSD"]]
 
 You want to organize your users and services into a
 [[Kerberos|kerberos]] realm to enable
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 12:56:39 -0000	1.15
+++ wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 13:17:56 -0000	1.16
@@ -1,6 +1,6 @@
-[[!template id=note text="[[!toc startlevel=3 levels=1]]"]]
+[[!meta title="How to set up Kerberos authentication in network services"]]
 
-## How to set up Kerberos authentication in network services
+[[!template id=note text="[[!toc startlevel=3 levels=1]]"]]
 
 Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM, or you
 [[set one up|tutorials/kerberos_realm]].

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.291
retrieving revision 1.292
diff -u -r1.291 -r1.292
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:11:51 -0000	1.291
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:14:03 -0000	1.292
@@ -1,5 +1,7 @@
 [[!meta title="Xen Status and HowTo"]]
 
+[[!template id=note text="[[!toc levels=2]]"]]
+
 Xen is a Type 1 hypervisor which supports running multiple guest operating
 systems on a single physical machine. One uses the Xen kernel to control the
 CPU, memory and console, a dom0 operating system which mediates access to
@@ -24,8 +26,6 @@
 See also an [earlier Xen tutorial](http://wiki.netbsd.org/tutorials/how_to_set_up_a_guest_os_using_xen3/)
 which should perhaps be folded into this HOWTO.
 
-[[!toc]]
-
 # Overview
 
 The basic concept of Xen is that the hypervisor (xenkernel) runs on
@@ -202,6 +202,8 @@
 [scripts to run the tests](https://ftp.netbsd.org/pub/NetBSD/misc/bouyer/nbsd-tests/)
 as a source of configuration hints.
 
+[[!template id=note text="[[!toc startlevel=2]]"]]
+
 # Creating a NetBSD dom0
 
 In order to install a NetBSD as a dom0, one first installs a normal

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.290
retrieving revision 1.291
diff -u -r1.290 -r1.291
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:10:53 -0000	1.290
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:11:51 -0000	1.291
@@ -1283,7 +1283,8 @@
 \# USB Mass Storage
 umass\*  at uhub? port ? configuration ? interface ?
 wd\*     at umass?
-# SCSI controllers
+<span></span>
+\# SCSI controllers
 ahc\*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
 <span></span>
 \# SCSI bus support (for both ahc and umass)

Members: 
	ports/xen/howto.mdwn:1.289->1.290 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.289
retrieving revision 1.290
diff -u -r1.289 -r1.290
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:09:32 -0000	1.289
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:10:53 -0000	1.290
@@ -339,15 +339,16 @@
 
 ### Selecting the console for the boot blocks
 
-See [[!template id=man name=boot_console section=8]].  Understand that
-you should start from a place of having the console setup correct for
-booting GENERIC before trying to configure Xen.
-
-Generally, one sets the console in bootxx_ffsv1 or equivalent, and
-this is passed on to `/boot` (where one typically does not set the
-console).  This configuration should also be in place for Xen systems,
-to allow seeing messages and typing to `/boot`.  It is necessary for
-proper booting of GENERIC as a rescue/fallback.
+See [[!template id=man name="x86/boot_console" section=8]].  Understand
+that you should start from a place of having the console setup correct
+for booting GENERIC before trying to configure Xen.
+
+Generally, one sets the console in bootxx_ffsv1 or equivalent with
+[[!template id=man name=installboot section=8]], and this is passed on
+to `/boot` (where one typically does not set the console).  This
+configuration should also be in place for Xen systems, to allow seeing
+messages and typing to `/boot`.  It is necessary for proper booting of
+GENERIC as a rescue/fallback.
 
 ### Selecting the console for Xen
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.288
retrieving revision 1.289
diff -u -r1.288 -r1.289
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:06:51 -0000	1.288
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:09:32 -0000	1.289
@@ -304,13 +304,13 @@
 pseudo-device	xenevt
 pseudo-device	xvif
 pseudo-device	xbdback
-&newline;
+<span></span>
 \# Likely only necessary if you have these devices and booting with them crashes.
 no i915drmkms\*     at pci?
 no radeon\*         at pci?
 no nouveau\*        at pci?
 no options      DRM_LEGACY
-&newline;
+<span></span>
 no options DDB_COMMANDONENTER
 \#options DDB_COMMANDONENTER="trace"
 """]]
@@ -333,7 +333,7 @@
 (because it's faster), and thus:
 
 - DOM00PS and xenevt, xvif, and xbdback will be in GENERIC
-- XEN3_DOM* kernels will be non-preferred and perhaps not used much
+- XEN3_DOM\* kernels will be non-preferred and perhaps not used much
 
 \todo Validate that these instructions are correct, and that they work.
 
@@ -642,7 +642,7 @@
 
 ## Config files
 
-See /usr/pkg/share/examples/xen/xlexample* for a very small number of
+See /usr/pkg/share/examples/xen/xlexample\* for a very small number of
 examples for running GNU/Linux.
 
 The following is an example minimal domain configuration file.  The
@@ -692,7 +692,7 @@
 
 ## Logs
 
-Look in /var/log/xen/* for logs written at creation time.
+Look in /var/log/xen/\* for logs written at creation time.
 
 ## CPU and memory
 
@@ -1198,13 +1198,13 @@
            target=/dev/zvol/rdsk/tank/foo',
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
-&newline;
+<span></span>
 vncdisplay=0
 vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"
-&newline;
+<span></span>
 boot = "d"
 """]]
 
@@ -1268,26 +1268,26 @@
 # Add support for PCI buses to the XEN3_DOMU kernel
 xpci\* at xenbus ?
 pci\* at xpci ?
-&newline;
+<span></span>
 \# PCI USB controllers
 uhci\*   at pci? dev ? function ?        # Universal Host Controller (Intel)
-&newline;
+<span></span>
 \# USB bus support
 usb\*    at uhci?
-&newline;
+<span></span>
 \# USB Hubs
 uhub\*   at usb?
 uhub\*   at uhub? port ? configuration ? interface ?
-&newline;
+<span></span>
 \# USB Mass Storage
 umass\*  at uhub? port ? configuration ? interface ?
 wd\*     at umass?
 # SCSI controllers
 ahc\*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
-&newline;
+<span></span>
 \# SCSI bus support (for both ahc and umass)
 scsibus\* at scsi?
-&newline;
+<span></span>
 \# SCSI devices
 sd\*     at scsibus? target ? lun ?      # SCSI disk drives
 cd\*     at scsibus? target ? lun ?      # SCSI CD-ROM drives

`<' -> `&lt;'
`*' -> `\*'

Members: 
	ports/xen/howto.mdwn:1.287->1.288 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.287
retrieving revision 1.288
diff -u -r1.287 -r1.288
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:01:03 -0000	1.287
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:06:51 -0000	1.288
@@ -304,22 +304,22 @@
 pseudo-device	xenevt
 pseudo-device	xvif
 pseudo-device	xbdback
-&#32;
+&newline;
 \# Likely only necessary if you have these devices and booting with them crashes.
-no i915drmkms*     at pci?
-no radeon*         at pci?
-no nouveau*        at pci?
+no i915drmkms\*     at pci?
+no radeon\*         at pci?
+no nouveau\*        at pci?
 no options      DRM_LEGACY
-&#32;
+&newline;
 no options DDB_COMMANDONENTER
 \#options DDB_COMMANDONENTER="trace"
 """]]
 
 As an alternative to disabling graphic devices in the kernel, add to /boot.cfg:
 [[!template id=filecontent name="/boot.cfg" text="""
-userconf=disable i915drmkms*
-userconf=disable nouveau*
-userconf=disable radeon*
+userconf=disable i915drmkms\*
+userconf=disable nouveau\*
+userconf=disable radeon\*
 """]]
 
 Then, create a copy of the boot line, adding `dom0=pvh` near
@@ -366,7 +366,7 @@
 
 When Xen uses a serial console, it manages the serial port and, after
 booting, forwards it it to the dom0's xencons(4) device.  An exception
-is that when Xen receives the "comswitch" character (<CTRL-A> by
+is that when Xen receives the "comswitch" character (&lt;CTRL-A> by
 default) three times in quick succession, it will take over serial I/O
 until three more presses.  Xen console interactions can be used for
 various debugging features which are not usually present in the
@@ -1083,7 +1083,7 @@
 wdc1 at isa0 port 0x170-0x177 irq 15
 atabus0 at wdc1 channel 0
 atapibus0 at atabus0: 2 targets
-cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.5+> cdrom removable
+cd0 at atapibus0 drive 0: &lt;QEMU DVD-ROM, QM00003, 2.5+> cdrom removable
 cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
 """]]
 
@@ -1091,7 +1091,7 @@
 wdc0 at isa0 port 0x1f0-0x1f7 irq 14
 atabus0 at wdc0 channel 0
 wd0 at atabus0 drive 0
-wd0: <ST506>
+wd0: &lt;ST506>
 wd0: drive supports 1-sector PIO transfers, chs addressing
 wd0: 69632 KB, 1024 cyl, 8 head, 17 sec, 512 bytes/sect x 139264 sectors
 """]]
@@ -1147,7 +1147,7 @@
 """]]
 
 does matter to Linux. It wants a Linux device number here (e.g. 0x300
-for hda).  Linux builds device numbers as: (major << 8 + minor).
+for hda).  Linux builds device numbers as: (major &lt;&lt; 8 + minor).
 So, hda1 which has major 3 and minor 1 on a Linux system will have
 device number 0x301.  Alternatively, devices names can be used (hda,
 hdb, ...)  as xentools has a table to map these names to devices
@@ -1198,13 +1198,13 @@
            target=/dev/zvol/rdsk/tank/foo',
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
-&#32;
+&newline;
 vncdisplay=0
 vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"
-&#32;
+&newline;
 boot = "d"
 """]]
 
@@ -1266,31 +1266,31 @@
 
 [[!template id=filecontent name="XEN3_DOMU.local" text="""
 # Add support for PCI buses to the XEN3_DOMU kernel
-xpci* at xenbus ?
-pci* at xpci ?
-&#32;
+xpci\* at xenbus ?
+pci\* at xpci ?
+&newline;
 \# PCI USB controllers
-uhci*   at pci? dev ? function ?        # Universal Host Controller (Intel)
-&#32;
+uhci\*   at pci? dev ? function ?        # Universal Host Controller (Intel)
+&newline;
 \# USB bus support
-usb*    at uhci?
-&#32;
+usb\*    at uhci?
+&newline;
 \# USB Hubs
-uhub*   at usb?
-uhub*   at uhub? port ? configuration ? interface ?
-&#32;
+uhub\*   at usb?
+uhub\*   at uhub? port ? configuration ? interface ?
+&newline;
 \# USB Mass Storage
-umass*  at uhub? port ? configuration ? interface ?
-wd*     at umass?
+umass\*  at uhub? port ? configuration ? interface ?
+wd\*     at umass?
 # SCSI controllers
-ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
-&#32;
+ahc\*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
+&newline;
 \# SCSI bus support (for both ahc and umass)
-scsibus* at scsi?
-&#32;
+scsibus\* at scsi?
+&newline;
 \# SCSI devices
-sd*     at scsibus? target ? lun ?      # SCSI disk drives
-cd*     at scsibus? target ? lun ?      # SCSI CD-ROM drives
+sd\*     at scsibus? target ? lun ?      # SCSI disk drives
+cd\*     at scsibus? target ? lun ?      # SCSI CD-ROM drives
 """]]
 
 # Miscellaneous Information

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.286
retrieving revision 1.287
diff -u -r1.286 -r1.287
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:50:18 -0000	1.286
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 13:01:03 -0000	1.287
@@ -304,13 +304,13 @@
 pseudo-device	xenevt
 pseudo-device	xvif
 pseudo-device	xbdback
- 
+ 
 \# Likely only necessary if you have these devices and booting with them crashes.
 no i915drmkms*     at pci?
 no radeon*         at pci?
 no nouveau*        at pci?
 no options      DRM_LEGACY
- 
+ 
 no options DDB_COMMANDONENTER
 \#options DDB_COMMANDONENTER="trace"
 """]]
@@ -1198,13 +1198,13 @@
            target=/dev/zvol/rdsk/tank/foo',
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
-\ 
+ 
 vncdisplay=0
 vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"
-\ 
+ 
 boot = "d"
 """]]
 
@@ -1268,26 +1268,26 @@
 # Add support for PCI buses to the XEN3_DOMU kernel
 xpci* at xenbus ?
 pci* at xpci ?
-\ 
+ 
 \# PCI USB controllers
 uhci*   at pci? dev ? function ?        # Universal Host Controller (Intel)
-\ 
+ 
 \# USB bus support
 usb*    at uhci?
-\ 
+ 
 \# USB Hubs
 uhub*   at usb?
 uhub*   at uhub? port ? configuration ? interface ?
-\ 
+ 
 \# USB Mass Storage
 umass*  at uhub? port ? configuration ? interface ?
 wd*     at umass?
 # SCSI controllers
 ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
-\ 
+ 
 \# SCSI bus support (for both ahc and umass)
 scsibus* at scsi?
-\ 
+ 
 \# SCSI devices
 sd*     at scsibus? target ? lun ?      # SCSI disk drives
 cd*     at scsibus? target ? lun ?      # SCSI CD-ROM drives

Members: 
	tutorials/kerberos_services.mdwn:1.14->1.15 

Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 04:28:49 -0000	1.14
+++ wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 12:56:39 -0000	1.15
@@ -24,9 +24,9 @@
    realm name).
 
 2. **Get a keytab for the service principal** from the Kerberos KDC
-   using [[!template id=man name="kadmin" section="8"]]:
-   first `kadmin add` to generate a key for the service principal in
-   the KDC database, and then `kadmin ext` to extract it into a keytab.
+   using [[!template id=man name="kadmin" section="8"]] commands:
+   first “`add`” to generate a key for the service principal in the KDC
+   database, and then “`ext`” to extract it into a keytab.
 
    The key is a secret shared between the service and the KDC.
    Anyone who knows the key can spoof the service, so you must keep
@@ -34,8 +34,8 @@
 
    You can run
    [[!template id=man name="kadmin" section="8"]]
-   on the KDC itself with `kadmin -l` (`kadmin --local`), or you can
-   configure
+   on the KDC itself with “`kadmin -l`”
+   (“`kadmin --local`”), or you can configure
    [[!template id=man name="kadmind" section="8"]]
    on the KDC and run
    [[!template id=man name="kadmin" section="8"]]
@@ -78,20 +78,16 @@
    keytab:
 
    [[!template id=programlisting text="""
-# kadmin add --random-key --max-ticket-life=unlimited \
-       --max-renewable-life=unlimited --use-defaults \
-       imap/imap.example.com
-# kadmin add --random-key --max-ticket-life=unlimited \
-       --max-renewable-life=unlimited --use-defaults \
-       pop/pop.example.com
-# kadmin add --random-key --max-ticket-life=unlimited \
-       --max-renewable-life=unlimited --use-defaults \
-       smtp/mail.example.com
 # mkdir -m 0700 /usr/pkg/etc/dovecot/private
 # cd /usr/pkg/etc/dovecot/private
-# kadmin ext -k keytab imap/imap.example.com
-# kadmin ext -k keytab pop/pop.example.com
-# kadmin ext -k keytab smtp/mail.example.com
+# kadmin
+kadmin> add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --use-defaults imap/imap.example.com
+kadmin> add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --use-defaults pop/pop.example.com
+kadmin> add --random-key --max-ticket-life=unlimited --max-renewable-life=unlimited --use-defaults smtp/mail.example.com
+kadmin> ext -k keytab imap/imap.example.com
+kadmin> ext -k keytab pop/pop.example.com
+kadmin> ext -k keytab smtp/mail.example.com
+kadmin> ^D
 # chown dovecot:dovecot . keytab
 """]]
 
@@ -129,7 +125,7 @@
 [[!template id=filecontent name="/usr/pkg/etc/dovecot/local.conf" text="""
 protocols =
 service auth {
-    unix_listener /var/spool/postfix/private/auth {
+    unix_listener /var/spool/postfix/private/dovecot-auth {
         mode = 0660
         user = postfix
         group = postfix
@@ -147,7 +143,7 @@
    ([[!template id=man name="postconf" section="5"]]):
 
    [[!template id=filecontent name="/etc/postfix/main.cf" text="""
-smtpd_sasl_path = private/auth
+smtpd_sasl_path = private/dovecot-auth
 smtpd_sasl_type = dovecot
 """]]
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.285
retrieving revision 1.286
diff -u -r1.285 -r1.286
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:46:29 -0000	1.285
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:50:18 -0000	1.286
@@ -304,15 +304,15 @@
 pseudo-device	xenevt
 pseudo-device	xvif
 pseudo-device	xbdback
-
-# Likely only necessary if you have these devices and booting with them crashes.
+ 
+\# Likely only necessary if you have these devices and booting with them crashes.
 no i915drmkms*     at pci?
 no radeon*         at pci?
 no nouveau*        at pci?
 no options      DRM_LEGACY
-
+ 
 no options DDB_COMMANDONENTER
-#options DDB_COMMANDONENTER="trace"
+\#options DDB_COMMANDONENTER="trace"
 """]]
 
 As an alternative to disabling graphic devices in the kernel, add to /boot.cfg:
@@ -1198,13 +1198,13 @@
            target=/dev/zvol/rdsk/tank/foo',
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
- 
+\ 
 vncdisplay=0
 vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"
- 
+\ 
 boot = "d"
 """]]
 
@@ -1268,26 +1268,26 @@
 # Add support for PCI buses to the XEN3_DOMU kernel
 xpci* at xenbus ?
 pci* at xpci ?
- 
+\ 
 \# PCI USB controllers
 uhci*   at pci? dev ? function ?        # Universal Host Controller (Intel)
- 
+\ 
 \# USB bus support
 usb*    at uhci?
- 
+\ 
 \# USB Hubs
 uhub*   at usb?
 uhub*   at uhub? port ? configuration ? interface ?
- 
+\ 
 \# USB Mass Storage
 umass*  at uhub? port ? configuration ? interface ?
 wd*     at umass?
 # SCSI controllers
 ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
- 
+\ 
 \# SCSI bus support (for both ahc and umass)
 scsibus* at scsi?
- 
+\ 
 \# SCSI devices
 sd*     at scsibus? target ? lun ?      # SCSI disk drives
 cd*     at scsibus? target ? lun ?      # SCSI CD-ROM drives

Members: 
	ports/xen/howto.mdwn:1.284->1.285 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.284
retrieving revision 1.285
diff -u -r1.284 -r1.285
--- wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:40:31 -0000	1.284
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:46:29 -0000	1.285
@@ -782,7 +782,7 @@
 [[!template id=filecontent name="/usr/pkg/etc/xen/foo" text="""
 # Newer key/value format:
 disk = [ 'format=raw, vdev=hdc, devtype=cdrom, access=ro, target=/n0/xen/iso/NetBSD-10.1_STABLE-amd64.iso' ]
-# Older positional format:
+\# Older positional format:
 disk = [ 'file:/n0/xen/iso/NetBSD-10.1_STABLE-amd64.iso,hdc:cdrom,r' ]
 """]]
 
@@ -1198,13 +1198,13 @@
            target=/dev/zvol/rdsk/tank/foo',
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
-
+ 
 vncdisplay=0
 vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"
-
+ 
 boot = "d"
 """]]
 
@@ -1268,27 +1268,27 @@
 # Add support for PCI buses to the XEN3_DOMU kernel
 xpci* at xenbus ?
 pci* at xpci ?
-
-# PCI USB controllers
+ 
+\# PCI USB controllers
 uhci*   at pci? dev ? function ?        # Universal Host Controller (Intel)
-
-# USB bus support
+ 
+\# USB bus support
 usb*    at uhci?
-
-# USB Hubs
+ 
+\# USB Hubs
 uhub*   at usb?
 uhub*   at uhub? port ? configuration ? interface ?
-
-# USB Mass Storage
+ 
+\# USB Mass Storage
 umass*  at uhub? port ? configuration ? interface ?
 wd*     at umass?
 # SCSI controllers
 ahc*    at pci? dev ? function ?        # Adaptec [23]94x, aic78x0 SCSI
-
-# SCSI bus support (for both ahc and umass)
+ 
+\# SCSI bus support (for both ahc and umass)
 scsibus* at scsi?
-
-# SCSI devices
+ 
+\# SCSI devices
 sd*     at scsibus? target ? lun ?      # SCSI disk drives
 cd*     at scsibus? target ? lun ?      # SCSI CD-ROM drives
 """]]

Members: 
	ports/xen/howto.mdwn:1.283->1.284 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.283
retrieving revision 1.284
diff -u -r1.283 -r1.284
--- wikisrc/ports/xen/howto.mdwn	22 Jul 2026 11:32:05 -0000	1.283
+++ wikisrc/ports/xen/howto.mdwn	31 Jul 2026 12:40:31 -0000	1.284
@@ -246,9 +246,10 @@
 options](https://xenbits.xenproject.org/docs/4.18-testing/misc/xen-command-line.html)
 documentation.
 
-Read boot.cfg(8) carefully.  Add lines to /boot.cfg to boot Xen,
-adjusting for your root filesystem (if you installed with GPT partitioning,
-your root filesystem is likely to be /dev/dk0):
+Read [[!template id=man name="boot.cfg" section=8]] carefully.  Add
+lines to `/boot.cfg` to boot Xen, adjusting for your root filesystem
+(if you installed with GPT partitioning, your root filesystem is likely
+to be `/dev/dk0`):
 
 [[!template id=filecontent name="/boot.cfg" text="""
 menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=wd0a console=pc;multiboot /xen.gz dom0_mem=1024M
@@ -282,8 +283,8 @@
 
 A PVH dom0 is currently experimental, as of Xen 4.18.  For 4.19 and
 later, not yet in pkgsrc, it is
-[supported](https://xenbits.xen.org/docs/unstable/support-matrix.html
-) with
+[supported](https://xenbits.xen.org/docs/unstable/support-matrix.html)
+with
 [caveats](https://xenbits.xen.org/docs/4.19-testing/SUPPORT.html#x86pvh),
 notably that SR-IOV is missing and PCI passthrough does not work.
 
@@ -298,7 +299,7 @@
 Prepare a GENERIC kernel with the additions necessary to be a DOM0,
 which consists of code to deal with DOM0 requests, and PV drivers for
 the dom0 part of events, network interfaces, and disks.
-[[!template id=programlisting text="""
+[[!template id=filecontent name="GENERIC.local" text="""
 options		DOM0OPS
 pseudo-device	xenevt
 pseudo-device	xvif
@@ -315,7 +316,7 @@
 """]]
 
 As an alternative to disabling graphic devices in the kernel, add to /boot.cfg:
-[[!template id=programlisting text="""
+[[!template id=filecontent name="/boot.cfg" text="""
 userconf=disable i915drmkms*
 userconf=disable nouveau*
 userconf=disable radeon*
@@ -329,22 +330,23 @@
 fine on bare metal and, if not, it's a bug -- but so far we have no
 reports either way.  In the glorious future, it will be normal to run
 a dom0 as PVH (because it's faster), and to run a domU as PVH or PVHVM
-(because it's faster), and thus: - DOM00PS and xenevt, xvif, and
-xbdback will be in GENERIC - XEN3_DOM* kernels will be non-preferred
-and perhaps not used much
+(because it's faster), and thus:
+
+- DOM00PS and xenevt, xvif, and xbdback will be in GENERIC
+- XEN3_DOM* kernels will be non-preferred and perhaps not used much
 
 \todo Validate that these instructions are correct, and that they work.
 
 ### Selecting the console for the boot blocks
 
-See boot_console(8).  Understand that you should start from a place of
-having the console setup correct for booting GENERIC before trying to
-configure Xen.
+See [[!template id=man name=boot_console section=8]].  Understand that
+you should start from a place of having the console setup correct for
+booting GENERIC before trying to configure Xen.
 
 Generally, one sets the console in bootxx_ffsv1 or equivalent, and
-this is passed on to /boot (where one typically does not set the
+this is passed on to `/boot` (where one typically does not set the
 console).  This configuration should also be in place for Xen systems,
-to allow seeing messages and typing to /boot.  It is necessary for
+to allow seeing messages and typing to `/boot`.  It is necessary for
 proper booting of GENERIC as a rescue/fallback.
 
 ### Selecting the console for Xen
@@ -368,7 +370,7 @@
 default) three times in quick succession, it will take over serial I/O
 until three more presses.  Xen console interactions can be used for
 various debugging features which are not usually present in the
-default /xen kernel (the xenkernel package also includes a xen-debug kernel).
+default `/xen` kernel (the xenkernel package also includes a xen-debug kernel).
 
 When Xen uses vga as a console, the vga console is relinquished at the
 conclusion of hypervisor boot, before the dom0 is started.  See also
@@ -380,16 +382,17 @@
 menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1
 """]]
 
-On Xen's console, one can type the escape character (default ^A) three
-times to switch input from Xen to the dom0.  (See ddb(4) for how to
-get into DDB, which differs from non-Xen amd64.)
+On Xen's console, one can type the escape character (default `^A`)
+three times to switch input from Xen to the dom0.  (See
+[[!template id=man name=ddb section=4]] for how to get into DDB, which
+differs from non-Xen amd64.)
 \todo Xen's vga console is probably output only, but this needs clarifying.
 
 The default serial console speed may depend on whether the whether the
 bootloader or earlier firmware has already set it up. To be certain,
 the desired speed can be specified with the com1= boot command. For example,
 the following configures use of serial console with the speed explicitly
-set to 115200
+set to 115200:
 [[!template id=filecontent name="/boot.cfg" text="""
 menu=Xen:load /netbsd-XEN3_DOM0.gz rndseed=/var/db/entropy-file bootdev=sd0; multiboot /xen.gz dom0_mem=1024M console=com1 com1=115200,8n1
 """]]
@@ -659,9 +662,10 @@
 various domUs independently.  The `vif` line causes an interface to be
 provided, with a specific mac address (do not reuse MAC addresses!),
 in bridge mode.  Two disks are provided, and they are both writable;
-the bits are stored in files and Xen attaches them to a vnd(4) device
-in the dom0 on domain creation.  The system treats xbd0 as the boot
-device without needing explicit configuration.
+the bits are stored in files and Xen attaches them to a
+[[!template id=man name=vnd section=4]] device in the dom0 on domain
+creation.  The system treats xbd0 as the boot device without needing
+explicit configuration.
 
 There is not a type line; that implicitly defines a pv domU.
 Otherwise, one sets type to the lower-case version of the domU type in
@@ -735,7 +739,7 @@
 """]]
 
 The vdev field can be 0x0 in PV mode but must be something like
-hda in HVM mode. Leaving as 0x0 will generate a warning such as 
+hda in HVM mode. Leaving as 0x0 will generate a warning such as
 'unable to determine disk number for 0x0'
 
 For key-value pairs:
@@ -866,9 +870,9 @@
 See [Xen's Booting Overview](https://wiki.xenproject.org/wiki/Booting_Overview).
 and the more detailed [pvgrub2 page](https://wiki.xenproject.org/wiki/PvGrub2).
 
-See [Debian's pvgrub page](https://wiki.debian.org/PvGrub). 
+See [Debian's pvgrub page](https://wiki.debian.org/PvGrub).
 
-For information about how specific provider's address booting,  
+For information about how specific provider's address booting,
 see the sections below about Panix and Tornado VPS.
 See also [Bitfolk's Booting page](https://tools.bitfolk.com/wiki/Booting).
 
@@ -903,8 +907,8 @@
 The kernel must be specifically built for Xen, to use PV interfaces as
 a domU.  NetBSD release builds provide the following kernels:
 
-        i386 XEN3PAE_DOMU
-        amd64 XEN3_DOMU
+- i386: XEN3PAE_DOMU
+- amd64: XEN3_DOMU
 
 This will boot NetBSD, but this is not that useful if the disk is
 empty.  One approach is to unpack sets onto the disk outside of Xen
@@ -915,14 +919,18 @@
 and can load sets from the network.  To do this, copy the INSTALL
 kernel to / and change the kernel line in the config file to:
 
-        kernel = "/netbsd-INSTALL_XEN3_DOMU"
+[[!template id=filecontent name="/usr/pkg/etc/xen/foo" text="""
+kernel = "/netbsd-INSTALL_XEN3_DOMU"
+"""]]
 
-Then, start the domain as "xl create -c configfile".
+Then, start the domain as "xl create -c foo".
 
 Alternatively, if you want to install NetBSD/Xen with a physical
 CDROM, the following line should be used in the config file.
 
-    disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ]
+[[!template id=filecontent name="/usr/pkg/etc/xen/foo" text="""
+disk = [ 'phy:/dev/wd0e,0x1,w', 'phy:/dev/cd0a,0x2,r' ]
+"""]]
 
 After booting the domain, the option to install via CDROM may be
 selected.  The CDROM device should be changed to `xbd1d`.
@@ -939,11 +947,13 @@
 `/etc/ttys` and `/etc/wscons.conf`. You must disable all terminals in
 `/etc/ttys`, except *console*, like this:
 
-    console "/usr/libexec/getty Pc"         vt100   on secure
-    ttyE0   "/usr/libexec/getty Pc"         vt220   off secure
-    ttyE1   "/usr/libexec/getty Pc"         vt220   off secure
-    ttyE2   "/usr/libexec/getty Pc"         vt220   off secure
-    ttyE3   "/usr/libexec/getty Pc"         vt220   off secure
+[[!template id=filecontent name="/etc/ttys" text="""
+console "/usr/libexec/getty Pc"         vt100   on secure
+ttyE0   "/usr/libexec/getty Pc"         vt220   off secure
+ttyE1   "/usr/libexec/getty Pc"         vt220   off secure
+ttyE2   "/usr/libexec/getty Pc"         vt220   off secure
+ttyE3   "/usr/libexec/getty Pc"         vt220   off secure

(Diff truncated)

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 05:22:47 -0000	1.43
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 05:27:39 -0000	1.44
@@ -308,19 +308,6 @@
   content of the snapshot.  The content can later be restored with the
   [[!template id=man name=restore section=8]] tool.
 
-  By default, any user in the “`operator`” group (see
-  [[!template id=man name=groups]]) can configure snapshots, read disk
-  devices, and write to tape devices to take backups—this way
-  backups can be taken without root privileges.  However, since
-  “`dump -X ... /fs`” requires creating a snapshot backing
-  store at `/fs/<tempfile>`, running command such as
-  &ldquo;`dump -X ... /`&rdquo; or &ldquo;`dump -X ... /usr`&rdquo;
-  unprivileged will fail because `/` and `/usr` are writable only by
-  root.  Instead, you can create a directory `/operator` that group
-  &ldquo;`operator`&rdquo; can write to, and use
-  &ldquo;`dump -x /operator/ ... /`&rdquo; to create the snapshot file
-  for `/` at `/operator/<tempfile>`.
-
 - **For lfs**, the [[!template id=man name=dump_lfs section=8]] tool
   supports an option &ldquo;`-X`&rdquo; to dump a snapshot of the file
   system.  (However, lfs does not support persistent snapshots, nor
@@ -347,6 +334,24 @@
 
 These tools can be used on any mounted snapshot.
 
+#### Unprivileged snapshots and backups
+
+By default, any user in the &ldquo;`operator`&rdquo; group (see
+[[!template id=man name=groups section=7]]) can configure
+[[!template id=man name=fss section=4]] snapshots, read disk devices,
+and write to tape devices to take backups&mdash;this way backups can be
+taken without root privileges, at least for some file systems like ffs
+and lfs.
+
+However, since &ldquo;`dump -X ... /fs`&rdquo; requires creating a
+snapshot backing store at `/fs/<tempfile>`, running commands such as
+&ldquo;`dump -X ... /`&rdquo; or &ldquo;`dump -X ... /usr`&rdquo;
+unprivileged will fail because `/` and `/usr` are writable only by
+root.  Instead, you can create a directory `/operator` that group
+&ldquo;`operator`&rdquo; can write to, and use
+&ldquo;`dump -x /operator/ ... /`&rdquo; to create the snapshot file
+for `/` at `/operator/<tempfile>`.
+
 #### Example: tar
 
 Mount a persistent snapshot of `/home` and back it up with

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:53:58 -0000	1.42
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 05:22:47 -0000	1.43
@@ -18,9 +18,12 @@
 of an ffs file system will use a snapshot with the “`-X`”
 or &ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
 sqlite3 databases aren't concurrently modified while it is trying to
-read them.  Snapshots can also be mounted like regular file systems to
-give read-only views of past states of file systems.  (See [caveat
-about incremental backups and mtimes](#caveat-mtime), though.)
+read them; without snapshots, such files can be backed up reliably only
+with application-specific cooperation like [sqlite3
+backup](https://sqlite.org/backup.html).  Snapshots can also be mounted
+like regular file systems to give read-only views of past states of
+file systems.  (See [caveat about incremental backups and
+mtimes](#caveat-mtime), though.)
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
 **persistent**: you can take a snapshot, stored in the file system
@@ -383,7 +386,7 @@
 haven't changed the last time.  The &ldquo;`--snaptime`&rdquo; argument
 gives a file whose ctime must predate the snapshot; see
 [caveat about mtime](#caveat-mtime) below for why this is necessary to
-avoid losing data in later incremental backups.
+avoid data loss in later incremental backups.
 
 #### Example: borgbackup
 
@@ -397,7 +400,7 @@
 """]]
 
 **WARNING: If used to take incremental backups, this may be vulnerable
-to a race condition with mtime checks; see
+to data loss with naive mtime checks; see
 [caveat about mtime](#caveat-mtime) below.**
 
 #### Example: rsync
@@ -420,35 +423,44 @@
 while the snapshot is active, and then discard it as soon as it is
 unconfigured.
 
-**WARNING: If used to take incremental backups, this may be vulnerable
-to a race condition with mtime checks; see
-[caveat about mtime](#caveat-mtime) below.**
+**WARNING: This may be vulnerable to data loss with naive mtime checks;
+see [caveat about mtime](#caveat-mtime) below.**
 
 <a name="caveat-mtime"></a>
 ### Caveat: Incremental backups and mtimes
 
-An incremental backup tool such as tarsnap, borg, or rsync which backs
-up the snapshot and records mtimes to avoid reprocessing unchanged
-files the next time around may have a subtle race condition that can
-lead to data loss if you are not careful.  Suppose:
+Some incremental backup tools such as tarsnap, borg, or rsync will
+record the mtimes of files they have backed up to avoid reprocessing
+unchanged files the next time around.  Although backing up a snapshot
+rather than the live file system avoids writing corrupted live
+application data into the backup (at least from applications that can
+recover from interruption), mtime-based incremental backups may have a
+subtle race condition that can lead to data loss if you are not
+careful.
+
+Suppose:
 
 1. A file is modified at time *t* + 0.1sec.
-2. The snapshot is taken at time *t* + 0.2sec and backed up.
+2. A snapshot is taken at time *t* + 0.2sec and backed up.
 3. The file is modified again at time *t* + 0.3sec.
 
 In this case, the file's mtime before the snapshot and after the
-snapshot may both be rounded down by the tool to just a number of
-seconds *t* since the epoch.  **The next time the tool runs, it may
-conclude the file was unchanged since the last run, and *lose the second
-modification*.**
+snapshot may both be rounded down&mdash;whether by the file system, by
+the backup tool, or by the backup archive format&mdash;to just a number
+of seconds *t* since the epoch.  **The next time the tool runs, it may
+conclude the file was unchanged since the last run, and *lose the
+second modification*.**  (Of course, in this scenario, trying to back
+up the live file system instead of a snapshot may lead to the even
+worse outcome of storing a corrupted file with some garbled mixture of
+the modifications instead!)
 
 The tarsnap
 &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
 option avoids this problem by treating any file with an mtime equal
 to or newer than the ctime *t* of `<reference>` as if it had an mtime
 of *t* &minus; 1 when comparing mtimes on the next run.  Other backup
-tools may have&mdash;or may need&mdash;similar options to reliably take
-incremental backups with snapshots.
+tools may have&mdash;or may not have, but may need!&mdash;similar
+options to reliably take incremental backups.
 
 The [[!template id=man name="dump" section="8"]] options
 &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also avoid this

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:49:58 -0000	1.41
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:53:58 -0000	1.42
@@ -19,8 +19,8 @@
 or &ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
 sqlite3 databases aren't concurrently modified while it is trying to
 read them.  Snapshots can also be mounted like regular file systems to
-give read-only views of past states of file systems.  (See [caveats
-about taking incremental backups and mtimes](#caveat-mtime), though.)
+give read-only views of past states of file systems.  (See [caveat
+about incremental backups and mtimes](#caveat-mtime), though.)
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
 **persistent**: you can take a snapshot, stored in the file system
@@ -381,8 +381,9 @@
 Tarsnap takes incremental backups and caches the mtimes of files each
 time it runs in order to avoid spending time processing files that
 haven't changed the last time.  The &ldquo;`--snaptime`&rdquo; argument
-gives a file whose ctime must predate the snapshot; see below for why
-this is necessary to avoid losing data in later incremental backups.
+gives a file whose ctime must predate the snapshot; see
+[caveat about mtime](#caveat-mtime) below for why this is necessary to
+avoid losing data in later incremental backups.
 
 #### Example: borgbackup
 
@@ -396,7 +397,8 @@
 """]]
 
 **WARNING: If used to take incremental backups, this may be vulnerable
-to a race condition with mtime checks; see below.**
+to a race condition with mtime checks; see
+[caveat about mtime](#caveat-mtime) below.**
 
 #### Example: rsync
 
@@ -419,14 +421,16 @@
 unconfigured.
 
 **WARNING: If used to take incremental backups, this may be vulnerable
-to a race condition with mtime checks; see below.**
+to a race condition with mtime checks; see
+[caveat about mtime](#caveat-mtime) below.**
 
 <a name="caveat-mtime"></a>
 ### Caveat: Incremental backups and mtimes
 
 An incremental backup tool such as tarsnap, borg, or rsync which backs
 up the snapshot and records mtimes to avoid reprocessing unchanged
-files the next time around may have a subtle race condition.  Suppose:
+files the next time around may have a subtle race condition that can
+lead to data loss if you are not careful.  Suppose:
 
 1. A file is modified at time *t* + 0.1sec.
 2. The snapshot is taken at time *t* + 0.2sec and backed up.

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:46:42 -0000	1.40
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:49:58 -0000	1.41
@@ -266,8 +266,9 @@
 **WARNING: If you enter the command before you finished typing, you
 might accidentally destroy the file system instead of just a
 snapshot!**
-[[!template id=man name=zfs section=8]] uses the same “`zfs
-destroy`” for destroying file systems, zvols, and snapshots.
+[[!template id=man name=zfs section=8]] uses the same
+“`zfs destroy`” command for destroying file systems, zvols,
+and snapshots.
 
 One technique to avoid this mistake is to start by typing
 “`xxxzfs`” instead of “`zfs`” so if you enter
@@ -280,7 +281,7 @@
 -sh: xxxzfs: not found
 """]]
 
-Or start by typing “`echo zfs`&rdqou; instead of
+Or start by typing “`echo zfs`” instead of
 “`zfs`”, or use “`zfs destroy -n`”, especially
 if you are running a loop over many different snapshot names, to review
 what you *would* do.

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:43:42 -0000	1.39
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:46:42 -0000	1.40
@@ -65,10 +65,10 @@
 # mount /dev/fss0 /home/.snap/20260706
 """]]
 
-Users can then browse their home directories in `/home/.snap` as they
-existed at the time the snapshot was taken.  There's nothing special
-about the directory name `.snap`; you can store snapshots anywhere in
-the file system.
+Users can then browse their home directories in `/home/.snap/20260706`
+as they existed at the time the snapshot was taken.  There's nothing
+special about the directory name `.snap`; you can store snapshots
+anywhere inside the file system, and mount them anywhere at all.
 
 Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag, visible
 with the [[!template id=man name=ls section=1]] option

- Explain how to destroy a zfs snapshot, and suggest ways to make
  sure mistakes in the command don't destroy your whole zfs file
  system.

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.38->1.39 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:12:16 -0000	1.38
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:43:42 -0000	1.39
@@ -19,7 +19,8 @@
 or &ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
 sqlite3 databases aren't concurrently modified while it is trying to
 read them.  Snapshots can also be mounted like regular file systems to
-give read-only views of past states of file systems.
+give read-only views of past states of file systems.  (See [caveats
+about taking incremental backups and mtimes](#caveat-mtime), though.)
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
 **persistent**: you can take a snapshot, stored in the file system
@@ -246,6 +247,51 @@
 # zfs rollback rpool/home/jruser@20260706
 """]]
 
+#### Discarding a persistent snapshot
+
+When done with a snapshot, you can destroy it with
+&ldquo;`zfs destroy`&rdquo;:
+
+[[!template id=programlisting text="""
+# zfs destroy rpool/home/jruser@20260706
+"""]]
+
+You can also recursively destroy all snapshots of the same name on
+datasets under a path:
+
+[[!template id=programlisting text="""
+# zfs destroy -r rpool/home/jruser@20260706
+"""]]
+
+**WARNING: If you enter the command before you finished typing, you
+might accidentally destroy the file system instead of just a
+snapshot!**
+[[!template id=man name=zfs section=8]] uses the same &ldquo;`zfs
+destroy`&rdquo; for destroying file systems, zvols, and snapshots.
+
+One technique to avoid this mistake is to start by typing
+&ldquo;`xxxzfs`&rdquo; instead of &ldquo;`zfs`&rdquo; so if you enter
+the command too early, it will fail harmlessly:
+
+[[!template id=programlisting text="""
+# xxxzfs destroy -r rpool/home
+-sh: xxxzfs: not found
+# xxxzfs destroy -r rpool/home@20260706
+-sh: xxxzfs: not found
+"""]]
+
+Or start by typing &ldquo;`echo zfs`&rdqou; instead of
+&ldquo;`zfs`&rdquo;, or use &ldquo;`zfs destroy -n`&rdquo;, especially
+if you are running a loop over many different snapshot names, to review
+what you *would* do.
+
+Then, once you have finished typing the whole command, go back to the
+beginning of the line and remove the `xxx`:
+
+[[!template id=programlisting text="""
+# zfs destroy -r rpool/home@20260706
+"""]]
+
 ### Taking backups with snapshots
 
 A snapshot of a file system won't help you recover if the disk it is
@@ -374,6 +420,7 @@
 **WARNING: If used to take incremental backups, this may be vulnerable
 to a race condition with mtime checks; see below.**
 
+<a name="caveat-mtime"></a>
 ### Caveat: Incremental backups and mtimes
 
 An incremental backup tool such as tarsnap, borg, or rsync which backs

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/tutorials/kerberos_client.mdwn	31 Jul 2026 04:22:37 -0000	1.12
+++ wikisrc/tutorials/kerberos_client.mdwn	31 Jul 2026 04:28:49 -0000	1.13
@@ -1,4 +1,4 @@
-[[!template id=note text="[[!toc startlevel=3 levels=1]]"]]
+[[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
 
 ## How to use Kerberos for single sign-on in a NetBSD client
 
@@ -6,6 +6,8 @@
 You have a login password for the principal jruser@EXAMPLE.COM.
 How do you log in and authenticate to services?
 
+### Set up Kerberos and get a ticket
+
 1. Create a directory ~/.krb5 and a file ~/.krb5/config with the
    following content to enable Kerberos on the client side:
 
@@ -82,7 +84,9 @@
      Make sure to set `[libdefaults] dns_lookup_realm = false` in each
      config file too in this case.
 
-### ssh
+### Applications
+
+#### ssh
 
 To enable [[!template id=man name="ssh" section="1"]] to use Kerberos
 authentication when logging into any host under *.example.com, add the
@@ -109,7 +113,7 @@
 Now run kerberized applications on foo.example.com through ssh without
 a password!
 
-### Firefox
+#### Firefox
 
 To log into kerberized web sites at `https://*.example.com/`:
 
@@ -131,7 +135,7 @@
 
 - This is restricted to HTTPS, and will not work with HTTP sites.
 
-### Kerberos for local login
+#### Kerberos for local login
 
 To use Kerberos for local logins, e.g. at the console or in a display
 manager such as [[!template id=man name="xdm" section="8"]], when your
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 04:23:56 -0000	1.13
+++ wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 04:28:49 -0000	1.14
@@ -55,8 +55,6 @@
    by creating “\_kerberos._host_” TXT records with the realm name in
    the DNS.
 
-[[!toc startlevel=2 levels=1]]
-
 ### sshd
 
 [[!template id=man name="sshd" section="8"]] uses service principal

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:10:44 -0000	1.15
+++ wikisrc/tutorials/kerberos_realm.mdwn	31 Jul 2026 04:23:56 -0000	1.16
@@ -1,4 +1,4 @@
-# How to create a Kerberos realm for single sign-on running on NetBSD
+## How to create a Kerberos realm for single sign-on running on NetBSD
 
 You want to organize your users and services into a
 [[Kerberos|kerberos]] realm to enable
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:40:56 -0000	1.12
+++ wikisrc/tutorials/kerberos_services.mdwn	31 Jul 2026 04:23:56 -0000	1.13
@@ -1,4 +1,6 @@
-# How to set up Kerberos authentication in network services
+[[!template id=note text="[[!toc startlevel=3 levels=1]]"]]
+
+## How to set up Kerberos authentication in network services
 
 Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM, or you
 [[set one up|tutorials/kerberos_realm]].
@@ -55,7 +57,7 @@
 
 [[!toc startlevel=2 levels=1]]
 
-## sshd
+### sshd
 
 [[!template id=man name="sshd" section="8"]] uses service principal
 names of the form “host/_hostname_” (not “ssh/_hostname_”).
@@ -69,7 +71,7 @@
 
 XXX warn against pam_krb5
 
-## dovecot (IMAP, POP, SMTP/submission, or any protocol with SASL)
+### dovecot (IMAP, POP, SMTP/submission, or any protocol with SASL)
 
 [(Main documentation)](https://doc.dovecot.org/2.3/configuration_manual/authentication/kerberos/)
 
@@ -137,7 +139,7 @@
 }
 """]]
 
-## postfix (submission)
+### postfix (submission)
 
 [(Main documentation)](https://www.postfix.org/SASL_README.html)
 
@@ -184,7 +186,7 @@
    `smtpd_sender_restrictions` to restrict senders to submit
    `MAIL FROM` envelope addresses that match their login names.
 
-## apache2 (HTTPS)
+### apache2 (HTTPS)
 
 “HTTP/_hostname_”
 
@@ -194,7 +196,7 @@
 
 XXX single-sign-on option with session cookie
 
-## nginx (HTTPS)
+### nginx (HTTPS)
 
 “HTTP/_hostname_”
 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:24:44 -0000	1.11
+++ wikisrc/tutorials/kerberos_client.mdwn	31 Jul 2026 04:22:37 -0000	1.12
@@ -1,4 +1,6 @@
-# How to use Kerberos for single sign-on in a NetBSD client
+[[!template id=note text="[[!toc startlevel=3 levels=1]]"]]
+
+## How to use Kerberos for single sign-on in a NetBSD client
 
 Your organization has a [[Kerberos|kerberos]] realm EXAMPLE.COM.
 You have a login password for the principal jruser@EXAMPLE.COM.
@@ -22,9 +24,7 @@
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!
 
-[[!toc startlevel=2 levels=1]]
-
-##### Notes
+##### Notes for unusual use-cases
 
 - If your realm isn't set up for Kerberos DNS autoconfiguration, you
   may need to specify the KDC address in the `[realms]` section of
@@ -82,7 +82,7 @@
      Make sure to set `[libdefaults] dns_lookup_realm = false` in each
      config file too in this case.
 
-## ssh
+### ssh
 
 To enable [[!template id=man name="ssh" section="1"]] to use Kerberos
 authentication when logging into any host under *.example.com, add the
@@ -109,7 +109,7 @@
 Now run kerberized applications on foo.example.com through ssh without
 a password!
 
-## Firefox
+### Firefox
 
 To log into kerberized web sites at `https://*.example.com/`:
 
@@ -131,7 +131,7 @@
 
 - This is restricted to HTTPS, and will not work with HTTP sites.
 
-## Kerberos for local login
+### Kerberos for local login
 
 To use Kerberos for local logins, e.g. at the console or in a display
 manager such as [[!template id=man name="xdm" section="8"]], when your

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:11:44 -0000	1.37
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:12:16 -0000	1.38
@@ -70,7 +70,7 @@
 the file system.
 
 Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag, visible
-with the [[!template id=man name=ls section=1]] flag
+with the [[!template id=man name=ls section=1]] option
 “`-o`”; see [[!template id=man name=chflags section=1]].
 The nominal size of a snapshot file is the size of the whole file
 system, but it only uses up space for the old content of blocks that

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:05:00 -0000	1.36
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:11:44 -0000	1.37
@@ -14,9 +14,9 @@
 suspend their activity.
 
 Snapshots are often used to take backups.  For example, the
-[[!template id=man name="dump" section="8"]] tool for dumping a file
-system backup can take a snapshot with the “`-X`” or
-&ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
+[[!template id=man name="dump" section="8"]] tool for taking a backup
+of an ffs file system will use a snapshot with the &ldquo;`-X`&rdquo;
+or &ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
 sqlite3 databases aren't concurrently modified while it is trying to
 read them.  Snapshots can also be mounted like regular file systems to
 give read-only views of past states of file systems.

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.35->1.36 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:03:28 -0000	1.35
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:05:00 -0000	1.36
@@ -297,7 +297,7 @@
 
 These tools can be used on any mounted snapshot.
 
-#### Example: [[!template id=man name=tar section=1]]
+#### Example: tar
 
 Mount a persistent snapshot of `/home` and back it up with
 [[!template id=man name=tar section=1]]:
@@ -337,7 +337,7 @@
 gives a file whose ctime must predate the snapshot; see below for why
 this is necessary to avoid losing data in later incremental backups.
 
-#### Example: [[!pkgsrc sysutils/py-borgbackup desc="borgbackup"]]
+#### Example: borgbackup
 
 Take a zfs snapshot of `/usr` and back it up with
 [[!pkgsrc sysutils/py-borgbackup desc="sysutils/py-borgbackup"]]:
@@ -351,7 +351,7 @@
 **WARNING: If used to take incremental backups, this may be vulnerable
 to a race condition with mtime checks; see below.**
 
-#### Example: [[!pkgsrc net/rsync desc="rsync"]]
+#### Example: rsync
 
 Mount an external snapshot of the msdos volume `/data` and back it up
 incrementally with [[!pkgsrc net/rsync desc="net/rsync"]]:

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 03:28:51 -0000	1.34
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 04:03:28 -0000	1.35
@@ -261,8 +261,9 @@
   By default, any user in the “`operator`” group (see
   [[!template id=man name=groups]]) can configure snapshots, read disk
   devices, and write to tape devices to take backups—this way
-  backups can be taken without root privileges.  However, since taking
-  a snapshot requires creating a file, running command such as
+  backups can be taken without root privileges.  However, since
+  “`dump -X ... /fs`” requires creating a snapshot backing
+  store at `/fs/<tempfile>`, running command such as
   &ldquo;`dump -X ... /`&rdquo; or &ldquo;`dump -X ... /usr`&rdquo;
   unprivileged will fail because `/` and `/usr` are writable only by
   root.  Instead, you can create a directory `/operator` that group
@@ -272,8 +273,9 @@
 
 - **For lfs**, the [[!template id=man name=dump_lfs section=8]] tool
   supports an option &ldquo;`-X`&rdquo; to dump a snapshot of the file
-  system.  (However, lfs does not support persistent or mountable
-  snapshots.)
+  system.  (However, lfs does not support persistent snapshots, nor
+  does it support mounting snapshots other than via generic external
+  [[!template id=man name=fss section=4]] snapshots.)
 
 - **For zfs**, the [[!template id=man name=zfs section=8]] tool's
   &ldquo;`zfs send <rpool>/<datasetpath>@<snapname>`&rdquo; command

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 03:12:49 -0000	1.33
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 03:28:51 -0000	1.34
@@ -275,7 +275,7 @@
   system.  (However, lfs does not support persistent or mountable
   snapshots.)
 
-- **For zfs**, the [[!template id=man name=zfs section=8]]
+- **For zfs**, the [[!template id=man name=zfs section=8]] tool's
   &ldquo;`zfs send <rpool>/<datasetpath>@<snapname>`&rdquo; command
   dumps the content of a snapshot.  The content can later be restored
   with the &ldquo;`zfs receive`&rdquo; command.
@@ -288,9 +288,9 @@
   [[!template id=man name=pax section=1]],
   [[!template id=man name=cpio section=1]]
 - Packages available in pkgsrc:
-  [[!pkgsrc net/rsync desc="net/rsync"]],
-  [[!pkgsrc sysutils/py-borgbackup desc="sysutils/py-borgbackup"]],
-  [[!pkgsrc sysutils/restic desc="sysutils/restic"]],
+  [[!pkgsrc net/rsync desc="rsync"]],
+  [[!pkgsrc sysutils/py-borgbackup desc="borgbackup"]],
+  [[!pkgsrc sysutils/restic desc="restic"]],
   and various others.
 
 These tools can be used on any mounted snapshot.
@@ -349,7 +349,7 @@
 **WARNING: If used to take incremental backups, this may be vulnerable
 to a race condition with mtime checks; see below.**
 
-#### Example: [[!pkgsrc net/rsync desc="net/rsync"]]
+#### Example: [[!pkgsrc net/rsync desc="rsync"]]
 
 Mount an external snapshot of the msdos volume `/data` and back it up
 incrementally with [[!pkgsrc net/rsync desc="net/rsync"]]:

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:59:45 -0000	1.32
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 03:12:49 -0000	1.33
@@ -1,18 +1,16 @@
 [[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
 
-## How to use file system snapshots in NetBSD
-
 ### Overview
 
 A **snapshot** is a consistent view of a file system at a certain point
-in time.  If you take a snapshot of a file system, and then create a
+in time.  If you take a snapshot of a file system, and later create a
 new file or modify an existing one or make any other changes to the
-file system, and the snapshot will still have the old version of the
-file system without the changes.
+file system, the snapshot will still have the old version of the file
+system without the changes.
 
 Unlike copies, snapshots use space on disk only for data that have been
-overwritten since the snapshot was taken, and can be taken for the
-whole file system at once without any cooperation from applications to
+overwritten since the snapshot was taken, and can be taken for a whole
+file system at once without any cooperation from applications to
 suspend their activity.
 
 Snapshots are often used to take backups.  For example, the
@@ -26,8 +24,8 @@
 On some file systems—ffs and zfs—snapshots can be
 **persistent**: you can take a snapshot, stored in the file system
 itself, and it will persist until it is explicitly deleted, even if the
-system is rebooted.  All disk-backed (non-virtual) file systems in
-NetBSD also support external but non-persistent snapshots.
+system is rebooted.  All disk-backed file systems in NetBSD, such as
+msdos and ext2fs, also support external but non-persistent snapshots.
 
 ### Persistent snapshots with [[!template id=man name="fss" section="4"]]
 
@@ -47,11 +45,13 @@
 File systems may impose a limit on the number of snapshots that can be
 stored at any time.  For ffs, this limit is 20.
 
+**Cost of snapshots.**
 In ffs, overwriting a block that was in use in any snapshots causes a
 copy of the old block content to be saved in *each* of the snapshots
-separately.  So while snapshots are more space-efficient than copies
-when most blocks are unchanged, they can cause write amplification by a
-factor of up to the number of snapshots when many blocks are changing.
+separately, whether or not they are actively configured with
+[[!template id=man name=fss section=4]].  So while snapshots are more
+space-efficient than copies when most blocks are unchanged, they can
+cause write amplification by a factor of up to the number of snapshots.
 
 #### Taking a snapshot
 
@@ -163,6 +163,7 @@
 - nfs
 - fuse/puffs
 
+**Cost of active snapshots.**
 Overwriting a block that was in use in any active snapshots causes a
 copy of the old block content to be saved in *each* of the snapshots
 separately, causing write amplification by a factor of up to the number
@@ -384,8 +385,8 @@
 In this case, the file's mtime before the snapshot and after the
 snapshot may both be rounded down by the tool to just a number of
 seconds *t* since the epoch.  **The next time the tool runs, it may
-conclude the file was unchanged since the last run, and lose the second
-modification.**
+conclude the file was unchanged since the last run, and *lose the second
+modification*.**
 
 The tarsnap
 &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:58:17 -0000	1.31
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:59:45 -0000	1.32
@@ -156,6 +156,7 @@
 
 [[!template id=man name="fss" section="4"]] only supports file systems
 mounted from disk devices, so it does not support, for example:
+
 - memory-backed file systems such as tmpfs
 - virtual file systems such as procfs, ptyfs, or nullfs
 - zfs

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.30->1.31 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:48:07 -0000	1.30
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:58:17 -0000	1.31
@@ -309,12 +309,14 @@
 #### Example: tarsnap
 
 Mount a (single-use) “persistent” snapshot of `/var` and
-back it up with tarsnap:**
+back it up with tarsnap:
 
 [[!template id=programlisting text="""
 # fssconfig fss3 /var /var/
 # mount /dev/fss3 /mnt
-# tarsnap -C /mnt -cf var-20260706 --snaptime /var .
+# touch /tmp/20260706
+# tarsnap -C /mnt -cf var-20260706 --snaptime /tmp/20260706 .
+# rm /tmp/20260706
 # umount /mnt
 # fssconfig -u fss3
 """]]
@@ -326,12 +328,10 @@
 discarded as soon as it is unconfigured.
 
 Tarsnap takes incremental backups and caches the mtimes of files each
-time it runs to avoid checking for files that haven't changed the last
-time.  Here, since [[!template id=man name=fssconfig section=8]]
-created a snapshot backing store at `/var/<tempfile>`, it updated the
-ctime of `/var`, so `/var` itself provides a pre-snapshot reference
-time; see below for why it is important to provide a pre-snapshot
-reference time with &ldquo;`--snaptime`&rdquo;.
+time it runs in order to avoid spending time processing files that
+haven't changed the last time.  The &ldquo;`--snaptime`&rdquo; argument
+gives a file whose ctime must predate the snapshot; see below for why
+this is necessary to avoid losing data in later incremental backups.
 
 #### Example: [[!pkgsrc sysutils/py-borgbackup desc="borgbackup"]]
 
@@ -399,4 +399,4 @@
 problem by recording a time just *before* taking the snapshot as the
 dump date; on the next incremental run,
 [[!template id=man name="dump" section="8"]] will include any file
-with an mtime of the last dump date or newer.
+with an mtime equal to the last dump date or newer.

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:44:23 -0000	1.29
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:48:07 -0000	1.30
@@ -327,8 +327,11 @@
 
 Tarsnap takes incremental backups and caches the mtimes of files each
 time it runs to avoid checking for files that haven't changed the last
-time.  See below for why the “`--snaptime`” argument to
-`tarsnap` is important in this scenario.
+time.  Here, since [[!template id=man name=fssconfig section=8]]
+created a snapshot backing store at `/var/<tempfile>`, it updated the
+ctime of `/var`, so `/var` itself provides a pre-snapshot reference
+time; see below for why it is important to provide a pre-snapshot
+reference time with &ldquo;`--snaptime`&rdquo;.
 
 #### Example: [[!pkgsrc sysutils/py-borgbackup desc="borgbackup"]]
 
@@ -387,12 +390,9 @@
 &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
 option avoids this problem by treating any file with an mtime equal
 to or newer than the ctime *t* of `<reference>` as if it had an mtime
-of *t* &minus; 1 when comparing mtimes on the next run.  (In this
-example, since [[!template id=man name=fssconfig section=8]] created
-a snapshot backing store in `/var/<tempfile>`, it updated the ctime
-of `/var`, so `/var` serves as a reference for this purpose.)  Other
-backup tools may have&mdash;or may need&mdash;similar options to
-reliably take incremental backups with snapshots.
+of *t* &minus; 1 when comparing mtimes on the next run.  Other backup
+tools may have&mdash;or may need&mdash;similar options to reliably take
+incremental backups with snapshots.
 
 The [[!template id=man name="dump" section="8"]] options
 &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also avoid this

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:38:06 -0000	1.28
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:44:23 -0000	1.29
@@ -53,7 +53,7 @@
 when most blocks are unchanged, they can cause write amplification by a
 factor of up to the number of snapshots when many blocks are changing.
 
-#### Example: Taking a snapshot
+#### Taking a snapshot
 
 To create and mount a persistent snapshot of the `/home` file system,
 via `/dev/fss0`:
@@ -111,7 +111,7 @@
 # mount /dev/fss0 /home/.snap/20260706
 """]]
 
-#### Example: Recovering from a snapshot
+#### Recovering from a snapshot
 
 If you made a mistake and need to recover from the snapshot, you can
 use, e.g., [[!pkgsrc net/rsync desc="net/rsync"]] to revert files back
@@ -126,7 +126,7 @@
 to avoid writing unchanged content back to the file system, since that
 would waste space in the snapshot backing store.
 
-#### Example: Discarding a persistent snapshot
+#### Discarding a persistent snapshot
 
 When done with a snapshot, after unmounting and unconfiguring the
 [[!template id=man name="fss" section="4"]], you can unlink the
@@ -167,7 +167,7 @@
 separately, causing write amplification by a factor of up to the number
 of snapshots configured.
 
-#### Example: Taking a snapshot
+#### Taking a snapshot
 
 To create a snapshot of the `/boot` directory, using space in
 `/var/tmp/` to save any data overwritten while the snapshot is active,
@@ -219,7 +219,7 @@
 `/dev/zvol/dsk/<pool>/<zvol>@<snapname>` (block device) and
 `/dev/zvol/rdsk/<pool>/<zvol>@<snapname>` (raw character device).
 
-#### Example: Taking a snapshot
+#### Taking a snapshot
 
 To create a snapshot of a dataset, and all datasets under it atomically:
 
@@ -234,7 +234,7 @@
 (NOTE: not under `/home/.zfs/snapshot/20260706/jruser`, which will just
 appear as an empty directory).
 
-#### Example: Recovering from a snapshot
+#### Recovering from a snapshot
 
 You can recover individual files from the `.zfs/snapshot/<snapname>/`
 directory, but you can also roll back a whole file system to the latest
@@ -335,9 +335,11 @@
 Take a zfs snapshot of `/usr` and back it up with
 [[!pkgsrc sysutils/py-borgbackup desc="sysutils/py-borgbackup"]]:
 
+[[!template id=programlisting text="""
 # zfs snap -r rpool/usr@20260706
 # (cd /usr/.zfs/snapshot/20260706 &&
     borg create borghost:/path/to/repo::usr-20260706 .)
+"""]]
 
 **WARNING: If used to take incremental backups, this may be vulnerable
 to a race condition with mtime checks; see below.**
@@ -347,6 +349,7 @@
 Mount an external snapshot of the msdos volume `/data` and back it up
 incrementally with [[!pkgsrc net/rsync desc="net/rsync"]]:
 
+[[!template id=programlisting text="""
 # fssconfig fss1 /data /var/tmp/
 # mount /dev/fss1 /mnt
 # ssh rsynchost mkdir /backups/$(hostname)/data/20260706
@@ -355,6 +358,7 @@
 # ssh rsynchost ln -sfn 20260706 /backups/$(hostname)/latest
 # umount /mnt
 # fssconfig -u fss1
+"""]]
 
 This will use a temporary file in `/var/tmp/` as the backing store
 while the snapshot is active, and then discard it as soon as it is
@@ -363,11 +367,11 @@
 **WARNING: If used to take incremental backups, this may be vulnerable
 to a race condition with mtime checks; see below.**
 
-#### CAVEAT: Incremental backups and mtimes
+### Caveat: Incremental backups and mtimes
 
-A tool such as tarsnap, borg, or rsync which backs up the snapshot and
-records mtimes to avoid reprocessing unchanged files the next time
-around may have a subtle race condition.  Suppose:
+An incremental backup tool such as tarsnap, borg, or rsync which backs
+up the snapshot and records mtimes to avoid reprocessing unchanged
+files the next time around may have a subtle race condition.  Suppose:
 
 1. A file is modified at time *t* + 0.1sec.
 2. The snapshot is taken at time *t* + 0.2sec and backed up.
@@ -379,7 +383,7 @@
 conclude the file was unchanged since the last run, and lose the second
 modification.**
 
-The (third-party) tarsnap
+The tarsnap
 &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
 option avoids this problem by treating any file with an mtime equal
 to or newer than the ctime *t* of `<reference>` as if it had an mtime

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.27->1.28 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:41:48 -0000	1.27
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 02:38:06 -0000	1.28
@@ -1,8 +1,8 @@
-# How to use file system snapshots in NetBSD
+[[!template id=note text="[[!toc startlevel=3 levels=2]]"]]
 
-[[!toc startlevel=2 levels=2]]
+## How to use file system snapshots in NetBSD
 
-## Overview
+### Overview
 
 A **snapshot** is a consistent view of a file system at a certain point
 in time.  If you take a snapshot of a file system, and then create a
@@ -18,43 +18,42 @@
 Snapshots are often used to take backups.  For example, the
 [[!template id=man name="dump" section="8"]] tool for dumping a file
 system backup can take a snapshot with the “`-X`” or
-&ldquo;`-x <snapstore>`&rdquo; options (q.v.) to ensure that files such
-as sqlite3 databases aren't concurrently modified while it is trying to
+&ldquo;`-x <snapstore>`&rdquo; options to ensure that files such as
+sqlite3 databases aren't concurrently modified while it is trying to
 read them.  Snapshots can also be mounted like regular file systems to
 give read-only views of past states of file systems.
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
-**persistent**: you can take a snapshot, and it will persist until it
-is explicitly deleted, even if the system is rebooted.  Most other file
-systems only support external snapshots which don't persist past
-reboot.
+**persistent**: you can take a snapshot, stored in the file system
+itself, and it will persist until it is explicitly deleted, even if the
+system is rebooted.  All disk-backed (non-virtual) file systems in
+NetBSD also support external but non-persistent snapshots.
 
-## Persistent snapshots with [[!template id=man name="fss" section="4"]]
+### Persistent snapshots with [[!template id=man name="fss" section="4"]]
 
 *Persistent snapshots are currently supported for ffs file systems
 only&mdash;not to be confused with the fss file system snapshot
 device used to manage them.*
 
-A persistent snapshot of a file system is represented by a regular file
-*inside* the file system, with a special flag (so it can't be read or
-written normally), and persists until the file is unlinked.  This file
-is used as a backing store for the snapshot, to save any data
-overwritten later in the file system.  Snapshots can be created with or
-loaded back into [[!template id=man name="fss" section="4"]] devices in
-order to mount them.  Active snapshots are managed with the
+A persistent snapshot of a file system is represented by a file inside
+the file system (with a special flag so it can't be read or written
+normally), and persists until the file is unlinked.  This file is used
+as a backing store for the snapshot, to save any data overwritten later
+in the file system.  Snapshots can be created with or loaded back into
+[[!template id=man name="fss" section="4"]] devices in order to mount
+them.  Active snapshots are managed with the
 [[!template id=man name="fssconfig" section="8"]] command.
 
 File systems may impose a limit on the number of snapshots that can be
 stored at any time.  For ffs, this limit is 20.
 
-In ffs, overwriting a block that was in use in multiple snapshots
-causes a copy of old block content to be saved in *each* of the
-snapshots separately.  So while snapshots are more space-efficient than
-copies when most blocks are unchanged, they can cause write
-amplification by a factor of up to the number of snapshots when many
-blocks are changing.
+In ffs, overwriting a block that was in use in any snapshots causes a
+copy of the old block content to be saved in *each* of the snapshots
+separately.  So while snapshots are more space-efficient than copies
+when most blocks are unchanged, they can cause write amplification by a
+factor of up to the number of snapshots when many blocks are changing.
 
-### Example: Taking a snapshot
+#### Example: Taking a snapshot
 
 To create and mount a persistent snapshot of the `/home` file system,
 via `/dev/fss0`:
@@ -78,18 +77,18 @@
 have been overwritten since it was taken:
 
 [[!template id=programlisting text="""
-# ls -hlo /altroot/.snap
+# ls -hlo /home/.snap
 total 8.0G
 -rw-------  1 root  wheel  snap 4.0G Jun 22 02:29 20260622.store
 drwxr-xr-x  2 root  wheel  -    512B Jun 22 02:28 20260622
 -rw-------  1 root  wheel  snap 4.0G Jul 06 01:18 20260706.store
 drwxr-xr-x  2 root  wheel  -    512B Jul 06 01:17 20260706
-# du -ahx /altroot/.snap/
-1.6G    /altroot/.snap/20260622.store
-1.7M    /altroot/.snap/20260706.store
-2.0K    /altroot/.snap/20260622
-2.0K    /altroot/.snap/20260706
-1.6G    /altroot/.snap/
+# du -ahx /home/.snap/
+1.6G    /home/.snap/20260622.store
+1.7M    /home/.snap/20260706.store
+2.0K    /home/.snap/20260622
+2.0K    /home/.snap/20260706
+1.6G    /home/.snap/
 """]]
 
 Note: [[!template id=man name=find section=1]] cannot currently filter
@@ -112,11 +111,11 @@
 # mount /dev/fss0 /home/.snap/20260706
 """]]
 
-### Example: Recovering from a snapshot
+#### Example: Recovering from a snapshot
 
 If you made a mistake and need to recover from the snapshot, you can
-use, e.g., rsync (pkgsrc [[!pkgsrc net/rsync desc="net/rsync"]]) to
-revert files back to what they were in the snapshot:
+use, e.g., [[!pkgsrc net/rsync desc="net/rsync"]] to revert files back
+to what they were in the snapshot:
 
 [[!template id=programlisting text="""
 # rsync -aHc --delete /home/.snap/20260706/bofh/. /home/bofh/.
@@ -125,9 +124,9 @@
 It is better to use rsync rather than
 [[!template id=man name="tar" section="1"]] for this purpose, in order
 to avoid writing unchanged content back to the file system, since that
-would take up space in the snapshot backing store.
+would waste space in the snapshot backing store.
 
-### Example: Discarding a persistent snapshot
+#### Example: Discarding a persistent snapshot
 
 When done with a snapshot, after unmounting and unconfiguring the
 [[!template id=man name="fss" section="4"]], you can unlink the
@@ -141,107 +140,38 @@
 # rm /home/.snap/20260706.store
 """]]
 
-### Example: Single-use snapshot to take a backup
+### External snapshots with [[!template id=man name="fss" section="4"]]
 
-You can also take a “persistent” snapshot of a file system and
-immediately unlink it while it is still configured.  That way, any
-storage it uses will be released as soon as the
-[[!template id=man name="fss" section="4"]] device is unconfigured, and
-(unlike for external [[!template id=man name="fss" section="4"]]
-snapshots) you don't need any backing store outside the file system.
-For example, to take an anonymous persistent snapshot of the file
-system `/var` and mount it at `/var/.snapshot`:
+Any file system mounted from a disk device, such as ext2fs and msdosfs,
+supports snapshots with [[!template id=man name="fss" section="4"]].
 
-[[!template id=programlisting text="""
-# fssconfig fss3 /var /var/
-# mkdir /var/.snapshot
-# mount /dev/fss3 /var/.snapshot
-"""]]
-
-Then you can take a backup of `/var` from the snapshot with your
-favourite backup archiving tool:
-
-[[!template id=programlisting text="""
-# tar -C /var/.snapshot -cf - . | ...
-
-# tarsnap -C /var/.snapshot -cf var-20260706 --snaptime /var .
-
-# (cd /var/.snapshot &&
-      borg create borghost:/path/to/repo::var-20260706 .)
-
-# ssh rsynchost mkdir /backups/$(hostname)/var/20260706 &&
-  rsync -aHc --link-dest=/backups/$(hostname)/var/latest/. \
-      /var/.snapshot/. rsynchost:/backups/$(hostname)/var/20260706/. &&
-  ssh rsynchost ln -sfn 20260706 /backups/$(hostname)/var/latest
-"""]]
-
-Note that if you use [[!template id=man name="dump" section="8"]] and
-[[!template id=man name="restore" section="8"]] for backups,
-[[!template id=man name="dump" section="8"]] can automatically take a
-snapshot itself with the &ldquo;`-X`&rdquo; or
-&ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
-[[!template id=man name="fssconfig" section="8"]] at all.
-
-- **N.B. about incremental backups and mtimes:**
-  A tool such as tarsnap, borg, or rsync which backs up the snapshot and
-  records mtimes to avoid reprocessing unchanged files the next time
-  around may have a race condition.  Suppose:
-
-  1. A file is modified at time *t* + 0.1sec.
-  2. The snapshot is taken at time *t* + 0.2sec and backed up.
-  3. The file is modified again at time *t* + 0.3sec.
-
-  In this case, the file's mtime before the snapshot and after the
-  snapshot may both be rounded down by the tool to just a number of
-  seconds *t* since the epoch.  If so, the next time the tool runs, it

(Diff truncated)

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:34:18 -0000	1.26
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:41:48 -0000	1.27
@@ -182,38 +182,38 @@
 &ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
 [[!template id=man name="fssconfig" section="8"]] at all.
 
-- **N.B. about incremental snapshot backups and mtimes:**
+- **N.B. about incremental backups and mtimes:**
   A tool such as tarsnap, borg, or rsync which backs up the snapshot and
   records mtimes to avoid reprocessing unchanged files the next time
   around may have a race condition.  Suppose:
 
-  1. A file is modified at time t + 0.1sec.
-  2. The snapshot is taken at time t + 0.2sec and backed up.
-  3. The file is modified again at time t + 0.3sec
+  1. A file is modified at time *t* + 0.1sec.
+  2. The snapshot is taken at time *t* + 0.2sec and backed up.
+  3. The file is modified again at time *t* + 0.3sec.
 
   In this case, the file's mtime before the snapshot and after the
   snapshot may both be rounded down by the tool to just a number of
-  seconds t.  If so, the next time the tool runs, it may conclude the
-  file was unchanged since the last run, and lose the second
-  modification.
+  seconds *t* since the epoch.  If so, the next time the tool runs, it
+  may conclude the file was unchanged since the last run, and lose the
+  second modification.
 
   The (third-party) Tarsnap
   &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
-  option avoids this by treating any file newer than the ctime t of
-  `<reference>` as if it had an mtime of t &minus; 1 when comparing
-  mtimes on the next run.  (In this example, since
-  [[!template id=man name=fssconfig section=8]] created a snapshot
-  backing store in `/var/<tempfile>`, it updated the ctime of `/var`, so
-  `/var` serves as a reference for this purpose.)  Other backup tools
-  may have&mdash;or need&mdash;similar options to reliably take
-  incremental backups with snapshots.
+  option avoids this problem by treating any file with an mtime equal
+  to or newer than the ctime *t* of `<reference>` as if it had an mtime
+  of *t* &minus; 1 when comparing mtimes on the next run.  (In this
+  example, since [[!template id=man name=fssconfig section=8]] created
+  a snapshot backing store in `/var/<tempfile>`, it updated the ctime
+  of `/var`, so `/var` serves as a reference for this purpose.)  Other
+  backup tools may have&mdash;or may need&mdash;similar options to
+  reliably take incremental backups with snapshots.
 
   The [[!template id=man name="dump" section="8"]] options
   &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also avoid this
   problem by recording a time just *before* taking the snapshot as the
   dump date; on the next incremental run,
-  [[!template id=man name="dump" section="8"]] will dump any file with
-  an mtime of the last dump date or newer.
+  [[!template id=man name="dump" section="8"]] will include any file
+  with an mtime of the last dump date or newer.
 
 When the snapshot is unmounted and unconfigured, the backing store will
 automatically be discarded:

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:27:45 -0000	1.25
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:34:18 -0000	1.26
@@ -185,12 +185,16 @@
 - **N.B. about incremental snapshot backups and mtimes:**
   A tool such as tarsnap, borg, or rsync which backs up the snapshot and
   records mtimes to avoid reprocessing unchanged files the next time
-  around may have a race condition: if a file is modified at time t +
-  0.1sec, the snapshot is taken at time t + 0.2sec, and the file is
-  modified again at time t + 0.3sec, the file's mtime before the snapshot
-  and after the snapshot may both be rounded down by the tool to just a
-  number of seconds t.  If so, the next time the tool runs, it may
-  conclude the file was unchanged since the last run, and lose the second
+  around may have a race condition.  Suppose:
+
+  1. A file is modified at time t + 0.1sec.
+  2. The snapshot is taken at time t + 0.2sec and backed up.
+  3. The file is modified again at time t + 0.3sec
+
+  In this case, the file's mtime before the snapshot and after the
+  snapshot may both be rounded down by the tool to just a number of
+  seconds t.  If so, the next time the tool runs, it may conclude the
+  file was unchanged since the last run, and lose the second
   modification.
 
   The (third-party) Tarsnap
@@ -200,12 +204,16 @@
   mtimes on the next run.  (In this example, since
   [[!template id=man name=fssconfig section=8]] created a snapshot
   backing store in `/var/<tempfile>`, it updated the ctime of `/var`, so
-  `/var` serves as a reference for this purpose.)  The
-  [[!template id=man name="dump" section="8"]] options &ldquo;`-X`&rdquo;
-  and &ldquo;`-x <snapstore>`&rdquo; also avoid this problem by recording
-  a time just *before* taking the snapshot as the dump date; on the next
-  incremental run, [[!template id=man name="dump" section="8"]] will dump
-  any file with an mtime of the last dump date or newer.
+  `/var` serves as a reference for this purpose.)  Other backup tools
+  may have&mdash;or need&mdash;similar options to reliably take
+  incremental backups with snapshots.
+
+  The [[!template id=man name="dump" section="8"]] options
+  &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also avoid this
+  problem by recording a time just *before* taking the snapshot as the
+  dump date; on the next incremental run,
+  [[!template id=man name="dump" section="8"]] will dump any file with
+  an mtime of the last dump date or newer.
 
 When the snapshot is unmounted and unconfigured, the backing store will
 automatically be discarded:

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.24->1.25 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:21:12 -0000	1.24
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:27:45 -0000	1.25
@@ -182,31 +182,30 @@
 &ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
 [[!template id=man name="fssconfig" section="8"]] at all.
 
-[[!template id=note text="""
-**N.B. about snapshot backups and mtimes:**
-Beware that a tool which backs up the snapshot and records mtimes to
-avoid reprocessing unchanged files the next time around may have a race
-condition: if a file is modified at time t + 0.1sec, the snapshot is
-taken at time t + 0.2sec, and the file is modified again at time t +
-0.3sec, the file's mtime before the snapshot and after the snapshot may
-both be rounded down to just a number of seconds t.  If so, the next
-time the tool runs, it may conclude the file was unchanged since the
-last run, and lose the second modification.
-
-The (third-party)
-&ldquo;[`tarsnap --snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
-option avoids this by treating any file newer than the ctime t of
-`<reference>` as if it had an mtime of t &minus; 1 when comparing
-mtimes on the next run.  (In this example, since
-[[!template id=man name=fssconfig section=8]] created a snapshot
-backing store in `/var/<tempfile>`, it updated the ctime of `/var`, so
-`/var` serves as a reference for this purpose.)  The
-[[!template id=man name="dump" section="8"]] options &ldquo;`-X`&rdquo;
-and &ldquo;`-x <snapstore>`&rdquo; also avoid this problem by recording
-a time just *before* taking the snapshot as the dump date; on the next
-incremental run, [[!template id=man name="dump" section="8"]] will dump
-any file with an mtime of the last dump date or newer.
-"""]]
+- **N.B. about incremental snapshot backups and mtimes:**
+  A tool such as tarsnap, borg, or rsync which backs up the snapshot and
+  records mtimes to avoid reprocessing unchanged files the next time
+  around may have a race condition: if a file is modified at time t +
+  0.1sec, the snapshot is taken at time t + 0.2sec, and the file is
+  modified again at time t + 0.3sec, the file's mtime before the snapshot
+  and after the snapshot may both be rounded down by the tool to just a
+  number of seconds t.  If so, the next time the tool runs, it may
+  conclude the file was unchanged since the last run, and lose the second
+  modification.
+
+  The (third-party) Tarsnap
+  &ldquo;[`--snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
+  option avoids this by treating any file newer than the ctime t of
+  `<reference>` as if it had an mtime of t &minus; 1 when comparing
+  mtimes on the next run.  (In this example, since
+  [[!template id=man name=fssconfig section=8]] created a snapshot
+  backing store in `/var/<tempfile>`, it updated the ctime of `/var`, so
+  `/var` serves as a reference for this purpose.)  The
+  [[!template id=man name="dump" section="8"]] options &ldquo;`-X`&rdquo;
+  and &ldquo;`-x <snapstore>`&rdquo; also avoid this problem by recording
+  a time just *before* taking the snapshot as the dump date; on the next
+  incremental run, [[!template id=man name="dump" section="8"]] will dump
+  any file with an mtime of the last dump date or newer.
 
 When the snapshot is unmounted and unconfigured, the backing store will
 automatically be discarded:

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.23->1.24 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 23:31:41 -0000	1.23
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	31 Jul 2026 00:21:12 -0000	1.24
@@ -182,6 +182,7 @@
 &ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
 [[!template id=man name="fssconfig" section="8"]] at all.
 
+[[!template id=note text="""
 **N.B. about snapshot backups and mtimes:**
 Beware that a tool which backs up the snapshot and records mtimes to
 avoid reprocessing unchanged files the next time around may have a race
@@ -192,18 +193,20 @@
 time the tool runs, it may conclude the file was unchanged since the
 last run, and lose the second modification.
 
-The
+The (third-party)
 &ldquo;[`tarsnap --snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
 option avoids this by treating any file newer than the ctime t of
-`<reference>` as if it had an mtime of t &minus; 1 (in the example
-above, since [[!template id=man name=fssconfig section=8]] created a
-snapshot backing storein `/var/<tempfile>`, the ctime of `/var` serves
-for this purpose).  The [[!template id=man name="dump" section="8"]]
-options &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also
-avoid this problem by recording a time just *before* taking the
-snapshot as the dump date; on the next incremental run,
-[[!template id=man name="dump" section="8"]] will dump any file with an
-mtime of the last dump date or newer.
+`<reference>` as if it had an mtime of t &minus; 1 when comparing
+mtimes on the next run.  (In this example, since
+[[!template id=man name=fssconfig section=8]] created a snapshot
+backing store in `/var/<tempfile>`, it updated the ctime of `/var`, so
+`/var` serves as a reference for this purpose.)  The
+[[!template id=man name="dump" section="8"]] options &ldquo;`-X`&rdquo;
+and &ldquo;`-x <snapstore>`&rdquo; also avoid this problem by recording
+a time just *before* taking the snapshot as the dump date; on the next
+incremental run, [[!template id=man name="dump" section="8"]] will dump
+any file with an mtime of the last dump date or newer.
+"""]]
 
 When the snapshot is unmounted and unconfigured, the backing store will
 automatically be discarded:

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 22:24:33 -0000	1.22
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 23:31:41 -0000	1.23
@@ -164,7 +164,7 @@
 [[!template id=programlisting text="""
 # tar -C /var/.snapshot -cf - . | ...
 
-# tarsnap -C /var/.snapshot -cf var-20260706 .
+# tarsnap -C /var/.snapshot -cf var-20260706 --snaptime /var .
 
 # (cd /var/.snapshot &&
       borg create borghost:/path/to/repo::var-20260706 .)
@@ -175,12 +175,35 @@
   ssh rsynchost ln -sfn 20260706 /backups/$(hostname)/var/latest
 """]]
 
-(Note that if you use [[!template id=man name="dump" section="8"]] and
+Note that if you use [[!template id=man name="dump" section="8"]] and
 [[!template id=man name="restore" section="8"]] for backups,
 [[!template id=man name="dump" section="8"]] can automatically take a
 snapshot itself with the “`-X`” or
 &ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
-[[!template id=man name="fssconfig" section="8"]] at all.)
+[[!template id=man name="fssconfig" section="8"]] at all.
+
+**N.B. about snapshot backups and mtimes:**
+Beware that a tool which backs up the snapshot and records mtimes to
+avoid reprocessing unchanged files the next time around may have a race
+condition: if a file is modified at time t + 0.1sec, the snapshot is
+taken at time t + 0.2sec, and the file is modified again at time t +
+0.3sec, the file's mtime before the snapshot and after the snapshot may
+both be rounded down to just a number of seconds t.  If so, the next
+time the tool runs, it may conclude the file was unchanged since the
+last run, and lose the second modification.
+
+The
+&ldquo;[`tarsnap --snaptime <reference>`](https://www.tarsnap.com/snaptime.html)&rdquo;
+option avoids this by treating any file newer than the ctime t of
+`<reference>` as if it had an mtime of t &minus; 1 (in the example
+above, since [[!template id=man name=fssconfig section=8]] created a
+snapshot backing storein `/var/<tempfile>`, the ctime of `/var` serves
+for this purpose).  The [[!template id=man name="dump" section="8"]]
+options &ldquo;`-X`&rdquo; and &ldquo;`-x <snapstore>`&rdquo; also
+avoid this problem by recording a time just *before* taking the
+snapshot as the dump date; on the next incremental run,
+[[!template id=man name="dump" section="8"]] will dump any file with an
+mtime of the last dump date or newer.
 
 When the snapshot is unmounted and unconfigured, the backing store will
 automatically be discarded:

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.21->1.22 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 19:35:05 -0000	1.21
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 22:24:33 -0000	1.22
@@ -163,9 +163,12 @@
 
 [[!template id=programlisting text="""
 # tar -C /var/.snapshot -cf - . | ...
+
 # tarsnap -C /var/.snapshot -cf var-20260706 .
-# (cd /var/.snapshot && \
+
+# (cd /var/.snapshot &&
       borg create borghost:/path/to/repo::var-20260706 .)
+
 # ssh rsynchost mkdir /backups/$(hostname)/var/20260706 &&
   rsync -aHc --link-dest=/backups/$(hostname)/var/latest/. \
       /var/.snapshot/. rsynchost:/backups/$(hostname)/var/20260706/. &&

If they redirected http:// -> https://, I replaced the URL prefix in
the template/shortcut by `https://'.

If they seemed to serve the same content from both, I replaced the
URL by `//'.

If I didn't review it before I got bored, I left it alone.

Members: 
	shortcuts.mdwn:1.4->1.5 
	templates/pkg.mdwn:1.8->1.9 

Index: wikisrc/shortcuts.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/shortcuts.mdwn,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- wikisrc/shortcuts.mdwn	17 Sep 2014 23:10:14 -0000	1.4
+++ wikisrc/shortcuts.mdwn	30 Jul 2026 22:18:44 -0000	1.5
@@ -11,36 +11,36 @@
 
 This page controls what shortcut links the wiki supports.
 
-* [[!shortcut name=google url="https://encrypted.google.com/search?q=%s"]]
-* [[!shortcut name=archive url="http://web.archive.org/*/%S"]]
+* [[!shortcut name=google url="https://www.google.com/search?q=%s"]]
+* [[!shortcut name=archive url="//web.archive.org/*/%S"]]
 * [[!shortcut name=gmap url="https://maps.google.com/maps?q=%s"]]
 * [[!shortcut name=gmsg url="https://groups.google.com/groups?selm=%s"]]
 * [[!shortcut name=wikipedia url="https://en.wikipedia.org/wiki/%W"]]
 * [[!shortcut name=wikitravel url="https://wikitravel.org/en/%s"]]
 * [[!shortcut name=wiktionary url="https://en.wiktionary.org/wiki/%s"]]
-* [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]]
+* [[!shortcut name=debbug url="https://bugs.debian.org/%S" desc="Debian bug #%s"]]
 * [[!shortcut name=deblist url="https://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]]
-* [[!shortcut name=debpkg url="http://packages.debian.org/%s"]]
-* [[!shortcut name=debpkgsid url="http://packages.debian.org/sid/%s"]]
-* [[!shortcut name=debpts url="http://packages.qa.debian.org/%s"]]
+* [[!shortcut name=debpkg url="https://packages.debian.org/%s"]]
+* [[!shortcut name=debpkgsid url="https://packages.debian.org/sid/%s"]]
+* [[!shortcut name=debpts url="https://packages.qa.debian.org/%s"]]
 * [[!shortcut name=debmsg url="https://lists.debian.org/msgid-search/%s"]]
 * [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]]
 * [[!shortcut name=debss url="http://snapshot.debian.org/package/%s/"]]
   * Usage: `\[[!debss package]]` or `\[[!debss package/version]]`.  See <http://snapshot.debian.org/> for details.
 * [[!shortcut name=debwiki url="https://wiki.debian.org/%S"]]
 * [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]]
-* [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]]
+* [[!shortcut name=fdolist url="https://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]]
 * [[!shortcut name=gnomebug url="https://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]]
 * [[!shortcut name=linuxbug url="https://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]]
 * [[!shortcut name=mozbug url="https://bugzilla.mozilla.org/show_bug.cgi?id=%s" desc="Mozilla bug #%s"]]
 * [[!shortcut name=gnulist url="https://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]]
-* [[!shortcut name=marcmsg url="http://marc.info/?i=%s"]]
-* [[!shortcut name=marclist url="http://marc.info/?l=%s"]]
+* [[!shortcut name=marcmsg url="https://marc.info/?i=%s"]]
+* [[!shortcut name=marclist url="https://marc.info/?l=%s"]]
 * [[!shortcut name=gmane url="http://dir.gmane.org/gmane.%s" desc="gmane.%s"]]
 * [[!shortcut name=gmanemsg url="http://mid.gmane.org/%s"]]
-* [[!shortcut name=cpan url="http://search.cpan.org/search?mode=dist&query=%s"]]
-* [[!shortcut name=ctan url="http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s"]]
-* [[!shortcut name=hoogle url="http://haskell.org/hoogle/?q=%s"]]
+* [[!shortcut name=cpan url="https://metacpan.org/search?q=dist%3A%s"]]
+* [[!shortcut name=ctan url="https://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s"]]
+* [[!shortcut name=hoogle url="https://haskell.org/hoogle/?q=%s"]]
 * [[!shortcut name=iki url="http://ikiwiki.info/%S/"]]
 * [[!shortcut name=ljuser url="http://%s.livejournal.com/"]]
 * [[!shortcut name=rfc url="https://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]]
@@ -59,11 +59,11 @@
 * [[!shortcut name=ohloh url="https://www.ohloh.net/p/%s"]]
 * [[!shortcut name=cpanrt url="https://rt.cpan.org/Ticket/Display.html?id=%s" desc="CPAN RT#%s"]]
 * [[!shortcut name=novellbug url="https://bugzilla.novell.com/show_bug.cgi?id=%s" desc="bug %s"]]
-* [[!shortcut name=ubupkg url="http://packages.ubuntu.com/%s"]]
+* [[!shortcut name=ubupkg url="https://packages.ubuntu.com/%s"]]
 * [[!shortcut name=mozillazinekb url="http://kb.mozillazine.org/%s"]]
-* [[!shortcut name=freebsdwiki url="http://wiki.freebsd.org/%s"]]
+* [[!shortcut name=freebsdwiki url="https://wiki.freebsd.org/%s"]]
 * [[!shortcut name=hackage url="http://hackage.haskell.org/package/%s"]]
-* [[!shortcut name=pkgsrc url="http://pkgsrc.se/%S"]]
+* [[!shortcut name=pkgsrc url="https://pkgsrc.se/%S"]]
 
 To add a new shortcut, use the `shortcut`
 [[ikiwiki/directive]]. In the url, "%s" is replaced with the
@@ -87,5 +87,5 @@
 
 # Shortcuts specific to this wiki
 
-* [[!shortcut name=nbbug url="http://gnats.netbsd.org/%s"]]
-* [[!shortcut name=nbcvsweb url="http://cvsweb.netbsd.org/bsdweb.cgi/%S"]]
+* [[!shortcut name=nbbug url="//gnats.netbsd.org/%s"]]
+* [[!shortcut name=nbcvsweb url="//cvsweb.netbsd.org/bsdweb.cgi/%S"]]
Index: wikisrc/templates/pkg.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/pkg.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/templates/pkg.mdwn	20 Jul 2026 12:49:19 -0000	1.8
+++ wikisrc/templates/pkg.mdwn	30 Jul 2026 22:18:44 -0000	1.9
@@ -1,5 +1,5 @@
 [[!templatebody <<ENDBODY
-[<TMPL_VAR NAME="category">/<TMPL_VAR NAME="name">](//pkgsrc.se/<TMPL_VAR ESCAPE=URL NAME="category">/<TMPL_VAR ESCAPE=URL NAME="name">)
+[<TMPL_VAR NAME="category">/<TMPL_VAR NAME="name">](https://pkgsrc.se/<TMPL_VAR ESCAPE=URL NAME="category">/<TMPL_VAR ESCAPE=URL NAME="name">)
 ENDBODY]]
 
 ## Description

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.20->1.21 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:51:29 -0000	1.20
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 19:35:05 -0000	1.21
@@ -82,8 +82,8 @@
 total 8.0G
 -rw-------  1 root  wheel  snap 4.0G Jun 22 02:29 20260622.store
 drwxr-xr-x  2 root  wheel  -    512B Jun 22 02:28 20260622
--rw-------  1 root  wheel  snap 4.0G Jul 06 01:18 20260729.store
-drwxr-xr-x  2 root  wheel  -    512B Jul 06 01:17 20260729
+-rw-------  1 root  wheel  snap 4.0G Jul 06 01:18 20260706.store
+drwxr-xr-x  2 root  wheel  -    512B Jul 06 01:17 20260706
 # du -ahx /altroot/.snap/
 1.6G    /altroot/.snap/20260622.store
 1.7M    /altroot/.snap/20260706.store

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:50:52 -0000	1.19
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:51:29 -0000	1.20
@@ -75,7 +75,7 @@
 “`-o`”; see [[!template id=man name=chflags section=1]].
 The nominal size of a snapshot file is the size of the whole file
 system, but it only uses up space for the old content of blocks that
-have been overwritten since it were taken:
+have been overwritten since it was taken:
 
 [[!template id=programlisting text="""
 # ls -hlo /altroot/.snap

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:47:03 -0000	1.18
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:50:52 -0000	1.19
@@ -175,7 +175,7 @@
 (Note that if you use [[!template id=man name="dump" section="8"]] and
 [[!template id=man name="restore" section="8"]] for backups,
 [[!template id=man name="dump" section="8"]] can automatically take a
-snapshot itself with the“`-X`” or
+snapshot itself with the “`-X`” or
 &ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
 [[!template id=man name="fssconfig" section="8"]] at all.)
 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:36:33 -0000	1.17
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:47:03 -0000	1.18
@@ -17,11 +17,11 @@
 
 Snapshots are often used to take backups.  For example, the
 [[!template id=man name="dump" section="8"]] tool for dumping a file
-system backup can take a snapshot with the `-x` or `-X` options (q.v.)
-to ensure that files such as sqlite3 databases aren't concurrently
-modified while it is trying to read them.  Snapshots can also be
-mounted like regular file systems to give read-only views of past
-states of file systems.
+system backup can take a snapshot with the “`-X`” or
+&ldquo;`-x <snapstore>`&rdquo; options (q.v.) to ensure that files such
+as sqlite3 databases aren't concurrently modified while it is trying to
+read them.  Snapshots can also be mounted like regular file systems to
+give read-only views of past states of file systems.
 
 On some file systems&mdash;ffs and zfs&mdash;snapshots can be
 **persistent**: you can take a snapshot, and it will persist until it
@@ -70,11 +70,12 @@
 about the directory name `.snap`; you can store snapshots anywhere in
 the file system.
 
-Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag (visible
+Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag, visible
 with the [[!template id=man name=ls section=1]] flag
-&ldquo;`-o`&rdquo;; see [[!template id=man name=chflags section=1]])
-with the size of the file system, but they only use up space for the
-old content of blocks that have been overwritten since they were taken:
+&ldquo;`-o`&rdquo;; see [[!template id=man name=chflags section=1]].
+The nominal size of a snapshot file is the size of the whole file
+system, but it only uses up space for the old content of blocks that
+have been overwritten since it were taken:
 
 [[!template id=programlisting text="""
 # ls -hlo /altroot/.snap
@@ -174,7 +175,8 @@
 (Note that if you use [[!template id=man name="dump" section="8"]] and
 [[!template id=man name="restore" section="8"]] for backups,
 [[!template id=man name="dump" section="8"]] can automatically take a
-snapshot itself with the `-x` or `-X` option; you don't need to use
+snapshot itself with the&ldquo;`-X`&rdquo; or
+&ldquo;`-x <snapstore>`&rdquo; option; you don't need to use
 [[!template id=man name="fssconfig" section="8"]] at all.)
 
 When the snapshot is unmounted and unconfigured, the backing store will
@@ -242,10 +244,10 @@
 from a snapshot with &ldquo;`zfs clone`&rdquo;.
 
 The snapshots of a file system are automounted on demand as
-subdirectories of its `.zfs/snapshot` directory, at the root of the
+subdirectories of its `.zfs/snapshot/` directory, at the root of the
 file system.  The `.zfs/` directory is hidden from directory listings
-by default, but it can be exposed with `zfs set snapdir=visible
-<pool>/<fs>`.
+by default, but it can be exposed with
+&ldquo;`zfs set snapdir=visible <pool>/<fs>`&rdquo;.
 
 The snapshots of a zvol are available at
 `/dev/zvol/dsk/<pool>/<zvol>@<snapname>` (block device) and

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:38:40 -0000	1.16
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 15:36:33 -0000	1.17
@@ -65,16 +65,16 @@
 # mount /dev/fss0 /home/.snap/20260706
 """]]
 
-Users can then browse their home directories in /home/.snap as they
+Users can then browse their home directories in `/home/.snap` as they
 existed at the time the snapshot was taken.  There's nothing special
 about the directory name `.snap`; you can store snapshots anywhere in
 the file system.
 
 Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag (visible
-with the [[!template id=man name=ls section=1]] flag `-o`; see
-[[!template id=man name=chflags section=1]]) with the size of the file
-system, but they only use up space for the old content of blocks that
-have been overwritten since they were taken:
+with the [[!template id=man name=ls section=1]] flag
+“`-o`”; see [[!template id=man name=chflags section=1]])
+with the size of the file system, but they only use up space for the
+old content of blocks that have been overwritten since they were taken:
 
 [[!template id=programlisting text="""
 # ls -hlo /altroot/.snap
@@ -232,12 +232,14 @@
 ## zfs snapshots
 
 In a zfs zpool, any dataset—a mountable file system or a zvol
-block device—can be snapshotted with the `zfs snapshot` command;
-see [[!template id=man name="zfs" section="8"]] for details.  The
-snapshots for a dataset `<pool>/<datasetpath>` are named
-`<pool>/<datasetpath>@<snapname>`, and can be listed with `zfs list -t
-snap <pool>/<datasetpath>`.  Datasets can be rolled back to a snapshot
-with `zfs rollback`, or cloned from a snapshot with `zfs clone`.
+block device&mdash;can be snapshotted with the
+&ldquo;`zfs snapshot`&rdquo; command; see
+[[!template id=man name="zfs" section="8"]] for details.  The snapshots
+for a dataset `<pool>/<datasetpath>` are named
+`<pool>/<datasetpath>@<snapname>`, and can be listed with
+&ldquo;`zfs list -t snap <pool>/<datasetpath>`&rdquo;.  Datasets can be
+rolled back to a snapshot with &ldquo;`zfs rollback`&rdquo;, or cloned
+from a snapshot with &ldquo;`zfs clone`&rdquo;.
 
 The snapshots of a file system are automounted on demand as
 subdirectories of its `.zfs/snapshot` directory, at the root of the
@@ -257,7 +259,7 @@
 # zfs snapshot -r rpool/home@20260706
 """]]
 
-The current state of /home will now be visible under
+The current state of `/home` will now be visible under
 `/home/.zfs/snapshot/20260706`.  If you have a separate zfs file system
 for each user's home directory, the current state of jruser's home
 directory will be visible under `/home/jruser/.zfs/snapshot/20260706`
@@ -268,8 +270,8 @@
 
 You can recover individual files from the `.zfs/snapshot/<snapname>/`
 directory, but you can also roll back a whole file system to the latest
-snapshot with `zfs rollback`:
+snapshot with &ldquo;`zfs rollback`&rdquo;:
 
 [[!template id=programlisting text="""
-    # zfs rollback rpool/home/jruser@20260706
+# zfs rollback rpool/home/jruser@20260706
 """]]

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:37:26 -0000	1.15
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:38:40 -0000	1.16
@@ -94,7 +94,7 @@
 Note: [[!template id=man name=find section=1]] cannot currently filter
 for snapshot files; see [[!template id=pr number=60380]].  Also,
 [[!template id=man name=file section=1]] does not recognize snapshot
-files as such; see [[!template id=pr number=60380]].
+files as such; see [[!template id=pr number=60379]].
 
 The snapshot can be unmounted and unconfigured:
 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:34:40 -0000	1.14
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:37:26 -0000	1.15
@@ -48,7 +48,7 @@
 stored at any time.  For ffs, this limit is 20.
 
 In ffs, overwriting a block that was in use in multiple snapshots
-causes the a copy of old block content to be saved in *each* of the
+causes a copy of old block content to be saved in *each* of the
 snapshots separately.  So while snapshots are more space-efficient than
 copies when most blocks are unchanged, they can cause write
 amplification by a factor of up to the number of snapshots when many

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.13->1.14 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:16:23 -0000	1.13
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 13:34:40 -0000	1.14
@@ -8,8 +8,12 @@
 in time.  If you take a snapshot of a file system, and then create a
 new file or modify an existing one or make any other changes to the
 file system, and the snapshot will still have the old version of the
-file system without the changes.  Unlike copies, snapshots don't take
-much extra space.
+file system without the changes.
+
+Unlike copies, snapshots use space on disk only for data that have been
+overwritten since the snapshot was taken, and can be taken for the
+whole file system at once without any cooperation from applications to
+suspend their activity.
 
 Snapshots are often used to take backups.  For example, the
 [[!template id=man name="dump" section="8"]] tool for dumping a file
@@ -29,7 +33,7 @@
 
 *Persistent snapshots are currently supported for ffs file systems
 only—not to be confused with the fss file system snapshot
-device.*
+device used to manage them.*
 
 A persistent snapshot of a file system is represented by a regular file
 *inside* the file system, with a special flag (so it can't be read or
@@ -43,6 +47,13 @@
 File systems may impose a limit on the number of snapshots that can be
 stored at any time.  For ffs, this limit is 20.
 
+In ffs, overwriting a block that was in use in multiple snapshots
+causes the a copy of old block content to be saved in *each* of the
+snapshots separately.  So while snapshots are more space-efficient than
+copies when most blocks are unchanged, they can cause write
+amplification by a factor of up to the number of snapshots when many
+blocks are changing.
+
 ### Example: Taking a snapshot
 
 To create and mount a persistent snapshot of the `/home` file system,
@@ -59,6 +70,32 @@
 about the directory name `.snap`; you can store snapshots anywhere in
 the file system.
 
+Snapshots appear as files with the `snap` (`SF_SNAPSHOT`) flag (visible
+with the [[!template id=man name=ls section=1]] flag `-o`; see
+[[!template id=man name=chflags section=1]]) with the size of the file
+system, but they only use up space for the old content of blocks that
+have been overwritten since they were taken:
+
+[[!template id=programlisting text="""
+# ls -hlo /altroot/.snap
+total 8.0G
+-rw-------  1 root  wheel  snap 4.0G Jun 22 02:29 20260622.store
+drwxr-xr-x  2 root  wheel  -    512B Jun 22 02:28 20260622
+-rw-------  1 root  wheel  snap 4.0G Jul 06 01:18 20260729.store
+drwxr-xr-x  2 root  wheel  -    512B Jul 06 01:17 20260729
+# du -ahx /altroot/.snap/
+1.6G    /altroot/.snap/20260622.store
+1.7M    /altroot/.snap/20260706.store
+2.0K    /altroot/.snap/20260622
+2.0K    /altroot/.snap/20260706
+1.6G    /altroot/.snap/
+"""]]
+
+Note: [[!template id=man name=find section=1]] cannot currently filter
+for snapshot files; see [[!template id=pr number=60380]].  Also,
+[[!template id=man name=file section=1]] does not recognize snapshot
+files as such; see [[!template id=pr number=60380]].
+
 The snapshot can be unmounted and unconfigured:
 
 [[!template id=programlisting text="""
@@ -198,14 +235,15 @@
 block device—can be snapshotted with the `zfs snapshot` command;
 see [[!template id=man name="zfs" section="8"]] for details.  The
 snapshots for a dataset `<pool>/<datasetpath>` are named
-`<pool>/<datasetpath>@<snapname>`.  Datasets can be rolled back to a
-snapshot with `zfs rollback`, or cloned from a snapshot with `zfs
-clone`.
-
-The snapshots of a file system are available as subdirectories of its
-`.zfs/snapshot` directory, at the root of the file system.  The `.zfs/`
-directory is hidden from directory listings by default, but it can be
-exposed with `zfs set snapdir=visible <pool>/<fs>`.
+`<pool>/<datasetpath>@<snapname>`, and can be listed with `zfs list -t
+snap <pool>/<datasetpath>`.  Datasets can be rolled back to a snapshot
+with `zfs rollback`, or cloned from a snapshot with `zfs clone`.
+
+The snapshots of a file system are automounted on demand as
+subdirectories of its `.zfs/snapshot` directory, at the root of the
+file system.  The `.zfs/` directory is hidden from directory listings
+by default, but it can be exposed with `zfs set snapdir=visible
+<pool>/<fs>`.
 
 The snapshots of a zvol are available at
 `/dev/zvol/dsk/<pool>/<zvol>@<snapname>` (block device) and

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.12->1.13 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:15:32 -0000	1.12
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:16:23 -0000	1.13
@@ -99,6 +99,7 @@
 [[!template id=programlisting text="""
 # umount /home/.snap/20260706
 # fssconfig -u fss0
+# rmdir /home/.snap/20260706
 # rm /home/.snap/20260706.store
 """]]
 

Members: 
	tutorials/how_to_use_snapshots.mdwn:1.11->1.12 

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:05:51 -0000	1.11
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:15:32 -0000	1.12
@@ -99,7 +99,7 @@
 [[!template id=programlisting text="""
 # umount /home/.snap/20260706
 # fssconfig -u fss0
-# rm /home/.snap/20260706
+# rm /home/.snap/20260706.store
 """]]
 
 ### Example: Single-use snapshot to take a backup

Index: wikisrc/tutorials/how_to_use_snapshots.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/how_to_use_snapshots.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/tutorials/how_to_use_snapshots.mdwn	18 Jul 2026 23:15:50 -0000	1.10
+++ wikisrc/tutorials/how_to_use_snapshots.mdwn	30 Jul 2026 06:05:51 -0000	1.11
@@ -129,7 +129,7 @@
       borg create borghost:/path/to/repo::var-20260706 .)
 # ssh rsynchost mkdir /backups/$(hostname)/var/20260706 &&
   rsync -aHc --link-dest=/backups/$(hostname)/var/latest/. \
-      /var/.snapshot/. rsynchost:/backups/$(hostname)/var/. &&
+      /var/.snapshot/. rsynchost:/backups/$(hostname)/var/20260706/. &&
   ssh rsynchost ln -sfn 20260706 /backups/$(hostname)/var/latest
 """]]
 

Index: wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	27 Jul 2026 15:23:46 -0000	1.6
+++ wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	27 Jul 2026 18:56:40 -0000	1.7
@@ -24,6 +24,7 @@
 Harold | `hgutch@` | yes | n/a
 Stephen | `sborrill@` | yes | 10th or 11th, please
 Adrian | `ast@` | yes | n/a
+Yuri | `yurix@` | yes | n/a
 """]]
 
 ## Planning to present something?

Index: wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	30 Jun 2026 10:17:40 -0000	1.5
+++ wikisrc/summits/eurobsdcon_2026_netbsd_summit.mdwn	27 Jul 2026 15:23:46 -0000	1.6
@@ -23,6 +23,7 @@
 First Last | `login@` | join dinner? | comment(s)
 Harold | `hgutch@` | yes | n/a
 Stephen | `sborrill@` | yes | 10th or 11th, please
+Adrian | `ast@` | yes | n/a
 """]]
 
 ## Planning to present something?

Index: wikisrc/releasing.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releasing.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/releasing.mdwn	26 Jul 2026 15:15:56 -0000	1.1
+++ wikisrc/releasing.mdwn	26 Jul 2026 15:21:08 -0000	1.2
@@ -43,6 +43,9 @@
   will be backed out immediately (and postponed after the first release).
   The release engineering team might make exceptions from this rule if the fix
   is clear and quick, in cooperation with the requesting developer.
+* The first release should not be delayed longer than four months after 
+  the branch has been created. Any pending changes will go in for the
+  first dot-one release two months later.
 
 ## General rules for pullups for all release branches
 

--- /dev/null	2026-07-26 15:16:00.726934412 +0000
+++ wikisrc/releasing.mdwn	2026-07-26 15:16:38.871536686 +0000
@@ -0,0 +1,61 @@
+** This is not an official policy yet, but work-in-progress! **
+
+It will be published more loudly once the release engineering
+team has agreed on it and the details are polished.
+
+# Handling of branches
+
+## Branching for a new major release branch
+
+We try to branch for a new major release branch about once a year.
+This is not a date controlled process, and requires some coordination.
+Before we get ready to branch, the driving release engineer will
+
+* Push maintainers of stuff mentioned in ``doc/3RDPARTY`` and get feedback
+  about missing or planned updates.
+* Coordinate with the toolchain team to allow for a single gcc/binutils
+  tree on the branch, by making sure only a single one of each is active
+  and deleting the unused ones post-branch.
+* Publicaly announce a tentative branch date, pointing at this policy, asking developers
+  to *not* rush in anything last minute before the branch, and ask for allowance
+  if they are unsure on some mostly-done change. See below for a strict
+  post-branch backout rule in case any last minute changes cause issues.
+
+When getting close to the announced branch date, a reminder will be sent out
+asking developers to exercise extra care with all further commits until the 
+branch has happened.
+
+## Handling of new major release branches in the first few weeks
+
+Since we only know how good a branch point was after the fact and when first
+test results for the new branch become available (which might be delayed by
+setup requiring a few days after the branch happened), the first few weeks
+of the new branch will be monitored more closely.
+
+If the release engineering team decides some changes that went in later
+before the branch, the offending changes will be backed out on the branch.
+
+## General rules for pullups before the first release on a branch
+
+* No feature additions (whatever small) will be pulled up
+* No third-party updates will be pulled up
+* Any pullups that cause new test failures or build breakage
+  will be backed out immediately (and postponed after the first release).
+  The release engineering team might make exceptions from this rule if the fix
+  is clear and quick, in cooperation with the requesting developer.
+
+## General rules for pullups for all release branches
+
+* **TBD** - copy the existing policy over here
+* The developers processing pullups are requested to immediately
+  revert all pullup request that appear to not have been tested
+  (or obviously are broken). The branch should be buildable and
+  and tests in good shape always.
+
+# Timeline
+
+The release engineering team will try to meet the following timeline
+
+* One new major branch and release per year
+* One point release for the newest stable branch every other month
+* One point release for the old stable branch every quarter

Index: wikisrc/releng.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/releng.mdwn,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- wikisrc/releng.mdwn	7 Feb 2026 10:46:25 -0000	1.60
+++ wikisrc/releng.mdwn	26 Jul 2026 08:36:40 -0000	1.61
@@ -42,4 +42,5 @@
 ##  Release Engineer Documentation
 
 * [[Pull-up workflow and policies|workflow]]
+* [[WIP: new branching, pullup and release policies|releasing]]
 * ~~[[Long and mid-term releng chores|releng-todo]]~~

Index: wikisrc/users/jun/2025.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun/2025.mdwn,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wikisrc/users/jun/2025.mdwn	27 Dec 2025 10:44:55 -0000	1.1
+++ wikisrc/users/jun/2025.mdwn	23 Jul 2026 03:00:04 -0000	1.2
@@ -5,7 +5,7 @@
 - [[https://event.ospn.jp/osc2025-hiroshima/]]
 - Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2025hiroshima.pdf]]
 - togetter [[https://posfie.com/@ebijun/p/WkwSt6x]]
-- [[https://www.pastel-flower.jp/~isaki/NetBSD/osc23hi/]]
+- [[https://www.pastel-flower.jp/~isaki/NetBSD/osc25hi/]]
 - [[https://speakerdeck.com/tsutsui/osc2025hiroshima]]
 
 ## Open Source Conference 2025 Okinawa NetBSD Booth&BoF

Index: wikisrc/users/jun.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/users/jun.mdwn,v
retrieving revision 1.154
retrieving revision 1.155
diff -u -r1.154 -r1.155
--- wikisrc/users/jun.mdwn	30 Jun 2026 10:03:51 -0000	1.154
+++ wikisrc/users/jun.mdwn	23 Jul 2026 02:58:46 -0000	1.155
@@ -9,36 +9,42 @@
 ## Event Updates [[https://www.facebook.com/NetBSD.jp]]
 
 #2026
-## Japan NetBSD Users' Group 23th annual meeting and NetBSD BoF 2026
-- 2026 Jul.5 13:00-18:00 Nezu,Tokyo Univ.,VDEC
-- [[http://www.jp.netbsd.org/ja/JP/JNUG/announce/meeting23.html]]
-- [[https://www.facebook.com/events/1547607546993967]]
-- [[http://www.vdec.u-tokyo.ac.jp/Guide/access.html]]
-
-## Open Source Conference 2026 Shimane NetBSD Booth
-- Booth: 2026 Jul.11 Sat 10:00-17:00 JST (UTC+9)
-- Matsue Terusa,near by JR Matsue station
-- Session: 
-- [[https://event.ospn.jp/osc2026-shimane/]]
-- Tour Guide [[]]
-- togetter [[]]
-
 ## Open Source Conference 2026 Kyoto NetBSD Booth & NetBSD BoF
 - 2025 Aug.1 Sat 10:00-16:00 JST (UTC+9) 
-- 2025 Aug.1 Sat 16:00-16:45 JST (UTC+9) NetBSD BoF [[https://event.ospn.jp/osc2026-kyoto/session/2329485]]
-
+- 2025 Aug.1 Sat 16:00-16:45 JST (UTC+9) NetBSD BoF at Room2B [[https://event.ospn.jp/osc2026-kyoto/session/2329485]]
 - Kyoto Research Park [[https://www.krp.co.jp/access/map.html]]
 - [[https://event.ospn.jp/osc2026-kyoto/]]
 - Tour Guide [[]]
-- togetter [[]]
+- togetter [[https://posfie.com/@ebijun/p/k4thRpd]]
 
 ## Open Developers Conference 2026 NetBSD BoF
-- 2026 Aug.27 Sat 12:00-12:45 JST (UTC+9)
+- 2026 Aug.29 Sat 11:00-11:45 JST (UTC+9)
 - [[https://event.ospn.jp/odc2026/]]
 - Nihon Kogakuin Kamata Campus [[https://www.neec.ac.jp/portal/access/kamata/]]
 - Tour Guide [[]]
 - togetter [[]]
 
+
+## Open Source Conference 2026 Hiroshima NetBSD Booth&BoF
+- 2026 Sep.12 Sun 10:00-18:00 JST (UTC+9)
+- https://event.ospn.jp/osc2026-hiroshima/
+- Tour Guide [[]]
+- togetter [[]]
+
+## Open Source Conference 2026 Online/Fall BSD BoF
+- 2025 Oct.2(Fri)-3(Sat) 10:00-18:00 JST (UTC+9)
+- https://event.ospn.jp/osc2026-online-fall/
+- BSD BoF XX:00-XX:45 JST (UTC+9) 
+- Tour Guide [[]]
+- togetter [[]]
+
+## Open Source Conference 2025 Tokyo/Fall NetBSD Booth
+- Booth: 2026 Oct.17 Sat 10:00-16:00 JST (UTC+9)
+- Toritsu Sangyo Boueki Center Taito-kan [[https://www.sanbo.metro.tokyo.lg.jp/taito/access/ Asakusa,Tokyo]]
+- [[https://event.ospn.jp/osc2026-fall/]]
+- Tour Guide [[]]
+- togetter [[]]
+
 ## Kansai Open Forum 2026
 - 2026 Nov.13 Fri-14 Sat 10:50-18:00 JST (UTC+9) 
 - [[https://www.k-of.jp/]]
@@ -48,7 +54,28 @@
 - togetter [[]]
 - youtube[[]]
 
+## Open Source Conference 2025 Fukuoka NetBSD Booth
+- Booth: 2025 Dec.12 Sat 10:00-16:00 JST (UTC+9)
+- NetBSD BoF Dec.12 Sat XX:00-XX:45 JST (UTC+9)
+- FUKUOKA UNIVERSITY [[https://www.fukuoka-u.ac.jp/help/map/]]
+- https://event.ospn.jp/osc2026-fukuoka/
+- Tour Guide [[]]
+- togetter [[]]
+
 # Past in 2026
+## Open Source Conference 2026 Shimane NetBSD Booth
+- Booth: 2026 Jul.11 Sat 10:00-17:00 JST (UTC+9)
+- Matsue Terusa,near by JR Matsue station
+- Session: 
+- [[https://event.ospn.jp/osc2026-shimane/]]
+- Tour Guide [[https://cdn.netbsd.org/pub/NetBSD/misc/jun/OSC/OSC2026shimane.pdf]]
+- togetter [[https://posfie.com/@ebijun/p/s0cekjK]]
+
+## Japan NetBSD Users' Group 23th annual meeting and NetBSD BoF 2026
+- 2026 Jul.5 13:00-18:00 Nezu,Tokyo Univ.,VDEC
+- [[http://www.jp.netbsd.org/ja/JP/JNUG/announce/meeting23.html]]
+- [[https://www.facebook.com/events/1547607546993967]]
+- [[http://www.vdec.u-tokyo.ac.jp/Guide/access.html]]
 
 ## Open Source Conference 2026 Hokkaido NetBSD Booth and NetBSD BoF
 - 2026 Jun.27 Sat 10:00-18:00 JST (UTC+9)

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.282
retrieving revision 1.283
diff -u -r1.282 -r1.283
--- wikisrc/ports/xen/howto.mdwn	20 Jul 2026 14:44:58 -0000	1.282
+++ wikisrc/ports/xen/howto.mdwn	22 Jul 2026 11:32:05 -0000	1.283
@@ -646,7 +646,7 @@
 domU serves as a network file server.
 
 [[!template id=filecontent name="/usr/pkg/etc/xen/foo" text="""
-name = "domU-id"
+name = "foo"
 kernel = "/netbsd-XEN3PAE_DOMU-i386-foo.gz"
 memory = 1024
 vif = [ 'mac=aa:00:00:d1:00:09,bridge=bridge0' ]
@@ -675,9 +675,9 @@
 
 [[!template id=programlisting text="""
 xl create /usr/pkg/etc/xen/foo
-xl console domU-id
+xl console foo
 xl create -c /usr/pkg/etc/xen/foo
-xl shutdown domU-id
+xl shutdown foo
 xl list
 """]]
 

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.281
retrieving revision 1.282
diff -u -r1.281 -r1.282
--- wikisrc/ports/xen/howto.mdwn	20 Jul 2026 12:41:31 -0000	1.281
+++ wikisrc/ports/xen/howto.mdwn	20 Jul 2026 14:44:58 -0000	1.282
@@ -995,7 +995,7 @@
 \todo Expand to say NetBSD 10 and later.
 
 \todo Include needing to add DOM0 OPS and the dom0-flavored
-psuedodevices to GENERIC.
+pseudodevices to GENERIC.
 
 In boot.cfg, add dom0=pvh (dom0=pv is the default).  Configure GENERIC
 instead of XEN3_DOM0.
@@ -1010,7 +1010,7 @@
 
 ## Creating a NetBSD HVM domU
 
-Use type='hvm'.  Use a GENERIC kernel within the disk image, or an
+Use `type='hvm'`.  Use a GENERIC kernel within the disk image, or an
 INSTALL cd image.  The disk image should have bootblocks, as if it
 were a real machine.  (Note that because GENERIC has PV drivers, this
 will be PVHVM, unless you remove or disable them.)
@@ -1020,15 +1020,16 @@
 
 The graphical console will be accessible with VNC on 127.0.0.1 port 5900.
 To change the IP address use vnclisten="IP.AD.DR.ESS".
-To change the port use vncdisplay=XX where XX will be added to 5900 to determine
+Use `vnclisten="0.0.0.0"` to listen on all IP addresses on the dom0.
+To change the port use `vncdisplay=XX` where XX will be added to 5900 to determine
 the port to use.
 A plain-text password may be specified with vncpasswd.
 You may need to specify a different keymap if en-us isn't what you use with
-the keymap option (e.g. keymap="en-gb"). N.B. specifying a non-existent
-keymap may create a zombie VM that cannot be destroyed. Adding usbdevice="tablet"
-will make the VM's mouse pointer align correctly.
+the keymap option (e.g. `keymap="en-gb"`). N.B. specifying a non-existent
+keymap may create a zombie VM that cannot be destroyed.
+Adding `usbdevice="tablet"` will make the VM's mouse pointer align correctly.
 
-To enable a text (serial) console that you can access with xl console, add serial="pty".
+To enable a text (serial) console that you can access with xl console, add `serial="pty"`.
 e.g. if you boot from a boot-com.iso image, you can install without using VNC.
 
 [[!template id=filecontent name="After installation" text="""
@@ -1040,6 +1041,7 @@
 disk =  [ 'format=raw, vdev=hda, access=rw,
            target=/dev/zvol/rdsk/tank/foo' ]
 boot = "c"
+vnclisten="0.0.0.0"
 """]]
 
 [[!template id=filecontent name="Install from CD" text="""
@@ -1053,6 +1055,8 @@
           'format=raw, vdev=hdc, access=ro,
            target=/n0/xen/iso/NetBSD-10.1_STABLE-amd64.iso' ]
 boot = "d"
+vnclisten = "0.0.0.0"
+vncpasswd = "secret"
 """]]
 
 N.B. the vdev device for a cdrom device MUST be given as hdc, not hdb,
@@ -1176,7 +1180,7 @@
            target=/n0/xen/iso/SW_DVD9_Win_Server_STD_CORE_2022_2108.6_64Bit_English_DC_STD_MLF_X23-03231.ISO' ]
 
 vncdisplay=0
-#vncpasswd="secret"
+vncpasswd="secret"
 vnclisten="0.0.0.0"
 keymap="en-gb"
 usbdevice = "tablet"

Members: 
	templates/note.mdwn:1.2->1.3 
	templates/page.tmpl:1.77->1.78 
	templates/pkg.mdwn:1.7->1.8 
	templates/port.mdwn:1.34->1.35 
	templates/pr.mdwn:1.8->1.9 

Index: wikisrc/templates/note.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/note.mdwn,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- wikisrc/templates/note.mdwn	23 Mar 2024 18:33:22 -0000	1.2
+++ wikisrc/templates/note.mdwn	20 Jul 2026 12:49:19 -0000	1.3
@@ -12,12 +12,12 @@
 
 ## Examples
 
-Some text floating to the right, with the [NetBSD's logo](http://www.netbsd.org/gallery/logos.html):
+Some text floating to the right, with the [NetBSD's logo](//www.NetBSD.org/gallery/logos.html):
 
 [[!template id=note text="""
-<img src="http://www.netbsd.org/images/NetBSD-smaller.png" /><br />
+<img src="//www.NetBSD.org/images/NetBSD-smaller.png" /><br />
 The official NetBSD Foundation Logo."""]]
 
         \[[!template id=note text="""
-        <img src="http://www.netbsd.org/images/NetBSD-smaller.png" /><br />
+        <img src="//www.NetBSD.org/images/NetBSD-smaller.png" /><br />
         The official NetBSD Foundation Logo."""]]
Index: wikisrc/templates/page.tmpl
===================================================================
RCS file: /cvsroot/wikisrc/templates/page.tmpl,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -r1.77 -r1.78
--- wikisrc/templates/page.tmpl	2 Jan 2026 06:03:12 -0000	1.77
+++ wikisrc/templates/page.tmpl	20 Jul 2026 12:49:19 -0000	1.78
@@ -13,9 +13,9 @@
 <TMPL_IF NAME="FAVICON">
 <link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" />
 </TMPL_IF>
-<link rel="stylesheet" href="//wiki.netbsd.org/global.css" type="text/css" />
-<link rel="stylesheet" href="//www.netbsd.org/donations/thermo/fundraiser.css" type="text/css" />
-<link rel="stylesheet" href="//wiki.netbsd.org/style.css" type="text/css" />
+<link rel="stylesheet" href="//wiki.NetBSD.org/global.css" type="text/css" />
+<link rel="stylesheet" href="//www.NetBSD.org/donations/thermo/fundraiser.css" type="text/css" />
+<link rel="stylesheet" href="//wiki.NetBSD.org/style.css" type="text/css" />
 <TMPL_IF LOCAL_CSS>
 <link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" />
 <TMPL_ELSE>
@@ -45,7 +45,7 @@
           <div id="logo">
             <a href="//www.NetBSD.org/"><img id="projectLogo" src="//www.NetBSD.org/images/NetBSD-smaller-tb.png" alt="" height="120"/></a>
           </div>
-            <a href="https://netbsd.org/donations/#how-to-donate">
+            <a href="https://www.NetBSD.org/donations/#how-to-donate">
               <div id="fundraiser">
                 <br />
                 <div id="fundraiser-amount">
@@ -115,7 +115,7 @@
 	<li>
 	<a href="//www.NetBSD.org/developers/">
 		  Developers</a><ul>
-	<li><a href="http://cvsweb.NetBSD.org/">
+	<li><a href="//cvsweb.NetBSD.org/">
 		    CVSWeb</a></li>
 	<li><a href="//anonhg.NetBSD.org/">
 		    Mercurial</a></li>
Index: wikisrc/templates/pkg.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/pkg.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/templates/pkg.mdwn	7 Dec 2015 23:12:48 -0000	1.7
+++ wikisrc/templates/pkg.mdwn	20 Jul 2026 12:49:19 -0000	1.8
@@ -1,10 +1,10 @@
 [[!templatebody <<ENDBODY
-[<TMPL_VAR NAME="category">/<TMPL_VAR NAME="name">](http://pkgsrc.se/<TMPL_VAR ESCAPE=URL NAME="category">/<TMPL_VAR ESCAPE=URL NAME="name">)
+[<TMPL_VAR NAME="category">/<TMPL_VAR NAME="name">](//pkgsrc.se/<TMPL_VAR ESCAPE=URL NAME="category">/<TMPL_VAR ESCAPE=URL NAME="name">)
 ENDBODY]]
 
 ## Description
 
-Use this template to create a link to a [pkgsrc](http://www.pkgsrc.org)'s package. The template uses two parameters:
+Use this template to create a link to a [pkgsrc](//www.pkgsrc.org)'s package. The template uses two parameters:
 
 * *category* - This required parameter is the category of the package.
 * *name* - This required parameter is the name of the package.
Index: wikisrc/templates/port.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/port.mdwn,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- wikisrc/templates/port.mdwn	15 Jan 2025 19:24:58 -0000	1.34
+++ wikisrc/templates/port.mdwn	20 Jul 2026 12:49:19 -0000	1.35
@@ -232,19 +232,19 @@
 
 ## Mailing List
 <TMPL_IF port_alt>
-The [NetBSD/<TMPL_VAR port_alt> mailing list](http://www.netbsd.org/mailinglists/#port-<TMPL_VAR port_alt> "<TMPL_VAR port_alt>mailing list"), covering NetBSD's port to <TMPL_VAR port_alt> machine:
+The [NetBSD/<TMPL_VAR port_alt> mailing list](//www.NetBSD.org/mailinglists/#port-<TMPL_VAR port_alt> "<TMPL_VAR port_alt>mailing list"), covering NetBSD's port to <TMPL_VAR port_alt> machine:
 [
-<a href="http://www.NetBSD.org/cgi-bin/subscribe_list.pl?list=port-<TMPL_VAR port_alt>">subscribe</a>
+<a href="//www.NetBSD.org/cgi-bin/subscribe_list.pl?list=port-<TMPL_VAR port_alt>">subscribe</a>
 |
-<a href="http://mail-index.NetBSD.org/port-<TMPL_VAR port_alt>/">archive</a>
+<a href="//mail-index.NetBSD.org/port-<TMPL_VAR port_alt>/">archive</a>
 ]
 
 <TMPL_ELSE>
-The [NetBSD/<TMPL_VAR port> mailing list](http://www.netbsd.org/mailinglists/#port-<TMPL_VAR port> "<TMPL_VAR port>mailing list"), covering NetBSD's port to <TMPL_VAR port> machine:
+The [NetBSD/<TMPL_VAR port> mailing list](//www.NetBSD.org/mailinglists/#port-<TMPL_VAR port> "<TMPL_VAR port>mailing list"), covering NetBSD's port to <TMPL_VAR port> machine:
 [
-<a href="http://www.NetBSD.org/cgi-bin/subscribe_list.pl?list=port-<TMPL_VAR port>">subscribe</a>
+<a href="//www.NetBSD.org/cgi-bin/subscribe_list.pl?list=port-<TMPL_VAR port>">subscribe</a>
 |
-<a href="http://mail-index.NetBSD.org/port-<TMPL_VAR port>/">archive</a>
+<a href="//mail-index.NetBSD.org/port-<TMPL_VAR port>/">archive</a>
 ]
 
 </TMPL_IF>
Index: wikisrc/templates/pr.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/pr.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/templates/pr.mdwn	20 Jul 2026 12:43:49 -0000	1.8
+++ wikisrc/templates/pr.mdwn	20 Jul 2026 12:49:19 -0000	1.9
@@ -1,5 +1,5 @@
 [[!templatebody <<ENDBODY
-[PR #<TMPL_VAR NAME="number">](//gnats.netbsd.org/<TMPL_VAR ESCAPE=URL NAME="number">)
+[PR #<TMPL_VAR NAME="number">](//gnats.NetBSD.org/<TMPL_VAR ESCAPE=URL NAME="number">)
 ENDBODY]]
 
 ## Description

Members: 
	templates/pr.mdwn:1.7->1.8 

Index: wikisrc/templates/pr.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/pr.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/templates/pr.mdwn	7 Dec 2015 23:12:48 -0000	1.7
+++ wikisrc/templates/pr.mdwn	20 Jul 2026 12:43:49 -0000	1.8
@@ -1,5 +1,5 @@
 [[!templatebody <<ENDBODY
-[PR #<TMPL_VAR NAME="number">](http://gnats.netbsd.org/<TMPL_VAR ESCAPE=URL NAME="number">)
+[PR #<TMPL_VAR NAME="number">](//gnats.netbsd.org/<TMPL_VAR ESCAPE=URL NAME="number">)
 ENDBODY]]
 
 ## Description

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.280
retrieving revision 1.281
diff -u -r1.280 -r1.281
--- wikisrc/ports/xen/howto.mdwn	20 Jul 2026 09:38:46 -0000	1.280
+++ wikisrc/ports/xen/howto.mdwn	20 Jul 2026 12:41:31 -0000	1.281
@@ -448,7 +448,8 @@
 
 On modern hardware with many CPUs, the DOM0 kernel may panic with a
 message similar to `panic: pirq 4991 out of bound, increase NR_PIRQS`
-(NR_PIRQS is [set to 4096 on amd64](https://nxr.netbsd.org/xref/src/sys/external/mit/xen-include-public/dist/xen/include/public/xen.h#619)).
+(NR_PIRQS is [set to 4096 on amd64](https://nxr.netbsd.org/xref/src/sys/external/mit/xen-include-public/dist/xen/include/public/xen.h?r=1.2#619);
+see [[!template id=pr number=60466]]).
 A tested workaround for this is to add `dom0_max_vcpus=1
 dom0_vcpus_pin`, to force only one vcpu to be provided and to pin that
 vcpu to a physical CPU.

Index: wikisrc/ports/xen/howto.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/ports/xen/howto.mdwn,v
retrieving revision 1.279
retrieving revision 1.280
diff -u -r1.279 -r1.280
--- wikisrc/ports/xen/howto.mdwn	1 Oct 2025 22:19:02 -0000	1.279
+++ wikisrc/ports/xen/howto.mdwn	20 Jul 2026 09:38:46 -0000	1.280
@@ -438,21 +438,20 @@
 ### Xen Options Related to NetBSD Versions
 
 See [xen-command-line.html(7)](https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html),
-but other than dom0 memory and
-max_vcpus, tuning options are not generally necessary.
+but other than dom0_mem and
+dom0_max_vcpus, tuning options are not generally necessary.
 
 When the dom0 kernel is NetBSD 9 before 2021-04-17 (9.3 is ok), Xen
 4.15 and later require "dom0=msr-relaxed=1" on the boof.cfg line.
 (See /src/sys/arch/x86/x86/pmap.c revision 1.410.)  However, no one
 should be running early NetBSD 9 in 2024 or later, so fix that instead.
 
-With NetBSD 9 and below, one could add `dom0_max_vcpus=1
+On modern hardware with many CPUs, the DOM0 kernel may panic with a
+message similar to `panic: pirq 4991 out of bound, increase NR_PIRQS`
+(NR_PIRQS is [set to 4096 on amd64](https://nxr.netbsd.org/xref/src/sys/external/mit/xen-include-public/dist/xen/include/public/xen.h#619)).
+A tested workaround for this is to add `dom0_max_vcpus=1
 dom0_vcpus_pin`, to force only one vcpu to be provided and to pin that
-vcpu to a physical CPU.  \todo Explain if anyone has ever actually
-measured that this helps, or delete it entirely.
-
-With NetBSD 10 and up, there does not seem to be an argument that
-pinning or limiting CPUs is a good idea.
+vcpu to a physical CPU.
 
 From discussion on port-xen@, some machines have problems with
 timekeeping, and sometimes having one CPU, and further pinned, seems

- Use ramdisk, not kernel module.  Simpler, and doesn't pose kernel
  version compatibility issues on upgrades.

- Don't claim disk encryption defends against tampering.  It
  absolutely does not.  Clarify what threats it does defend against.

- Link to 10.1 versions of things.

Members: 
	security/cgdroot.mdwn:1.23->1.24 

Index: wikisrc/security/cgdroot.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/security/cgdroot.mdwn,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- wikisrc/security/cgdroot.mdwn	15 Jan 2025 19:24:58 -0000	1.23
+++ wikisrc/security/cgdroot.mdwn	20 Jul 2026 01:22:58 -0000	1.24
@@ -1,52 +1,59 @@
-[[!meta title="Root Filesystem Encryption"]]
+[[!meta title="Full Disk Encryption"]]
 
-[[!template id=needs-update reason="""
-the `fs ramdisk-cgdroot.fs` in [[!template id=man name="boot.cfg" section="5"]] obviates the need for a custom kernel module with the ramdisk embedded
-"""]]
+NetBSD supports full disk encryption with [[!template id=man name=cgd section=4]].
 
-It is possible to run NetBSD with [complete root filesystem encryption][1], thanks to the `cgdroot.kmod` kernel module. It really is a memory disk (also knows as RAM disk) that is expected to be loaded in the kernel while booting. It is named after CGD, the "cryptographic device driver", which implements encryption for storage in the NetBSD kernel.
+Disk encryption prevents disclosure of secrets stored on encrypted partitions while the machine is powered off in the event of theft, or if you recycle the disk later.  With _partial_ disk encryption, e.g. encrypting just the /home partition but not the / partition in a laptop's internal disk, there may be some secrets stored in unencrypted parts of the disk, such as wifi keys in /etc/wpa_supplicant.conf, IPsec keys in /etc/ipsec.conf or /etc/racoon/psk.txt, or hashed passphrases in /etc/master.passwd.  Full disk encryption covers the whole disk, including the / partition.
 
-The mechanism described here still requires one unencrypted partition to boot from (typically `wd0a`). Full disk encryption would make it more difficult for an attacker to modify the unencrypted part of the disk to plant a backdoor. With only partial encryption, the original [[!template id=man name="cgdconfig" section="8"]] binary may be modified to send the passphrase away, allowing an attacker with a disk dump to recover the data.
+The mechanism described here still requires one unencrypted partition to boot from.  This partition can be on a removable medium such as a USB flash drive, which can be removed after boot.
 
-The NetBSD Guide contains [an entire section about CGD][2].
+Note: Disk encryption does not defend against _tampering_ with a disk.  See also [the NetBSD Guide chapter on disk encryption][2].
 
 The boot process
 ----------------
 
-Instead of booting the GENERIC kernel normally and using the root filesystem directly as usual, a special kernel module containing a memory disk is loaded at boot-time. This minimal filesystem image will then be the actual root filesystem, where the decryption process takes place.
+1. The bootloader loads the kernel from the boot partition.
+1. The kernel loads a file system image `ramdisk-cgdroot.fs` from the boot partition as the initial root file system and starts [[!template id=man name=init section=8]] from inside it.
+1. [[!template id=man name=init section=8]] runs the `/etc/rc` script inside `ramdisk-cgdroot.fs` to configure [[!template id=man name=cgd section=4]] volumes, which will prompt for your passphrase.
+1. Once the [[!template id=man name=cgd section=4]] volumes are configured, the `/etc/rc` script inside `ramdisk-cgdroot.fs` mounts the final root file system at `/altroot`, and instructs [[!template id=man name=init section=8]] to [[!template id=man name=chroot section-2]] into it.
+1. [[!template id=man name=init section=8]] chroots into `/altroot`, where the final root file system is  and the rest of the boot proceeds from there.
 
-The boot partition on disk needs to contain:
+The boot partition on disk must contain:
 
 * [[!template id=man name="boot" section="8"]], the second-stage bootloader
-* [[!template id=man name="boot.cfg" section="5"]], the configuration file for the bootloader (optional)
-* a GENERIC kernel
-* the `cgdroot.kmod` kernel module
-* the configuration file for CGD, `cgd.conf`
-* the CGD parameters file for the volume, named after its partition (like `wd0f`), which determines how the encryption key is derived and verified
+* [[!template id=man name="boot.cfg" section="5"]], the configuration file for the bootloader
+* a kernel image (e.g., NetBSD/amd64 10.1 [netbsd-GENERIC](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/amd64/binary/kernel/netbsd-GENERIC.gz))
+* `ramdisk-cgdroot.fs` (e.g., NetBSD/amd64 10.1 [ramdisk-cgdroot.fs](https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.1/amd64/installation/ramdisk/ramdisk-cgdroot.fs))
+
+Additionally, there must be a config partition, which is either named `cgd.conf` in a GPT, or is the disklabel partition wd0a or ld0a, containing;
+
+* `cgd.conf`, the [[!template id=man name=cgdconfig section=8]] configuration file which the [[!template id=man name=cgd section=4]] volumes are to be configured from which partitions
+* [[!template id=man name=cgdconfig section=8]] parameter files for each volume; see [[!template id=man name=cgdconfig section=8]] and [the NetBSD Guide chapter on disk encryption][2] for details
 
-Once loaded the memory disk mounts the `wd0a` partition onto `/etc/cgd`, and asks for the encryption passphrase as usual (with [[!template id=man name="cgdconfig" section="8"]]). If successful, the `cgd0a` volume configured is mounted on `/altroot`, and [[!template id=man name="init" section="8"]] is told via [[!template id=man name="sysctl" section="7"]] to chroot into this volume before actually booting. The system then starts normally.
+The `cgd.conf` file must configure a [[!template id=man name=cgd section=4]] volume with a partition having the name `cgdroot`, or a disklabel partition cgd0a.
+
+The boot partition and the config partition may be one and the same, either wd0a or ld0a—this way, you can just use the first partition of a disklabel-formatted internal ATA disk (wd0a) or NVME module (ld0a).  Alternatively, you can use a GPT-formatted disk with separate boot and `cgd.conf` partitions.  The boot and `cgd.conf` partitions may also be on the USB flash drive while the encrypted root partition is on the internal medium; this way, the USB flash drive together with your passphrase are both needed to boot, but as soon as the kernel has started (green text appears), you can remove the USB flash drive.
 
 In practice the memory disk remains the real root, and the regular system is
-really ran from a chroot in `/altroot`.
+really run from a chroot in `/altroot`.
 
-Obtaining the kernel module
----------------------------
+Obtaining the ramdisk
+---------------------
 
-The `cgdroot.kmod` kernel module is part of the regular NetBSD releases since NetBSD 7.0. It can be found in the `<arch>/installation/miniroot` folder from the release. For instance, for the amd64 architecture of the 7.0.1 release, download it at [cdn.netbsd.org/pub/NetBSD/NetBSD-7.0.1/amd64/installation/miniroot/cgdroot.kmod](http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.0.1/amd64/installation/miniroot/cgdroot.kmod).
+The `ramdisk-cgdroot.fs` image is part of the regular NetBSD releases since NetBSD 10.0 (or 9.4).  It can be found in the `<arch>/installation/ramdisk` directory of the release.  For instance, for the amd64 architecture of the 10.1 release, download it at [https://cdn.NetBSD.org/pub/NetBSD/NetBSD-10.1/amd64/installation/ramdisk/ramdisk-cgdroot.fs](https://cdn.NetBSD.org/pub/NetBSD/NetBSD-10.1/amd64/installation/ramdisk/ramdisk-cgdroot.fs).
 
-Configuring the kernel module
------------------------------
+Configuring the ramdisk
+-----------------------
 
-The kernel module needs to be available in the boot partition, alongside the desired kernel. The bootloader configuration in `/boot.cfg` should be modified to load the module, as in this example:
+The ramdisk needs to be available in the boot partition, alongside the desired kernel.  The bootloader configuration in `/boot.cfg` should be modified to load the ramdisk, as in this example:
 
 [[!template id=filecontent name="/boot.cfg" text="""
-menu=Boot normally:rndseed /etc/entropy-file;load /cgdroot.kmod;boot /netbsd.gz -z
+menu=Boot normally:rndseed /etc/entropy-file;fs /ramdisk-cgdroot.fs;boot /netbsd.gz
 """]]
 
-Building the kernel module
---------------------------
+Building the ramdisk
+--------------------
 
-The kernel module can be compiled in two steps from within the source tree for the NetBSD base system, once the distribution has been built. Change to the `distrib/<arch>/ramdisks/ramdisk-cgdroot` and use `nbmake-<arch>` to build:
+The ramdisk can be compiled from the source tree for the NetBSD base system, once the distribution has been built.  Change to the `distrib/<arch>/ramdisks/ramdisk-cgdroot` directory and use `nbmake-<arch>` to build:
 
 [[!template id=programlisting text="""
 src/distrib/amd64/ramdisks/ramdisk-cgdroot$ /path/to/tooldir/bin/nbmake-amd64
@@ -62,41 +69,29 @@
 Image `ramdisk-cgdroot.fs.tmp' complete
 """]]
 
-Then the kernel module can be built:
-
-[[!template id=programlisting text="""
-src/distrib/amd64/kmod-cgdroot$ /path/to/tooldir/bin/nbmake-amd64
-"""]]
-
-It will be found in `/path/to/objdir/distrib/amd64/kmod-cgdroot/cgdroot.kmod`.
-
 Caveats
 -------
 
 The biggest (known) issue with this setup occurs when firmware needs to be loaded early in the boot process (such as graphics drivers for the console). At the moment they need to be provided as part of the memory disk. Some network interfaces, of which some wireless devices in particular, also require loading firmware to work properly.
 
-Firmware that can be loaded later (e.g. microcode in `sysutils/intel-microcode-netbsd` package) can be found only if the corresponding paths in the `hw.firmware.path` sysctl variable are adjusted to start with `/altroot`. 
-
-This setup is not entirely safe against physical attacks. An attacker can modify the boot process to store the passphrase for later retrieval, or insert a backdoor while booting. To defend against such attacks, the bootloader, kernel and ramdisk all need to be signed and their integrity checked before booting (e.g. with [[!template id=man name="tpm" section="4"]]). Alternatively, it is possible to boot from a removable medium (e.g. USB stick), which can be protected against tampering attacks (e.g. secure storage, read-only volume...).
+Firmware that can be loaded later (e.g. microcode in `sysutils/intel-microcode-netbsd` package) can be found only if the corresponding paths in the `hw.firmware.path` sysctl variable are adjusted to start with `/altroot`, or by adding a symlink in the ramdisk `/libdata` ⟶ `/altroot/libdata`.
 
-It is also possible to boot a Xen DOM0 system with root filesystem encryption. However, Xen-enabled NetBSD kernels currently do not support loading modules at boot-time. The memory disk has to be placed directly inside the kernel instead (with [[!template id=man name="mdconfig" section="8"]] or a new kernel configuration).
+It is also possible to boot a Xen DOM0 system with full disk encryption. However, Xen-enabled NetBSD kernels currently do not support loading ramdisks at boot-time. The memory disk has to be placed directly inside the kernel instead (with [[!template id=man name="mdconfig" section="8"]] or a new kernel configuration).
 
 It should really be possible to install NetBSD this way with [[!template id=man name="sysinst" section="8"]]. Unfortunately this is not supported yet.
 
 Customized Boot and unlocking via pkgsrc tools
 ----------------------------------------------
 
-It is relatively straight forward to [customize the memory root disk contents][3]
+It is relatively straight forward to [customize the ramdisk contents][3]
 and set up a different process to unlock the cgd root via for example tools
-form pkgsrc and a fido key.
+form pkgsrc and a FIDO key.
 
 References
 ----------
 
-* [Full Disk Encryption with cgd (well, almost)][1]
 * [The cryptographic device driver (CGD)][2]
 * [Creating a custom CGD ramdisk][3]
 
-[1]: https://mail-index.netbsd.org/current-users/2013/03/21/msg022311.html "Full Disk Encryption with cgd (well, almost)"
 [2]: http://www.netbsd.org/docs/guide/en/chap-cgd.html "The cryptographic device driver (CGD)"
 [3]: ../custom_cgdroot

Members: 
	tutorials/kerberos_realm.mdwn:1.14->1.15 

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:09:32 -0000	1.14
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:10:44 -0000	1.15
@@ -112,24 +112,24 @@
    admin access, and [[!template id=man name="kpasswdd" section="8"]]
    for remote password changes.**
 
-   (a) Extract keys into the keytab at /etc/krb5.keytab for
-       [[!template id=man name="kadmind" section="8"]] and
-       [[!template id=man name="kpasswdd" section="8"]]:
+   1. Extract keys into the keytab at /etc/krb5.keytab for
+      [[!template id=man name="kadmind" section="8"]] and
+      [[!template id=man name="kpasswdd" section="8"]]:
 
-       [[!template id=programlisting text="""
+      [[!template id=programlisting text="""
 # kadmin -l ext kadmin/admin@EXAMPLE.COM
 # kadmin -l ext kadmin/changepw@EXAMPLE.COM
 """]]
 
-   (a) Create an access control list for admins:
+   1. Create an access control list for admins:
 
-       [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
+      [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
 jruser/admin@EXAMPLE.COM        all,get-keys
 """]]
 
-   (a) Add entries to /etc/inetd.conf for the services:
+   1. Add entries to /etc/inetd.conf for the services:
 
-       [[!template id=filecontent name="/etc/inetd.conf" text="""
+      [[!template id=filecontent name="/etc/inetd.conf" text="""
 # service       type    proto   wait    user    program                 argv
 kerberos-adm    stream  tcp     nowait  root    /usr/libexec/kadmind    kadmind
 kerberos-adm    stream  tcp6    nowait  root    /usr/libexec/kadmind    kadmind
@@ -137,10 +137,10 @@
 kpasswd         dgram   udp6    wait    root    /usr/libexec/kpasswdd   kpasswdd
 """]]
 
-   (a) Reboot or tell [[!template id=man name="inetd" section="8"]] to
-       reload /etc/inetd.conf:
+   1. Reboot or tell [[!template id=man name="inetd" section="8"]] to
+      reload /etc/inetd.conf:
 
-       [[!template id=programlisting text="""
+      [[!template id=programlisting text="""
 # service inetd reload
 """]]
 

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:08:10 -0000	1.13
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:09:32 -0000	1.14
@@ -112,24 +112,24 @@
    admin access, and [[!template id=man name="kpasswdd" section="8"]]
    for remote password changes.**
 
-   a. Extract keys into the keytab at /etc/krb5.keytab for
-      [[!template id=man name="kadmind" section="8"]] and
-      [[!template id=man name="kpasswdd" section="8"]]:
+   (a) Extract keys into the keytab at /etc/krb5.keytab for
+       [[!template id=man name="kadmind" section="8"]] and
+       [[!template id=man name="kpasswdd" section="8"]]:
 
-      [[!template id=programlisting text="""
+       [[!template id=programlisting text="""
 # kadmin -l ext kadmin/admin@EXAMPLE.COM
 # kadmin -l ext kadmin/changepw@EXAMPLE.COM
 """]]
 
-   a. Create an access control list for admins:
+   (a) Create an access control list for admins:
 
-      [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
+       [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
 jruser/admin@EXAMPLE.COM        all,get-keys
 """]]
 
-   a. Add entries to /etc/inetd.conf for the services:
+   (a) Add entries to /etc/inetd.conf for the services:
 
-      [[!template id=filecontent name="/etc/inetd.conf" text="""
+       [[!template id=filecontent name="/etc/inetd.conf" text="""
 # service       type    proto   wait    user    program                 argv
 kerberos-adm    stream  tcp     nowait  root    /usr/libexec/kadmind    kadmind
 kerberos-adm    stream  tcp6    nowait  root    /usr/libexec/kadmind    kadmind
@@ -137,10 +137,10 @@
 kpasswd         dgram   udp6    wait    root    /usr/libexec/kpasswdd   kpasswdd
 """]]
 
-   a. Reboot or tell [[!template id=man name="inetd" section="8"]] to
-      reload /etc/inetd.conf:
+   (a) Reboot or tell [[!template id=man name="inetd" section="8"]] to
+       reload /etc/inetd.conf:
 
-      [[!template id=programlisting text="""
+       [[!template id=programlisting text="""
 # service inetd reload
 """]]
 

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:05:38 -0000	1.12
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:08:10 -0000	1.13
@@ -112,7 +112,7 @@
    admin access, and [[!template id=man name="kpasswdd" section="8"]]
    for remote password changes.**
 
-   1. Extract keys into the keytab at /etc/krb5.keytab for
+   a. Extract keys into the keytab at /etc/krb5.keytab for
       [[!template id=man name="kadmind" section="8"]] and
       [[!template id=man name="kpasswdd" section="8"]]:
 
@@ -121,13 +121,13 @@
 # kadmin -l ext kadmin/changepw@EXAMPLE.COM
 """]]
 
-   1. Create an access control list for admins:
+   a. Create an access control list for admins:
 
       [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
 jruser/admin@EXAMPLE.COM        all,get-keys
 """]]
 
-   1. Add entries to /etc/inetd.conf for the services:
+   a. Add entries to /etc/inetd.conf for the services:
 
       [[!template id=filecontent name="/etc/inetd.conf" text="""
 # service       type    proto   wait    user    program                 argv
@@ -137,7 +137,7 @@
 kpasswd         dgram   udp6    wait    root    /usr/libexec/kpasswdd   kpasswdd
 """]]
 
-   1. Reboot or tell [[!template id=man name="inetd" section="8"]] to
+   a. Reboot or tell [[!template id=man name="inetd" section="8"]] to
       reload /etc/inetd.conf:
 
       [[!template id=programlisting text="""

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:04:24 -0000	1.11
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:05:38 -0000	1.12
@@ -135,7 +135,7 @@
 kerberos-adm    stream  tcp6    nowait  root    /usr/libexec/kadmind    kadmind
 kpasswd         dgram   udp     wait    root    /usr/libexec/kpasswdd   kpasswdd
 kpasswd         dgram   udp6    wait    root    /usr/libexec/kpasswdd   kpasswdd
-"""]
+"""]]
 
    1. Reboot or tell [[!template id=man name="inetd" section="8"]] to
       reload /etc/inetd.conf:

Members: 
	tutorials/kerberos_realm.mdwn:1.10->1.11 

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:27:12 -0000	1.10
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 02:04:24 -0000	1.11
@@ -65,7 +65,7 @@
 # verify_krb5_conf /etc/krb5.conf
 """]]
 
-1. Initialize the KDC:
+1. **Initialize the KDC:**
 
    [[!template id=programlisting text="""
 # kadmin -l init EXAMPLE.COM
@@ -78,7 +78,7 @@
    This will create the database at the default location under
    `/var/heimdal`.
 
-1. Create a user principal and an admin principal.
+1. **Create a user principal and an admin principal.**
    We'll call the user `jruser` for J. Random User.
 
    [[!template id=programlisting text="""
@@ -90,12 +90,62 @@
 Verifying - jruser/admin@EXAMPLE.COM's Password: 
 """]]
 
-   The admin principal `jruser/admin@EXAMPLE.COM` has no intrinsic
-   connection to `jruser@EXAMPLE.COM` but by convention is chosen to be
-   authorized like a [[!template id=man name="su" section="1"]]-style
-   superuser version of `jruser` for administrative tasks with the help
-   of [[!template id=man name="kadmind" section="8"]].
+   The admin principal `jruser/admin@EXAMPLE.COM` is used by
+   [[!template id=man name="kadmin" section="8"]] for remote access via
+   [[!template id=man name="kadmind" section="8"]].  It need not have
+   the same password as `jruser@EXAMPLE.COM`.
+
+1. **Start up `kdc`, the KDC daemon.**
+   Enable it in /etc/rc.conf:
+
+   [[!template id=filecontent name="/etc/rc.conf" text="""
+kdc=YES
+"""]]
+
+   Then either reboot or start it explicitly:
+
+   [[!template id=programlisting text="""
+# service kdc start
+"""]]
+
+1. **Enable [[!template id=man name="kadmind" section="8"]] for remote
+   admin access, and [[!template id=man name="kpasswdd" section="8"]]
+   for remote password changes.**
+
+   1. Extract keys into the keytab at /etc/krb5.keytab for
+      [[!template id=man name="kadmind" section="8"]] and
+      [[!template id=man name="kpasswdd" section="8"]]:
+
+      [[!template id=programlisting text="""
+# kadmin -l ext kadmin/admin@EXAMPLE.COM
+# kadmin -l ext kadmin/changepw@EXAMPLE.COM
+"""]]
+
+   1. Create an access control list for admins:
+
+      [[!template id=filecontent name="/var/heimdal/kadmind.acl" text="""
+jruser/admin@EXAMPLE.COM        all,get-keys
+"""]]
+
+   1. Add entries to /etc/inetd.conf for the services:
+
+      [[!template id=filecontent name="/etc/inetd.conf" text="""
+# service       type    proto   wait    user    program                 argv
+kerberos-adm    stream  tcp     nowait  root    /usr/libexec/kadmind    kadmind
+kerberos-adm    stream  tcp6    nowait  root    /usr/libexec/kadmind    kadmind
+kpasswd         dgram   udp     wait    root    /usr/libexec/kpasswdd   kpasswdd
+kpasswd         dgram   udp6    wait    root    /usr/libexec/kpasswdd   kpasswdd
+"""]
+
+   1. Reboot or tell [[!template id=man name="inetd" section="8"]] to
+      reload /etc/inetd.conf:
+
+      [[!template id=programlisting text="""
+# service inetd reload
+"""]]
 
 Now you can do `kinit jruser@EXAMPLE.COM` for
-[[client-side single sign-on|tutorials/kerberos_client]], and set up
-[[kerberized services|tutorials/kerberos_services]]!
+[[client-side single sign-on|tutorials/kerberos_client]], use
+[[!template id=man name="kpasswd" section="1"]] to change your password
+or [[!template id=man name="kpasswd" section="8"]] administer the
+realm, and set up [[kerberized services|tutorials/kerberos_services]]!

Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:38:41 -0000	1.11
+++ wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:40:56 -0000	1.12
@@ -155,7 +155,7 @@
    `queue_directory`, matches the `unix_listener` path in Dovecot's
    auth service.
 
-1. Create a `submission` (port 587, [[!rfc 6409]]) and/or `submissions`
+1. Create `submission` (port 587, [[!rfc 6409]]) and/or `submissions`
    (port 465, [[!rfc 8314]]) services in master.cf
    ([[!template id=man name="master" section="5"]]) to handle
    authenticated mail submission:

Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:37:17 -0000	1.10
+++ wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:38:41 -0000	1.11
@@ -10,8 +10,8 @@
 The answer will vary from service to service, and may sometimes be
 phrased in terms of GSS-API, but it will always have three parts:
 
-1. Determine the service's principal name, based on the protocol, the
-   service's hostname, and the realm name.
+1. **Determine the service's principal name**, based on the protocol,
+   the service's hostname, and the realm name.
 
    For example, IMAP uses “imap/_hostname_” ([[!rfc 9051]], [IANA
    GSSAPI/Kerberos/SASL Service
@@ -21,10 +21,10 @@
    (or “imap/imap.example.com@EXAMPLE.COM” if fully qualified with a
    realm name).
 
-2. Get a key for the service principal from the Kerberos KDC using
-   [[!template id=man name="kadmin" section="8"]]:
-   first `kadmin add` to generate a key for the service principal, and
-   then `kadmin ext` to extract it into a keytab.
+2. **Get a keytab for the service principal** from the Kerberos KDC
+   using [[!template id=man name="kadmin" section="8"]]:
+   first `kadmin add` to generate a key for the service principal in
+   the KDC database, and then `kadmin ext` to extract it into a keytab.
 
    The key is a secret shared between the service and the KDC.
    Anyone who knows the key can spoof the service, so you must keep
@@ -39,7 +39,7 @@
    [[!template id=man name="kadmin" section="8"]]
    remotely.
 
-3. Put the keytab in a file readable by the server software, for
+3. **Put the keytab in a file readable by the server software**, for
    example /usr/pkg/etc/dovecot/private/keytab, and point the software
    at the keytab and service principal name.
 

2. Fix smtpd_tls_security_level=encrypt option.  It's not
   smtpd_tls_security_level_encrypt=yes, which must have been a
   paste-o in previous editing.

Members: 
	tutorials/kerberos_services.mdwn:1.9->1.10 

Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:24:44 -0000	1.9
+++ wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:37:17 -0000	1.10
@@ -155,19 +155,31 @@
    `queue_directory`, matches the `unix_listener` path in Dovecot's
    auth service.
 
-1. Create a `submission` (port 587) service in master.cf
-   ([[!template id=man name="master" section="5"]])
-   to handle authenticated mail submission ([[!rfc 6409]]):
+1. Create a `submission` (port 587, [[!rfc 6409]]) and/or `submissions`
+   (port 465, [[!rfc 8314]]) services in master.cf
+   ([[!template id=man name="master" section="5"]]) to handle
+   authenticated mail submission:
 
    [[!template id=filecontent name="/etc/postfix/master.cf" text="""
-# service  type private unpriv chroot wakeup maxproc command
-submission inet n       -      y      -      -       smtpd
-      -o smtpd_tls_security_level_encrypt=yes
+# service   type private unpriv chroot wakeup maxproc command
+submission  inet n       -      y      -      -       smtpd
+      -o smtpd_tls_security_level=encrypt
+      -o smtpd_sasl_auth_enable=yes
+      -o smtpd_client_restrictions=permit_sasl_authenticated,reject
+      -o local_header_rewrite_clients=permit_sasl_authenticated
+submissions inet n       -      y      -      -       smtpd
+      -o smtpd_tls_wrappermode=yes
       -o smtpd_sasl_auth_enable=yes
       -o smtpd_client_restrictions=permit_sasl_authenticated,reject
       -o local_header_rewrite_clients=permit_sasl_authenticated
 """]]
 
+   The difference between `submission`/587 and `submissions`/465 is
+   that `submission`/587 starts as plaintext, and is configured to
+   require a STARTTLS command to start the TLS session, whereas
+   `submissions`/465 starts immediately with a TLS session.  Most mail
+   clients will support both.
+
    You may also want to set options `smtpd_sender_login_maps` and
    `smtpd_sender_restrictions` to restrict senders to submit
    `MAIL FROM` envelope addresses that match their login names.

Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:24:44 -0000	1.9
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:27:12 -0000	1.10
@@ -25,8 +25,8 @@
 
    [[!template id=filecontent name="example.com zonefile" text="""
 ; name           ttl     class   type    rrdata
-_kerberos        300     IN      TXT     "EXAMPLE.COM"
-_kerberos._tcp   300     IN      SRV     1 0 88 kdc
+\_kerberos        300     IN      TXT     "EXAMPLE.COM"
+\_kerberos._tcp   300     IN      SRV     1 0 88 kdc
 """]]
 
    For access to services under `example.com`, clients will consult

> 1. foo bar
>
>    [[!template id="filecontent" file="/etc/foo.conf" text="""
> [section]
>         foo = bar
> """]]

The indented line with eight spaces of indentation is rendered with
only five, because the current indentation level in the surrounding
text has three-space indentation.

So, _for lines with leading spaces_, add as much space as the current
indentation level has.

Members: 
	tutorials/kerberos_client.mdwn:1.10->1.11 
	tutorials/kerberos_realm.mdwn:1.8->1.9 
	tutorials/kerberos_services.mdwn:1.8->1.9 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:19:19 -0000	1.10
+++ wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:24:44 -0000	1.11
@@ -9,7 +9,7 @@
 
    [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-        name_canon_rules = as-is:
+           name_canon_rules = as-is:
 """]]
 
 1. Get a ticket:
@@ -41,7 +41,7 @@
 
   [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-        name_canon_rules = nss:match_realm=EXAMPLE.COM
+          name_canon_rules = nss:match_realm=EXAMPLE.COM
 """]]
 
   See [[!template id=man name="krb5.conf" section="5"]] for more
@@ -57,12 +57,12 @@
 
      [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-        dns_lookup_realm = false
+             dns_lookup_realm = false
 [domain_realm]
-        example.com = EXAMPLE.COM
-        .example.com = EXAMPLE.COM
-        evil.net = EVIL.NET
-        .evil.net = EVIL.NET
+             example.com = EXAMPLE.COM
+             .example.com = EXAMPLE.COM
+             evil.net = EVIL.NET
+             .evil.net = EVIL.NET
 """]]
 
      The entry for example.com matches just example.com directly, and
@@ -145,8 +145,8 @@
 
    [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-        default_realm = EXAMPLE.COM
-        name_canon_rules = as-is:
+           default_realm = EXAMPLE.COM
+           name_canon_rules = as-is:
 """]]
 
 1. Uncomment the pam_krb5.so lines
Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:19:19 -0000	1.8
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:24:44 -0000	1.9
@@ -51,12 +51,12 @@
 
    [[!template id=filecontent name="/etc/krb5.conf" text="""
 [libdefaults]
-        default_realm = EXAMPLE.COM
-        name_canon_rules = as-is:
+           default_realm = EXAMPLE.COM
+           name_canon_rules = as-is:
 [kdc]
-        # Prevent UDP amplification by not listening on UDP:
-        # https://github.com/heimdal/heimdal/issues/1216
-        ports = kerberos/tcp
+           # Prevent UDP amplification by not listening on UDP:
+           # https://github.com/heimdal/heimdal/issues/1216
+           ports = kerberos/tcp
 """]]
 
    Check it by running:
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:06:25 -0000	1.8
+++ wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:24:44 -0000	1.9
@@ -79,14 +79,14 @@
 
    [[!template id=programlisting text="""
 # kadmin add --random-key --max-ticket-life=unlimited \
-    --max-renewable-life=unlimited --use-defaults \
-    imap/imap.example.com
+       --max-renewable-life=unlimited --use-defaults \
+       imap/imap.example.com
 # kadmin add --random-key --max-ticket-life=unlimited \
-    --max-renewable-life=unlimited --use-defaults \
-    pop/pop.example.com
+       --max-renewable-life=unlimited --use-defaults \
+       pop/pop.example.com
 # kadmin add --random-key --max-ticket-life=unlimited \
-    --max-renewable-life=unlimited --use-defaults \
-    smtp/mail.example.com
+       --max-renewable-life=unlimited --use-defaults \
+       smtp/mail.example.com
 # mkdir -m 0700 /usr/pkg/etc/dovecot/private
 # cd /usr/pkg/etc/dovecot/private
 # kadmin ext -k keytab imap/imap.example.com
@@ -162,10 +162,10 @@
    [[!template id=filecontent name="/etc/postfix/master.cf" text="""
 # service  type private unpriv chroot wakeup maxproc command
 submission inet n       -      y      -      -       smtpd
-   -o smtpd_tls_security_level_encrypt=yes
-   -o smtpd_sasl_auth_enable=yes
-   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
-   -o local_header_rewrite_clients=permit_sasl_authenticated
+      -o smtpd_tls_security_level_encrypt=yes
+      -o smtpd_sasl_auth_enable=yes
+      -o smtpd_client_restrictions=permit_sasl_authenticated,reject
+      -o local_header_rewrite_clients=permit_sasl_authenticated
 """]]
 
    You may also want to set options `smtpd_sender_login_maps` and

Members: 
	tutorials/kerberos_client.mdwn:1.9->1.10 
	tutorials/kerberos_realm.mdwn:1.7->1.8 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:06:25 -0000	1.9
+++ wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:19:19 -0000	1.10
@@ -9,7 +9,7 @@
 
    [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-	name_canon_rules = as-is:
+        name_canon_rules = as-is:
 """]]
 
 1. Get a ticket:
@@ -41,7 +41,7 @@
 
   [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-	name_canon_rules = nss:match_realm=EXAMPLE.COM
+        name_canon_rules = nss:match_realm=EXAMPLE.COM
 """]]
 
   See [[!template id=man name="krb5.conf" section="5"]] for more
@@ -57,13 +57,12 @@
 
      [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-	dns_lookup_realm = false
-
+        dns_lookup_realm = false
 [domain_realm]
-	example.com = EXAMPLE.COM
-	.example.com = EXAMPLE.COM
-	evil.net = EVIL.NET
-	.evil.net = EVIL.NET
+        example.com = EXAMPLE.COM
+        .example.com = EXAMPLE.COM
+        evil.net = EVIL.NET
+        .evil.net = EVIL.NET
 """]]
 
      The entry for example.com matches just example.com directly, and
@@ -92,7 +91,7 @@
 
 [[!template id=filecontent name="~/.ssh/config" text="""
 Match host *.example.com
-	GSSAPIAuthentication yes
+        GSSAPIAuthentication yes
 """]]
 
 Now log in to foo.example.com without a password!
@@ -103,8 +102,8 @@
 
 [[!template id=filecontent name="~/.ssh/config" text="""
 Match host *.example.com
-	GSSAPIAuthentication yes
-	GSSAPIDelegateCredentials yes
+        GSSAPIAuthentication yes
+        GSSAPIDelegateCredentials yes
 """]]
 
 Now run kerberized applications on foo.example.com through ssh without
@@ -146,8 +145,8 @@
 
    [[!template id=filecontent name="~/.krb5/config" text="""
 [libdefaults]
-	default_realm = EXAMPLE.COM
-	name_canon_rules = as-is:
+        default_realm = EXAMPLE.COM
+        name_canon_rules = as-is:
 """]]
 
 1. Uncomment the pam_krb5.so lines
Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:06:25 -0000	1.7
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:19:19 -0000	1.8
@@ -51,12 +51,12 @@
 
    [[!template id=filecontent name="/etc/krb5.conf" text="""
 [libdefaults]
-	default_realm = EXAMPLE.COM
-	name_canon_rules = as-is:
+        default_realm = EXAMPLE.COM
+        name_canon_rules = as-is:
 [kdc]
-	# Prevent UDP amplification by not listening on UDP:
-	# https://github.com/heimdal/heimdal/issues/1216
-	ports = kerberos/tcp
+        # Prevent UDP amplification by not listening on UDP:
+        # https://github.com/heimdal/heimdal/issues/1216
+        ports = kerberos/tcp
 """]]
 
    Check it by running:

> 1. Create a directory ~/.krb5 and a file ~/.krb5/config with the
>    following content to enable Kerberos on the client side:
>
>    [[!template id=filecontent name="~/.krb5/config" text="""
> [libdefaults]
> 	name_canon_rules = as-is:
> """]]

with the HTML fragment:

--------8<---------
<ol>
<li><p>Create a directory ~/.krb5 and a file ~/.krb5/config with the
following content to enable Kerberos on the client side:</p>

<p><fieldset>
<legend>~/.krb5/config</legend></p></li>
</ol>


<pre>
[libdefaults]
    name_canon_rules = as-is:
</pre>


<p></fieldset></p>
-------->8---------

This is full of <p>...</p> around opening and closing tags, rather
than balanced elements, which I hypothesize happens because of the
line breaks in the template.

Members: 
	templates/filecontent.mdwn:1.3->1.4 

Index: wikisrc/templates/filecontent.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/templates/filecontent.mdwn,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- wikisrc/templates/filecontent.mdwn	23 Mar 2024 18:33:22 -0000	1.3
+++ wikisrc/templates/filecontent.mdwn	19 Jul 2026 01:15:21 -0000	1.4
@@ -1,10 +1,5 @@
 [[!templatebody <<ENDBODY
-<fieldset>
-<legend><TMPL_VAR raw_name></legend>
-<pre>
-<TMPL_VAR raw_text>
-</pre>
-</fieldset>
+<fieldset><legend><TMPL_VAR raw_name></legend><pre><TMPL_VAR raw_text></pre></fieldset>
 ENDBODY]]
 
 ## Description

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:00:18 -0000	1.8
+++ wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:06:25 -0000	1.9
@@ -8,16 +8,16 @@
    following content to enable Kerberos on the client side:
 
    [[!template id=filecontent name="~/.krb5/config" text="""
-   [libdefaults]
-   	name_canon_rules = as-is:
-   """]]
+[libdefaults]
+	name_canon_rules = as-is:
+"""]]
 
 1. Get a ticket:
 
    [[!template id=programlisting text="""
-   $ kinit jruser@EXAMPLE.COM
-   jruser@EXAMPLE.COM's Password: 
-   """]]
+$ kinit jruser@EXAMPLE.COM
+jruser@EXAMPLE.COM's Password: 
+"""]]
 
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!
@@ -40,9 +40,9 @@
   realm:
 
   [[!template id=filecontent name="~/.krb5/config" text="""
-  [libdefaults]
-  	name_canon_rules = nss:match_realm=EXAMPLE.COM
-  """]]
+[libdefaults]
+	name_canon_rules = nss:match_realm=EXAMPLE.COM
+"""]]
 
   See [[!template id=man name="krb5.conf" section="5"]] for more
   information about the syntax of ~/.krb5/config.
@@ -56,15 +56,15 @@
      name-to-realm mapping:
 
      [[!template id=filecontent name="~/.krb5/config" text="""
-     [libdefaults]
-     	dns_lookup_realm = false
+[libdefaults]
+	dns_lookup_realm = false
 
-     [domain_realm]
-     	example.com = EXAMPLE.COM
-     	.example.com = EXAMPLE.COM
-     	evil.net = EVIL.NET
-     	.evil.net = EVIL.NET
-     """]]
+[domain_realm]
+	example.com = EXAMPLE.COM
+	.example.com = EXAMPLE.COM
+	evil.net = EVIL.NET
+	.evil.net = EVIL.NET
+"""]]
 
      The entry for example.com matches just example.com directly, and
      the entry for .example.com matches any subdomain one level under
@@ -76,9 +76,9 @@
      program:
 
      [[!template id=programlisting text="""
-     $ KRB5_CONFIG=$HOME/.krb5/config.example firefox &
-     $ KRB5_CONFIG=$HOME/.krb5/config.evil ssh foo.evil.net
-     """]]
+$ KRB5_CONFIG=$HOME/.krb5/config.example firefox &
+$ KRB5_CONFIG=$HOME/.krb5/config.evil ssh foo.evil.net
+"""]]
 
      Make sure to set `[libdefaults] dns_lookup_realm = false` in each
      config file too in this case.
@@ -145,10 +145,10 @@
    with the following content:
 
    [[!template id=filecontent name="~/.krb5/config" text="""
-   [libdefaults]
-   	default_realm = EXAMPLE.COM
-   	name_canon_rules = as-is:
-   """]]
+[libdefaults]
+	default_realm = EXAMPLE.COM
+	name_canon_rules = as-is:
+"""]]
 
 1. Uncomment the pam_krb5.so lines
    ([[!template id=man name="pam_krb5" section="8"]]) in
Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:00:18 -0000	1.6
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:06:25 -0000	1.7
@@ -24,10 +24,10 @@
    it easier for users:
 
    [[!template id=filecontent name="example.com zonefile" text="""
-   ; name           ttl     class   type    rrdata
-   _kerberos        300     IN      TXT     "EXAMPLE.COM"
-   _kerberos._tcp   300     IN      SRV     1 0 88 kdc
-   """]]
+; name           ttl     class   type    rrdata
+_kerberos        300     IN      TXT     "EXAMPLE.COM"
+_kerberos._tcp   300     IN      SRV     1 0 88 kdc
+"""]]
 
    For access to services under `example.com`, clients will consult
    `_kerberos.example.com` TXT records to find the realm name—see
@@ -50,28 +50,28 @@
    content:
 
    [[!template id=filecontent name="/etc/krb5.conf" text="""
-   [libdefaults]
-   	default_realm = EXAMPLE.COM
-   	name_canon_rules = as-is:
-   [kdc]
-   	# Prevent UDP amplification by not listening on UDP:
-   	# https://github.com/heimdal/heimdal/issues/1216
-   	ports = kerberos/tcp
-   """]]
+[libdefaults]
+	default_realm = EXAMPLE.COM
+	name_canon_rules = as-is:
+[kdc]
+	# Prevent UDP amplification by not listening on UDP:
+	# https://github.com/heimdal/heimdal/issues/1216
+	ports = kerberos/tcp
+"""]]
 
    Check it by running:
 
    [[!template id=programlisting text="""
-   # verify_krb5_conf /etc/krb5.conf
-   """]]
+# verify_krb5_conf /etc/krb5.conf
+"""]]
 
 1. Initialize the KDC:
 
    [[!template id=programlisting text="""
-   # kadmin -l init EXAMPLE.COM
-   Realm max ticket life [unlimited]:
-   Realm max renewable ticket life [unlimited]:
-   """]]
+# kadmin -l init EXAMPLE.COM
+Realm max ticket life [unlimited]:
+Realm max renewable ticket life [unlimited]:
+"""]]
 
    Hit return when prompted to use the defaults.
 
@@ -82,13 +82,13 @@
    We'll call the user `jruser` for J. Random User.
 
    [[!template id=programlisting text="""
-   # kadmin -l add --use-defaults jruser
-   jruser@EXAMPLE.COM's Password: 
-   Verifying - jruser@EXAMPLE.COM's Password: 
-   # kadmin -l add --use-defaults jruser/admin
-   jruser/admin@EXAMPLE.COM's Password: 
-   Verifying - jruser/admin@EXAMPLE.COM's Password: 
-   """]]
+# kadmin -l add --use-defaults jruser
+jruser@EXAMPLE.COM's Password: 
+Verifying - jruser@EXAMPLE.COM's Password: 
+# kadmin -l add --use-defaults jruser/admin
+jruser/admin@EXAMPLE.COM's Password: 
+Verifying - jruser/admin@EXAMPLE.COM's Password: 
+"""]]
 
    The admin principal `jruser/admin@EXAMPLE.COM` has no intrinsic
    connection to `jruser@EXAMPLE.COM` but by convention is chosen to be
Index: wikisrc/tutorials/kerberos_services.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_services.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:00:18 -0000	1.7
+++ wikisrc/tutorials/kerberos_services.mdwn	19 Jul 2026 01:06:25 -0000	1.8
@@ -78,37 +78,37 @@
    keytab:
 
    [[!template id=programlisting text="""
-   # kadmin add --random-key --max-ticket-life=unlimited \
-       --max-renewable-life=unlimited --use-defaults \
-       imap/imap.example.com
-   # kadmin add --random-key --max-ticket-life=unlimited \
-       --max-renewable-life=unlimited --use-defaults \

(Diff truncated)

Members: 
	tutorials/kerberos_client.mdwn:1.7->1.8 
	tutorials/kerberos_realm.mdwn:1.5->1.6 
	tutorials/kerberos_services.mdwn:1.6->1.7 

Index: wikisrc/tutorials/kerberos_client.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_client.mdwn,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wikisrc/tutorials/kerberos_client.mdwn	23 Aug 2023 12:02:26 -0000	1.7
+++ wikisrc/tutorials/kerberos_client.mdwn	19 Jul 2026 01:00:18 -0000	1.8
@@ -7,13 +7,17 @@
 1. Create a directory ~/.krb5 and a file ~/.krb5/config with the
    following content to enable Kerberos on the client side:
 
-       [libdefaults]
-               name_canon_rules = as-is:
+   [[!template id=filecontent name="~/.krb5/config" text="""
+   [libdefaults]
+   	name_canon_rules = as-is:
+   """]]
 
 1. Get a ticket:
 
-       $ kinit jruser@EXAMPLE.COM
-       jruser@EXAMPLE.COM's Password: 
+   [[!template id=programlisting text="""
+   $ kinit jruser@EXAMPLE.COM
+   jruser@EXAMPLE.COM's Password: 
+   """]]
 
 Now any kerberized applications such as ssh and Firefox can
 authenticate as jruser@EXAMPLE.COM on your behalf to services!
@@ -35,8 +39,10 @@
   `[libdefaults]` section of ~/.krb5/config matching the EXAMPLE.COM
   realm:
 
-      [libdefaults]
-              name_canon_rules = nss:match_realm=EXAMPLE.COM
+  [[!template id=filecontent name="~/.krb5/config" text="""
+  [libdefaults]
+  	name_canon_rules = nss:match_realm=EXAMPLE.COM
+  """]]
 
   See [[!template id=man name="krb5.conf" section="5"]] for more
   information about the syntax of ~/.krb5/config.
@@ -49,14 +55,16 @@
      different domains to different realms, and disable DNS
      name-to-realm mapping:
 
-         [libdefaults]
-                 dns_lookup_realm = false
-
-         [domain_realm]
-                 example.com = EXAMPLE.COM
-                 .example.com = EXAMPLE.COM
-                 evil.net = EVIL.NET
-                 .evil.net = EVIL.NET
+     [[!template id=filecontent name="~/.krb5/config" text="""
+     [libdefaults]
+     	dns_lookup_realm = false
+
+     [domain_realm]
+     	example.com = EXAMPLE.COM
+     	.example.com = EXAMPLE.COM
+     	evil.net = EVIL.NET
+     	.evil.net = EVIL.NET
+     """]]
 
      The entry for example.com matches just example.com directly, and
      the entry for .example.com matches any subdomain one level under
@@ -67,8 +75,10 @@
      environment variable set to whichever one you want to use for that
      program:
 
-         $ KRB5_CONFIG=$HOME/.krb5/config.example firefox &
-         $ KRB5_CONFIG=$HOME/.krb5/config.evil ssh foo.evil.net
+     [[!template id=programlisting text="""
+     $ KRB5_CONFIG=$HOME/.krb5/config.example firefox &
+     $ KRB5_CONFIG=$HOME/.krb5/config.evil ssh foo.evil.net
+     """]]
 
      Make sure to set `[libdefaults] dns_lookup_realm = false` in each
      config file too in this case.
@@ -80,8 +90,10 @@
 following stanza to the end of ~/.ssh/config
 ([[!template id=man name="ssh_config" section="5"]]):
 
-    Match host *.example.com
-            GSSAPIAuthentication yes
+[[!template id=filecontent name="~/.ssh/config" text="""
+Match host *.example.com
+	GSSAPIAuthentication yes
+"""]]
 
 Now log in to foo.example.com without a password!
 
@@ -89,9 +101,11 @@
 authenticate to kerberized applications on the remote host, you can
 also forward your Kerberos tickets with:
 
-    Match host *.example.com
-            GSSAPIAuthentication yes
-            GSSAPIDelegateCredentials yes
+[[!template id=filecontent name="~/.ssh/config" text="""
+Match host *.example.com
+	GSSAPIAuthentication yes
+	GSSAPIDelegateCredentials yes
+"""]]
 
 Now run kerberized applications on foo.example.com through ssh without
 a password!
@@ -130,9 +144,11 @@
    ([[!template id=man name="krb5.conf" section="5"]])
    with the following content:
 
-       [libdefaults]
-               default_realm = EXAMPLE.COM
-               name_canon_rules = as-is:
+   [[!template id=filecontent name="~/.krb5/config" text="""
+   [libdefaults]
+   	default_realm = EXAMPLE.COM
+   	name_canon_rules = as-is:
+   """]]
 
 1. Uncomment the pam_krb5.so lines
    ([[!template id=man name="pam_krb5" section="8"]]) in
Index: wikisrc/tutorials/kerberos_realm.mdwn
===================================================================
RCS file: /cvsroot/wikisrc/tutorials/kerberos_realm.mdwn,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- wikisrc/tutorials/kerberos_realm.mdwn	8 Oct 2023 18:55:59 -0000	1.5
+++ wikisrc/tutorials/kerberos_realm.mdwn	19 Jul 2026 01:00:18 -0000	1.6
@@ -7,37 +7,37 @@
 hostnames under example.com.
 How do you set it up?
 
-1. Pick a realm name.
+1. **Pick a realm name.**
    This is normally the uppercase version of your organization's domain
    name in the DNS, EXAMPLE.COM.
 
    _Note:_ Unlike DNS domain names, Kerberos realm names are
    case-sensitive.
 
-1. Pick a host to run the Kerberos Key Distribution Center, say
+1. **Pick a host to run the Kerberos Key Distribution Center**, say
    kdc.example.com.
 
-   Make sure TCP and/or UDP traffic to kdc.example.com goes to the
+   Make sure TCP traffic on port 88 to kdc.example.com goes to the
    host, in case it is behind a NAT or firewall or similar.
 
-1. To make it easier for users, create DNS records in the
-   example.com. zone:
+1. **Optional: Create DNS records** in the example.com. zone, to make
+   it easier for users:
 
-       ; name           ttl     class   type    rrdata
-       _kerberos        300     IN      TXT     "EXAMPLE.COM"
-       _kerberos._tcp   300     IN      SRV     1 0 88 kdc
-       _kerberos._udp   300     IN      SRV     1 0 88 kdc
+   [[!template id=filecontent name="example.com zonefile" text="""
+   ; name           ttl     class   type    rrdata
+   _kerberos        300     IN      TXT     "EXAMPLE.COM"
+   _kerberos._tcp   300     IN      SRV     1 0 88 kdc
+   """]]
 
    For access to services under `example.com`, clients will consult
-   `_kerberos.example.com` TXT records to find the realm name
-   (see `dns_lookup_realm` in
-   [[!template id=man name="krb5.conf" section="5"]])
+   `_kerberos.example.com` TXT records to find the realm name—see
+   `dns_lookup_realm` in
+   [[!template id=man name="krb5.conf" section="5"]].
 
    To find the KDC for the realm EXAMPLE.COM, clients and services will
-   consult `_kerberos._tcp.example.com` or `_kerberos._udp.example.com`
-   SRV records
-   (see `dns_lookup_kdc` in
-   [[!template id=man name="krb5.conf" section="5"]]).
+   consult `_kerberos._tcp.example.com` SRV records—see
+   `dns_lookup_kdc` in
+   [[!template id=man name="krb5.conf" section="5"]].
 
    If you don't set this up, you will need to distribute
    [[!template id=man name="krb5.conf" section="5"]] files to all users
@@ -46,21 +46,32 @@
    [[!template id=man name="krb5.conf" section="5"]] man page for
    details.
 
-1. On kdc.example.com, create /etc/krb5.conf with the following content:
+1. **On kdc.example.com, create /etc/krb5.conf** with the following
+   content:
 
-       [libdefaults]

(Diff truncated)