[Puppet Users] CRL is not honored by the puppetmaster.

2016-06-15 Thread Dan Mahoney

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.

2016-06-16 Thread Dan Mahoney

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

2016-06-17 Thread Dan Mahoney

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

2016-06-17 Thread Dan Mahoney

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?

2016-06-21 Thread Dan Mahoney

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

2016-08-15 Thread Dan Mahoney

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

2016-08-15 Thread Dan Mahoney

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

2015-12-07 Thread Dan Mahoney
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.

2018-06-04 Thread Dan Mahoney
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?

2020-11-09 Thread Dan Mahoney
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?

2020-11-10 Thread Dan Mahoney
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?

2022-12-04 Thread Dan Mahoney
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?

2022-12-04 Thread Dan Mahoney
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?

2023-01-10 Thread Dan Mahoney
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?

2025-06-21 Thread Dan Mahoney
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?

2025-06-25 Thread Dan Mahoney
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?

2016-05-13 Thread Dan Mahoney, System Admin

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?

2016-05-28 Thread Dan Mahoney, System Admin

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?

2016-06-14 Thread Dan Mahoney, System Admin

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