I did the following to see if it would work, and I got (for me anyway) a
surprising result. It may be the source of some of my confusion and reason
why I'm finding this so difficult. Note, I don't want to do this this way.
I just did it as an experiment.
define mac_managed_preferences ($source) {
include managed_preferences
file { "/System/Library/User
Template/English.lproj/Library/Preferences/${source}" :
source => "puppet:///modules/${source}/Preferences/",
owner => "root",
group => "wheel",
mode => "600",
recurse => "true",
}
exec { "Move Preferences":
command => "mv $source/* ../Preferences/",
path => "/bin",
cwd => "/System/Library/User
Template/English.lproj/Library/Preferences/",
require => File["/System/Library/User
Template/English.lproj/Library/Preferences/${source}"],
}
exec { "Delete Folder":
command => "rm -rf $source",
path => "/bin/",
cwd => "/System/Library/User
Template/English.lproj/Library/Preferences/",
require => Exec["Move Preferences"],
}
}
Here is the relevant portion of the module that installs the application.
mac_managed_preferences { "$module_name":
source => "$module_name",
}
I got an error: Duplicate declaration [Move Preferences] is already
declared in file (path to managed_preferences file) cannot redeclare at
(path to same file). In my previous posts I said that I though that I
accessed the module multiple times, but declared it once, but this message
is making me understand that puppet says I was declaring it multiple times,
but I am unsure how. I know two modules are accessing it, but felt that
was what I was supposed to do. To make things more confusing, the command
has a variable in it (which is why it didn't error on the file part), but
the working directory is static and is causing the problem. But what if my
command was just "ls" would it complain about the same cwd when it would
cause no harm? How does puppet know what my command would do anyway? What
am I not understanding in this example that is causing the redeclaring
error? Is it the same principle in the other posts where the file resource
was causing the problem?
On Monday, September 22, 2014 2:58:52 PM UTC-5, aar...@gmail.com wrote:
>
> Thanks Neil,
>
> In yours and Johns example you both have ${title} at the end of
> Preferences. When I tried this (after his post, I haven't tried your code
> yet), I ended up with a folder called Preferences/office_2011 which defeats
> the purpose of what I am trying to do. Am I misunderstanding that line? I
> understand why two modules can't manage the same folder (from a Puppet
> perspective) but was thinking that all of my modules would send a list of
> files to the one module that had the ability to write to that folder and it
> would work.
>
> I really appreciate everyone trying to help me, but I guess there is
> something that I am not understanding, or perhaps I am not explaining
> myself properly. If I have a variable after Preferences (which I need to
> prevent the duplicate resource) then how do I get all of my files into the
> root of that Preference folder?
>
> I apologize if your code works the way I am asking, but if it does, then I
> don't understand what the variable is doing after the word Preference and
> could use some clarification on that. Also, what is the $components
> variable mean? Is that a type of function or feature that I can read up on
> in the documentation?
>
>
>
> On Monday, September 22, 2014 2:27:44 PM UTC-5, Neil - Puppet List wrote:
>>
>> Hello
>>
>> I do not think that is possible or really desirable. Puppet is about
>> desired state so you can not say the directory should both be
>> /pathtodir
>> ├── fileA
>> └── fileB
>>
>> and /tmp should be
>> /pathtodir
>> ├── fileB
>> └── fileC
>>
>> as the first says must not have fileC and the second says must have
>> fileC. Those are conflicting.
>>
>> Back to what you could do, which is to write to two separate directories
>> and then merge them together with a separate command that is triggered by
>> either directory changing. But you should not go down that route especially
>> in a situation like this where you can specify exactly what files you want.
>>
>> Going to your original post what you are trying to do is write the
>> preferences for a particular application in the User Template for that
>> application. Trouble is, looking on my mac, there are multiple plist files
>> there for each application
>>
>> so transform your
>> file { "System/Library/User Template/English.lproj/Library/Preferences/":
>> source => "puppet:///modules/office_2011/Preferences",
>> owner => "root",
>> group => "wheel",
>> mode => 600,
>> recurse => true,
>> require => Package["$main_package"],
>> }
>>
>> into
>>
>> $components = ['com.microsoft.Excel.plist',
>> 'com.microsoft.Outlook.plist',]
>>
>> macprefs::usertemplate{ $components:
>> require => Package[$main_package],
>> sourcebase => 'puppet:///modules/office_2011/Preferences',
>> }
>>
>> (or that can be wrapped up into a define for this set of prefs,)
>>
>> now you need to implement macprefs::usertemplate. (I've ignored the
>> language/locale issue which could complicate matters)
>>
>> so now you make a module and in there you do similar things to John's
>> post
>>
>> in a file macprefs/manifest/init.pp start by making "/System/Library/User
>> Template"
>>
>> class macprefs {
>> # A shared resource:
>> file { '/System/Library/User Template/English.lproj/Library/Preferences
>> ':
>> ensure => 'directory',
>> owner => 'root',
>> owner => 'wheel',
>> mode => '0700'
>> }
>> }
>>
>> in a file macprefs/manifest/usertemplate.pp
>>
>> define macprefs::usertemplate($sourcebase, $require) {
>> # relies on the preferences base directory:
>> include 'macprefs'
>>
>> # A file in the templates directory:
>> file { "/System/Library/User Template/English.lproj/Library/Preferences
>> /${title}":
>> ensure => 'file',
>> source => "$sourcebase/$title",
>> require => $require,
>> owner => 'root',
>> group => 'wheel',
>> mode => '0600'
>> }
>> }
>>
>> ----
>> Neil
>>
>> On 22 September 2014 17:30, <aar...@gmail.com> wrote:
>>
>>> Thanks John,
>>>
>>> By putting the /etc/preferences/${title} in the file line, aren't you
>>> putting a subfolder in the preferences folder on the puppet agent? I tried
>>> to follow your example and it happened to me.
>>>
>>> What I am looking to do is to have different modules writing into the
>>> base folder, in your example "/etc/preferences/". The modules won't ever
>>> have the same file names, so overwritting isn't a concern.
>>>
>>> Is this possible?
>>>
>>>
>>> On Monday, September 22, 2014 9:33:04 AM UTC-5, jcbollinger wrote:
>>>>
>>>>
>>>>
>>>> On Saturday, September 20, 2014 2:33:34 PM UTC-5, aar...@gmail.com
>>>> wrote:
>>>>>
>>>>> Thanks Neil,
>>>>>
>>>>> I am not sure I understand exactly what you mean, so I will post the
>>>>> code I have done for testing (I am using different paths, but the concept
>>>>> is the same as the original post).
>>>>>
>>>>> Here is the class with the define. It is in a module called
>>>>> copy_directory.
>>>>>
>>>>> class copy_directory {
>>>>> }
>>>>>
>>>>> define managed_preferences ($source = undef) {
>>>>> file {"/tmp/":
>>>>> source => "puppet:///modules/${source}/tmp",
>>>>> recurse => true,
>>>>> owner => "root",
>>>>> group => "root",
>>>>> mode => 600,
>>>>> }
>>>>> }
>>>>>
>>>>> Here is the module that calls it.
>>>>>
>>>>> include copy_directory
>>>>>
>>>>> class test_module {
>>>>> managed_preferences { 'title':
>>>>> source => "$module_name",
>>>>> }
>>>>> }
>>>>>
>>>>> I also created a module called test_module2 with the same code. I
>>>>> know that file {"/tmp/": is causing the problem, but the entire point is
>>>>> different modules copy files into that directory. To me I'm defining it
>>>>> once, and using it twice. As I defined it in the copy_directory module,
>>>>> and I am using it in the test_module and test_module2. What am I doing
>>>>> wrong?
>>>>>
>>>>>
>>>>
>>>> A class may be declared multiple times (though the resource-like
>>>> syntax, if used, must be the first one evaluated), with the same effect as
>>>> declaring it just once. That is, classes are idempotent. Ordinary
>>>> resources, including defined-type instance, may be declared only once.
>>>> Given that defined types are usually meant to allow multiple instances, it
>>>> follows that defined type instances must declare only resources that
>>>> wholly
>>>> belong to them; they must not not declare shared resources. Instead, they
>>>> can rely on a class to declare the shared resources.
>>>>
>>>> For example:
>>>>
>>>> class my_module::preferences_base {
>>>> # A shared resource:
>>>> file { '/etc/preferences':
>>>> ensure => 'directory',
>>>> owner => 'root',
>>>> owner => 'group',
>>>> mode => '0644'
>>>> }
>>>> }
>>>>
>>>> define my_module::preference_file($source) {
>>>> # relies on the preferences base directory:
>>>> include 'my_module::preferences_base'
>>>>
>>>> # A file in the preferences base directory:
>>>> file { "/etc/preferences/${title}":
>>>> ensure => 'file',
>>>> source => $source,
>>>> owner => 'root',
>>>> owner => 'group',
>>>> mode => '0644'
>>>> }
>>>> }
>>>>
>>>>
>>>> That should also work if the the shared directory is managed
>>>> recursively, or if the defined type declares a directory instead of a file
>>>> -- even a recursively managed one. Does that help?
>>>>
>>>>
>>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/99ac011e-153b-4675-825f-575fd81bf911%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/puppet-users/99ac011e-153b-4675-825f-575fd81bf911%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
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/309bf8c3-5673-4827-894f-545bef118965%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
