On May 1, 11:24 am, Philip Brown <p...@bolthole.com> wrote:
> On Tue, May 1, 2012 at 6:58 AM, jcbollinger <john.bollin...@stjude.org> wrote:
>
> >> But that requires the files be hosted on the puppet master.
> >> What if the conf files are still rdisted out under /rdist/base instead?
> >> What does that look like?
>
> > It looks exactly like what you are now doing (i.e. no Puppet). How do
> > you suppose Puppet is going to recognize that it needs to notify a
> > service if it's not managing the file?
>
> That was indeed a major part of the question I have.
> I thought it keeps some kind of database of file checksums, etc?
It checksums managed files on the client and the corresponding source
files on the master to determine whether they match. Possibly it
caches the master-side checksums (MD5 hashes by default), which would
amount to pretty much what you seem to be thinking.
> Doesnt puppet support some kind of
> (action if file changed), even if it doesnt "manage the file" itself?
There is an important concept that you need to understand to use
Puppet effectively, or even to accurately analyze how it might work
for you: Puppet is all about *state*. Actions that Puppet performs
are thoroughly a secondary consideration. A great many people seem to
miss this concept or have trouble with it. They tend to view Puppet
as some kind of fancy script engine, and that leads to all sorts of
misconceptions, wrong expectations, and manifest design problems.
It is more correct and more useful to view Puppet as a state
management service. One describes desired aspects of his nodes'
states to Puppet, and Puppet figures out how to make it so and keep it
so. Puppet does have ancillary features such as 'subscribe' and
'notify' that have a functional flavor, but even these are expressed
in terms of managed resources, and best interpreted in terms of
state. For example, a Service may 'subscribe' to the File managing
its configuration to express the idea that the running instance of the
service should be using the latest configuration (a matter of the
service instance's state).
In short, therefore, no, Puppet does not provide for triggering
actions based on changes to files or resources it does not manage.
Even if it did, in your case you would be looking at duplicating work
that rdist already does to determine whether to copy the file, and you
would have issues with synchronizing Puppet and rdist actions.
> > I think it would be useful to you to consider what you hope to achieve
> > by incorporating Puppet into your infrastructure. Your rdist system
> > must be working fairly well because you seem resistant to changing
> > it. What, then, do you think Puppet can bring to the table?
>
> A fair question. I thought I had mentioned it, but perhaps not
> sufficiently clearly:
> I want to change our existing hosttype:/etc/file.conf ->
> /rdistbase/conf/file.conf.hosttype symlink methodology, to be more
> like
>
> node hosttype {
> keep /rdistbase/conf/file.conf.host synced to /etc/file.conf
>
> }
>
> Our existing methodology works well 95% of the time. There are reasons
> to keep it in place as is. But I want 100% coverage. symlinks break
> patches, and a few other things.. The only way to extend things in
> that direction that I can see, is have puppet manage the duplication
> on a per-host basis.
Note that Puppet can keep a local file in sync with a copy *on the
master*, but it does not naturally support keeping files in sync with
other files on the node. You could hash something up with an Exec or
Cron job that uses a local rsync to perform such a task, but that's a
bit messy. It also doesn't solve the problem of synchronizing Puppet
and rdist: what happens when Puppet (or whatever other service)
happens to try to sync a file at the same time that rdist is updating
it?
> Yes, I understand the "normal puppet way" of doing things, is to have
> those conf files inside the puppet tree, but it is more maintainable
> *for us*, to have all multi-host related stuff, in the single rdist
> directory tree.
You could have it both ways by symlinking directories or individual
files from your rdist tree into the Puppet tree on the master. Puppet
should be ok with that.
Alternatively, it may be that Puppet just isn't going to do what you
hope without more changes to your existing system than you're willing
to accept.
John
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
