Re: [ansible-project] Maintain file timestamp during copy

[Michael DeHaan]

This seems to be a dangerous idea, as it would cover up the last
modified time of the file.

You should just check to see that the file md5sums are the same.

Ansible will already not transfer the file if it does not need to be replaced.

On Mon, Mar 18, 2013 at 2:35 PM, mtovey <mto...@go2uti.com> wrote:
> Is there a way to maintain the source file time stamp when copying files to
> servers? I want to be able to run 'ls -l' on both the destination and
> source files and see the exact same results. Currently, all I can see is
> the date and time that the copy occurred.
> Thanks,
> -Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[VK]

IMHO this is standard sysadmin practice, via "cp -p" or "scp -p ..." or
"rsync -a..." and so on. It doesn't seem unreasonable to expect a similar
capability in ansible.

-VK

[Michael DeHaan]

Unless I am reading the docs wrong, rsync -t (part of -a) preserves
timestamps of **unchanged** files.

scp -p is something I don't use, and it's the first time I've received
this request. Not to say "new requests are bad", but "thousands of
users and not received this request" is at least significant :)

My logic was this -- if someone had manually edited it, and then the
file is edited from the config system, you'd lose that record, which
means the user might be rather confused.

Conversation to the contrary is welcome, of course, though I think the
role of a config & deployment system is not the same as the role of
low level shell tools.

I'd also be curious if anyone else agrees with me.

I'm willing to accept this, but I want to understand the underlying
reason for this first.

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Michael DeHaan]

(To clarify, I'm willing to accept this as something like a global
option, but not the default, and not as a per template or copy
parameter)

[mtovey]

    Let me explain a scenario.  I have an environment with several hundred servers running in it.  We needed to add a few more, and the new servers need to be configured identically to the already existing servers.  I have a repository of configuration files and I need to push out files from that repository to the new servers.  We want to be able to tell at a glance with 'ls -l' that the configuration files on the new servers match the configuration files on the old servers (I am fully aware that this is not an absolute guarantee that the files are truly identical, but it does provide us with reasonable enough satisfaction).  There are also other tools, such as 'find -newer', etc., that are impacted by the time stamps not being identical.
    So, maintaining the time stamp of a file between its ultimate source and where it is installed in an important expectation.  As it is now, after I have installed a file through Ansible, I am going back afterwards and using 'touch -r' to change the time stamps of the newly installed files to match that of the source for those files.  It seems to me that I should be able to do that with the copy command without the need of this second step.
    -Mark

[Michael DeHaan]

>> We want to be able to tell at a glance with 'ls -l' that the configuration files on the new servers match the configuration files on the old servers (I am fully aware that this is not an absolute guarantee that the files are truly identical, but it does provide us with reasonable enough satisfaction)

A good way to do this would be to run the playbook with --check and
see if it recorded the need to make any changes.

[Michael DeHaan]

I believe I indicated I was open to making it configurable, if it were
a global setting.

Send me a patch.

It needs to work for both paramiko and ssh connection types, as well
as ssh in scp and sftp modes.

On Tue, Mar 19, 2013 at 7:04 PM, Peter Pletcher
<peter.p...@gmail.com> wrote:
> At our site scp -p and rsync -a are the standard "old way" of doing things.
> As a new Ansible user I was unpleasantly surprised that the copy module did
> not preserve source file timestamp information, or even provide the option.
>
> As another way to look at it, the current behaviour hides the source file
> timestamp, which is what we are more interested in and accustomed to seeing.
> We want to know when the source file was last modified, not when this server
> happened to get its copy.

[Antonio Messina]

On Wed, Mar 20, 2013 at 12:41 AM, Michael DeHaan
<michael...@gmail.com> wrote:
> I believe I indicated I was open to making it configurable, if it were
> a global setting.

I am just curious, why you don't want it to be a module argument like
group=, owner=, and perm=? It would make much more sense to me...

.a.

--
antonio....@gmail.com
GC3: Grid Computing Competence Center
http://www.gc3.uzh.ch/
University of Zurich
Winterthurerstrasse 190
CH-8057 Zurich Switzerland

[Michael DeHaan]

Because you'd have to specify it every time and then would leave it
out, and also makes your playbook more verbose.

[Antonio Messina]

On Wed, Mar 20, 2013 at 3:58 PM, Michael DeHaan
<mic...@ansibleworks.com> wrote:
> On Wed, Mar 20, 2013 at 6:42 AM, Antonio Messina
> <antonio....@gmail.com> wrote:
>> On Wed, Mar 20, 2013 at 12:41 AM, Michael DeHaan
>> <michael...@gmail.com> wrote:
>>> I believe I indicated I was open to making it configurable, if it were
>>> a global setting.
>>
>> I am just curious, why you don't want it to be a module argument like
>> group=, owner=, and perm=? It would make much more sense to me...
>
> Because you'd have to specify it every time and then would leave it
> out, and also makes your playbook more verbose.

That's right, but you could only have *one* behaviour at a time, while
I think that if someone will ever need this option would also like to
switch it on only for specific files. (again, just for the sake of
discussion)

.a.

[Brian Coca]

preserve=(default false) ? values (times,ctime, owner, group,mode)
a single item or list of items

another option:

ctime={$item.ctime} user=${item.user} atime= ....
with_items: - filename

Implementing both/either should not be hard.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001
Pedo mellon a minno

[Michael DeHaan]

I'm not open to making it switchable on a per file basis.



On Wed, Mar 20, 2013 at 12:09 PM, Antonio Messina

[Kahlil Hodgson]

On 20/03/13 10:04, Peter Pletcher wrote:
> As another way to look at it, the current behaviour hides the source file
> timestamp, which is what we are more interested in and accustomed to
> seeing. We want to know when the source file was last modified, not when
> this server happened to get its copy.

Argument could go the other way. Preserving the timestamp hides the
destination file timestamp. You would not be able to tell, by looking
at the server, exactly when the configuration changes took effect. This
info could be very useful for system forensics/autopsy or for debugging
issues with you configuration management process itself.

K

--
Kahlil (Kal) Hodgson GPG: C9A02289
Head of Technology (m) +61 (0) 4 2573 0382
DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415
401 Docklands Drive
Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer." -- IBM maintenance manual, 1925

[Kahlil Hodgson]

On 20/03/13 05:17, mtovey wrote:
>
> Let me explain a scenario. I have an environment with several hundred
> servers running in it. We needed to add a few more, and the new servers
> need to be configured identically to the already existing servers. I have
> a repository of configuration files and I need to push out files from that
> repository to the new servers. We want to be able to tell at a glance with
> 'ls -l' that the configuration files on the new servers match the
> configuration files on the old servers (I am fully aware that this is not
> an absolute guarantee that the files are truly identical, but it does
> provide us with reasonable enough satisfaction). There are also other
> tools, such as 'find -newer', etc., that are impacted by the time stamps
> not being identical.

If your systems are supposed to be identical, then I think using the
command module and 'rsync' is your friend, passing an include file and
appropriate arguments.

[Peter Pletcher]

Information about when configuration changes were made is already available in other places.
And of course it goes both ways, that is why this would be a configuration option.