Make includes/excludes in InclExcl less aggressive or at least array-ify them programatically

[bschonec]

The default InclExcl files (at least for Red Hat) are too aggressive for my use case. For example, I mount GPFS file systems under /mnt that do need to be backed up. Unfortunately, the excludes are hard-coded into the file https://github.com/nosolutions/puppet-tsm/blob/master/files/InclExcl.redhat#L10 and there's no way to 'undo' the exclude programatically.

I recommend pulling the values out of the static file and creating an array that is then dumped into Inclexcl file.

Another example of being too aggressive is exclude /var/log/.../*. I would think that most certainly you'd want to back up your system logs.

I understand that one can point inclexcl_source to a different, static file on the puppet server but this seems like a bit of extra work when all you really should have to do is specify an array in hiera. The module makes assumptions that aren't programmatically changeable.

[tosmi]

did you find a solution for this problem or are you using your own inclexcl file for now?

thanks for the info
toni

[tosmi]

ah, never mind, you reopened this issue... i basically used the same content for the inclexcl file we use internally without think much about it.

i'm not sure if using an array instead of inclexcl_source makes a huge difference in usability. the inclexcl_source option is also configurable via hiera, so whatever route we go you have to modify your hiera data.

but i'm open to a discussion or a pull request for review, where ever this goes :-)

thanks for providing feedback.

[bschonec]

What I'm doing currently is modifying the file that's in the module. While this works for me, I don't think it's the proper way to pseudo-solve the problem. I'm sure I'm not the only one that mounts external (or local!) file systems under /mnt and needs to back up the data.

Using the inclexcl_source won't help because it's not possible to 'undo' a setting in TSM client once the exclude/exclude.dir has been set -- which is exactly what the ../files/InclExcl.redat file (https://github.com/nosolutions/puppet-tsm/blob/master/files/InclExcl.redhat#L10) does.

I do agree that there are some file systems and directory paths that you never want backed up. /proc, /sys/, etc but /mnt I think makes a too-aggressive assumption about the administrator's needs. The only real way to solve the [my] issue is with an array variable that allows the override of InclExcl.redhat.

I'm happy to try to solve the problem but I have absolutely no idea how to create spec tests for anything I do.

[tosmi]

hm, what about the following

1. reduce the default inclexcl file to the bare minimum
2. introduce an array for specifing additional content for the default inclexcl file, which holds the
   rest of the inclexcl file.

so the content is going to be the same, but now you can easily remove things you don't like.

i don't like to change the default content because this is going to require that consumers of the module need to check/alter their current deployment. this would require a major version bump (2.x), but i try to save this for dropping puppet 3 support :-)

if you come up with a pull request, don't worry about rspec tests for this for now.

learning rspec-puppet is not that difficult, for the most part it's just copy & paste programming.

thanks
toni

[bschonec]

Yeah, I think that's a great idea to keep the current settings as defaults and then have the ability to change or overwrite them with a [new?] array. I'll work on something this week as I'm migrating 1500 servers to TSM soon and will definitely need this functionality.

[tosmi]

exclude /var/cache/.../*
exclude /var/crash/.../*
exclude /var/lib/slocate/*
exclude /var/lock/.../*
exclude /var/log/.../*
exclude /var/run/.../*
exclude /var/spool/.../*
exclude /.../core
exclude /.../tmp/.../*
exclude.dir /mnt
exclude.dir /proc
exclude.dir /sys
exclude.fs /dev/shm
exclude.fs /dev/pts

this is the current list of entries in inclexcl.redhat. i would only keep

/proc
/sys
/dev/shm
/dev/pts

imho the rest could go into the array.