I have the following define... define puppet::module_dir { if $name { include puppet file { "${puppetdir}/modules/${name}": ensure => directory, mode => 0755, purge => true, recurse => true, } } } I call it like so: puppet::module_dir { "main" } puppet::module_dir { "dev" } ... the creation sense works great. however when I manually create some file in one of these directories and run puppetd I would expect it to be deleted (as that it''s unmanaged and I have purge => true and recurse => true) however what happens is the file gets chmod''ed notice: //base/puppet::common/puppet::server/puppet::module_dir[main]/File[/etc/puppet/modules/main/foo]/mode: mode changed ''644'' to ''755'' Bug? Misunderstanding? Cosmic Forces out of my control? -- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Nov 6, 2007, at 5:54 PM, Chris MacLeod wrote:> however when I manually create some file in one of these > directories and run puppetd I would expect it to be deleted (as > that it''s unmanaged and I have purge => true and recurse => true) > > however what happens is the file gets chmod''ed > > notice: //base/puppet::common/puppet::server/puppet::module_dir > [main]/File[/etc/puppet/modules/main/foo]/mode: mode changed ''644'' > to ''755'' > > Bug? > Misunderstanding? > Cosmic Forces out of my control?File purging is kinda weird right now, and I don''t know how to fix it, design-wise. If you specify an attribute to change -- e.g., its mode or owner -- then Puppet will recurse down the filesystem and make changes to all files. Thus, Puppet is managing those files. If you then say to purge unmanaged files, Puppet considers all of the files it finds to be managed, so it doesn''t delete any of them. This is probably pretty stupid; I should either make purge only work when doing a remote copy (in which case it currently behaves relatively well, but only through a hack), or I should find some kind of behaviour that makes sense in this case. If anyone has any recommendations, I''m all ears (or eyes, or whatever). Maybe to get to the heart of it: Why bother changing the mode of files you''re planning on deleting? I''m assuming the mode is for the directory and the purge is for the contained files; right? -- To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 11/8/07, Luke Kanies <luke@madstop.com> wrote:> > On Nov 6, 2007, at 5:54 PM, Chris MacLeod wrote: > > > however when I manually create some file in one of these > > directories and run puppetd I would expect it to be deleted (as > > that it''s unmanaged and I have purge => true and recurse => true) > > > > however what happens is the file gets chmod''ed > > > > notice: //base/puppet::common/puppet::server/puppet::module_dir > > [main]/File[/etc/puppet/modules/main/foo]/mode: mode changed ''644'' > > to ''755'' > > > > Bug? > > Misunderstanding? > > Cosmic Forces out of my control? > > File purging is kinda weird right now, and I don''t know how to fix > it, design-wise. > > If you specify an attribute to change -- e.g., its mode or owner -- > then Puppet will recurse down the filesystem and make changes to all > files. Thus, Puppet is managing those files. > > If you then say to purge unmanaged files, Puppet considers all of the > files it finds to be managed, so it doesn''t delete any of them. > > This is probably pretty stupid; I should either make purge only work > when doing a remote copy (in which case it currently behaves > relatively well, but only through a hack), or I should find some kind > of behaviour that makes sense in this case. > > If anyone has any recommendations, I''m all ears (or eyes, or whatever). > > Maybe to get to the heart of it: Why bother changing the mode of > files you''re planning on deleting? I''m assuming the mode is for the > directory and the purge is for the contained files; right?I use that define to create the directory my puppet modules live in. I have puppet create the directory then I clone modules into it. I guess I was assuming that by using purge I could have puppet clean up modules that were no longer relevant. Ie a module is created, it gets cloned into the appropriate directory. If for some reason the module isn''t used or it''s functionality it rolled into somewhere else, the module in question would be removed from the config I would then have expected the purge to remove the directory since it wasn''t ''owned'' by puppet any longer. Am I misunderstanding how puppet takes ownership (for lack of a better term) of a file object? C -- stickm@gmail.com -==< Stick >==- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 November 2007, Chris MacLeod wrote:> On 11/8/07, Luke Kanies <luke@madstop.com> wrote: > > On Nov 6, 2007, at 5:54 PM, Chris MacLeod wrote: > > > however when I manually create some file in one of these > > > directories and run puppetd I would expect it to be deleted (as > > > that it''s unmanaged and I have purge => true and recurse => true) > > > > > > however what happens is the file gets chmod''ed > > > > > > notice: //base/puppet::common/puppet::server/puppet::module_dir > > > [main]/File[/etc/puppet/modules/main/foo]/mode: mode changed ''644'' > > > to ''755'' > > > > > > Bug? > > > Misunderstanding? > > > Cosmic Forces out of my control? > > > > File purging is kinda weird right now, and I don''t know how to fix > > it, design-wise. > > > > If you specify an attribute to change -- e.g., its mode or owner -- > > then Puppet will recurse down the filesystem and make changes to all > > files. Thus, Puppet is managing those files. > > > > If you then say to purge unmanaged files, Puppet considers all of the > > files it finds to be managed, so it doesn''t delete any of them. > > > > This is probably pretty stupid; I should either make purge only work > > when doing a remote copy (in which case it currently behaves > > relatively well, but only through a hack), or I should find some kind > > of behaviour that makes sense in this case. > > > > If anyone has any recommendations, I''m all ears (or eyes, or whatever). > > > > Maybe to get to the heart of it: Why bother changing the mode of > > files you''re planning on deleting? I''m assuming the mode is for the > > directory and the purge is for the contained files; right? > > I use that define to create the directory my puppet modules live in. > I have puppet create the directory then I clone modules into it. I guess I > was assuming that by using purge I could have puppet clean up modules that > were no longer relevant. Ie a module is created, it gets cloned into the > appropriate directory. If for some reason the module isn''t used or it''s > functionality it rolled into somewhere else, the module in question would > be removed from the config I would then have expected the purge to remove > the directory since it wasn''t ''owned'' by puppet any longer. > > Am I misunderstanding how puppet takes ownership (for lack of a better > term) of a file object?That''s why my version of modules_dir[1] has a source=> parameter to an empty directory. This ensures that only explicitly managed files are left there. Regards, David [1] http://git.black.co.at/?p=manifests.git;a=blob;f=modules/common/manifests/defines/modules_dir.pp;hb=HEAD - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHM1s3/Pp1N6Uzh0URAhuBAJ0ZoqjYDlrKmp428TySSJHkVPahiwCfexwp MAH0TWUAQJYd64bv997WSmE=grfp -----END PGP SIGNATURE-----
On Nov 8, 2007, at 11:54 AM, Chris MacLeod wrote:> I use that define to create the directory my puppet modules live in. > I have puppet create the directory then I clone modules into it. I > guess I was assuming that by using purge I could have puppet clean > up modules that were no longer relevant. Ie a module is created, > it gets cloned into the appropriate directory. If for some reason > the module isn''t used or it''s functionality it rolled into > somewhere else, the module in question would be removed from the > config I would then have expected the purge to remove the directory > since it wasn''t ''owned'' by puppet any longer. > > Am I misunderstanding how puppet takes ownership (for lack of a > better term) of a file object?I use the term "managed" -- as in, "Puppet is managing that file". Ownership isn''t bad, though. It''s part of the general problems with recursion in Puppet -- it just isn''t flexible enough. You want to recursively purge but only set modes on a single file, which is, well, difficult to do with just one resource specification. We need to find a solution, but we don''t have one yet. Until then, things are always going to be a bit clumsy. If someone implemented globbing, that would get us most of the way there, because then you could have something like: file { "/my/dir": mode => 755 } file { "/my/dir/*": purge => true, recurse => true } Still feels kludgy, but it''s better than nothing, anyway. It''s not a trivial amount of work, but at least Puppet can support it now, where a year ago it couldn''t have. -- A gentleman is a man who can play the accordion but doesn''t. -- Unknown --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com