The New Layout for all SIMP Modules

Background

This is a record of the discussion on the 12th regarding the new layout of all SIMP Puppet Component Modules

As we were working through issues regarding SIMP-57 - Getting issue details... STATUS , we started discussing how make our module collection more consistent and make it easier to adopt across the board.

Our decision ended up being as follows.

Basic Module Structure

Our component modules will be patterned after the Puppet Labs suggested layout du jour.  SIMP-specific additions are in bold below.

• module/manifests/
  • init.pp 
  • params.pp
  • install.pp
  • config.pp
  • service.pp
  • simp/firewall/simp.pp
  • simp/logging/simp.pp
  • simp/audit/simp.pp
  • simp/selinux/simp.pp
  • simp/pki/simp.pp
  • simp/tcpwrappers/simp.pp
    

Each of these items in bold must adhere to the following:

1. They must be disabled by default
2. They must be name-based where the Boolean true and the String 'simp' amount to the same action (e.g., the Trevorian type "Stroolean")
3. They must allow for an ENC or Hiera or straight parameter, since we want maximum module uptake where possible

   1. This will look something like the following

      $manage_firewall = defined($::manage_firewall) ? $::manage_firewall : hiera('manage_firewall',false)

      1. NOTE: the management defaults will be "false" as a safety consideration to Forge users who might try any SIMP module ala carte. However, these parameters will be enabled by default in simp-core, so we're.
      2. QUESTION: Should we make this defined->hiera->default logic a function in simplib? Is that too much trouble/obfuscation?

Each module willl have the following class parameters in init.pp (when applicable):

• simp_firewall
  • true = includes simp-iptables (NOTE: simp-iptables should be renamed for SIMP6) and sets up rules to permit the application
• simp_logging
  • true = 
• simp_auditd
  • true = 
• simp_selinux
  • true  = includes simp-selinux (which effectively manages the SELinux enforcement and mode) and configures the SELinux booleans
    • NOTE:  Many SElinux configurations are handled as attributes of native puppet resources.
    •   SIMP. module and are  part of Puppet resources
    • Should one , however, any boolean flipping should probably be done here
• simp_pki
  • true / 'simp' = includes simp-pki and uses pki::copy to distribute PKI certificates to the correct locations
  • false = PKI certificates are not distributed by SIMP; make your own arrangements to get them in place
• simp_tcpwrappers
  • true = includes simp-tcpwrappers and uses tcpwrappers::allow to permit the application to the subnets in $::client_nets

Advanced Module Structure

Some modules may manage components that do not easily fit the recommended structure.  

• If the module has taken on too much responsibility for a single component, refactor it into separate component modules and use the recommended structure.
• If the module manages a single responsibility yet is inherently complex, apply the recommended structure to appropriate areas.

Below are two recommended patterns for complex adaptations:

Modules that manage a client and a server

This pattern applies to any module that manages several asymmetric services that must manage the same resources.

The general pattern is to:

• • create a namespace (directory) for each service
  • apply the basic structure to each namespace
  • continue to use the basic (top-level) module structure to manage module-wide configurations and resource orderings

Separate Client and Server Components (When NOT to apply this pattern)

In the case that you have a server and client that are two separately isolated services, such as the SSH server and client, then two separate modules should be created. This provides for a clean usage pattern over time.

Combined Client and Server Components (When TO apply this pattern)

There are going to be times where the server and client components cannot be split. A classic example is ntp, where the client and server require the same package and config file. 

In these cases, isolate the functionality within the module to the bests of your ability and repeat the pattern below each subdirectory segment.

As an example, you may use something like the following:

• module/manifests/
  • init.pp
  • params.pp, config.pp, etc (for module-wide settings)
  • server.pp
  • server/
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • firewall.pp
    • logging.pp
    • audit.pp
    • selinux.pp
  • client.pp
  • client/
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • firewall.pp
    • logging.pp
    • audit.pp
    • selinux.pp

NOTE: Many legacy modules will use an earlier client/server pattern in init.pp where the Boolean parameters $is_client and $is_server.  To maintain compatibility, keep the parameters in init.pp and .

Modules that manage their own internal "services"

Occasionally there may be a component (like xinted) that manages multiple services of its own.  Managing these services 

• module/manifests/
  • init.pp
  • params.pp
  • config.pp
  • config/inet_service.pp  (a define that configures an inet_service)
  • service.pp
  • firewall.pp
  • firewall/inet_service.pp  (a define that establishes firewall rules for the inet_service)
    
  • logging.pp
  • audit.pp
  • selinux.pp (this one may just have to be mixed in at times, however, any boolean flipping should probably be done here)
    
    

Action Items

• Discuss these decisions on Monday and ensure that I didn't miss anything of note. Update the page accordingly.
  
• Construct the Puppet module skeleton defined in  SIMP-20 - Getting issue details... STATUS  to adhere to this structure.