Puppet

Sure, we just want to be able to clobber immutable files with a flag or something-or-other. So for instance, people for various reasons will chattr +i files that puppet writes after they realize their changes get overwritten, not knowing there are knobs we provide that provide most functionality without having to make the files immutable.

This feature may not make a lot of sense to those of you who only use Puppet to manage servers that you have entirely under your own control.

We’re managing a lot of desktops and laptops as well, where users have root privileges and may make a bad decision to chattr/chflag a file to stop Puppet overwriting their local changes.

When we were thinking about it here we came up with three main options.

a) add another parameter to the File resource (make_mutable?) b) add this to the “force” parameter c) Inherit the File resource to a MutableFile resource

Really for upstream puppet only a) or b) make sense. I’m unsure which method makes the most sense.

afaik, the only two implementations for this are chattr and chflags, but my commercial UNIX-fu is pretty weak outside of Linux, BSDs and OS X.

I like b).

I think b) is the right approach too, but given it’s a major behavior change (look ma! I even spell like an American now) it’s probably something to push off to rowlf.

A variant of this: have an option to make failures to modify files that are immutable non-fatal.

Some ability to interact with “immutable” files would be nice, but I can work around it with a pair of execs if this isn’t going to be implemented.

Wolf, can you elaborate more on what you’d like to be able to do with immutable files?

Do you want the force == “remove immutable bits if present” behavior? Do you want to be able to make files immutable via puppet more easily?

I’d like to be able to manage and work with/around files' extended attributes.. most especially mutability. if a file is immutable, and I’ve a need to update or change it, I’d like the ability to do so within a file resource. perhaps setting: mutability => true (normal: would basically be an exec chattr -i if the file is immutable) mutability => false (immutable: would set the file to immutable when changed) mutability => respect (default: whine when attempting to update/change/remove a file which is immutable with a reasonable error message)

(or something)

I agree with Wolf there. Some people might want to use the immutable to prevent people changing the files, and other people might want to use it to prevent puppet changing a specific file (testing changes in a single server, debugging a problem in a production system, etc.).

So Puppet should be able to: – remove immutable flag – set immutable flag – ignore immutable flag (and report as pending if it can’t change the file)

Is immutability the only extended attribute we want to control?

e.g. here’s the chflags options you have on a BSD/OS X.

           arch, archived
                   set the archived flag (super-user only)

           opaque  set the opaque flag (owner or super-user only).  [Directory is opaque when viewed
                   through a union mount]

           nodump  set the nodump flag (owner or super-user only)

           sappnd, sappend
                   set the system append-only flag (super-user only)

           schg, schange, simmutable
                   set the system immutable flag (super-user only)

           uappnd, uappend
                   set the user append-only flag (owner or super-user only)

           uchg, uchange, uimmutable
                   set the user immutable flag (owner or super-user only)

           hidden  set the hidden flag [Hide item from GUI]

chattr gives us relatively similar options.