Ah manual changes...
Ok you need some way to identify which hosts use which hash type and
classify them as such.
We have an external node classifier, and we would set a parameter for the
host to say hash_type => 'bsdmd5' for example. You could default if
osfamily is Redhat to not even look for th
John/Garret, thanks but the hash-type isn't specific to os&release, it is
manually defined/altered by the sysadmin.
Does that help any?
To be more detailed, I might have something like the following:
CentOS-6.X. 12 nodes all hash=sha-512,
Solaris 10u6 13 nodes all hash=bsdmd5, but...
Solaris 10u
There's a doc about it here:
https://docs.puppetlabs.com/pe/latest/pe_versioning.html
Rich
On Wed, Feb 10, 2016 at 3:58 PM warron.french
wrote:
> Can someone please explain to me, the purpose or difference between the
> various puppet versions?
>
> More specifically, I see references to PE 201
Warron
Use the operatingsystemrelease fact and decide the hash to use based on
that.
It will spit out something like 10_u9 by reading /etc/release. This isn't
too bad, but if you patch a server built as u9 with a current patch set,
the actual OS will be u11 no matter what /etc/release says, so be
Can someone please explain to me, the purpose or difference between the
various puppet versions?
More specifically, I see references to PE 2015.3.2 and I also see other
version patterns like 3.7 for example?
Was this due to a shift in marketing style, or is it a matter of PE versus
open source Pu
The text on the download page(s) seems to say "2015.3.1", even though the
links pull files labelled 2015.3.2.
>
--
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
Always a smart move to start simple...
For what it's worth, a large company here in western Sweden I know has
started using Ansible and Docker and then simply swapping out docker
instances for upgrades. I could imagine something similar could be
accomplished in Puppet as well.
Btw, good luck f
Hey John,
After changing 'stringify_facts' to false on both master and client, things
are working as expected.
Thank you again for the insight; not sure how I missed that one.
Cheers,
Mike
On Wednesday, February 10, 2016 at 6:12:40 AM UTC-8, jcbollinger wrote:
>
>
>
> On Tuesday, February 9,
On 2/10/16 8:38 AM, Warron French wrote:
> Hello, I was hoping someone could help with answering this question, for
> the following scenario.
>
> On our network we have some OLD ( I mean 1/06, up to 1/09) Solaris 10
> SPARC servers and workstations along with newer Solaris 10 SPARC servers
> (runn
On Tuesday, February 9, 2016 at 5:00:12 PM UTC-6, Mike Reed wrote:
>
> Running 'facter -p' on the client side (assuming we have two video cards
> installed), I receive a result of: video_card_id => ["17c2", "17c2"]
> This result means to me that I was returned two strings, each of which are
Hello, I was hoping someone could help with answering this question, for
the following scenario.
On our network we have some OLD ( I mean 1/06, up to 1/09) Solaris 10 SPARC
servers and workstations along with newer Solaris 10 SPARC servers (running
even the lastest revisions, like 1/13); and we
11 matches
Mail list logo