[Puppet Users] CRL is not honored by the puppetmaster.
Hey all, This terrifies me. As part of my certificate roll, I did, on my master: root@pm:~ # puppet cert clean somehost.foo.org Notice: Revoked certificate with serial 43 Notice: Removing file Puppet::SSL::Certificate somehost.foo.org at '/var/puppet/ssl/ca/signed/somehost.foo.org.pem' Notice: Removing file Puppet::SSL::Certificate somehost.foo.org at '/var/puppet/ssl/certs/somehost.foo.org.pem' If I run it again, it re-revokes the cert, but of course there's nothing to delete. Doing puppet ca revoke somehost.foo.org also redoes the revocation. However the agent happily continues to download catalogs. (Or more accurately, the master continues to hand them out). I've verified that the cert is listed as revoked in *both* the host CRL as well as the CA CRL, using the following: openssl crl -inform PEM -text -noout -in /var/puppet/ssl/ca/ca_crl.pem (where it's listed as 2B, because it's in hex, but the revoke date is right). It's also in the host ca on the puppetmaster -- so the two places there's a CA, it's listed with the right date. There's only one place each of these files can be pointed to in puppet.conf, so it's not possible that I've set it to be written, but not actually used, is it? -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: [Puppet Users] CRL is not honored by the puppetmaster.
On Thu, 16 Jun 2016, Kurt Wall wrote: The CRL needs to be reloaded to take effect. As of Puppet Server 2.3, you can SIGHUP it to force the reload without having to incur the overhead of a full server restart (https://docs.puppet.com/puppetserver/latest/restarting.html). Thanks Kurt, this helped! I'd think doing a revoke would cause a forced reload of the CRL -- at least if I'm using the built-in webrick puppetmaster (maybe it would stat() the file and check the date to see if there's a reload?). I guess I'd be wrong. As it's largely deprecated, suggesting improvements to it seems sort of moot. (It would also be nice if the CA had some kind of hook it could run when you do a revoke -- like an apachectl graceful). Reading up, it looks like if I'm using apache (which I just switched over to), I can configure an OCSP responder on the same box, and have apache check that on the fly, which would save apache from having to read a static file. In that way, revoked really is revoked, immediately. As mentioned in a previous thread, it would be good if puppet fired up its own OCSP responder, and embedded the OCSP url into the certificates it issues. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
[Puppet Users] puppet-agent package on FreeBSD
All, I keep seeing updates about a new release of a standalone puppet agent. Other than small file size and a possible reduced dependency set, is there any useful point in porting it to FreeBSD? Right now, on FreeBSD, pkg shows the following subset of things for a "pkg search puppet" (there are other things that aren't relevant, like a Nagios plugin and the like): puppet37-3.7.5_1 Configuration management framework written in Ruby puppet38-3.8.4_1 Configuration management framework written in Ruby puppet4-4.4.1 Configuration management framework written in Ruby puppetdb-2.3.8_1 PuppetDB storeconfigs backend puppetdb-terminus-2.3.4_1 PuppetDB storeconfigs backend terminus module puppetdb-terminus4-4.0.0 PuppetDB storeconfigs backend terminus module puppetdb4-4.0.0PuppetDB storeconfigs backend puppetserver-2.2.1 Puppet Server running in the JVM None of these version numbers seem to align with the things I see being announced here -- do the packages being built here basically include the agent? We have lots of nodes where we don't need a full puppet server, but I don't know how much code that would actually save. (Disk is cheap) -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
[Puppet Users] FreeBSD 8.x: Warning: Found multiple default providers for package: pkgng, freebsd; using pkgng
Hey there, Puppet 3.8.1 under FreeBSD 8.x (yes, I know it's EOL). I'm seeing the following warning when my manifest runs: Warning: Found multiple default providers for package: pkgng, freebsd; using pkgng I've set a provider in site.pp (and verified that that portion of the manifest has been loading): if $::operatingsystem == 'FreeBSD' { Package { provider => 'pkgng' } } But the warning persists. It's defaulting to use the provider that I want, so this is totally harmless. Clearly, setting that provider doesn't stop the warning that there's multiple *default* ones. Is there any way, within my manifest (not the code) to say "ignore the FreeBSD provider" (which uses classic FreeBSD packages), which are at this point totally unsupported. I've seen several other reported bugs involving this error, some of which cause debian package managers to show up under FreeBSD -- so I guess whenever I'm seeing this, it's a bug? -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: [Puppet Users] Re: Good documentation somewhere for doing a cert-roll?
On Mon, 20 Jun 2016, John Gelnaw wrote: Many thanks for the re-signing of the CA idea. I can report that it worked for me, although I had to run the webrick version of puppetmaster to regenerate the puppet master's certificate. Okay -- so, I discovered a few things that I should share, and perhaps that others should perhaps heed as well. Take your old certificate, and plug it in here: https://redkestrel.co.uk/products/decoder/ (Super helpful tool!) And then try your old cert. You'll notice some differences. There's a few things that you should do if you're following my previous instructions. Additional Certificate Fields = When you sign a certificate, there can be extra fields in the certificate, beyond the basic "here's a key, signed by another key". There's at least a couple fields that we didn't add -- some may matter in the future, some may not. For example, there's a comment field (puppet probably will never care about this), as well as some special attributes that say CA: True. (Puppet may in the future care about this -- a proper root ca cert will have this field set). There's also a few hashes, a "subject key identifier" and an "authority key identifier". Finally, there's some certificate purpose fields present that list what a cert may be used for. (Puppet for the moment doesn't seem to look for or check these, but if they decide to be more strict in the future, you want to at least match the puppetmaster's old behavior). To get these in, I made use of my openssl.cnf (on FreeBSD this is in /etc/ssl), and added the following fields: [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer nsComment = "Ruby Generated Certificate" basicConstraints = critical,CA:true keyUsage = cRLSign, keyCertSign And ran OpenSSL with the following args: openssl x509 -req -in /tmp/ca_cert.csr -signkey /var/puppet/ssl/ca/ca_key.pem -days 3500 -out /tmp/ca_crt.pem -extfile /etc/ssl/openssl.cnf -extensions v3_ca -sha256 Better Hashtypes for your certs === The redkestrel tool will complain about an sha1 hash on your cert (as will ssllabs, and other tools -- with a commercial certificate, you'd often be eligibile for a free re-issue). I added -sha256 because openssl defaults to an sha1 signature on my platform, and this is deprecated. I did make sure my oldest clients could still validate that cert (your linuxes and other OSes should be tested as well). It's possible (but unlikely) that a future update to OpenSSL or puppet could cause it to no longer like sha1 signed hashes -- similar to the way chrome and other browsers are choosing to no longer honor them. I don't know if puppet currently uses a better algo in current versions. Note that there's openssl docbugs listed for the fact that -sha256 isn't listed in the usage messages, but please do feel free to google -- I wouldn't expect you to randomly trust running undocumented openssl commands from a stranger on the net. :) Inventory.txt = Finally, take note of the fact that your new certificate doesn't show up in inventory.txt -- adding it manually might not be a bad idea, just in case, but openssl itself doesn't know how to update that file. (I'm not sure why the puppet authors didn't use the standard openssl CA format for their key list). Since 'puppet cert clean' uses that file to get the serial number to revoke, you probably want your new cert there for completeness. Moving Forward == At least for me, this is still an older key that I'm using (five years ago, the default was 1024-bit) -- so there's a plan to replace it, gradually, with a new one with modern expectations (4096-bit, most likely). What we've done here is simply made sure that our old key doesn't expire out from under us while we're rolling this stuff out. There's still a bunch of questions and problems I've got with this process, but I do hope my previous statements and the above are helpful. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: [Puppet Users] module design: different module sections manipulating files in single directory
On Mon, 15 Aug 2016, dkoleary wrote: Hey; I suspected this was going to be a problem and, sure enough, it is. Here's the scenario: puppet server 4.5: I have ~ 1200 hosts on which I want specific files in /root/bin on all hosts. A reasonably large subset of those should have additional files in /root/bin as part of an home-grown application management process. To be clear, none of the files from the 'all-host' group overlap with any of the files from the 'some-hosts' group. The all-host group is easy enough:: file { '/root/bin': ensure => 'directory', owner => 'root', group => 'root', mode => '0700', recurse => true, source => 'puppet:///modules/myroot/rootbin', require => File['/root'], } So, that's worked for weeks now. In my company's slow migration to puppet management, I'm finally to the point of adding some custom application related files to /root/bin. On the surface, the some-hosts group is pretty easy too:: file { 'webconfbin': ensure => 'directory', path => '/root/bin', owner => 'root', group => 'root', mode => '0700', recurse => true, source => 'puppet:///modules/myroot/webconf', } As I suspected, that resulted in the bright red error message about 'resource /root/bin already declared'. The two options that I can think of aren't particularly appetizing: 1. Add the files from some-hosts to all-hosts resulting in the app management files being everywhere. These files, themselves, don't represent a security issue, but it's not a very clean approach. 2. Use individual file resources. I could get away with that approach on this one; but, when I run into a similar issue with dozens or 100s of files, I'd hate to be specifying all those file resources. Realizing I probably took a wrong turn in my initial design and figuring someone else has to have had run into this problem before, I'm asking the experts. What's the right way to have a set of files on all hosts and a different set of files on a subset of all hosts in the same directory? I don't often comment on the puppet stuff, but yours made me need to chime in and say this: Recurse is an ugly, awful, terrible hack and should be deprecated. I don't say that with any knowledge of the way it evolved or what its future support status is, but if you look at it -- it's effectively an expansion macro that turns into dozens or hundreds of File[] resources (and interally -- can and MUST grow your manifest internally in-memory to that size). Judging by the fact that you're using a /bin directory to distribute things, which I assume are binaries, or scripts, the thing that makes sense here (especially with 1200 hosts) is to look in to using your OS's package manager to accomplish this task -- where you could, possibly, break out the installables by host-class. (i.e. the files in yoursite-db.rpm would require the files in yoursite-common.rpm) You could, then, use puppet to manage a local installable of that distributable, with a notify action that ran the installer -- or you could use the builtin package resource type with a local repo, and use require => latest to upgrade that, if you have a high change delta. (Where I say RPM, subsitute OS package manager of choice, obviously). Yes, this steps outside of puppet, but on its face, puppet is *config* management, and what you seem to be trying to do, is not. --
Re: [Puppet Users] module design: different module sections manipulating files in single directory
On Mon, 15 Aug 2016, dkoleary wrote: Hey; Thanks for the responses. I hadn't thought of packages. I will start exploring that option What would work, as a short term option: * A class that just owns /root/bin * Separate classes that create things in directories under /root/bin (say /root/bin/webserver), and requires the above class. Similar to how a core class may own /etc/apache/conf.d, but others may own things under. * If you absolutely need them, symlinks, either via individual file resources, or a script that basically goes through and updates them, as a notify exec. What you haven't said, is how many files are involved in your recurse, so it's hard to say how well this would work for you. Also an ugly hack, but may be more easily available than learning to package overnight. -Dan Thanks again. Doug O'Leary On Monday, August 15, 2016 at 3:42:20 PM UTC-5, Rob Nelson wrote: Doubt, I agree with Dan, packaging is the answer. And before you say it - yes, packaging sounds scary at first, but it doesn't have to be. Check out FPM - https://github.com/jordansissel/fpm/wiki - to generate a package in the correct format. You can very easily package static files that way, and use file resources with `source => template(...)` for any dynamic files required. Hosting the files is pretty easy if you're using yum, as yumrepos are built in. You can host them on a node with profile::yumrepo(https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/m anifests/yumrepo.pp andhttps://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_ro le/yumrepo.yaml), throw the rpms in /var/www/html/puppetrepo/el7, and then ensure your base profile distributes that repo(https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/m anifests/base.pp#L29-L38). That code is dated and needs a little improvement (stop using `create_resources()`!) but should get you started quickly. I'm sure there's an equivalent for Apt. Rob Nelson rnel...@gmail.com On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney wrote: On Mon, 15 Aug 2016, dkoleary wrote: Hey; I suspected this was going to be a problem and, sure enough, it is. Here's the scenario: puppet server 4.5: I have ~ 1200 hosts on which I want specific files in /root/bin on all hosts. A reasonably large subset of those should have additional files in /root/bin as part of an home-grown application management process. To be clear, none of the files from the 'all-host' group overlap with any of the files from the 'some-hosts' group. The all-host group is easy enough:: file { '/root/bin': ensure => 'directory', owner => 'root', group => 'root', mode => '0700', recurse => true, source => 'puppet:///modules/myroot/rootbin', require => File['/root'], } So, that's worked for weeks now. In my company's slow migration to puppet management, I'm finally to the point of adding some custom application related files to /root/bin. On the surface, the some-hosts group is pretty easy too:: file { 'webconfbin': ensure => 'directory', path => '/root/bin', owner => 'root', group => 'root', mode => '0700', recurse => true, source => 'puppet:///modules/myroot/webconf', } As I suspected, that resulted in the bright red error message about 'resource /root/bin already declared'. The two options that I can think of aren't particularly appetizing: 1. Add the files from some-hosts to all-hosts resulting in the app management files being everywhere. These files, themselves, don't represent a security issue, but it's not a very clean approach. 2. Use individual file resources. I could get away with that approach on this one; but, when I run into a similar issue with dozens or 100s of files, I'd hate to be specifying all those file resources. Realizing I probably took a wrong turn in my in
[Puppet Users] Best way to do cross-module dependencies
Hey all, Everything I've done thusfar in creating my own custom modules has drilled some basics into my head -- these are right from the puppet web docs: "A module’s classes, defined types, and plugins *should all be related,* and the module should aim to be *as self-contained as possible.* Manifests in one module should never reference files or templates stored in another module." I've also seen it preached hard that modules should attempt in all cases to be "portable". So, with that said -- how is the best way to declare dependencies across modules? For example, I have a one-file-per-rule firewall stack, where rules are placed in /etc/firewall.d, and loaded using a standardized ordering script -- this way my "httpd" module can add (and own) an "httpd" firewall rule. How would I tell my web module that if that firewall type is in play, that it should add a file there, and reload the firewall? How do I get the web module to only do this *if* that firewall type is in play, without directly *requiring* it? I have a similar thing for syslog, where I can populate a directory and have individual packages own files in there. Same question. I also have a similar thing for logfile rotation. Same question. I don't want to build huge metaclasses all in site.pp -- nor does it seem sane to me to build meta-modules that do all the combining, although those *are* both ways forward. Thanks, -Dan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6e51be82-b270-4cb8-bf31-90e39eedd9cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] How to have init.pp in a module run some function whenever any class in the module is called.
Hey all, We have a simple adduser module, with an init.pp like so: class adduser::config { case $facts['operatingsystem'] { 'Debian': { $bash = '/bin/bash' $tcsh = '/bin/csh' $sh = '/bin/sh' $staffgid = '50' $wheelgroups = ['adm', 'sudo'] $rootgroup = 'root' } default: { $bash = '/usr/local/bin/bash' $csh = '/bin/csh' $tcsh = '/bin/csh' $sh = '/bin/sh' $staffgid = '20' $wheelgroups = ['wheel'] $rootgroup = 'wheel' } } } This code *was* in the main "adduser" class, but we found that when we called a user directly, it didn't run. All our users have stanzas like this one: class adduser::user_ray { require adduser::config user { 'bob': ensure => 'present', comment => 'Bob User', gid => $staffgid, home => '/home/bob', password => '*', shell=> $tcsh, uid => '20049', managehome => true } } Even with the direct require of adduser::config we still see errors like this in the puppetserver log: 2018-06-04 03:27:24,369 WARN [qtp1220040994-783] [puppetserver] Puppet Unknown variable: 'tcsh'. at /usr/local/etc/puppet/code/environments/production/modules/adduser/manifests/init.pp:249:17 2018-06-04 03:27:24,377 WARN [qtp1220040994-783] [puppetserver] Puppet Unknown variable: 'staffgid'. at /usr/local/etc/puppet/code/environments/production/modules/adduser/manifests/init.pp:460:17 2018-06-04 03:27:24,380 WARN [qtp1220040994-783] [puppetserver] Puppet Unknown variable: 'wheelgroups'. at /usr/local/etc/puppet/code/environments/production/modules/adduser/manifests/init.pp:461:17 2018-06-04 03:27:24,382 WARN [qtp1220040994-783] [puppetserver] Puppet Unknown variable: 'bash'. at /usr/local/etc/puppet/code/environments/production/modules/adduser/manifests/init.pp:464:17 What's the proper way to do this inheritance? And the proper way to name variables so they scope right? Thanks in advance, -Dan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/801c1a76-75e0-4cc7-a7ee-8c7262c3ca70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Older Ciphers? Weak Cipher Suites?
All, This is probably nothing but I've searched the mailing lists and can't find anything useful about this. We're running our puppetmaster under FreeBSD at the day job (puppet 6.18), and we see errors like this on puppetserver startup in the logs: WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA enabled for InternalSslContextFactory@7beb914b[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] All in all, each warning is repeated several different times, and there's probably seven or eight different ciphers. Java logging is...a mess, honestly, and it's pretty difficult to separate signal from noise when you're trying to debug something. That said, I see release notes that something changed about weak ciphers in 6.5, but we're not there yet. Is this something I should worry about, or just ignore? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e50a1727-9c98-47ec-ad76-31cbcf1d1740n%40googlegroups.com.
[Puppet Users] Re: Older Ciphers? Weak Cipher Suites?
To be clear, here's the full list of what's warned about (each of these gets logged six times in succession, which I've deduplicated for brevity *except for the last one* so you can see that there are different addresses being listed). WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_128_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@4f27d2a8[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@5a789c49[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@6593530a[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@71baa8f5[provider=null,keyStore=null,trustStore=null] WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 enabled for InternalSslContextFactory@7beb914b[provider=null,keyStore=null,trustStore=null] On Monday, November 9, 2020 at 11:58:30 PM UTC-8 Dan Mahoney wrote: > All, > > This is probably nothing but I've searched the mailing lists and can't > find anything useful about this. We're running our puppetmaster under > FreeBSD at the day job (puppet 6.18), and we see errors like this on > puppetserver startup in the logs: > > WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite > TLS_DHE_RSA_WITH_AES_256_CBC_SHA enabled for > InternalSslContextFactory@7beb914b[provider=null,keyStore=null,trustStore=null] > WARN [async-dispatch-2] [o.e.j.u.s.S.config] Weak cipher suite > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA enabled for > InternalSslContextFactory@3900153c[provider=null,keyStore=null,trustStore=null] > > All in all, each warning is repeated several different times, and there's > probably seven or eight different ciphers. > > Java logging is...a mess, honestly, and it's pretty difficult to separate > signal from noise when you're trying to debug something. > > That said, I see release notes that something changed about weak ciphers > in 6.5, but we're not there yet. > > Is this something I should worry about, or just ignore? > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b5ec5090-810b-4bbc-80b4-cab024b20722n%40googlegroups.com.
[Puppet Users] Using VS Code with PDK -- how can I manually run puppet-lint?
Hey there all, I apologize if this is off-topic. If it is, please do let me know where better to ask. I tried joining the puppet-vscode slack but it apparently only works if I have a puppet.com email address. I'm on a mac, using Visual Studio Code with the PDK installed via homebrew. The version of puppet-lint included with the PDK runs WAY more tests than any previous version of puppet-lint. So, here are my questions: 1) Obviously the vscode plugin is running some version of puppet-lint behind the scenes, but it's unclear as to how I can run that manually in a terminal (perhaps with --fix). When I installed pdk, it put it in /opt/puppetlabs/pdk/bin/pdk, but didn't do anything like that for puppet-lint. 2) Is there an easy way to grab those extra tests for a system that doesn't have them? It looks to be like 20 different ruby gems, all dumped into /opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems ls |grep lint | grep check puppet-lint-absolute_classname-check-3.0.1 puppet-lint-anchor-check-1.0.1 puppet-lint-classes_and_types_beginning_with_digits-check-1.0.0 puppet-lint-file_ensure-check-1.0.0 puppet-lint-leading_zero-check-1.0.0 puppet-lint-legacy_facts-check-1.0.4 puppet-lint-lookup_in_parameter-check-1.0.0 puppet-lint-manifest_whitespace-check-0.1.17 puppet-lint-optional_default-check-1.0.0 puppet-lint-params_empty_string-check-1.0.0 puppet-lint-strict_indent-check-2.0.8 puppet-lint-top_scope_facts-check-1.0.1 puppet-lint-topscope-variable-check-1.0.1 puppet-lint-trailing_comma-check-0.4.2 puppet-lint-unquoted_string-check-2.1.0 puppet-lint-version_comparison-check-1.0.0 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e6a2470f-0b71-44d7-a027-41618ae1cc8cn%40googlegroups.com.
[Puppet Users] Re: Using VS Code with PDK -- how can I manually run puppet-lint?
It turns out the answer to my second question is: gem install voxpupuli-puppet-lint-plugins ...which seems to be a meta package that installs most of the nonstandard plugins which were then adopted by pdk. I'm not sure how we can get those added to official puppet-lint so this step isn't necessary. On Sunday, December 4, 2022 at 3:31:18 AM UTC-8 Dan Mahoney wrote: > Hey there all, > > I apologize if this is off-topic. If it is, please do let me know where > better to ask. I tried joining the puppet-vscode slack but it apparently > only works if I have a puppet.com email address. > > I'm on a mac, using Visual Studio Code with the PDK installed via > homebrew. The version of puppet-lint included with the PDK runs WAY more > tests than any previous version of puppet-lint. > > So, here are my questions: > > 1) Obviously the vscode plugin is running some version of puppet-lint > behind the scenes, but it's unclear as to how I can run that manually in a > terminal (perhaps with --fix). When I installed pdk, it put it in > /opt/puppetlabs/pdk/bin/pdk, but didn't do anything like that for > puppet-lint. > > 2) Is there an easy way to grab those extra tests for a system that > doesn't have them? It looks to be like 20 different ruby gems, all dumped > into /opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems > > ls |grep lint | grep check > puppet-lint-absolute_classname-check-3.0.1 > puppet-lint-anchor-check-1.0.1 > puppet-lint-classes_and_types_beginning_with_digits-check-1.0.0 > puppet-lint-file_ensure-check-1.0.0 > puppet-lint-leading_zero-check-1.0.0 > puppet-lint-legacy_facts-check-1.0.4 > puppet-lint-lookup_in_parameter-check-1.0.0 > puppet-lint-manifest_whitespace-check-0.1.17 > puppet-lint-optional_default-check-1.0.0 > puppet-lint-params_empty_string-check-1.0.0 > puppet-lint-strict_indent-check-2.0.8 > puppet-lint-top_scope_facts-check-1.0.1 > puppet-lint-topscope-variable-check-1.0.1 > puppet-lint-trailing_comma-check-0.4.2 > puppet-lint-unquoted_string-check-2.1.0 > puppet-lint-version_comparison-check-1.0.0 > > > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f029a449-27e1-42a3-a512-660f5d864eb8n%40googlegroups.com.
Re: [Puppet Users] Using VS Code with PDK -- how can I manually run puppet-lint?
There is not a way to just run puppet-lint on a file from that. On Mon, Dec 5, 2022 at 4:51 AM Martin Alfke wrote: > PDK allows you to also run rake tasks > > pdk bundle exec rake -T > > Gives you an overview on available rake tasks. > > > On 5. Dec 2022, at 07:08, Dan Mahoney wrote: > > It turns out the answer to my second question is: > > gem install voxpupuli-puppet-lint-plugins > > ...which seems to be a meta package that installs most of the nonstandard > plugins which were then adopted by pdk. > > I'm not sure how we can get those added to official puppet-lint so this > step isn't necessary. > > On Sunday, December 4, 2022 at 3:31:18 AM UTC-8 Dan Mahoney wrote: > >> Hey there all, >> >> I apologize if this is off-topic. If it is, please do let me know where >> better to ask. I tried joining the puppet-vscode slack but it apparently >> only works if I have a puppet.com email address. >> >> I'm on a mac, using Visual Studio Code with the PDK installed via >> homebrew. The version of puppet-lint included with the PDK runs WAY more >> tests than any previous version of puppet-lint. >> >> So, here are my questions: >> >> 1) Obviously the vscode plugin is running some version of puppet-lint >> behind the scenes, but it's unclear as to how I can run that manually in a >> terminal (perhaps with --fix). When I installed pdk, it put it in >> /opt/puppetlabs/pdk/bin/pdk, but didn't do anything like that for >> puppet-lint. >> >> 2) Is there an easy way to grab those extra tests for a system that >> doesn't have them? It looks to be like 20 different ruby gems, all dumped >> into /opt/puppetlabs/pdk/share/cache/ruby/2.5.0/gems >> >> ls |grep lint | grep check >> puppet-lint-absolute_classname-check-3.0.1 >> puppet-lint-anchor-check-1.0.1 >> puppet-lint-classes_and_types_beginning_with_digits-check-1.0.0 >> puppet-lint-file_ensure-check-1.0.0 >> puppet-lint-leading_zero-check-1.0.0 >> puppet-lint-legacy_facts-check-1.0.4 >> puppet-lint-lookup_in_parameter-check-1.0.0 >> puppet-lint-manifest_whitespace-check-0.1.17 >> puppet-lint-optional_default-check-1.0.0 >> puppet-lint-params_empty_string-check-1.0.0 >> puppet-lint-strict_indent-check-2.0.8 >> puppet-lint-top_scope_facts-check-1.0.1 >> puppet-lint-topscope-variable-check-1.0.1 >> puppet-lint-trailing_comma-check-0.4.2 >> puppet-lint-unquoted_string-check-2.1.0 >> puppet-lint-version_comparison-check-1.0.0 >> >> >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/f029a449-27e1-42a3-a512-660f5d864eb8n%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/f029a449-27e1-42a3-a512-660f5d864eb8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/lH9UiV2bnfw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/F6189B0A-A32D-4D09-A9E1-D13A420D7505%40gmail.com > <https://groups.google.com/d/msgid/puppet-users/F6189B0A-A32D-4D09-A9E1-D13A420D7505%40gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CADU3PDHBcLxMP5ZueCA_LhxOKs46z%3D3F9d9OT8vhx7iRAoqE_g%40mail.gmail.com.
[Puppet Users] Error coming from puppetdb and partitions?
Hey there folks, We're using puppetdb and we see this error fairly regularly in our logs. Anyone have any ideas? We're using puppet8 under FreeBSD, with postgres 17. 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-1] 2025-06-18 00:46:27.415 UTC [93417] ERROR: no partition of relation "reports_historical" found for row 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-2] 2025-06-18 00:46:27.415 UTC [93417] DETAIL: Partition key of the failing row contains (producer_timestamp) = (2025-06-18 00:16:27.044+00). 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-3] 2025-06-18 00:46:27.415 UTC [93417] STATEMENT: UPDATE reports SET latest = $1 WHERE latest = true and certname = $2 We don't have any reports_ttl set or anything like that, only a node_ttl which is at 365d. Any other info that would help? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/puppet-users/4b2e2328-6682-45cf-abab-c29629975240n%40googlegroups.com.
[Puppet Users] Re: Error coming from puppetdb and partitions?
Okay, no response at all so far. Is there a better place to ask about this? We've pushed an issue here: https://github.com/puppetlabs/puppetdb/issues/4020 -Dan On Saturday, June 21, 2025 at 3:00:56 AM UTC-4 Dan Mahoney wrote: > Hey there folks, > > We're using puppetdb and we see this error fairly regularly in our logs. > Anyone have any ideas? We're using puppet8 under FreeBSD, with postgres > 17. > > 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-1] > 2025-06-18 00:46:27.415 UTC [93417] ERROR: no partition of relation > "reports_historical" found for row > > 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-2] > 2025-06-18 00:46:27.415 UTC [93417] DETAIL: Partition key of the failing > row contains (producer_timestamp) = (2025-06-18 00:16:27.044+00). > > 2025-06-18T00:46:27+00:00 repo-us postgres [local0.warning] [7-3] > 2025-06-18 00:46:27.415 UTC [93417] STATEMENT: UPDATE reports SET latest = > $1 WHERE latest = true and certname = $2 > > We don't have any reports_ttl set or anything like that, only a node_ttl > which is at 365d. > > Any other info that would help? > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/puppet-users/4b0715e0-6f40-41af-be98-f00ba752fce3n%40googlegroups.com.
[Puppet Users] Good documentation somewhere for doing a cert-roll?
Hey there puppet-users deinzens. One of my puppet agents helpfully reminded me that my root CA cert is due to expire within a few months, and I'm wondering what the best way to go about rolling it over would be. A lot of my reading suggests something like "burn everything involving certificates to the ground and start your entire CA infrastructure over from scorched earth" is an approximation of the way to go. From the various looks and reading I've done, this was one of those parts of puppet that had some serious technical debt involved in authoring it. I've likened puppet's SSL config to how I might manage an SSL cert on my webserver/clients, and I'm seeing a disconnect, since many of the things I'd do in those cases don't work here.. In short -- I think the following problems still exist: * There's still no support for putting multiple certificate files as the puppet CA -- all must still be signed by a common root entity. Is this correct? (In the "web" analogy, my browser could have lots of built-in and additional trust-points, both corporate and as-shipped). * There's no directive I can find whereby puppet agents can, within N days of expiry, re-request their certificate, while maintaining a valid one in the meantime. On the puppet master, a duplicate cert is treated as an absolute error and must be purged from both sides with extreme prejudice and started over. * There's no way the puppet master itself can have multiple trust points. (I.e. old CA and new CA) -- in the real world, of course, I can have multiple CA files from which I can trust clients, for example, for SMTP auth. * Puppet has no concept of a CA Path, rather than a CA file. And since certificates are multi-line blocks in text files, they're a real pain to manipulate with Augeas or shell scripts. * There's no way the master can say "multiple public keys for the same cert are bad, but we will re-sign *existing* keys that are merely near expiry." (Which is a thing we might do in PGP). And even if we could define such a policy, there's no support in the agent to do such a thing. * There's no way to have the puppet-master auto-sign a cert, based on the presence of some sort of file or hash on the node, similar to the above. * We blindly trust the first CA we get (using the default options), but then have NO real method for accepting a second CA without manually manipulating the CA files directly. (DANE, anyone?) * Your old CA, Puppet Master Certs, and Client Certs, are all an ecosystem, and there's no way to replace any one of them without having to replace the whole thing. Am I getting this wrong? Please tell me I am. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
[Puppet Users] How to deliberately cause modules to conflict?
Hey there. This is a weird question, but I guess I'll ask it anyway. Is there a way to say one of the following two things? 1) That you want a manifest to deliberately break when you try to include two different items? For example, most of our machines run a very simple mailer called DMA (dragonfly mail agent), but some machines (which handle inbound mail) require full blown postfix. I'd love for the manifest to simply refuse to operate. Since there's no common files between them, right now if you try to install both, you'll just have a bunch of Augeas changes required for each MTA being made back and forth. 2) To say that if I've installed the "postfix" module, that it basically de-includes the "dma" class from the manifest? I realize I could in fact create an "mta" class which installs dma by default, but parameterize it such that postfix is another option. Are there any other ways? -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: [Puppet Users] Re: Good documentation somewhere for doing a cert-roll?
On Tue, 17 May 2016, Eric Sorenson wrote: Hi Dan, this is a good and timely post. I apologize for the lack of response. Health issues have taken a front seat for a while. I'm working on some related issues regarding Puppet's CA that may help you out. Your thinking on this is roughly correct -- things are a lot harder than they need to be, but the above advice to nuke everything and start over is both overly simplistic and wrong-headed. Funny, that's pretty much exactly the advice I'm seeing here: https://docs.puppet.com/puppet/4.4/reference/ssl_regenerate_certificates.html Once you blow away your old CA, *none* of your agents work. If you've been running puppet for five years, not everything is due to expire all at once. I've found a way forward that I think is reasonably clever, and I'll go into it below. Note that my comments here are specifically about the Clojure CA that is included in puppetserver, not the Ruby CA; most things apply to both but the past couple of years of server-side bugfixes and development energy have gone into the Clojure CA, and Puppet 5 will consolidate all the CA-side cert lifecycle onto this codebase. I'm largely running Puppet 3.8, open source. My certs expire sooner than 5 will be released. You're right that the agent SSL code is very old and badly needs an overhaul. * There's still no support for putting multiple certificate files as the puppet CA -- all must still be signed by a common root entity. Is this correct? (In the "web" analogy, my browser could have lots of built-in and additional trust-points, both corporate and as-shipped). Have you verified experientially that this doesn't work in current Puppet versions? I have verified that multiple root certificates in the file will at the very least not crash the agent. Which means, I guess, if you're rolling from one master to another, you can seed out a ca file with two roots in it, via puppet itself (but *not* via the auto-download). You're right that the agent does not support a CApath, in openssl parlance: a directory of hashed CA certs, any of which are valid. The server side farms out its SSL verification to the underlying web stack, so it ought to be tolerant of agents issued from multiple CAs checking in. I haven't tried this angle yet. Not every OS uses CA pathing. Some of the linuxes do. FreeBSD uses a monolithic cert. As far as I understood it, it's a function of the underlying SSL library. It would be nice -- at least that way you could deploy certs atomically. * There's no directive I can find whereby puppet agents can, within N days of expiry, re-request their certificate, while maintaining a valid one in the meantime. On the puppet master, a duplicate cert is treated as an absolute error and must be purged from both sides with extreme prejudice and started over. The first part is true, the second is controlled by the 'allow-duplicate-certs' CA setting which will allow later requests to overwrite newer ones. I think you mean older? Also, do you really mean overwrite, or do you mean the two certs can coexist? Presumably, the master needs to keep a list of everything it's signed, so that it can later revoke a given certificate. That's all listed in the inventory.txt file, as well as a copy cached in the "signed" directory. As I said above, on the master the cert verification is delegated to the web server layer (jetty in the case of the puppetserver, apache or nginx or (gah) webrick for non-puppetserver setups). There's nothing built-in that does either of these things. But policy-based autosigning provides an API that lets you do this based on some 'a priori' knowledge you have of the node: https://docs.puppet.com/puppet/4.4/reference/ssl_autosign.html Frustrating. When you're using an external signing executable -- unless you've had the forethought to tell all your agents to see extra, non-default information into their CSR, the only info you get is the CSR and the common-name. This is an interesting line of thought that I'm looking into more on the CA side: you can re-use the same private key to generate a new certificate that would have an extended lifetime but not require a complete re-key. There isn't an API guarantee that agents' certs (and therefore their public keys) are collected and stored in the CA, though such a thing would be very useful and is on deck for future work - you can see the whole list of these things at https://tickets.puppetlabs.com/browse/SERVER-974 * We blindly trust the first CA we get (using the default options), but then have NO real method for accepting a second CA without manually manipulating the CA files directly. (DANE, anyone?) I don't know what DANE means in this context, but this statement is true. DANE (and the DNS TLSA Record) is a way of putting your SSL certificate (either your private key, o