{"id":22313338,"url":"https://github.com/nwops/puppet-psick","last_synced_at":"2026-02-26T02:37:25.267Z","repository":{"id":66969936,"uuid":"275907370","full_name":"nwops/puppet-psick","owner":"nwops","description":"Clone from https://github.com/example42/puppet-psick","archived":false,"fork":false,"pushed_at":"2020-06-29T19:28:13.000Z","size":994,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2025-03-26T02:40:45.290Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nwops.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-06-29T19:28:08.000Z","updated_at":"2020-06-29T19:28:19.000Z","dependencies_parsed_at":"2023-02-28T17:16:30.940Z","dependency_job_id":null,"html_url":"https://github.com/nwops/puppet-psick","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"purl":"pkg:github/nwops/puppet-psick","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-psick","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-psick/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-psick/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-psick/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nwops","download_url":"https://codeload.github.com/nwops/puppet-psick/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Fpuppet-psick/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29848634,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-25T22:37:40.667Z","status":"online","status_checked_at":"2026-02-26T02:00:06.774Z","response_time":89,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-03T22:06:59.847Z","updated_at":"2026-02-26T02:37:25.262Z","avatar_url":"https://github.com/nwops.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"# PSICK: The Infrastructure Puppet module\n\n[![Build Status](https://travis-ci.org/example42/puppet-psick.png?branch=master)](https://travis-ci.org/example42/puppet-psick)\n[![Codacy Badge](https://api.codacy.com/project/badge/Grade/353bcccff8fd405d9e867c839fd5b5b6)](https://www.codacy.com/app/example42/puppet-psick?utm_source=github.com\u0026amp;utm_medium=referral\u0026amp;utm_content=example42/puppet-psick\u0026amp;utm_campaign=Badge_Grade)\n\nThis is the PSICK (Puppet Systems Infrastructure Construction Kit) module.\n\nIt is what we call an **Infrastructure** Puppet **module**, as it can be used for most common systems configurations.\n\nIt provides:\n\n- Solid management of **classification**. Entirely hiera driven.\n- An integrated set of **profiles** for common systems management activities\n- A growing number flexible set of **tp profiles** for applications\n- Safe and easy to be integrated in existing setups, cohexists with other modules\n- It allows expandibility and customisability by design.\n- Entirely Hiera driven: In practice a DSL to configure infrastructures\n\nIt can be used together with the [PSICK control-repo](https://github.com/example42/psick) or as a strandalone module, just:\n\n    include psick\n\nThis doesn't do anything at all, by default, but is enough to let you manage *everything* via Hiera.\n\nIn the following examples we will use Hiera YAML files, but any backend can be used: psick is a normal, even if somehow unusual, Puppet module, with classes (a lot of them) whose params can be set as Hiera data, defines, templates, files, fuctions, custom data types etc.\n\nCheck the default [PSICK hiera data](https://github.com/example42/psick-hieradata) module for various usage examples.\n\n## Do You Speak Psick?\n\nPsick \"language\" has the syntax of any Hiera supported backend (here we use YAML), and the semantic you are going to discover here.\n\nThe module provides 3 major features:\n\n  - Structured cross-os, staged **classification**\n  - Base **profiles** for common system configurations\n  - Standardised and multifunctional **tp profiles** for applications\n\n### Classification\n\nPsick can manage the whole classification of the nodes of an infrastructure. It can work side by side and External Node Classifier, or it can totally replace it.\n\nAll you need is to include the psick class and define, using ```${::kernel}_class``` parameters, which classes to include in a node in different phases.\n\nPsick provides 4 phases, managed by the relevant subclasses:\n\n  - **firstrun**, optional phase, in which the resulting catalog is applied only once, at the first Puppet run. After a reboot can optionally be triggered and the real definitive catalog is applied.\n  - **pre**, prerequisites classes, they are applied in a normal catalog run (that is, always except in the very first Puppet run, if firstrun is enabled) before all the other classes.\n  - **base**, base classes, common to all the nodes (but exceptions can be applied), applied in normal catalog runs after the pre classes and before the profiles.\n  - **profiles**, exactly as in the roles and profiles pattern. The profile classes that differentiate nodes by their role or function. Profiles are applied after the base classes are managed.\n\nAn example of configurations, both for Linux and Windows nodes that use all the above phases:\n\n    # First run mode must be enabled and each class to include there explicitely defined:\n    psick::enable_firstrun: true\n    psick::firstrun::linux_classes:\n      hostname: psick::hostname\n      packages: psick::aws::sdk\n    psick::firstrun::windows_classes:\n      hostname: psick::hostname\n      packages: psick::aws::sdk\n\n    # Pre and base classes, both on Linux and Windows\n    psick::pre::linux_classes:\n      puppet: ::puppet\n      dns: psick::dns::resolver\n      hostname: psick::hostname\n      hosts: psick::hosts::resource\n      repo: psick::repo\n    psick::base::linux_classes:\n      sudo: psick::sudo\n      time: psick::time\n      sysctl: psick::sysctl\n      update: psick::update\n      ssh: psick::openssh::tp\n      mail: psick::postfix::tp\n      mail: psick::users::ad\n\n    psick::pre::windows_classes:\n      hosts: psick::hosts::resource\n    psick::base::windows_classes:\n      features: psick::windows::features\n      registry: psick::windows::registry\n      services: psick::windows::services\n      time: psick::time\n      users: psick::users::ad\n\n    # Profiles for specific roles (ie: webserver)\n    psick::profiles::linux_classes:\n      webserver: apache\n    psick::profiles::windows_classes:\n      webserver: iis\n\nThe each key-pair of these $kernel_classes parameters contain an arbitrary tag or marker (users, time, services, but could be any string), and the name the class to include.\n\nThis name must be a valid class, which can be found in the Puppet Master modulepath (so probably defined in your control-repo ```Puppetfile```): you can use any of the predefinied Psick profiles, or your own local site profiles, or directly classes from public modules and configure them via Hiera in their own namespace.\n\nTo manage exceptions and use a different class on different nodes is enough to specify the alternative class name as value for the used marker (here 'ssh'), in the appropriate Hiera file:\n\n    psick::base::linux_classes:\n      ssh: ::profile::ssh_bastion\n\nTo completely disable on specific nodes the usage of a class, included in a general hierarhy level, set the class name to an empty string:\n\n    psick::base::linux_classes:\n      ssh: ''\n\nThis is the classification part, since it's based on class parameters, it can be managed with flexibility via Hiera and can cohexist (even if this might not be an optimal choice) with other classifications methods.\n\nThe pre -\u003e base -\u003e profiles order is strictly enforced, so we sure to place your class in the most appropriate phase (even if functionally they all do the same work: include the specified classes) and, to prevent dependency cycles, avoid to set the same class in two different phases.\n\n### Psick tp profiles\n\nPsick provides out of the box profiles, based on ([Tiny Puppet](https://github.com/example42/puppet-tp), to manage common applications. They can replace or complement component modules when applications can be managed via packeages, services and files.\n\nThey have generated from a common [template](https://github.com/example42/pdk-module-template-tp-profile) so have standard parameters, and are always called ```psick::$app::tp```.\n\nFor example to configure Openssh both client and server settings we can write something like:\n\n    # By including the psick::openssh::tp profile we install Openssh via tp\n    psick::base::linux_classes:\n      ssh: 'psick::openssh::tp'\n\n    # To customise the configuration files to manage at their options:\n    psick::openssh::tp::resources_hash:\n      tp::conf:\n        openssh: # The openssh main configuration file\n          template: 'profile/openssh/sshd_config.erb'\n        openssh::ssh_config # The /etc/ssh/ssh_config file\n          epp: 'profile/openssh/ssh_config.epp'\n\n    # To manage the variables referenced in the used templates (the have to map the same keys):\n    psick::openssh::options_hash:\n      AllowAgentForwarding: yes\n      AllowTcpForwarding: yes\n      ListenAddress:\n        - 127.0.0.1\n        - 0.0.0.0\n      PasswordAuthentication: yes\n      PermitEmptyPasswords: no\n      PermitRootLogin: no\n\nSimilary we could manage postfix with data like:\n\n    psick::base::linux_classes:\n      mail: 'psick::postfix::tp'\n\n    # To customise the configuration files to manage at their options:\n    psick::postfix::tp::resources_hash:\n      tp::conf:\n        postfix: # Postfix's main.cf\n          template: 'profile/postfix/main.cf.erb'\n        postfix::master.cf # master.cf\n          epp: 'profile/postfix/master.cf.erb'\n\n\n### Psick base profiles\n\nBasides tp profiles, Psick features a large set of profiles for common baseline configurations.\n\nSome of them are intended to be used both on Linux and Windows, others are more specific.\n\nHere follows documentation on how to manage different common system configurations:\n\n- [psick::hosts](docs/hosts.md) - Manage /etc/hosts\n- [psick::motd](docs/motd.md) - Manage /etc/motd and /etc/issue\n- [psick::nfs](docs/nfs.md) - Manage NFS client and server\n- [psick::sudo](docs/sudo.md) - Manage sudo configuration\n- [psick::sysctl](docs/sysctl.md) - Manage sysctl settings\n- [psick::firewall](docs/firewall.md) - Manage firewalling\n- [psick::openssh](docs/openssh.md) - Manage openssh. Manage or create ssh keypairs\n- [psick::hardening](docs/hardening.md) - Manage system hardening\n- [psick::network](docs/network.md) - Manage networking\n- [psick::puppet](docs/puppet.md) - Manage Puppet components\n- [psick::users](docs/users.md) - Manage users\n- [psick::time](docs/time.md) - Manage time and timezones [Linux/Windows]\n- [psick::windows](docs/windows.md) - Windows profiles and tools\n\n\n### Applications profiles\n\nFor some applications, besides standard tp profiles, there are dedicated profile classes and defines. Here's a list:\n\n- [psick::ansible](docs/ansible.md) - Manage Ansible installation and user\n- [psick::aws](docs/aws.md) - Manage AWS client tools and infrastructures setup\n- [psick::bolt](docs/bolt.md) - Manage Bolt installation and user\n- [psick::docker](docs/docker.md) - Docker installation and build tools\n- [psick::foreman](docs/foreman.md) - Foreman installation\n- [psick::git](docs/git.md) - Git installation and configuration\n- [psick::gitlab](docs/gitlab.md) - GitLab installation and configuration\n- [psick::mariadb](docs/mysql.md) - Manage Mariadb\n- [psick::mysql](docs/mysql.md) - Manage Mysql\n- [psick::mongo](docs/mongo.md) - Manage Mongo\n- [psick::php](docs/php.md) - Manage php and modules\n- [psick::oracle](docs/oracle.md) - Manage Oracle prerequisites and installation\n- [psick::sensu](docs/sensu.md) - Manage Sensu\n\n### Main variables and common paraters\n\nThe main ```psick``` class manages classification (it includes ```psick::pre```, ```psick::base```, ```psick::profiles``` and eventually ```psick::firstrun``` classes, from where classes are included based on Hiera data) and exposes some parameters which can be used by other psick profiles.\n\n#### Parameters in main psick class used by other psick profiles\n\nSome of psick class' parameters are used as defaults for all tp profiles and most of the base ones.\n\nThey are as follows, with their default values.\n\nDefine if to actually manage any resource. This setting is the default entry point for the manage paramenter on each psick class.\n\n    Boolean $manage            = true\n\nIf to manage automatically prerequisites for the used profiles. This affects tp::install and other resources.\nSet to false, globally or in specific profiles, to cope with duplicated resources errors, in case same prerequisites are requested by more profiles.\n\n    Boolean $auto_prereq       = true\n\nIf to use the noop() function for all the classes included in this module. This setting is the default for all the psick classes, and can be overridden in each of them. When true the value of the parameter noop_value is passed to the noop() function.\n\n    Boolean $noop_manage       = false\n\nThe value to pass to the noop function when $noop_manage is true. This value is the default, which can be overridden, in each psick class.\n\n    Boolean $noop_value        = false # No-noop is enforced on the class and overrides any noop settings\n    Boolean $noop_value        = true  # Noop is enforced on the class\n\n#### Special parameters in main psick class\n\nA generic, by default empty, hash of custom settings to use as needed in any class included by psick.\nNo psick profile is using this.\n\n    Hash $settings             = {}\n\nAn hash of different endpoints for different infrastructure services (which may be referenced in different classes).\nCurrently used in psick::proxy\n\n    Hash $servers              = {}\n\nAn hash that configures the default resource defaults for tp::install, tp::conf and tp::dir defines.\nIs honoured by the above tp defines in any class included via psick.\n\n    Hash $tp                   = {} # Defaults in data/common.yaml\n\nAn hash to configure firewall related settings.\n\n    Hash $firewall             = {} # Defaults in data/common.yaml\n\nAn hash to configure monitor related settings.\n\n    Hash $monitor              = {} # Defaults in data/common.yaml\n\nA parameter that disables forced ordering of the classes included in psick different phases (pre, base, profiles). Set this to false when you can dependency cicles between classes included via psick which you are not able to manage via proper psick classification. If set to false classes included in pre might not be actually applied before the other ones.\n\n    Boolean $force_ordering    = true\n\n#### Common parameters in psick base and tp profiles\n\nSome other parameters can be found in psick profiles:\n\nGeneric hash of options which can be used in templates evaluated in the relevant profile. It's looked up in deep merge mode and in some profiles in can be merged with local default settings. In erb templates the keys used in the $options_hash can be generally referred with \u003c%= @options['key'] %\u003e, with the $options var being the merge of a local $options_default + $options_hash.\n\n    Hash            $options_hash             = {}\n\nIf to install or remove the relevant profile resources (can be present, absent, installed or a version number):\n\n    Psick::Ensure   $ensure                   = 'present'\n\nWhat module to use to manage the relevant profile application. This is present is some base profiles. The default is to use local psick resources (usually a tp profile), some profiles have integrations with different common public modules.\n\n    String          $module                  = 'psick'\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Fpuppet-psick","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnwops%2Fpuppet-psick","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Fpuppet-psick/lists"}