This message was deleted.

Do you have existing puppet agents in this environment whose certificate trust you need to maintain? Or is this a brand new Puppet infra with no agents?

The way to set dns alt names from the start is to add

dns_alt_names

to the

[server]

section of puppet.conf before starting puppetserver for the first time. That can be done manually:

sudo mkdir -p /etc/puppetlabs/puppet
sudo vim /etc/puppetlabs/puppet/puppet.conf

Or with:

sudo puppet config set dns_alt_names --section server name1,name2,name3

This message was deleted.

This message was deleted.

Would I need to look into tagging?

So, say for example you did have some fact called

app

that identifies that application that is running on a node, you could do something like the above example that just has a static list of app names to "onboard" to the new feature.

A good way of dealing with this kind of situation is to use feature flags. Wrap the declaration of those registry keys in conditional logic that is gated by a class parameter. For example:

class windows_mitigations (
  Boolean $enable_new_mitigations = false,
) {

  if $enable_new_mititgations {
    registry_value { 'foo/bar':
      ensure => present,
      data   => 'hello',
  }

}

1. The feature flag is

false

by default. This means you can push the change out and nothing will happen. It lets you stage the feature without enabling it. 2. Where you would declare the class that controls windows mitigations, you flip that feature flag parameter to

true

when you want to rollout to a new app.

At the moment most of our nodes are falling into the "default" bucket within site.pp

Sure.... though how would you identify which ring a node is in? Usually, in my experience, it always comes down to a feature flag. Whether you slice up your nodes by app, deployment ring, owner, or zodiac sign doesn't matter. What matters is organizing your new feature in your code behind some class parameter that can be toggle on or off.

Sure.... though how would you identify which ring a node is in? Usually, in my experience, it always comes down to a feature flag. Whether you slice up your nodes by app, deployment ring, owner, or zodiac sign doesn't matter. What matters is organizing your new feature in your code behind some class parameter that can be toggled on or off.

The goal is basically to limit the deployment to a portion of the environment, and not let er rip against the entirety of "production" including currently uncategorized db servers

Yeah, definitely. And this is made easier with custom facts. If there's a custom fact that portions your nodes in some way, you could use that fact to limit the blast radius of a change via the feature flag model.

The goal is basically to limit the deployment to a portion of the environment, and not let er rip against the entirety of "production" including currently uncategorized db servers

Yeah, definitely. And this is made easier with custom facts or ENC data. If there's a custom fact that portions your nodes in some way, you could use that fact to limit the blast radius of a change via the feature flag model.

So... how would you identify that information? Say I came into your network and pointed at a node, how would you know what purpose that node serve?

So... how would you identify that information? Say I came into your network and pointed at a node, how would you know what purpose that node serves?

There is a way to set arbitrary node data at the Puppetserver level, though that's a little more involved and assumes you have some kind of central database of node data that can be read from (or even just a small shell script that spits out some data). That thing is called an External Node Classifier (ENC): https://www.puppet.com/docs/puppet/7/nodes_external.html An ENC is a script that you write, and is executed at the start of each Puppet run. It's input is the agent's certname, and it's output is a YAML document of arbitrary key:value pairs. Those keys become top-scope variables that you can access anywhere in your Puppet code.

And I mean, I guess at the extreme end of this, if you don't have facts or ENC data to slice up your nodes into bite-sizes groups, you'd need to write either

node

definitions per node that set some variable. Or have a giant

if

or

case

statement in site.pp that sets that variable. Now.... that's a terrible idea... and is why it's good to have facts or ENC data so that you can group your nodes.

yea, this is what my personal site.pp currently looks like...

node default {
  include profile::base
}
### Debian (x86_64)
node 'vmipam01.britanniahome.local' {
  include profile::base
  include profile::phpipam::phpipam_apache
}
node '<http://vmsftp.britanniahome.net|vmsftp.britanniahome.net>' {
  include profile::base
  include profile::sftp::vmsftp::vmsftp_config
  include accounts
  include fail2ban
}

## Windows
## debian (arm64)
node '<http://octopi.britanniahome.net|octopi.britanniahome.net>' {
  include profile::base::linux_directories # site wide direcories
  include serviceaccounts::linux::root # linux root user account
}

### Template VMs:
node '<http://tmplt-ubntu-2004.britanniahome.net|tmplt-ubntu-2004.britanniahome.net>' {
  include profile::vmtemplate
}

So, back to the question of "how would you tell me what a node does if I pointed to it in your datacenter?" Some organizations have a hostname strategy where the purpose of a node is part of its hostname. It looks like in your case, there's not a consistent host naming convention. Some organizations have a central database of IP address or hostnames that map back to a business unit and/owner. Do you have something like that?

In our case one would have to look at it's details and description, sometimes documentation to figure out what it does

If webapp1 and webapp2 are fundamentally different in terms of their Puppet code, then yes, that'd be different roles. Usually the name of the "role" class should tell you the purpose of the machine. For example, what business purpose that node serves. It doesn't have to be as specific as the name of the technology running on that node since that's usually handled by technology-specific profiles.

Dear lord, On a whim I asked ChatGPT for a recommendation and visualization and it gave me a hot mess

Good news for Nate and me! We cannot be replaced with GPT yet! 😆

Hmm, this would probably be a lot easier if the T0 systems were in a different environment.

message has been deleted

message has been deleted

It looks like PE can group based on node name and then apply classes or hieradata based off that, but with community I'd have to create ENC's to group hosts and apply group based overrides opposed to individual files within /hieradata/nodes/* for every node, is that accurate?

For example, let's say I want to apply a very specific set of properties to the ssh module, specifically for those hosts.. I'd rather not have to create a hiera file for each individual host containing this data and handle it at the group level instead.

ssh::server_options:
  protocol: '2'
  Port: '22'
  PasswordAuthentication: 'no'
  PermitRootLogin: 'no'
  ChallengeResponseAuthentication: 'no'
  # ChrootDirectory: '%h'
  UsePAM: 'yes'
  AllowTcpForwarding: 'no'
  X11Forwarding: 'no'
  LoginGraceTime: '1m'
  MaxAuthTries: '4'
  MaxSessions: '20'
  MaxStartups: '10:30:100'
  KexAlgorithms: '-diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,ecdh-sha2-nistp256'
  ciphers: '-aes128-cbc,aes256-cbc'
  PrintMotd: 'no'
  Subsystem: 'sftp internal-sftp'
  Match group sftponly:
    ForceCommand: 'internal-sftp -u 027'
    ChrootDirectory: '/srv/sftpdata/%u'
    PermitTunnel: 'no'
    AllowAgentForwarding: 'no'
    AllowTcpForwarding: 'no'
    X11Forwarding: 'no'
    PasswordAuthentication: 'yes'
  Match all:

that overrides my defaults in common.yaml . For example, let's say I want to apply a very specific set of properties to the ssh module, specifically for those hosts. I'd rather not have to create a hiera file for each individual host containing this data and handle it at the group level instead.

ssh::server_options:
  protocol: '2'
  Port: '22'
  PasswordAuthentication: 'no'
  PermitRootLogin: 'no'
  ChallengeResponseAuthentication: 'no'
  # ChrootDirectory: '%h'
  UsePAM: 'yes'
  AllowTcpForwarding: 'no'
  X11Forwarding: 'no'
  LoginGraceTime: '1m'
  MaxAuthTries: '4'
  MaxSessions: '20'
  MaxStartups: '10:30:100'
  KexAlgorithms: '-diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,ecdh-sha2-nistp256'
  ciphers: '-aes128-cbc,aes256-cbc'
  PrintMotd: 'no'
  Subsystem: 'sftp internal-sftp'
  Match group sftponly:
    ForceCommand: 'internal-sftp -u 027'
    ChrootDirectory: '/srv/sftpdata/%u'
    PermitTunnel: 'no'
    AllowAgentForwarding: 'no'
    AllowTcpForwarding: 'no'
    X11Forwarding: 'no'
    PasswordAuthentication: 'yes'
  Match all:

This message was deleted.