On 2/10/16 9:33 PM, John Warburton wrote:
> 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 the parameter as all Centos
> nodes will be the same
> 
> No node classifier? Not sure how you would do this? A custom fact
> interrogating the hash type?
> 
> John
> 
> On Thursday, 11 February 2016, warron.french <warron.fre...@gmail.com
> <mailto:warron.fre...@gmail.com>> wrote:
> 
>     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 10u6 4 nodes all hash=sha-512, AND
>     Solaris 10u11 8 nodes all hash=bsdbf, but...
>     Solaris 10u11 3 nodes all hash=sha-512.
> 
>     I can see where you might say, then patch and augment all up to
>     Solaris 10u11 with hash=sha-512; I work in a secured VERY BUSY
>     environment so it's not quite that simple.
> 
>     Thank you both,
> 
>     On Feb 10, 2016 7:13 PM, "John Warburton" <jwarbur...@gmail.com
>     <javascript:_e(%7B%7D,'cvml','jwarbur...@gmail.com');>> wrote:
> 
>         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 beware
> 
>         You can look at projects.puppetlabs.com/issues/11082
>         <http://projects.puppetlabs.com/issues/11082> you can see the
>         mapping between 1/06 (I hear ya) and the update number. There is
>         a link to the Oracle document that maps that out too
> 
>         John
> 
>         On Thursday, 11 February 2016, Warron French
>         <warron.fre...@gmail.com
>         <javascript:_e(%7B%7D,'cvml','warron.fre...@gmail.com');>> 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 (running even the lastest
>             revisions, like 1/13); and we have CentOS servers and
>             workstations.
> 
>             The password hashing algorithm is different between the OLD
>             Solaris 10 SPARC servers and workstations versus the newer
>             *recently rebuilt* Solaris 10 1/13 SPARC servers and
>             workstations; the *older ones *run with *MD5*for password
>             hashing, we don't want that.  Even some of the Solaris 10
>             machines that running the newer Solaris 10 1/13 (build a
>             couple of years ago) might be running with the MD5 hashing
>             algorithm.  *All* of our CENTOS systems though, thank
>             goodness, are running with the sha-512 (yay!).
> 
> 
>             Anyway, we have a potential project to use puppet to
>             populate/generate *LOCAL *(not AD/LDAP) accounts across all
>             of our systems and want our passwords for each of the
>             accounts added to be the same; but of course, if the 
>             /password/ attribute given to the *user* resource in the
>             puppet code is of an incorrect hash-type, then that account
>             will not work properly.
> 
>             That is why I am asking for help, to achieve this particular
>             goal.
> 
>             Thank you in advance,
>             Warron 
> 
>             -- 
>             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/ccd6ba2d-6f0e-45b7-9946-e99ec9cd78fe%40googlegroups.com
>             
> <https://groups.google.com/d/msgid/puppet-users/ccd6ba2d-6f0e-45b7-9946-e99ec9cd78fe%40googlegroups.com?utm_medium=email&utm_source=footer>.
>             For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
>         -- 
>         John Warburton
>         Ph: 0417 299 600
>         Email: jwarbur...@gmail.com
>         <javascript:_e(%7B%7D,'cvml','jwarbur...@gmail.com');>
> 
>         -- 
>         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
>         
> <javascript:_e(%7B%7D,'cvml','puppet-users%2bunsubscr...@googlegroups.com');>.
>         To view this discussion on the web visit
>         
> https://groups.google.com/d/msgid/puppet-users/CAAJLFxXmSU-H20DhyUTxRYwWT56nHVbJLd1qkGYfx4GB-8AWHQ%40mail.gmail.com
>         
> <https://groups.google.com/d/msgid/puppet-users/CAAJLFxXmSU-H20DhyUTxRYwWT56nHVbJLd1qkGYfx4GB-8AWHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>         For more options, visit https://groups.google.com/d/optout.
> 
>     -- 
>     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
>     
> <javascript:_e(%7B%7D,'cvml','puppet-users%2bunsubscr...@googlegroups.com');>.
>     To view this discussion on the web visit
>     
> https://groups.google.com/d/msgid/puppet-users/CAJdJdQkwh4Xcq%3DJPBf6vNyebNKNj-UjuiKMDuK0mp6o1%3DriGYg%40mail.gmail.com
>     
> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQkwh4Xcq%3DJPBf6vNyebNKNj-UjuiKMDuK0mp6o1%3DriGYg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>     For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> John Warburton
> Ph: 0417 299 600
> Email: jwarbur...@gmail.com <mailto:jwarbur...@gmail.com>
> 

Hello,

On your EL systems you can support multiple hash types. Not sure how
Solaris handles that. As John mentioned, you could use an ENC if you
want to dictate what to use as opposed to having the system figure it
out. You could use Hiera as I mentioned if you want the system to
determine the hashing method based on some fact. Going that route, you
could create a custom fact to aid in that approach.

Another approach would be to use plain text passwords (though still
encrypted in the Hiera data with heira-eyaml) and write a function that
takes the arguments of the password and the hashing type or use
generate() and call openssl, which would return the password hash
generated with the hashing algorithm you specified.

Best regards,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/56BCBE5C.7040304%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to