Puppet

I don’t think we can ever rebuild aliases by default, because the command varies. We could, however, set up relationships to the appropriate command, I think.

Replying to [comment:2 luke]:

I don’t think we can ever rebuild aliases by default, because the command varies. We could, however, set up relationships to the appropriate command, I think.

Maybe I don’t fully understand the architecture here, but could this be done with different “providers”?

Also, it was my impression that all the most-used mail packages used “newaliases” – am I wrong?

At least postfix uses ‘postalias /etc/aliases’, right?

And I don’t think it could be done with providers, since you’d need a new provider for every type of newaliases command.

Replying to [comment:4 luke]:

At least postfix uses ‘postalias /etc/aliases’, right?

That is the ‘postfix way’ of doing it, but postfix also provides a ‘newaliases’ command in the interest of compatibility. Qmail and exim both also provide a ‘newaliases’ command. I think we could handle 80% of cases just by calling ‘newaliases’…

And I don’t think it could be done with providers, since you’d need a new provider for every type of newaliases command.

Again, maybe my ignorance is showing here, but we also have to have a new provider for every type of package installation, right?

The problem with just using @@newaliases@@ is that it entrenches what is already a backward-compatibility problem. Better to remain flexible and decoupled.

As to having new providers, we’ve already got an /etc/aliases provider — we can’t have different providers for the provider. Only /etc/aliases needs to have the aliases db rebuilt; if you’re using ldap or whatever for aliases, you don’t need it. So, using different providers here would mean having parsed+postfix and parsed+sendmail providers, for instance.

Replying to [comment:6 luke]:

The problem with just using @@newaliases@@ is that it entrenches what is already a backward-compatibility problem. Better to remain flexible and decoupled.

That definitely makes sense. I agree.

As to having new providers, we’ve already got an /etc/aliases provider — we can’t have different providers for the provider. Only /etc/aliases needs to have the aliases db rebuilt; if you’re using ldap or whatever for aliases, you don’t need it. So, using different providers here would mean having parsed+postfix and parsed+sendmail providers, for instance.

This also makes sense, thank you for clearing that up :–)

Could someone maybe add the “notify” attribute to the mailalias type? At least then we could work around the issue by using a custom exec which could be notified when the alias file is updated.

Out of curiosity, why aren’t notify and subscribe part of the base inherited attributes?