I actually think this is the start of a very good idea with the main drawback being that not all filesystems support extended attributes.
However, most of the popular ones do. There is some overhead with reading the metadata and I'm not sure if this would be better than starting to work on an Open Standard for systems automation metadata and query. Trevor On Fri, Mar 1, 2013 at 10:55 PM, Wolf Noble <[email protected]> wrote: > Hey Gang, > > Longtime listener, first time caller…. > > I had a funny idea last night. I've thought it through a bit, and _I_ > still think it has merit, but not fully formed… then again, I am accustomed > to being wrong. > > So, I was thinking about how multiple realizations of the same virtual > file with different (but not conflicting) parameters/attributes might > coexist. > > I started thinking about filesystem extended attributes… > > > http://www.techrepublic.com/blog/opensource/learn-to-use-extended-file-attributes-in-linux-to-boost-security/1116 > > so, (in linux, not sure about other NIX, as I don't have any handy) a file > can have 128 userland attributes. As root, you can add them to a file > without any special mount parameters. you can add/remove an attribute, and > assign a string value to it: > > [root@puppet ~]# rm -f myapp.conf; > touch myapp.conf; > echo "clean"; > getfattr myapp.conf; > echo "adding attrs now"; > setfattr -n user.puppet.managed myapp.conf; > setfattr -n user.puppet.owner -v "root" myapp.conf; > getfattr myapp.conf; > getfattr -n user.puppet.owner myapp.conf; > > > clean > adding attrs now > # file: myapp.conf > user.puppet.managed > user.puppet.owner > > # file: myapp.conf > user.puppet.owner="root" > > > > now… I was thinking there's a handful of ways this _could_ be used… > > it could be a lightweight way for puppet and chef to inform each other > that they 'own' a file…. and what parts of the file they care about, > perms, owner, group, content, to prevent colliding 'config management' > > (I know of several places that use chef and puppet for management of the > same node, but different parts) > > backup programs could use this to not backup files under configuration > management (since puppet/chef/cfengine/etc can just redeploy, why waste IO?) > > inform vi/vim/emacs/pico (I don't judge, ok, maybe a little, but I won't > say it out loud) that the file's content is managed by configmanagement and > as such a banner should be displayed… > > store the modulenames which are trying to realize it, and what parts of > the overall file's attributes are wanting to be managed… > > there's a lot of possibilities, but before I get too deep here… what do > you guys think? does this idea have merit? > > > W > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
