Re: Managing untemplatable configuration files

[llowder]

On Wednesday, October 24, 2012 1:24:07 PM UTC-5, David Reagan wrote:

I'm brand new to Puppet. Just read through the tutorial online, and the first couple chapters of Pro Puppet.

As I've experimented with managing Apache, I ended up storing my wildcard ssl cert on the puppetmaster. Since my Apache hosts will all use it.

I'm also looking at managing Shibboleth with Puppet. I don't know the application well enough to figure out how to template the various configuration files correctly. So it seems like I might want to store them on the puppetmaster.

I'm sure I'll run into other applications with the same problem.

So, does it make sense to store files with host specific configuration in them on the puppet master? Files that are either unable to be turned into templates, or that I don't know enough about the application to make templates. Or is there a better way?

For complex configs, I either use ageaus or a define that builds fragments to be put together using puppet-concat.
I also wind up having to spend a lot of time studying docs and existing configs so that I can properly build the config files.
 

[jcbollinger]

On Wednesday, October 24, 2012 1:24:07 PM UTC-5, David Reagan wrote:

I'm brand new to Puppet. Just read through the tutorial online, and the first couple chapters of Pro Puppet.

As I've experimented with managing Apache, I ended up storing my wildcard ssl cert on the puppetmaster. Since my Apache hosts will all use it.

I'm also looking at managing Shibboleth with Puppet. I don't know the application well enough to figure out how to template the various configuration files correctly. So it seems like I might want to store them on the puppetmaster.

I'm sure I'll run into other applications with the same problem.

So, does it make sense to store files with host specific configuration in them on the puppet master? Files that are either unable to be turned into templates, or that I don't know enough about the application to make templates. Or is there a better way?

It makes a certain amount of sense to do that, but it does present a scaling and maintenance problem.  Also, since you don't understand the files, you must be planning on creating them on the client via some automated tool, then uploading them to the master.  In the end, then, all you really get for the work is Puppet ensuring that any changes to those files are reverted automatically.  That's a lot less valuable than being able to change a template or verbatim file on the master and having it pushed out to the appropriate clients.

I suggest that you study the target applications or their config files enough to template them.  Comparing two or three generated for different servers should get you most of the way to where you want to be.  Alternatively, maybe these particular files don't really need to be under Puppet management at all?


John

[Tim Mooney]

In regard to: [Puppet Users] Managing untemplatable configuration files,...:

> So, does it make sense to store files with host specific configuration in
> them on the puppet master? Files that are either unable to be turned into
> templates, or that I don't know enough about the application to make
> templates. Or is there a better way?

It's not the best way, but if it gets you started on puppet and helps you
get to the point where your infrastructure is in a known state, then it's
worth doing. It's definitely better than not managing the file content,
and remember that that too is an option; you can manage just the
permissions and existence, without managing the content itself.

Learning puppet is kind of like software development. Some day you'll
look back on your "1.0" version and think "what was I thinking?!", but
even knowing that's going to happen, you shouldn't get caught up in
"paralysis by analysis" at the start. It's good that you want to
do things elegantly or "correctly" even starting out, but don't let
the lack of a perfect solution keep you from making any progress at all.
Start with the simple stuff, like file-shipping entire config files
where necessary, but keep learning and keep refining.

Tim
--
Tim Mooney Tim.M...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164