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, [email protected] 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 [email protected]. 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.
