aboutsummaryrefslogtreecommitdiff
path: root/manifests/subsystem/modprobe/module.pp
diff options
context:
space:
mode:
Diffstat (limited to 'manifests/subsystem/modprobe/module.pp')
-rw-r--r--manifests/subsystem/modprobe/module.pp38
1 files changed, 38 insertions, 0 deletions
diff --git a/manifests/subsystem/modprobe/module.pp b/manifests/subsystem/modprobe/module.pp
new file mode 100644
index 0000000..21b7398
--- /dev/null
+++ b/manifests/subsystem/modprobe/module.pp
@@ -0,0 +1,38 @@
+#
+# 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
+#
+# In the future, this definition can also manage /etc/modprobe.d/ entries.
+#
+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",
+ }
+}