puppetEnforce server configuration with Puppet
Puppet describes the desired state of a server (packages, files, services, users) in manifests and enforces it: puppet apply compiles a manifest locally, while puppet agent fetches a catalog from a Puppet server every 30 minutes and corrects any drift. Notice lines report exactly what it changed.
puppet apply [--noop] [--detailed-exitcodes] MANIFEST.pp · puppet agent --test [--noop] · puppet resource TYPE [NAME] · puppet parser validate FILEMake sure a server has the tree package, a managed /etc/motd and a deploy user with bash, using a local manifest.
sudoMost resources (packages, users, /etc files) need root.
Puppet is declarative and agent-based. First facter collects facts about the node (OS, IPs, memory, hostname). With puppet apply the local node compiles the manifest plus modules into a catalog: a graph of resources (package, file, service, user...) with their desired attributes and ordering (require, before, notify, subscribe). With puppet agent the node sends its facts over HTTPS (port 8140, mutual TLS with certificates signed by the Puppet CA) to the Puppet server, which compiles the catalog for it and sends it back. Either way, the agent then walks the catalog: for each resource a provider (apt for packages, useradd for users, systemd for services) reads the current state, compares it to the desired state and changes only what differs, logging a Notice per change. A notify relationship refreshes a service when its config file changed. The run report is saved and, with a server, sent back; the agent repeats every runinterval (30 minutes), so manual changes are reverted automatically.
apply FILE.ppCompile and enforce a manifest locallyagent --test (-t)One verbose foreground agent run against the server--noopDry run: report changes, make none--detailed-exitcodes0 none, 2 changed, 4 failed, 6 changed+failedparser validate FILESyntax-check manifestsresource TYPE [NAME]Show a resource's current state as Puppet codefacts show [FACT]Print facts facter collects--debug / --verboseMore loggingagent --disable 'reason'Pause agent runs during maintenanceUsing exec { 'apt-get install nginx': } for everythingIt runs on every agent run and Puppet can't tell whether anything changed.
package { 'nginx': ensure => installed } (or add unless/onlyif/creates to the exec)Fixing a Puppet-managed file by handThe next agent run (within 30 minutes) puts the managed content back.
Change the manifest or Hiera data, or puppet agent --disable 'reason' while you investigateAssuming resources run in the order they're writtenOrder comes from relationships; without require/before/notify the order isn't guaranteed to match intent.
File['/etc/nginx/nginx.conf'] ~> Service['nginx'] and Package['nginx'] -> File[...]Try these on a Linux machine of your own. Each task has a hint and a solution.
Write a manifest that ensures the package nginx is installed, the service nginx is running and enabled, and the service is restarted when /etc/nginx/nginx.conf changes.
Read this and say what happens on the next run: "Notice: /Stage[main]/Main/File[/etc/motd]/content: current_value '{sha256}deed...', should be '{sha256}5105...' (noop)"
Puppet isn't in the sandbox, but the idea of declared state is. Check by hand what puppet resource would report: does user devops exist, what shell, which home?
puppetEnforce server configuration with Puppet
Puppet describes the desired state of a server (packages, files, services, users) in manifests and enforces it: puppet apply compiles a manifest locally, while puppet agent fetches a catalog from a Puppet server every 30 minutes and corrects any drift. Notice lines report exactly what it changed.
puppet apply [--noop] [--detailed-exitcodes] MANIFEST.pp · puppet agent --test [--noop] · puppet resource TYPE [NAME] · puppet parser validate FILEMake sure a server has the tree package, a managed /etc/motd and a deploy user with bash, using a local manifest.
sudoMost resources (packages, users, /etc files) need root.
Puppet is declarative and agent-based. First facter collects facts about the node (OS, IPs, memory, hostname). With puppet apply the local node compiles the manifest plus modules into a catalog: a graph of resources (package, file, service, user...) with their desired attributes and ordering (require, before, notify, subscribe). With puppet agent the node sends its facts over HTTPS (port 8140, mutual TLS with certificates signed by the Puppet CA) to the Puppet server, which compiles the catalog for it and sends it back. Either way, the agent then walks the catalog: for each resource a provider (apt for packages, useradd for users, systemd for services) reads the current state, compares it to the desired state and changes only what differs, logging a Notice per change. A notify relationship refreshes a service when its config file changed. The run report is saved and, with a server, sent back; the agent repeats every runinterval (30 minutes), so manual changes are reverted automatically.
apply FILE.ppCompile and enforce a manifest locallyagent --test (-t)One verbose foreground agent run against the server--noopDry run: report changes, make none--detailed-exitcodes0 none, 2 changed, 4 failed, 6 changed+failedparser validate FILESyntax-check manifestsresource TYPE [NAME]Show a resource's current state as Puppet codefacts show [FACT]Print facts facter collects--debug / --verboseMore loggingagent --disable 'reason'Pause agent runs during maintenanceUsing exec { 'apt-get install nginx': } for everythingIt runs on every agent run and Puppet can't tell whether anything changed.
package { 'nginx': ensure => installed } (or add unless/onlyif/creates to the exec)Fixing a Puppet-managed file by handThe next agent run (within 30 minutes) puts the managed content back.
Change the manifest or Hiera data, or puppet agent --disable 'reason' while you investigateAssuming resources run in the order they're writtenOrder comes from relationships; without require/before/notify the order isn't guaranteed to match intent.
File['/etc/nginx/nginx.conf'] ~> Service['nginx'] and Package['nginx'] -> File[...]Try these on a Linux machine of your own. Each task has a hint and a solution.
Write a manifest that ensures the package nginx is installed, the service nginx is running and enabled, and the service is restarted when /etc/nginx/nginx.conf changes.
Read this and say what happens on the next run: "Notice: /Stage[main]/Main/File[/etc/motd]/content: current_value '{sha256}deed...', should be '{sha256}5105...' (noop)"
Puppet isn't in the sandbox, but the idea of declared state is. Check by hand what puppet resource would report: does user devops exist, what shell, which home?