Puppet users - Jul 2011 - Best practices for confidential information -- fileserver path vs modules / template

We keep our puppet configuration in a revision control system and are
trying to facilitate developers using the same modules as production/
staging servers.

We define a variable ($servergroup) as test/staging/production and use
fileserver defaults from hostname to servergroup to generic.  The
hostname and $servergroup versions need to be confidential.  We have
modules specific to an application, say "helloworld" which include
configuration files (say, database.yml) that could contain sensitive
information.

Oversimplified example:

class apps::helloworld {
  file { "/home/apps/helloworld/config/database.yml":
    source  => [
        "puppet:///modules/apps/helloworld/database.yml.$hostname",
        "puppet:///modules/apps/helloworld/database.yml.$servergroup",
        "puppet:///modules/apps/helloworld/database.yml"
        ],
  }
}


We would like to be able to share the entire mercurial repository with
developers and others in the company, but the contents of all but the
default/generic database.yml need to be tightly controlled.

We had sort of solved this problem with a custom fileserver mount
point and a subrepo in our mercurial repo, but this only worked when
referring to content as puppet://hostname/custommountpoint.  As soon
as we switched to omitting the hostname ("puppet:///") we
can''t get
the references to the subrepo to work since it wasn''t actually
modules.

In a perfect world, we could share the main puppet repo with everyone,
keep a tighter controlled subrepo of confidential data, and have local
development environments using the same class as live, but having
their otherwise confidential config created as an insecure default
file (containing generic development environment passwords, etc).
These local development environments might be using local copies of
the configuration (via vagrant & puppet apply, for example) and would
not have access to the puppet master.

If there''s a better way to solve this by having the file contents be a
template output that would work too (while the above is an over
simplified example, nearly everything we have this problem with is
better done as a template anyways), but again some of the variables
would have to be hidden/confidential.

-Scott

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Jul 26, 2011 at 12:26 PM, scott <mccools@gmail.com> wrote:
>
> We had sort of solved this problem with a custom fileserver mount
> point and a subrepo in our mercurial repo, but this only worked when
> referring to content as puppet://hostname/custommountpoint.  As soon
> as we switched to omitting the hostname ("puppet:///") we
can''t get
> the references to the subrepo to work since it wasn''t actually
> modules.
>
>
Scott, are you saying that a custom mountpoint "mymount" with a file
"myfile" wasn''t working as:

puppet:///mymount/myfile ?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jul 26, 3:43 pm, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Tue, Jul 26, 2011 at 12:26 PM, scott <mcco...@gmail.com> wrote:
>
> > We had sort of solved this problem with a custom fileserver mount
> > point and a subrepo in our mercurial repo, but this only worked when
> > referring to content as puppet://hostname/custommountpoint.  As soon
> > as we switched to omitting the hostname ("puppet:///") we
can''t get
> > the references to the subrepo to work since it wasn''t
actually
> > modules.
>
> Scott, are you saying that a custom mountpoint "mymount" with a
file
> "myfile" wasn''t working as:
>
> puppet:///mymount/myfile ?
Thanks Nigel, now that you ask the problem seems obvious.

puppet:///mymount/myfile  does work when the client is talking to a
puppet master.  It does not work when running with a local copy of the
configuration repo, while puppet:///modules/mymodule/myfile does. This
is expected since there''s no actual fileserver available in that case!

It does leave my question about best practices  -- is the "right"
pattern:

  source => ["puppet:///mymount/apps/database.yml.${servergroup}",
"puppet:///modules/modulename/database.yml" ]

Keeping mymount confidential on the puppet master and a default file
in the modules directory available to "anyone"?  This does seem to be
working, and meets my general need.

What if I wanted to create these from a template and avoid having to
keep potentially diverging copies of the same config file around?  Not
an issue with database.yml, but I only picked that as a simple
example.

-Scott



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.