platform module

Welcome to your new module. A short overview of the generated parts can be found in the PDK documentation.

The README template below provides a starting point with details about what information to include in your README.

Table of Contents

1. Description
2. Setup - The basics of getting started with platform
   • What platform affects
   • Setup requirements
   • Beginning with platform
3. Usage - Configuration options and additional functionality
4. Limitations - OS compatibility, etc.
5. Development - Guide for contributing to the module

Description

Briefly tell users why they might want to use your module. Explain what your module does and what kind of problems users can solve with it.

This should be a fairly short description helps the user decide if your module is what they want.

Setup

What platform affects OPTIONAL

If it's obvious what your module touches, you can skip this section. For example, folks can probably figure out that your mysql_instance module affects their MySQL instances.

If there's more that they should know about, though, this is the place to mention:

• Files, packages, services, or operations that the module will alter, impact, or execute.
• Dependencies that your module automatically installs.
• Warnings or other important notices.

Setup Requirements OPTIONAL

If your module requires anything extra before setting up (pluginsync enabled, another module, etc.), mention it here.

If your most recent release breaks compatibility or requires particular steps for upgrading, you might want to include an additional "Upgrading" section here.

Beginning with platform

The very basic steps needed for a user to get the module up and running. This can include setup steps, if necessary, or it can be an example of the most basic use of the module.

Usage

Include usage examples for common use cases in the Usage section. Show your users how to use your module to solve problems, and be sure to include code examples. Include three to five examples of the most important or common tasks a user can accomplish with your module. Show users how to accomplish more complex tasks that involve different types, classes, and functions working in tandem.

Important Notes

1. Puppet configuration on Windows and Linux needs an extra section that we haven't previously provisioned. This section is the user section which controls the other puppet tools and commands. This includes plugin downloads.

...existing sections [agent] and [server]...
[user]
server = puppet.example.com
certname = <certname>

Features

platform

• General
  • Encrypted Hiera Support
  • Domain Information
  • Project Information
• System Basics
  • Configure Timezone
  • Configure NTP
  • Configure DNS
  • Hosts File Manipulation
• Networking
  • Configure Network Interfaces
  • Configure Network Routing
• Remote Management
  • SSH Configuration
  • RDP Configuration
  • WinRM Configuration
  • IPMI Configuration
  • IPMI User Management
  • IPMI Enablement
  • IPMI Disablement
• User Management
  • Create Local Users
    • Configure Users Shell
    • Configure Shell Extensions
    • Provision SSH Keys
      • Provision SSH Keys from Hiera
      • Provision SSH Keys from GitHub or LaunchPad
    • Provision Arbitrary Files
  • Create Domain Users
    • Configure Users Shell
    • Configure Shell Extensions
    • Provision SSH Keys
      • Provision SSH Keys from Hiera
      • Provision SSH Keys from GitHub or LaunchPad
    • Provision Arbitrary Files
• Access Control
  • Join Domain
  • Configure Access Control
    • Support Per-Project Access
    • Support Per-System Access
  • Configure Sudo Access
    • Support Per-Project Sudo
    • Support Per-System Sudo
• Firewall
  • Configure iptables
  • Configure nftables
• Monitoring
  • Node Exporter
• Logging
  • Command Execution Logging
• Tools
  • Netcheck
• Facts
  • Domain Joined
  • Domain Information
  • Home Directories
  • Domain Controller
  • Sudo Roles
• DNS

platform::domain

• Users
  • Create New Users
  • Delete Users
• Groups
  • Create New Groups
  • Delete Groups
  • Add Users to Groups
  • Add Groups to Groups
• Organizational Units
  • Create New Organizational Units
  • Delete Organizational Units
• Sudo
  • Create New Sudo Roles
  • Configure Sudo Role Groups
  • Configure Sudo Role Commands
  • Configure Sudo Role Hosts
• Domain Name Services
  • Create new DNS Records
  • Delete DNS Records

platform::<need_to_be_sorted_still>

• WEMO
  • WEMO Install
  • WEMO Configuration
  • WEMO Rule Manipulation
• System Deployment
  • MAAS
  • Virtualization
    • Libvirt
    • LXD
• Switch Management
  • Cisco Switch Configuration
  • Whitebox Switch Configuration
  • OVS
    • OVS Install
    • OVS Configuration
• GitHub Runners
  • Deploy GitHub Runner
  • Configure GitHub Runner
  • Deploy Secrets
• Puppet Server
  • Configure Puppet Server
  • Deploy Control Repo
  • Create GitHub Runner
  • Configure Pipelines

Reference

This section is deprecated. Instead, add reference information to your code as Puppet Strings comments, and then use Strings to generate a REFERENCE.md in your module. For details on how to add code comments and generate documentation with Strings, see the Puppet Strings documentation and style guide.

If you aren't ready to use Strings yet, manually create a REFERENCE.md in the root of your module directory and list out each of your module's classes, defined types, facts, functions, Puppet tasks, task plans, and resource types and providers, along with the parameters for each.

For each element (class, defined type, function, and so on), list:

• The data type, if applicable.
• A description of what the element does.
• Valid values, if the data type doesn't make it obvious.
• Default value, if any.

For example:

### `pet::cat`

#### Parameters

##### `meow`

Enables vocalization in your cat. Valid options: 'string'.

Default: 'medium-loud'.

Limitations

In the Limitations section, list any incompatibilities, known issues, or other warnings.

Development

In the Development section, tell other users the ground rules for contributing to your project and how they should submit their work.

Release Notes/Contributors/Etc. Optional

If you aren't using changelog, put your release notes here (though you should consider using changelog). You can also add any additional sections you feel are necessary or important to include here. Please use the ## header.