mailalias type: automatic rebuild of aliases.db?

[John Ingersoll]

HI,

All our unix boxes under puppet are configured with the 'mailalias' resource type as in :

mailalias { "root":
             recipient => "linuxroot@fqdn",
             ensure => present
}

The majority of those boxes however don't have /etc/aliases served out by puppet, rather, they simply have the installed default /etc/aliases locally.

I'm working on a couple of boxes within that set that have custom /etc/aliases served out from puppet, and have with that a notify => Exec [newaliases]. No problem there.

It's being reported that the other unix boxes aren't getting their /etc/aliases.db rebuild when /etc/aliases changes. I'm guessing that just having the newalias type doesn't ensure the newaliases command gets run.

If that's true, should I have another exec { "othernewaliases": with something like onlyif => [test /etc/aliases -nt /etc/aliases.db ] ?

Or rather insist that all such boxes have their aliases file maintained by Puppet?

Thanks

--
John Ingersoll, Jr.
Usage: fortune -P [] -a [xsz] [Q: [file]] [rKe9] -v6[+] dataspec ... inputdir

[Matthew Hyclak]

On Wed, Sep 23, 2009 at 10:21 AM, John Ingersoll <jh.ing...@gmail.com> wrote:
> HI,
>
> All our unix boxes under puppet are configured with the 'mailalias' resource
> type as in :
>
> mailalias { "root":
>              recipient => "linuxroot@fqdn",
>              ensure => present
> }
>
> The majority of those boxes however don't have /etc/aliases served out by
> puppet, rather, they simply have the installed default /etc/aliases locally.
>
> I'm working on a couple of boxes within that set that have custom
> /etc/aliases served out from puppet, and have with that a notify => Exec
> [newaliases]. No problem there.
>
> It's being reported that the other unix boxes aren't getting their
> /etc/aliases.db rebuild when /etc/aliases changes. I'm guessing that just
> having the newalias type doesn't ensure the newaliases command gets run.
>
> If that's true, should I have another exec { "othernewaliases": with
> something like onlyif => [test /etc/aliases -nt /etc/aliases.db ] ?
>
> Or rather insist that all such boxes have their aliases file maintained by
> Puppet?
>

We do the following:

class mail::aliases {
file {
"/etc/aliases" :
mode => 644,
owner => "root",
group => "root",
alias => 'aliases';
}

exec {
"newaliases" :
command => "/usr/bin/newaliases",
refreshonly => true,
subscribe => File['aliases'];
}
}

So /etc/aliases is defined as a resource, however no contents are
actually managed. You could use this on nodes where you don't want to
manage the contents of the alias. We have another class that is
included on some machines that sets the root forwarding in
/etc/aliases just like your example did.

Matt

[John Ingersoll]

On Thu, Sep 24, 2009 at 8:06 AM, Matthew Hyclak <hyc...@gmail.com> wrote:

On Wed, Sep 23, 2009 at 10:21 AM, John Ingersoll <jh.ing...@gmail.com>

-snip-

We do the following:

class mail::aliases {
 file {
   "/etc/aliases" :
     mode => 644,
     owner => "root",
     group => "root",
     alias => 'aliases';
 }

 exec {
   "newaliases" :
     command => "/usr/bin/newaliases",
     refreshonly => true,
     subscribe => File['aliases'];
 }
}

So /etc/aliases is defined as a resource, however no contents are
actually managed. You could use this on nodes where you don't want to
manage the contents of the alias. We have another class that is
included on some machines that sets the root forwarding in
/etc/aliases just like your example did.

Matt

 

Thanks, sounds exactly like what I need. It looks like, although the file resource is not managing content, it can still send events based on local (puppet-client) file changes (which I didn't realize).
--
John Ingersoll, Jr.