Requesting support for grub 'module' statements

[trevor-vaughan]

First, thanks for providing this module, it has been quite useful.

We're pushing forward with using trusted boot in grub and now find ourselves in need of the 'module' portion of the grub configuration.

An example of this usage can be found at https://fedoraproject.org/wiki/Features/Trusted_Boot.

As far as I can tell, the kernel line detection needs to go from just a kernel line to a kernel line followed by a module (somewhere) that contains the kernel specification line.

[raphink]

@trevor-vaughan what kind of Puppet code would you expect to write, and what kind of changes should that produce (ideally in the Augeas tree)?

[trevor-vaughan]

That's a really good question.

I suppose that I would really like management of the 80% of the grub.conf stack since right now it's either use the 'kernel_parameter' type or just hack something together by hand.

Globals

• default
• timeout
• password
• fallback

Perhaps these could be a grub_config type?

grub_config { 'default':  value => 0 }
grub_config { 'timeout': value => 10 }
grub_config { 'password': value => $1$stuff... }
grub_config { 'fallback': value => [1] }

Individual entries (title being $name):

• kernel + options
  ** module + module....
• initrd
• chainloader
• root/rootnoverify

In theory, this could be a 'grub_entry' type that has all available options and ignores the ones that are not specified.

grub_entry { 'default':
  # Make this the fallback
  order => 1,
  root => 'hd(0,0)',
  kernel => '/boot/vmlinuz',
  kernel_options => ['stuff', 'and', 'things']
  initrd => '/boot/initrd'
}
grub_entry { 'tboot':
  # Make this the default
  order => 0,
  root => 'hd(0,0)',
  kernel => '/boot/tboot.tgz',
  modules => {
     '/boot/vmlinuz' => ['option1','option2','option3'],
    '/boot/initrd' => ['option1','option2','option3']
  }

Thinking about the Augeas Tree (not my strong suit) it would probably go something like this:

/boot/grub/grub.conf/
  /password=[String]
  /default=[Integer]
  /timeout=[Integer]
  /entry[*]/
    /title=[String]
   /root=[String] (or rootnoverify)
   /kernel=[String]
     /option[*]=[String]
   /module[*]
      /name=[String]
     /option[*]=[String]
   /initrd=[String] (Can't be present if modules are defined)
   /chainloader=[String]

Of course, you'd also want to make sure that this can either be additive (add options, etc...) or authoritative (nuke the entire segment and replace it).

The issue is the magic that's done by the RPMs and when installing the new grub entries. Might have to pick apart the kernel installer scripts to see how they're doing what they're doing. It may be as simple as a fallback or copy the entities on the last entry.

I would also suggest letting the user always have a fallback of the stock system kernel. So, when you set the initial entry, take that one and make sure it's automatically at the tail of the fallback list just in case. This should be able to be disabled for those users that like to live on the edge/have strict policies about boot capabilities.

[raphink]

So a new type altogether. Your examples only mention Grub 1 configuration. How would this map to Grub 2 (which I personally wish never existed ;-))?

[trevor-vaughan]

Unfortunately, it wouldn't map to grub2.

This actually should be easier since you only need to mess about with /etc/default/grub.

There are, however, a stupid number of options that appear to be able to go into that file. And, of course, there is the 40_custom rule set.

This applies to RHEL-based systems, I'm not sure about the others. That may be the true issue.

And, of course, you'll have to run the grub2-mkconfig script after editing all files.