I know you pulled this from the doc but if the repo is in azure , I dont think tfs-git is working as a test

Gitlab is so I can confirm the token is correct

Changing the type while configuring the webhook in azure is giving a dns error

Does

puppet code deploy {environment} --wait

work from your primary? If Azure can't lookup/connect to the primary to trigger the webhook, then that is a connectivity issue from Azure to the primary; in the interim you may need to trigger deploys using a different mechanism (eg: puppet code deploy)

If Azure can't lookup/connect to the primary to trigger the webhook, then that is a connectivity issue from Azure to the primary. Do you know what can I do to resolve that on Azure side

I did find the webhook configured before which was removed and that was using tfs-git

So maybe your correct on that side and I'm missing something which needs to be done on azure side

puppet & selinux question. https://www.puppet.com/docs/puppet/7/types/file.html#file-attribute-selinux_ignore_defaults Are these just OS defaults that it's re-enforcing? the doc here gives "examples", rather than saying the default

Basically it won't do chcon on the file.

touch /root/blah
chcon -t var_t /root/blah
puppet apply --noop -e 'file{"/root/blah": ensure => file}'

Notice: /Stage[main]/Main/File[/root/blah]/seluser: current_value 'unconfined_u', should be 'system_u' (noop)
Notice: /Stage[main]/Main/File[/root/blah]/seltype: current_value 'var_t', should be 'admin_home_t' (noop)

puppet apply --noop -e 'file{"/root/blah": ensure => file, selinux_ignore_defaults => true}'

The last command won't do anything to change the context

imho, no such thing as OS defaults, it's just a default context

sure, used "os defaults" as not a default context set within puppet

thanks @vchepkov, we've never used selinux around here so was surprised when Puppet reapplied se* context here

it's good that way 🙂 Now that Amazon Linux 23 sets enforcing mode by default, more folks will start learning it, hopefully.

currently testing RHEL 9, so coming from 6 & 7, it's a good time to implement some of these things

that had been resisted for a long time

indeed, most of the documents start with 'disable SELinux' 😞

@vchepkov I remember bitterly the sadness as I marginally lost the argument to implement SElinux enforcing by default on the Rhel 7 build in a previous role 😭 It was promised it would definitely happen in Rhel 8 (It wasn't my job by the time 8 came round and it didn't happen)

VERBOSE: Transferring package from source https://us03p01as01.prod.nextravel.com:8140/packages/2021.7.2/windows-x86_64/puppet-agent-x64.msi VERBOSE: Downloading the Puppet Agent for Puppet Enterprise on US03P02APT05... VERBOSE: Using found Puppet CA certificate to validate the Puppet Agent download: C:\ProgramData\Puppetlabs\puppet\etc\ssl\certs\ca.pem Failed to download the Puppet Agent installer: https://us03p01as01.prod.nextravel.com:8140/packages/2021.7.2/windows-x86_64/puppet-agent-x64.msi. Does the primary have the pe_repo:platform:windows_x86_64 class applied to it? At C\Windows\system32\install.ps1246 char:9 + Throw $error_message + ~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (Failed to downl... applied to it?:String) [], RuntimeException + FullyQualifiedErrorId : Failed to download the Puppet Agent installer: https://us03p01as01.prod.nextravel.co m:8140/packages/2021.7.2/windows-x86_64/puppet-agent-x64.msi. Does the primary have the pe_repo:platform:windows _x86_64 class applied to it? (edited) Tried to add the node on Puppet ad keep getting this error. Manually tried setting up the agent as wChecked the PE master and removed that class from it. Still no luck when trying to add the node

does the installer present on the server?

ls -ld /opt/puppetlabs/server/data/packages/public/2021.7.2/windows*

btw, latest LTS is 2021.7.4

/opt/puppetlabs/server/data/packages/public/2021.7.2/windowsfips-x86_64 -> /opt/puppetlabs/server/data/packages/public/2021.7.2/windowsfips-x86_64-7.21.0 drwxr-xr-x. 2 root root 4096 Feb 21 11:24 /opt/puppetlabs/server/data/packages/public/2021.7.2/windowsfips-x86_64-7.21.0 lrwxrwxrwx. 1 root root 74 Feb 21 11:27 /opt/puppetlabs/server/data/packages/public/2021.7.2/windows-x86_64 -> /opt/puppetlabs/server/data/packages/public/2021.7.2/windows-x86_64-6.17.0 drwxr-xr-x. 2 root root 4096 Feb 21 11:27 /opt/puppetlabs/server/data/packages/public/2021.7.2/windows-x86_64-6.17.0 drwxr-xr-x. 2 root root 4096 Feb 21 11:24 /opt/puppetlabs/server/data/packages/public/2021.7.2/windows-x86_64-7.21.0

your windows-x86_64 point to and old PE there

you can probably remove

/opt/puppetlabs/server/data/packages/public

and re-run agent on the primary and it should put everything back

Remove that from puppetserver?

yes

did you upgrade that server from 2019?

I did do an upgrade on puppetserver

hmm, how did 6.17 got there?