Feat: adds nodo::subsystem::modprobe::module and improves nodo::subsystem::sensors

1 files changed, 35 insertions, 0 deletions

diff --git a/manifests/subsystem/modprobe/module.pp b/manifests/subsystem/modprobe/module.pp
new file mode 100644
index 0000000..21ec4ed
--- /dev/null
+++ b/manifests/subsystem/modprobe/module.pp
@@ -0,0 +1,35 @@
+#
+# Handles Linux kernel module loading.
+#
+# Module loading is implemented both for SysV and systemd based systems, to
+# ensure this module is managed in either case.
+#
+# It also remains to be tested whether _both_ /etc/modules and /etc/modules-load.d
+# are processed by recent systemd-based Debian systems; or if there are
+# inconsistencies between the implementation and the documentation:
+#
+#   https://wiki.debian.org/Modules#Automatic_loading_of_modules
+#
+# Anyway, having this configuration in both places does not seem to hurt (much).
+#
+# Check also https://wiki.archlinux.org/title/Kernel_module#Automatic_module_loading
+#            https://unix.stackexchange.com/questions/189670/whats-the-difference-of-etc-modules-load-d-and-etc-modules
+define nodo::subsystem::modprobe::module(
+  $ensure = 'present',
+){
+  # Drivetemp module loading for systems using SysV -- /etc/modules - modules(5)
+  file_line { "etc-modules-${name}":
+    path   => "/etc/modules",
+    line   => "${name}",
+    ensure => $ensure,
+  }
+
+  # Drivetemp module loading using systemd's /etc/modules-load.d/ - modules-load.d(5)
+  file { "/etc/modules-load.d/${name}.conf":
+    ensure  => $ensure,
+    owner   => root,
+    group   => root,
+    mode    => '0644',
+    content => "${name}\n",
+  }
+}