server_patching

The module provides classes built around server patching procedures.

Table of Contents

1. Description
2. Setup - The basics of getting started with server_patching
   • Setup requirements
   • Beginning with server_patching
3. Usage - Configuration options and additional functionality
4. Limitations - OS compatibility, etc.

Description

At the moment the only useable class is server_patching::validation, which allows to define post-patching checks and generate a bash script implementing these checks. Designed to be invoked with AWS SSM software.

Setup

Setup Requirements

The module uses netstat, curl and pgrep. These utilities have to be installed on the system. Designed to work only with modern systems managed by systemd.

Beginning with server_patching

Commonly the module is invoked by including a subclass. For patching validation it is just

include server_patching::validate

Further configuration is more conveniently performed in hiera.

Usage

The following example covers the use of all module parameters:

server_patching::validate::ensure: present
server_patching::validate::validation_script: /usr/local/sbin/validate.sh
server_patching::validate::services:
  - name: open-vm-tools.service
    active: true
  - name: openipmi.service
    active: false
server_patching::validate::processes:
  - name: falcond
    running: true
  - name: java
    command: solr 
server_patching::validate::urls:
  - url: https://netdb.stanford.edu/status-DLK87ufdskjf
    status: 200
  - url: https://netdb.stanford.edu
    resolve_to: 171.67.5.154
    status: 302
server_patching::validate::ports:
  - port: 22
    proto: tcp
    ip_ver: ipv4
    listening: true
  - port: 23
    proto: tcp
    ip_ver: ipv4
    listening: false
server_patching::validate::mounts:
  - /home
  - /mnt/data
server_patching::validate::exports:
  - /share/raw_data
  - /share/processed_data
server_patching::validate::zfs_pools:
  - pool1
  - pool2

The fragment generates verifies if:

• VMWare tools service is running
• CrowdStrike daemon process is running
• Java process which has solr in its command line is running
• NetDB URL redirects somewhere (to WebAuth presumably)
• NetDB server 171.67.5.154 status URL returns success
• SSH port is open over IPv4
• Telnet port is closed over IPv4
• Given ZFS pools are imported
• Given NFS shares are exported

The module would generate a validation script validation.sh in /usr/local/bin/ directory, which can be triggered by SSM and return a zero exit code if all checks pass or non-zero code with a number of failed checks. It outputs the log of the checks run to stdout.

Limitations

Designed for use only with the systems managed by systemd.