Keeping a directory clean at top level

646 views
Skip to first unread message

Rich Rauenzahn

unread,
Feb 15, 2011, 1:04:23 PM2/15/11
to puppet...@googlegroups.com
Say we have a directory called /FOO-- we want to only have in it what
puppet puts into it. I want to remove any symlinks, empty directories,
or files in it that don't belong -- but only one level deep. If the
subdirectory has content, I don't want it removed -- ideally, I'd like
a failure. This is because we might have some systems misconfigured
(prior to deploying puppet) and we want to manually fix them -- the
content in /FOO/bar might be important.

Hmm - maybe this is a case for audit? ...but doesn't seem to fit what
I want to do. Maybe it doesn't work in command line mode since there
isn't a history recorded.

I've been trying

puppet resource file /tmp/empty_me ensure=directory purge=true
source=/tmp/empty recurse=true recurselimit=1 force=true

recurselimit=0 does nothing. recurselimit=1 stll causes the
directory's contents to be removed. Without force, empty directories
aren't removed. Without recurse my directory isn't purged.

Any ideas? Is this possible to do without making my own file resource type?

donavan

unread,
Feb 16, 2011, 1:19:31 AM2/16/11
to Puppet Users


On Feb 15, 10:04 am, Rich Rauenzahn <rraue...@gmail.com> wrote:
> Say we have a directory called /FOO-- we want to only have in it what
> puppet puts into it.
...
> puppet resource file /tmp/empty_me ensure=directory purge=true
> source=/tmp/empty recurse=true recurselimit=1 force=true

I use this pattern myself, something like

file {
"/tmp/test":
ensure => directory,
purge => true,
recurse => true,
recurselimit => 1,
force => true;
"/tmp/test/foo":
ensure => directory;
}

For your particular case I suspect it's because your using the
resource application, instead of agent or apply. The applied catalog
doesn't have any other managed resources. Using the above snippet /tmp/
test/foo is ignored as a managed resource and can contain anything.

L. Matthew Blancett

unread,
Jul 16, 2015, 2:47:32 PM7/16/15
to puppet...@googlegroups.com, rrau...@gmail.com

I have this same need. In my case it's yum repo files that I want to ensure are ONLY what puppet manages (we occasional haven brazen users drop repo's on boxes, and cause big headaches down that road). Our environment is complex enough that repo's don't come from a single file, but from disparate modules and classes. When I tell puppet to manage /etc/yum.repos.d/  with purge => true, it seems to remove every repo, then re-add them later in its run.   

Christopher Wood

unread,
Jul 16, 2015, 2:52:39 PM7/16/15
to puppet...@googlegroups.com, rrau...@gmail.com
The yumrepos are not file resources, if I recall correctly the purging is done on files and the /etc/yum.repos.d/* are not explicitly managed as files. So the files are nuked and then the yumrepos are create and put in files for the cycle to start again.

Having the same issue I stopped declaring yumrepo types and started declaring files for the contents of that directory. Everybody here is used to the repo file format and it went transparently.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/a6a78d34-4d2b-49d7-8a91-d47cfa61e54c%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/a6a78d34-4d2b-49d7-8a91-d47cfa61e54c%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

Reply all
Reply to author
Forward
0 new messages