Page Comparison

Background

...

Our decision ended up being as follows.

Basic Module Assumptions

• It expected that SIMP 6 modules will drop support for Puppet 3.

Basic Module Structure

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

...

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

• simp_opt::trusted_nets
  
  • Old Name: client_nets
  • Array of Strings /or String = subnets to permit, generally in CIDR notation.  This may be required by the module regardless of whether any SIMP subsystems are used.
     
• simp_opt::firewall
  
  • Old Name: simp_firewall and use_iptables
  • true = includes simp-iptables and sets up rules to permit the application
  • false = Firewall settings for the application are not managed; use a profile to make your own arrangements
    
    
• simp_opt::syslog
  
  • Old Name: simp_logging
  • true = includes simp-rsyslog and configures rsyslog hooks into the application 's log files (and/or sets things up to be logged appropriately through the SIMP default LOCAL6 for security relevant items.)
    • NOTE: in the future this may expand to logging providers beyond rsyslog, thus requiring le Stroolean
  • false = doesn't set up logging via SIMP
     
• simp_opt::audit
  
  • Old Name: simp_auditd
  • true = QUESTION: I imagine "true" includes simp-auditd, and "false" leaves auditing unmanaged.  Should it do anything else? 

  • true  = If applicable, include the ::auditd class and add audit rules that are specific to the current module. If not applicable, this should do nothing.

  • false = Does not include any auditing capabilities via SIMP
     

• simp_opt::selinux

  • Old Name: simp_selinux

  • true  = includes simp-selinux (which effectively manages the SELinux enforcement and mode) and manages SIMP-specific SELinux configurations (QUESTION: like what? ANSWER: Not a lot, honestly besides the fact that we actually configure SELinux as a core part of the system and you need our facts to make it work.)

    • NOTE:  Most if not all module-specific SElinux configurations are handled as attributes of native puppet resources and will not be influence by this parameter.

    • SE boolean flipping should probably be done here, especially if they rely on the SIMP environment (NOTE: this is pretty vague. NOTE NOTE: We have a couple of facts that we added to help detect the SELinux state on your system.)

  • false = does not ensure that SELinux is enabled via simp-selinux; make your own arrangements elsewhere.   

    • NOTE: It may seem counterintuitive, but setting this parameter to false DOES NOT disable SELinux!  

    • To disable SELinux (within a SIMP ecosystem), include simp-selinux (with $simp_selinux = true) and ensure that the top-scope hiera or ENC variable  $::selinux::enable is set to false.
       

• simp_opt::pki
  
  • Old Name: simp_pki
  • true or '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_opt::tcpwrappers
  • Old Name: simp_tcpwrappers
  • true = includes simp-tcpwrappers and uses tcpwrappers::allow to permit the application to the subnets in $::simp_opt::clienttrusted_nets
  • false = TCP wrappers (/etc/hosts.*) entries for the application are not managed; make your own arrangements (using a profile, probably).

...

1. The parameter must be disabled (false) by default (NOTE: starting with SIMP 6).
2. The parameter must honor booleans and Strings where the Boolean true and the String 'simp' amount to the same action.
   1. Welcome to the Trevorian type "Stroolean." 
   2. The String value such as 'simp' will translate into the filename in the subsystem  path simp/<subsystem>/simp.pp 
      1. This is intended to permit backwards compatibility between SIMP versions if they require mutually exclusive logic (i.e., 'simp', 'simp4', 'simp4_2', 'simp5', etc.,).
      2. QUESTION: what is the benefit of these files over the ::params pattern? 
         ANSWER: 
         1. it allows n parallel configuration tracks to coexist without conflicting
         2. it separates SIMP-specific settings from the rest of the module.
3. The parameter 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:

          $simp_firewall = defined('$::simp_opt::firewall') ? { true => getvar($'::simp_opt::firewall'), default => hiera('simp_opt::firewall',true) }

      Note: When SIMP-1694 is complete, this will look like the following

          $simp_firewall = simp_opt('firewall', 'true')

      Translation:

          $parameter => { <if set> => <use global/ENV variable>, <otherwise> => <use what's in Hiera or default to true> } 

      1. QUESTION: Should we make this defined->hiera->default logic a function in simplib?
         ANSWER: Yeah, probably. How about.....simp_def('variable','default')
      2. QUESTION: Why not just lookup()?
         ANSWER: lookup() was introduced in Puppet 4.  The core SIMP modules will need to support Puppet 3.x for at some time (at least another major version, probably longer).
4. The default parameter lookup will reference the associated Global Catalyst.

Advanced Module Structure

...

•  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 

  Jira Legacy
  server JIRA (simp-project.atlassian.net) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 45e63be1-2551-37a6-b050-86a38172f71d key SIMP-20

   to adhere to this structure.