Issue #13031 has been updated by Stefan Schulte.
Puppet needs something to identify a resource to be able to check if a resource
is already present or currently absent. For the mailalias it is just the alias
name. It is not a combination of name and targetfile. So if you want the alias
X to be in file Y but it is currently present in file Z, puppet will move the
alias from one file to another saying that target is out of sync.
You have now defined two aliases with the same name and since puppet parses
both files it will get confused because puppet neeeds the name to be unique
across all files.
Note that in puppet >= 2.6.13 and puppet >= 2.7.3 (as of commit:fb2ffd6) you
will get a duplicate definition error message with your above manifest:
manifest similar to yours and ready for puppet apply:
<pre>
mailalias { 'foo':
ensure => present,
name => 'foo',
recipient => '[email protected]',
target => '/tmp/test1',
}
mailalias { 'not_foo_to_trick_puppet':
ensure => present,
name => 'foo',
recipient => '[email protected]',
target => '/tmp/test2',
}
</pre>
Error message:
<pre>
Puppet::Parser::AST::Resource failed with error ArgumentError:
Cannot alias Mailalias[not_foo_to_trick_puppet] to ["foo"] at /tmp/test.pp:12;
resource ["Mailalias", "foo"] already defined at /tmp/test.pp:6 at
/tmp/test.pp:12
</pre>
So one could argue that beeing able to define the same mailalias in more than
one file is more important than beeing able to move one mailalias from one file
to another but the current behaviour is what was choosen in the past:
http://groups.google.com/group/puppet-dev/browse_thread/thread/3e637c2ce543ce63
(see Luke's response)
----------------------------------------
Bug #13031: mailaliases
https://projects.puppetlabs.com/issues/13031#change-56392
Author: Andrew Ring
Status: Unreviewed
Priority: Normal
Assignee:
Category: mailalias
Target version:
Affected Puppet version: 2.6.2
Keywords:
Branch:
I thought I was being cleaver and used the mailaliases type to manage both the
/etc/aliases file and the /etc/email-addresses file on my systems as their
formating is the same for Exim4. (/etc/email-addresses needs to be managed due
to $work's email filtering rules.)
Unfortunately, when the "name" agrument is the same in both, the entry for
/etc/aliases is written repeatedly.
The following has been sanitized. Typos are possible.
>From script managing /etc/aliases:
mailalias { $user:
ensure => present,
name => $user,
recipient => $email,
notify => Exec["new_aliases"],
target => "/etc/aliases",
}
>From script managing /etc/email-addresses:
mailalias { from-${user}:
ensure => present,
name => $user,
recipient => $email,
target => "/etc/email-addresses",
}
Output from every puppet run is:
notice: /Stage[main]/Etc_email-addresses_$user/Mailalias[from-$user]/recipient:
recipient changed 'root' to '$email'
notice: /Stage[main]/Etc_email-addresses_$user/Mailalias[from-$user]/target:
target changed '/etc/aliases' to '/etc/email-addresses'
info: FileBucket adding /etc/aliases as {md5}ba206591fc3d135c8c1366deabfc0e00
info: FileBucket adding /etc/email-addresses as
{md5}1b8b12e534051e667d25353728421ca4
notice: /Stage[main]/Etc_aliases_sbgrid/Mailalias[$user]/ensure: created
/etc/aliases now reads:
$user: $email
$user: $email
$user: $email
$user: $email
$user: $email
/etc/email-addresses reads:
$user: $email
While for my issue I could revert to augeas scripts, this is unexpected
behavior.
I am running puppet version: 2.6.2-5+squeeze4
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
