Puppet users - Feb 2013 - Directory Layout Recommendations for Puppetmaster?

I manage a web/mail/dns server for my own small business and so far 
maintained the test and production servers by hand, keeping config files 
under cvs and using scp to copy them to the servers. Looking for a better 
way to do this (prompted by the more and more tedious work to do when 
upgrading the OS on a server and the planned hardware replacement) I 
stumbled upon puppet and so far this seems like the best solution. What won 
me over was the excellent tutorials
<http://docs.puppetlabs.com/learning/>.
I am now trying to figure out the best way to organize my work, and I need 
help from the experts, as I did not find any info on these questions of 
workflow setup.
I don''t think the ''tutorial'' way of editing files
directly under
/etc/puppet/{manifests,modules} is recommended for real work; I want to use 
another directory, which I can also mount on my workstation, for editing 
the files.
There is the ''confdir'' setting, but it affects more than what
I consider
the ''data'' part of the layout (manifests, modules, nodes,
....) so I am
considering this setup in /etc/puppet/puppet.conf:
    $datadir = "/some/fs/puppet"
    manifestdir = "$datadir/manifests"
    modulepath = 
"$datadir/modules:$confdir/modules:/usr/share/puppet/modules"
except that it is not possible to define variables in config files, but 
this works fine:
    manifestdir = "/some/fs/puppet/manifests"
    modulepath = 
"/some/fs/puppet/modules:$confdir/modules:/usr/share/puppet/modules"

so everything puppet-internal is still in /etc/puppet, and I can hack away 
(under CVS control) at the files under /some/fs/puppet.

Does this make sense?

Thanks for your consideration,

Roman

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

http://docs.puppetlabs.com/references/latest/configuration.html#confdir 


“Sometimes I think the surest sign that intelligent life exists elsewhere in the
universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes) 

----- Original Message -----
From: "Roman Mäder" <roman.maeder@gmail.com> 
To: puppet-users@googlegroups.com 
Sent: Wednesday, February 27, 2013 8:06:36 AM 
Subject: [Puppet Users] Directory Layout Recommendations for Puppetmaster? 

I manage a web/mail/dns server for my own small business and so far maintained
the test and production servers by hand, keeping config files under cvs and
using scp to copy them to the servers. Looking for a better way to do this
(prompted by the more and more tedious work to do when upgrading the OS on a
server and the planned hardware replacement) I stumbled upon puppet and so far
this seems like the best solution. What won me over was the excellent tutorials
.
I am now trying to figure out the best way to organize my work, and I need help
from the experts, as I did not find any info on these questions of workflow
setup.
I don''t think the ''tutorial'' way of editing files
directly under /etc/puppet/{manifests,modules} is recommended for real work; I
want to use another directory, which I can also mount on my workstation, for
editing the files.
There is the ''confdir'' setting, but it affects more than what
I consider the ''data'' part of the layout (manifests, modules,
nodes, ....) so I am considering this setup in /etc/puppet/puppet.conf:
$datadir = "/some/fs/puppet" 
manifestdir = "$datadir/manifests" 
modulepath =
"$datadir/modules:$confdir/modules:/usr/share/puppet/modules"
except that it is not possible to define variables in config files, but this
works fine:
manifestdir = "/some/fs/puppet/manifests" 
modulepath =
"/some/fs/puppet/modules:$confdir/modules:/usr/share/puppet/modules"

so everything puppet-internal is still in /etc/puppet, and I can hack away
(under CVS control) at the files under /some/fs/puppet.

Does this make sense? 

Thanks for your consideration, 

Roman 



-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com. 
Visit this group at http://groups.google.com/group/puppet-users?hl=en . 
For more options, visit https://groups.google.com/groups/opt_out . 


-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

> I manage a web/mail/dns server for my own small business and so far
> maintained the test and production servers by hand, keeping config files
> under cvs and using scp to copy them to the servers. Looking for a
> better way to do this (prompted by the more and more tedious work to do
> when upgrading the OS on a server and the planned hardware replacement)
> I stumbled upon puppet and so far this seems like the best solution.
> What won me over was the excellent tutorials
> <http://docs.puppetlabs.com/learning/>.
> I am now trying to figure out the best way to organize my work, and I
> need help from the experts, as I did not find any info on these
> questions of workflow setup.
> I don''t think the ''tutorial'' way of editing
files directly under
> /etc/puppet/{manifests,modules} is recommended for real work; I want to
> use another directory, which I can also mount on my workstation, for
> editing the files.
> There is the ''confdir'' setting, but it affects more than
what I consider
> the ''data'' part of the layout (manifests, modules, nodes,
....) so I am
> considering this setup in /etc/puppet/puppet.conf:
>     $datadir = "/some/fs/puppet"
>     manifestdir = "$datadir/manifests"
>     modulepath >
"$datadir/modules:$confdir/modules:/usr/share/puppet/modules"
> except that it is not possible to define variables in config files, but
> this works fine:
>     manifestdir = "/some/fs/puppet/manifests"
>     modulepath >
"/some/fs/puppet/modules:$confdir/modules:/usr/share/puppet/modules"
> 
> so everything puppet-internal is still in /etc/puppet, and I can hack
> away (under CVS control) at the files under /some/fs/puppet.
I have all my manifests and modules stored in a GIT repository. I''m
working with the files in my /home, and I have a Rakefile with a
"deploy" target defined. So typing "rake deploy" will push
the local
repo to the central server and login to the puppetmaster via SSH and
pull the latest files from the central server.

The only thing I haven''t figured out yet is what to do with sensible
files (private keys etc) that I want managed by puppet. Somehow, having
those in the repo doesn''t seem nice to me. Any recommendations?

Cheers, Andreas.

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wed, Feb 27, 2013 at 8:06 AM, Roman Mäder <roman.maeder@gmail.com>
wrote:
> I manage a web/mail/dns server for my own small business and so far
> maintained the test and production servers by hand, keeping config files
> under cvs and using scp to copy them to the servers. Looking for a better
> way to do this (prompted by the more and more tedious work to do when
> upgrading the OS on a server and the planned hardware replacement) I
> stumbled upon puppet and so far this seems like the best solution. What won
> me over was the excellent tutorials.
> I am now trying to figure out the best way to organize my work, and I need
> help from the experts, as I did not find any info on these questions of
> workflow setup.
> I don''t think the ''tutorial'' way of editing
files directly under
> /etc/puppet/{manifests,modules} is recommended for real work; I want to use
> another directory, which I can also mount on my workstation, for editing
the
> files.
> There is the ''confdir'' setting, but it affects more than
what I consider the
> ''data'' part of the layout (manifests, modules, nodes,
....) so I am
> considering this setup in /etc/puppet/puppet.conf:
>     $datadir = "/some/fs/puppet"
>     manifestdir = "$datadir/manifests"
>     modulepath >
"$datadir/modules:$confdir/modules:/usr/share/puppet/modules"
> except that it is not possible to define variables in config files, but
this
> works fine:
>     manifestdir = "/some/fs/puppet/manifests"
>     modulepath >
"/some/fs/puppet/modules:$confdir/modules:/usr/share/puppet/modules"
>
> so everything puppet-internal is still in /etc/puppet, and I can hack away
> (under CVS control) at the files under /some/fs/puppet.
>
> Does this make sense?
>
> Thanks for your consideration,
> Roman

A more typical workflow would be to keep all your production files
within /etc/puppet on the puppet master, with those checked out from a
production branch in your CVS server.  On your development machine,
you use a separate checkout from a separate branch, and when you''re
done you push into the production branch, then update to that release
on your production server.  This is a more typical approach and I
don''t think mounting the same files on different servers makes a lot
of sense.

I''m not really a fan of keeping files in /etc/puppet, but that seems
to be the default that most people use.  However, I would look into
environments and modules, and make sure to put everything inside
there, which forces you to keep things a lot more modular and also
eases development.  A typical setup for this would use the path:
    /etc/puppet/environments/dev/{manifests,modules}
and you would keep all files within "dev" under revision control.


❧ Brian Mathis

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Am Mittwoch, 27. Februar 2013 18:26:12 UTC+1 schrieb Brian
Mathis:
>
>
> A more typical workflow would be to keep all your production files 
> within /etc/puppet on the puppet master, with those checked out from a 
> production branch in your CVS server.  On your development machine, 
> you use a separate checkout from a separate branch, and when
you''re
> done you push into the production branch, then update to that release 
> on your production server.  ...
 
For my small setup, I wanted to keep things a bit simpler, and not set up a 
second, test, puppet master, but edit the files in the development 
environment of the master directly, test by ''kicking'' the test
node, and if
things work, commit and later push the committed files to the production 
environment.
 For anything larger than, say one server and a test and production node, a 
more elaborate setup would certainly make sense.

thanks,

Roman

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Yes, actually.

Use multiple git trees with varying levels of security. Keeping anything
and everything in the same tree is indeed bound to cause hedaches in the
future.

On the bright side, if your changes are sufficiently self contained, git
has pretty powerful tools to rebuild your tree to get rid of the
sensitive data.

Cheers,
Felix

On 02/27/2013 05:45 PM, Andreas Hilboll wrote:
> The only thing I haven''t figured out yet is what to do with
sensible
> files (private keys etc) that I want managed by puppet. Somehow, having
> those in the repo doesn''t seem nice to me. Any recommendations?
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.