Foreman » Installer

Have pushed a change to my local branch. https://github.com/fatmcgav/puppet-puppet/commit/4429c736837fad25371553d9351c26273d76f124

Comments welcome before I submit as a pull request.

Gavin Williams wrote:

Currently, the Passenger app root is configured in puppet::params to point to '$dir/rack', where $dir is set to '/etc/puppet' by default.

However the recommended location is '/usr/share/puppet/rack/puppetmasterd'.

That location only exists in the Debian puppet-passenger packages I think, it doesn't seem to exist in the Puppet RPMs.

Was it a concious decision to use '$dir/rack', or an oversight?

I think this used to be the convention before /usr/share/puppet/rack was shipped, I've seen a lot of Puppet docs refer to /etc/puppet/rack over the years.

Yeh, thought all the 3.0 documentation seems to suggest using /usr/share/puppet...

Looking at my current 3.0 master, I've got a /usr/share/puppet dir, but no rack dir within...

So sounds like need to modify the code to use '/usr/share/puppet', and create 'rack/puppetmasterd/{tmp,public}'...

It looks like the RPMs ship the upstream "ext" directory as-is, so there is this: /usr/share/puppet/ext/rack/files/config.ru

I'm fine with your proposed changes. Just make sure that on Debian we have the right package installed too, I've a feeling we don't install the puppet/passenger subpackage today and we may need to after this change.

Dominic Cleal wrote:

It looks like the RPMs ship the upstream "ext" directory as-is, so there is this: /usr/share/puppet/ext/rack/files/config.ru

I'm fine with your proposed changes. Just make sure that on Debian we have the right package installed too, I've a feeling we don't install the puppet/passenger subpackage today and we may need to after this change.

Ah, just spotted the /usr/share/puppet/ext/rack dir, which looks like it includes a lot of other related stuff in there aswell...

Will do my best with Debian support, however haven't used it with Puppet as yet so may need some pointers :)

We don't install the Debian package because it pulls in other stuff, and ships a vhost that conflicts with ours. Is there any need to fix this? Non-standard isn't a problem if it works :)

Greg Sutcliffe wrote:

We don't install the Debian package because it pulls in other stuff, and ships a vhost that conflicts with ours. Is there any need to fix this? Non-standard isn't a problem if it works :)

True... Or could just put some logic in to retain current behaviour for Debian and bring in-line for EL...

What about the current behaviour is required for Debian to work?