Closed zk closed 10 years ago
@fromonesrc any thoughts on this guy?
@zk This approach seems pretty valid to me. Mind rebasing against master to get in sync?
/cc @dgoodlad
@zk happy to consider this one asap, can you get this mergeable again?
@dgoodlad pulled the alias & rebased, let me know if you need anything else.
@dgoodlad I can squash this down to one commit if needed as well.
@zk no worries about squashing, just fix up the requires and we should be good to go
@dgoodlad updated, much appreciated!
Seems legit. Thanks @zk!
@zk released as 1.2.0: https://github.com/boxen/puppet-java/releases/tag/1.2.0
@dgoodlad @wfarr @fromonesrc related:
I was getting the following stacktrace when trying to generate 'large' crypto keys:
The background on this is that due to US export laws, the JDK (by default) dosen't allow you to use key sizes greater than some specified limit: http://docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#AppE
You can remove this limitation by installing certain jar files at certain JDK-aware paths, like so: http://www.ngs.ac.uk/tools/jcepolicyfiles
Essentially, this PR adds the following steps to the puppet-java module:
I've included the two required jar files in the source tree, due to Puppet not allowing remote files to be specified as
File
sources (i.e. the following fails):I had also considered using this workaround, but decided to start here as the jar files are ~5k combined. Let me know if you think the workaround is more appropriate and I'll switch.
Also, the path at which these files are installed is hardcoded, I had tried using
/usr/libexec/java_home
to establish the install path after jdk7 was installed using something likebut I wasn't able to figure out how to affect when that gets evaluated. Ultimately, I didn't think it was a huge deal since the JRE / JDK versions are hardcoded as well.
Thanks, and lmk if you have any questions.