aethylred / puppet-shibboleth Goto Github PK

With newer(ish) puppet, you cannot use a class/define param as part of the default value for another param.

Using OS puppet 4.5.3 with version 0.1.4 of this module, we ran into the following:

In a wrapper class, we set a value for shibboleth::metadata::provider_uri and shibboleth::metadata::cert_uri then called shibboleth::metadata with default values for the rest of the params.

The puppet run then fails with the following:

Could not retrieve catalog from remote server: Error 400 on SERVER: 
Evaluation Error: Error while evaluating a Resource Statement, 
Evaluation Error: Error while evaluating a Function Call, Failed to parse inline template: 
Undefined method 'split' for nil:NilClass at <location>/shibboleth/manifests/metadata.pp:7:31 
at <wrapper class location> 
on <node>

See this issue and the ones listed as "relates to" for additional information: https://tickets.puppetlabs.com/browse/PUP-1080

Hi!

Are you still maintaining this project. That is to say, are you accepting and reviewing pull request?

I'm trying to leverage existing code to manage shibboleth for machines on my campus. The code quality score for your module on Puppet Forge is great. The code accomplishes a lot out of the box. I noticed some good improvements by the LarkIT/puppet-shibboleth fork. However, I don't see where that project owner has submitted pull requests back to this project.

I'd like to get a stable repo that takes advantage of LarkIT's improvements with some additional improvements. I'd rather contribute pull requests back upstream to your project. But if you're no longer maintaining this project, then I'll probably just work in my own fork of the repo and submit that to Forge. I just wanted to hear from you how active you care to be with this particular project.

Thanks for all the work you put into this!

The Project URL on here https://forge.puppetlabs.com/Aethylred/shibboleth
Points to here https://github.com/Aethylred/shibboleth
which I guess was since renamed.

There may be a lot of these, so they need to be managed. Otherwise a gitlab node will always be in the blue changed state, not the green state.