"file {}" resources owned by uid instead of euid

[Turbo Fredriksson]

Puppet version: 3.8 (old, but can't upgrade).

I had a "file {}" resource "blow up" on me today, a crontab file that cron refused to load because

    (*system*file) WRONG FILE OWNER (/etc/cron.d/file)

This because I didn't have any 'owner' or 'group' parameters to the "file {}" resource.. I had logged

in as myself ('turbo') and run "sudo puppet agent -t", which lead to the file in question being owned

by *me* ('turbo') instead of 'root'.

Is this a known behaviour? Is it documented somewhere where I *should* have seen it?

[R.I. Pienaar]

When you don’t tell it you can’t have any expectations

In the past it took the owner of the files on the puppet master, not sure if that’s even defined expectation

Bottom line. If you care. Tell it what you care about or expect undefined outcomes. 

 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e1fc6c36-1fc2-443e-8edd-07d066fe48e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Turbo Fredriksson]

On Thursday, March 15, 2018 at 7:03:09 PM UTC, R.I. Pienaar wrote:

When you don’t tell it you can’t have any expectations

My expectations was that it work in a UN*X fashion:

----- s n i p ------

turbo@host:~$ ls -l file

ls: cannot access 'file': No such file or directory

turbo@host:~$ sudo touch file

turbo@host:~$ ls -l file

-rw-r--r-- 1 root root 0 Mar 16 10:00 file 

----- s n i p ------