John, I got it to work with the array. I had to remove the base class in your code otherwise that folder gets declared multiple times. After I did that, it pretty much worked as expected.
I like the idea of the loop and looked up future parser. I couldn't find any examples that I was comfortable with so again, the array is great for now. I will revisit this thread when I have a better grasp of puppet overall as I feel you gave great advice and examples that for right now I am just not getting. Thanks for your patience with me on this as I learned a lot in the process. On Thursday, September 25, 2014 8:49:20 AM UTC-5, jcbollinger wrote: > > > > On Wednesday, September 24, 2014 2:38:40 PM UTC-5, aar...@gmail.com wrote: >> >> Neil and John, >> >> You guys both agree on using individual files and I was thinking of how I >> could do this. If I have one file or three, it may not be a big deal to do >> individually, but some applications could need dozens or more. >> >> I don't know if it is possible, some searching makes me believe it isn't, >> but I'll share my thought. >> >> Can you do something like a for loop in a bash script. So it would be >> something like... >> > > > You can if you turn on the future parser, but there's an old-school way to > approach the problem that might actually be better in your case, because it > would be reusable across multiple application modules. The old-school way > revolves around Puppet's behavior when an array is provided as a resource > title > <https://docs.puppetlabs.com/puppet/3/reference/lang_resources.html#array-of-titles>, > > which is to declare a separate resource for each element of the array. > When the declared resource is of a defined type, it's body is evaluated > once for each title, which yields a pretty good analog of iteration. > Example: > > define my_module::mac_preference_file ($application) { > include my_module::mac_preferences_base > > file { "/System/Library/User > Template/English.lproj/Library/Preferences/${title}": > ensure => 'file', > owner => 'root', > group => 'wheel', > mode => '0600' > source => "puppet:///modules/${application}/Preferences/${title}" > } > } > > > # Manages the base preferences directory. > # Must be a class so that it can be declared multiple times.. > class my_module::mac_preferences_base { > # Note: not recursive. In this version, all managed contents > # are managed by separate File resources. > file { "/System/Library/User Template/English.lproj/Library/Preferences": > ensure => 'directory', > owner => 'root', > group => 'wheel', > mode => '0600' > } > } > > > That might be used like so: > > class some_application { > $my_preference_files = [ 'some.plist', 'another.plist', 'random.plist' ] > > my_module::mac_preference_file { $my_preference_files: > application => 'some_application' > } > > # ... > } > > > >> >> >> for files in .../module_name/Preferences/ # get a list of files and >> folders in the Preferences subfolder on the Puppet Master >> file { '/System/Library/User >> Template/English.lproj/Library/Preferences/${files}': #Directory on Puppet >> agent, the variable would make this a unique resource and it would work for >> a file and folder >> source => "puppet:///modules/${module_name}/Preferences/${files}", # >> Since it is looping every file on the Puppet Master would match perfectly >> to the same exact file/folder on the agent. No duplicate declaration. >> done >> >> John, >> >> I think I understand what your code is trying to do, but am not sure I >> understand how to implement. I think that $preference_sources is making a >> list of paths (puppet paths) to the Preferences folder of each module, >> > > > Yes, the approach depends on creating an array of all the source > directories from which to sync files into the master Preferences folder. > You cannot manage the Preferences folder more than once, but you *can* > give it multiple sources. > > > >> and I know that sourceselect all means that it will use all sources >> instead of stopping at the first match. I also see that the >> preferences_sources is being created from a regex expression that I don't >> completely understand, though that shouldn't matter in getting this to >> work. >> >> Is this still a defined type? >> > > > No, it is a class. That's what "class" instead of "define" at the > beginning means. There's no point to making it a defined type, because any > attempt to declare it (as a resource) more than once will fail with a > duplicate resource error. Also, if you make it a class then you have the > option of using automated data binding to assign the parameter value (via > Hiera). > > > >> Should class mac_managed_preferences be defined >> > > > Well, yes. Its definition is what I presented. Do you mean to ask > whether it should be *declared*? Also yes. A class definition by itself > does nothing for you. In this case, you make an array of the names of all > the application modules whose preferences you want to manage, and assign > that array as the class's parameter. If you do that via Hiera and > automated data binding, then you can declare the mac_managed_preferences > class as many times as you like, using the 'include' function. If you use > a resource-like class declaration, however, then it must not be evaluated > more than once. > > > >> or are we making a new class for each applications preferences (assuming >> that's the $applications variable in the class name)? >> > > > There is no variable in the class name. The class has a parameter named > $applications, but it is not part of the class name. You are already > supposing that there is a separate (and different) class for each managed > application, however. In fact, you are supposing that there is an entirely > separate *module* for each managed application. Class > mac_managed_preferences would be a single class, separate from all the > per-application classes. Whatever class or node block declares all the > per-application classes (and which therefore knows which ones are being > declared) would also declare class mac_managed_preferences. > > > Overall, you seem to be really struggling with a lot of fundamental Puppet > concepts. Puppet DSL is substantially unlike any programming language you > may have used (and indeed, it is not itself a programming language), so it > would be to your advantage to read the language reference section of the > Puppet reference manual <https://docs.puppetlabs.com/puppet/3/reference/>, > and to at least skim the resource type reference > <https://docs.puppetlabs.com/references/3.4.stable/type.html> and the > function > reference > <https://docs.puppetlabs.com/references/3.4.stable/function.html>. The > language reference is an easy read, and quite good. > > > John > > -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fb645c8d-bdd0-4a76-9d51-d80f3c213c34%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
