aboutsummaryrefslogtreecommitdiff
path: root/manifests/subsystem/modprobe/module.pp
blob: 21b73983aa1f986659ab54cbdfb23eac2e92fb7d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
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",
  }
}