how puppet client update the files only when the flles from puppet server are new?

1,105 views
Skip to first unread message

metalove

unread,
Mar 28, 2011, 9:32:26 PM3/28/11
to Puppet Users
Hi, all.

I'm not familiar with puppet itself and want to know that this is
possible or not..
As I know, puppet client updates all files from server without regard
to the files are old or new..

But, I think that puppet client should update the files only when the
target files from server are new..
so is there any option to do this?

Thanks...

Felix Frank

unread,
Mar 29, 2011, 10:56:26 AM3/29/11
to puppet...@googlegroups.com
Hi,

Not that I'm aware of, no. When you're using files' "source" parameter,
you tell puppet that the contents should never change.

To enable puppet to deal with changing files, there are other ways such
as augeas.

HTH,
Felix

metalove

unread,
Mar 29, 2011, 11:52:14 AM3/29/11
to Puppet Users
sorry for confusion.

What I meant was, if

-. the same file is between puppet daemon(server) and client
-. the timestamp was older at puppet server,

I think that puppet client should not update, right?
but puppet client seems update even the server's file is old....

so, what I should do, not to update the old file from server?


puppet client <--------------> puppet server

index.html index.html
2011-03-29 2011-03-28




On 3월29일, 오후11시56분, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:

Hugo Cisneiros (Eitch)

unread,
Mar 29, 2011, 8:46:11 PM3/29/11
to puppet...@googlegroups.com
I don't know if I got your question right, but puppet actually generates a "file metadata" consisting of a unique hash (md5) for a file content. The update only happens when the md5 hash from local differs from the server.

So actually, the puppet client asks for the file_metadata for the source, like

GET /production/file_metadata/module/file.conf

it returns *only* the md5 hash from the file on the server. Then it generates the hash from the local file. If the local hash is different, the client gets the file from the server

GET /production/file_content/module/file.conf

And updates on the local system.

Is that it? :-)

-- 
[]'s
Hugo
www.devin.com.br

2011/3/29 metalove <anti...@gmail.com>

Patrick

unread,
Mar 29, 2011, 9:27:04 PM3/29/11
to puppet...@googlegroups.com

On Mar 29, 2011, at 8:52 AM, metalove wrote:

> sorry for confusion.
>
> What I meant was, if
>
> -. the same file is between puppet daemon(server) and client
> -. the timestamp was older at puppet server,
>
> I think that puppet client should not update, right?
> but puppet client seems update even the server's file is old....
>
> so, what I should do, not to update the old file from server?

The problem is that, in general, this isn't how puppet works. Usually, it's considered a feature that you know that if the file is changed on the client, puppet will revert it. First, you should consider if generating the file using information about the client might be better.

Next, with you design, what would us expect to happen if the server's file changes? Is it only then that you want to wipe it?

Conclusion:
Puppet can do that, but it's not the usual way, and I think you need to use an exec instead.

>
> puppet client <--------------> puppet server
>
> index.html index.html
> 2011-03-29 2011-03-28
>
>
>
>
> On 3월29일, 오후11시56분, Felix Frank <felix.fr...@alumni.tu-berlin.de>
> wrote:
>> Hi,
>>
>> On 03/29/2011 03:32 AM, metalove wrote:
>>
>>> Hi, all.
>>
>>> I'm not familiar with puppet itself and want to know that this is
>>> possible or not..
>>> As I know, puppet client updates all files from server without regard
>>> to the files are old or new..
>>> But, I think that puppet client should update the files only when the
>>> target files from server are new..
>>> so is there any option to do this?
>>
>> Not that I'm aware of, no. When you're using files' "source" parameter,
>> you tell puppet that the contents should never change.
>>
>> To enable puppet to deal with changing files, there are other ways such
>> as augeas.
>>
>> HTH,
>> Felix
>

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

metalove

unread,
Mar 29, 2011, 10:38:55 PM3/29/11
to Puppet Users
Let's assume that
the file in the server was rollbacked to old data because of some
reason.

then, puppet client will update also..

What I want is,
puppet client should reject the update in this case...

so is there any option at puppet clinet to reject update in this case?

Thanks.
> > For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -

Patrick

unread,
Mar 29, 2011, 11:02:08 PM3/29/11
to puppet...@googlegroups.com

On Mar 29, 2011, at 7:38 PM, metalove wrote:

> Let's assume that
> the file in the server was rollbacked to old data because of some
> reason.
>
> then, puppet client will update also..
>
> What I want is,
> puppet client should reject the update in this case...
>
> so is there any option at puppet clinet to reject update in this case?


Short answer:
No

Hard answer: (and probably the wrong answer):
You can hack something together using exec or write your own provider using ruby.


Complete answer:
I'd say that if you have a problem with your server's files reverting for no reason, you need to fix your process or server. To me this suggests you need to put tighter control on your puppetmaster's folder. Frankly, I consider being able to revert files in the puppet folder to undo a change to be good. (Yes, reverting does take thought because puppet won't undo changes. It will only push the current configuration.)

Brian Gallew

unread,
Mar 30, 2011, 9:12:17 AM3/30/11
to puppet...@googlegroups.com
I think the fundamental problem here is that you see a particular piece of metadata in your mind (this version of the file is the previous version) which does not, in fact, exist.  Since good practices dictate that your Puppet manifests, files, and templates are all in some form of version control, it's easy to fall into that trap.  You'll note, however, that Puppet itself has no notion of "version" in the file type.    All Puppet knows about the file is either it's the same as the file on the client or it's different.   @yoda(Same or different, there is no version.)

One way to address this would be to put your file into a package (which *does* know about versions) and manage it as a package resource.  Even still, you have the same problem in that, if you specify versions in the Puppet manifest and the manifest reverts to an earlier version, then the package, as installed on the client, will also revert to an earlier version (on the next run).  This is the *desired* behavior.  If you don't want your Puppet manifests to ever revert, then don't do that. 

If the problem is that a co-worker is editing the Puppet manifests in-place and revision control is undoing those changes, well, that's a social problem, not a technical problem.  Puppet is really good for managing your servers, but it's not really capable of instilling good work habit in actual people.

2011/3/29 Patrick <kc7...@gmail.com>

jcbollinger

unread,
Mar 30, 2011, 9:16:25 AM3/30/11
to Puppet Users


On Mar 29, 9:38 pm, metalove <antih...@gmail.com> wrote:
> Let's assume that
> the file in the server was rollbacked to old data because of some
> reason.
>
> then, puppet client will update also..
>
> What I want is,
> puppet client should reject the update in this case...
>
> so is there any option at puppet clinet to reject update in this case?

Heed Patrick's "complete answer". It's spot on.

However, if you nevertheless want to set up something like you
describe, for specific files, then you can write a custom fact(s) to
report the mtime(s) of the files in question, then write conditional
logic based on those facts into your manifests. That would require
your manifests to know the current mtime of the server-side file,
which you might obtain via a custom function installed on the master.

If all of the "custom" and "conditional" in the above makes you
cringe, it should. (And if it doesn't, it still should.) It's a sign
that you are not fully grasping the Puppet paradigm: you are focusing
on changes, whereas Puppet is all about states. The principle is that
you describe to the puppetmaster what your nodes are supposed to look
like, and Puppet ensures that it is so. You want instead to describe
to the puppetmaster changes that might need to be made, and criteria
for deciding whether to apply those changes. That's just not the
Puppet model.


John
Reply all
Reply to author
Forward
0 new messages