Bug 117661 - /etc/aliases should merge all system wide aliases
/etc/aliases should merge all system wide aliases
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: postfix (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
David Lawrence
: FutureFeature, Tracking
: 90653 (view as bug list)
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-03-06 13:22 EST by Petri T. Koistinen
Modified: 2014-01-21 17:49 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-18 08:36:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
aliases only in postfix (332 bytes, text/plain)
2004-03-17 17:16 EST, John Dennis
no flags Details
aliases only in sendmail (610 bytes, text/plain)
2004-03-17 17:18 EST, John Dennis
no flags Details
aliases in both sendmail and postfix (204 bytes, text/plain)
2004-03-17 17:18 EST, John Dennis
no flags Details
patch for postfix-2.1.5-2.1, move alias_database in main.cf to correct place. (564 bytes, patch)
2004-10-17 06:47 EDT, Petri T. Koistinen
no flags Details | Diff

  None (edit)
Description Petri T. Koistinen 2004-03-06 13:22:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040122 Debian/1.6-1

Description of problem:
$ rpm -qf /etc/aliases
setup-2.5.31-1.1

$ rpm -qf /etc/postfix/aliases
postfix-2.0.16-13

Ok, where should the email aliases be defined? Is /etc/aliases correct
place what Postfix and Sendmail should support. Postfix has no problem
reading aliases from /etc/aliases if configured so.

So is this really a Postfix package bug, should it not provide
/etc/postfix/aliases or should setup package not provide /etc/alias at
all and let mail transport agents do that?

It's your call, but I think /etc/aliases as global place would be
better choice.

Version-Release number of selected component (if applicable):
setup-2.5.31-1.1

How reproducible:
Always

Steps to Reproduce:
1. Wonder where email aliases should be stored globally.
2. Note that Postfix package has own /etc/postfix/aliases file too.

Expected Results:  One place to define email aliases for all mail
transport agents.

Additional info:

Please, move this bug to Postfix package from setup if that is right
place.
Comment 1 Seth Vidal 2004-03-06 13:46:13 EST
How about we kill /etc/aliases entirely.

move sendmail's aliases to /etc/mail/aliases
postfix's in /etc/postfix/aliases

and no longer will there be an /etc/aliases.

then you could have an /etc/aliases determined by alternatives.
Comment 2 Petri T. Koistinen 2004-03-06 14:13:34 EST
How about other way around: /etc/mail/aliases and /etc/postfix/aliases
could be symbolic links to /etc/aliases.

That would allow you to switch between programs and aliases would
still stay same. This would also help keeping aliases consistent as
there is one file with actual data. File format is same for both programs.

I think that this approach would be more flexible.
Comment 3 Seth Vidal 2004-03-06 14:16:28 EST
The file format IS the same in the  default configuration, it does not
have to be. Postfix supports multiple filetypes for aliases.

I think separating the two is wiser anyway - application specific
aliases could crop up.
Comment 4 Petri T. Koistinen 2004-03-06 14:53:19 EST
We are talking default configuration, if you need something special,
I am sure you are able to set another file where special Postfix
specific aliases reside. You can use multiple aliases files with
Postfix. I agree that possibly there is no need for
/etc/postfix/aliases symbolic link to /etc/aliases at all. 

I think common scenario is that somebody is migrating from Sendmail to
Postfix. In order to make migration as smooth as possible _default_
Postfix configuration should be compatible with Sendmail. Following
principle of least surprise I think global email aliases should be in
/etc/aliases, as it has been de-facto email aliases place for years.

When you get more experienced with Postfix you can define that global
simple aliases are read from /etc/aliases and other more special
aliases are read from other files or data sources.
Comment 5 Bill Nottingham 2004-03-08 11:42:29 EST
/etc/aliases was moved from sendmail to setup so that postfix/exim
could use it - I assumed that postfix *was* using it by default.
Comment 6 Thomas Woerner 2004-03-08 11:55:58 EST
/etc/aliases is all the same for sendmail, exim and postfix. There is
no need for application specific aliases files. 

Postfix is/was using /etc/postfix/aliases file to not require
sendmail. Now we have the global /etc/aliases in setup, and postfix
can use this file without requireing sendmail. Sendmail was providing
/etc/aliases in the past.
Comment 7 Petri T. Koistinen 2004-03-08 12:30:37 EST
postfix-2.0.16-13 package comes with default in /etc/postfix/main.cf:
alias_maps = hash:/etc/postfix/aliases

Maybe this should be changed to:
alias_maps = hash:/etc/aliases

Moving bug to Postfix package...
Comment 8 Petri T. Koistinen 2004-03-08 12:36:49 EST
Oh, and /etc/init.d/postfix need fixing too
...
start() {
        # Start daemons.
        echo -n "Starting postfix: "
        /usr/sbin/postalias /etc/postfix/aliases
        /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure
...
there should be then /etc/aliases instead. Aside note, it's funny that
you "eat" postfix error messages.
Comment 9 Chris Ricker 2004-03-12 13:17:50 EST
Wrong, postfix *does* use additional aliases that sendmail / exim
don't, and that's why it's always been configured to use a separate
aliases file. It's not because /etc/aliases was formerly provided by
sendmail....

The mail difference is that root must be aliased for postfix because
of permissions / privilege separation issues from postfix's design.
Comment 10 Dax Kelson 2004-03-12 13:31:10 EST
As a datapoint, SUSE ships both Postfix and Sendmail and has one alias
file /etc/aliases.

Postfix is the default MTA on SUSE.
Comment 11 Chris Ricker 2004-03-12 13:38:40 EST
As do many other distributions which ship Postfix and something else.
Debian, for example, uses /etc/aliases w/ all MTAs

The real issue is whether RH wants a policy of always aliasing root's
email to non-root by default, since that's what using a single file
for all would require....
Comment 12 Bill Nottingham 2004-03-12 14:10:35 EST
And then, the issue of where to alias it *to*. Since, if you don't set
up another account....
Comment 13 Chris Ricker 2004-03-12 14:24:06 EST
That's the next political decision ;-)

Hmm, on second thought, that may have changed between Postfix 1 and
Postfix 2

RH's postfix aliases still sez:

# For various security reasons, postfix WILL NOT deliver mail as root, so
# ensure that the root alias is aliased to a HUMAN user, as otherwise
# mail may get delivered to the $default_privs user (nobody).

and then aliases root to "postfix" by default, but that might not
still be true.... I'll go check
Comment 14 Chris Ricker 2004-03-12 14:52:05 EST
Yep, it's still true with Postfix 2. Any external LDA gets run as the
user its delivering to. If it's delivering to a privileged user, the
LDA runs as $default_privs (ie, nobody), so non-aliased root users
can't get mail if you use an external LDA

If you use the Postfix 2 built-in LDA (instead of, say, procmail like
RH's sendmail configuration does), however, it can write to
/var/spool/mail/root (and presumably root Maildirs too).

In the past, RH has shipped Postfix with root aliased to postfix, and
using local (built-in LDA) instead of procmail. In keeping with that,
maybe the best solution would be just to skip the root aliasing, and
note in the release notes that it's no longer aliased, so enabling
procmail now requires more than just uncommenting the $mailbox_command
line in /etc/postfix/main.cf. That would solve the whole aliases and
root user email policy issue in the simplest way, unless I'm
overlooking any other reasons Postfix needed root to be aliased....
Comment 15 John Dennis 2004-03-15 11:57:11 EST
somehow I missed getting CC'ed on this, adding myself (as the rh
postfix maintainer)
Comment 16 Petri T. Koistinen 2004-03-15 12:02:05 EST
So are you going to move aliases to /etc directory in
/etc/postfix/main.cf file?

By the way Postfix 2.1 is soon released, I hope you have read this:
http://www.porcupine.org/postfix-mirror/newdoc/PACKAGE_README.html
Comment 17 John Dennis 2004-03-15 19:33:40 EST
My initial inclination would be to have /etc/aliases be a sym link to
/etc/postfix/aliases and be managed by alternatives. This provides the
easiest migration between MTA's and is consistent with much of RH's
other MTA configuration. It has the downside of having two alias files
with the possibility of having them get out of sync if people switch.
I think this is bad and will be a source of confusion, one alias file
is better I think. O.K. but this has the downside of not delivering
root mail with postfix, but unless someone has defined a root alias as
a human being in /etc/postfix/aliases and people won't generally do
this unless they are postfix aware so I don't think the root alias
issue is enough rational to keep a separate postfix alias file.

In summary, I think I'm in favor of a single /etc/aliases file and
configue postfix use this. I think this would make most people most
happy with the least amount of confusion.

Do others agree?
Comment 18 John Dennis 2004-03-17 13:19:46 EST
Today is the freeze date for FC2 and if we're going to make this
change it would be good to get it into FC2 today. 

Although it would be good to have one aliases file and I think that is
the right technical and product choice I'm concerned about the impact
on customers if we make this change. Here is my thinking, correct any
errors and provide your comments.

Installations that have been running postfix expect the aliases file
to be /etc/postfix/aliases, not /etc/aliases. If we move this file I
don't know of a good way to indicate the change other than via release
notes, which we all know nobody reads. I don't think there is anything
we can do during rpm installation to call attention to the change.

Although making /etc/postfix/aliases a link to /etc/aliases as an
interim solution would be an option I'm not 100% sure that's a good
choice either because /etc/postfix/aliases on an upgrade will probably
be present as a real file and contain user modifed data. I suppose we
could treat it like a %config file, move to
/etc/postfix/aliases.rpm.save and then link /etc/postfix/aliases to
/etc/aliases. The gives us one config file, preserves the legacy file
which transparently appears as the single aliases file, all of which
is good, except that in the past these config files have been
"noreplace" so we're effectively back in the same boat, which is if
the sys admin is not aware that we've changed things behind his back
he is likely to get nailed by this change. He/she will spend several
hours debugging it, and then flame us. We can always respond, "Did you
read the release notes?", but I'm not sure in practice thats going to
mitigate the irritation.

The other choice, which has less impact is to use alternatives to
selectively point to postfix/sendmail specific alias file. This has
the advantage of being transparent to the customer, but might result
in data integrity problems if the wrong file is edited or the MTA is
switched. But I think this is less obnoxious to the end user than
having his previosuly working aliases mysteriously stop working on an
upgrade. This also mitigates the "root alias" issue because it
preserves a postfix specfic alias file.

In summary my suggestion is:

1) preserve /etc/postfix/aliases, leave main.cf and the init script alone

2) have alternatives manage /etc/aliases, when postfix is the selected
mta it points to /etc/postfix/aliases, when sendmail is the selected
mta /etc/aliases points to ? (some yet to be determined file).

Think this has the least impact and sets us up for a future where
there is only one alias file as people get used to it.

Comments? Thoughts? Suggestions? Flames?

Bill, does this play well with the setup package, which is what this
was originally filed against?
Comment 19 Bill Nottingham 2004-03-17 14:05:58 EST
No, it really won't play well with setup owning /etc/aliases. It would
need to move back to sendmail.

Managing it via alternatives means that each MTA needs its own copy of
the aliases file, which would be a pain to keep in sync. Of course,
it's  not like the default alias file really changes that much.
Comment 20 John Dennis 2004-03-17 14:43:00 EST
Actually I didn't mean setup would own /etc/aliases, rather that it
would be managed by alternatives. The one issue that came to mind is
an order dependency, would the mta have been set by alternatives by
the time setup did anything that touched the alias file?

FWIW I'm not sure I agree the alias file rarely changes. What I do
think is a rare occurance is switching MTA's.

In theory we've passed the FC2 freeze by a few hours. I'm not sure
this issues has been thought out well enough to force the change into
FC2. Is it creating a significant issue that needs immediate
addressing as an FC2 blocker?
Comment 21 Bill Nottingham 2004-03-17 15:01:07 EST
Well, the only thing we ship that touches the aliases file is mailman.
Comment 22 Petri T. Koistinen 2004-03-17 15:23:19 EST
Kill /etc/postfix/aliases file.
alias_maps = hash:/etc/aliases

If postmaster can't figure that out, she/he shouldn't be allowed to
run mail server.
Comment 23 John Dennis 2004-03-17 17:15:08 EST
If we are going to go the route of merging postfix's and sendmail's
default alias file we should probably understand where they differ and
where they are the same. I'm attaching 3 files whose name should be
obvious as to what it lists.
Comment 24 John Dennis 2004-03-17 17:16:31 EST
Created attachment 98629 [details]
aliases only in postfix
Comment 25 John Dennis 2004-03-17 17:18:00 EST
Created attachment 98630 [details]
aliases only in sendmail
Comment 26 John Dennis 2004-03-17 17:18:59 EST
Created attachment 98631 [details]
aliases in both sendmail and postfix
Comment 27 Thomas Woerner 2004-03-18 05:02:02 EST
Please remember, that we have three mta's: exim, postfix and sendmail. 
To move /etc/aliases back to sendmail is not a good decision: exim and
postfix would require an installed sendmail. Exim and sendmail are
using exaclty the same aliases file. 
If postfix needs additional rules, then use an additional aliases file
for it, but common rules can reside in /etc/aliases (not owned by any
mta).
Comment 28 Petri T. Koistinen 2004-03-18 05:23:36 EST
Just merge all alias files to one.

More about required and suggested mailbox names:
http://www.ietf.org/rfc/rfc2142.txt
Comment 29 John Dennis 2004-03-18 16:48:00 EST
Thomas has a good point about a single aliases file. Files can only be
owned by one package, not multiple. Therefore some mta package has to
own the single /etc/aliases file and thus requires the installation of
that package even if the mta is not being used. This is not a good
design. I continue to believe what I advocated in comment #18 is the
preferred solution, which is: each mta has their own alias file,
/etc/aliases is a link maintained by alternatives to point to that
file.  If sys admins switch between MTA's there is the chance some
aliases will stop working. But any sys admin who is switching MTA's
around should be cognizant of the issues. It was Petri that said
earlie "If postmaster can't figure that out, she/he shouldn't be
allowed to run mail server."

Thomas and Bill, if you think this approach is O.K. just ACK, and I'll
edit postfix.spec so /etc/aliases is mananged by alternatives and when
postfix is configured /etc/aliases will point to /etc/postfix/aliases.

I believe this is the best approach. There are scripts/utilities out
there which make the assumption the alias file is /etc/aliases, this
way they can be ignorant of which MTA is configured.
Comment 30 Petri T. Koistinen 2004-03-18 17:11:02 EST
Hey, setup provides /etc/aliases, how can you provide alternative for
that in postfix package? Doesn't that conflict? Where does setup
installed /etc/aliases file go when postfix is installed? I still
think that one plain /etc/aliases file managed by setup package is
best for all. This would be a good default... Hey, did you read this
bug from the start at all?
Comment 31 Chris Ricker 2004-03-18 17:28:16 EST
John, just a couple of things to keep in mind:

of the aliases in postfix, but not in sendmail, the only one with
functional effect is the root one. All the others are either good
ideas for standards / ease-of-use (admin, for example) or for
historical reasons (falken), but only the root one will have impact on
how people use the package or are able to use the package

of the aliases in sendmail, but not in postfix, they should probably
be in postfix if they're going to be in sendmail. If RH thinks that,
say, the squid package is better integrated by aliasing the squid
address to something likely to be read, that should probably be done
for sendmail, postfix, and exim, not just sendmail

regarding Comment #29, files can be owned by multiple packages, as
long as the file is identical in each package. I'm not sure what that
fact gains you, though, in this case....

To me, the important issues here for keeping it separate are that:

* RH has shipped postfix using /etc/postfix/aliases for a while, so
there's an established usage
* aliasing root for postfix facilitates some common configurations /
interoperations with other software, and that's a long-standing
practice on RH as well

For uniting them:

* there's the obvious benefits in terms of packaging standardization
and such for just having one standard /etc/aliases for all MTAs
* there's simplicity for admins in standardizing common config files

If you do decide it's necessary to keep them separate, I think using
alternatives is likely to cause more confusion than just having both
/etc/aliases (for sendmail / exim) and /etc/postfix/aliases (for
postfix). After all, having both is what happened on previous RH
releases if you had both sendmail and postfix installed, and people
seemed to manage. The only difference now is that it would happen even
if you had just postfix installed....
Comment 32 Petri T. Koistinen 2004-03-21 08:18:25 EST
I think setup package should merge all system wide default aliases to
/etc/aliases file. Moving back to setup.
Comment 33 Bill Nottingham 2004-09-23 01:01:12 EDT
Aliases from the postfix-only list that are in rfc2142 merged as of
setup-2.5.34. I do not feel that missing 'foo' or 'falken' aliases are
a holdup. Back to postfix. :)
Comment 34 Thomas Woerner 2004-10-08 06:58:01 EDT
/etc/aliases contains now
  abuse:          root
  abuse:          postmaster

This is not allowed. Assigning to setup.
Comment 35 Bill Nottingham 2004-10-08 11:43:06 EDT
Fixed, just the alias to root is there now.
Comment 36 Thomas Woerner 2004-10-15 06:53:33 EDT
Fixed in rawhide in rpm postfix-2.1.5-2 or newer: Switched over to
/etc/aliases and /etc/aliases.db.
Comment 37 John Dennis 2004-10-15 11:07:57 EDT
Thomas: Does this mean the default main.cf that gets installed will
now have the alias file as hash:/etc/aliases instead of
hash:/etc/postfix/aliases and main.cf is marked as config noreplace so
as not to break existing installations? I ask in particular because
when mailman is configured to use postfix as its MTA it automatically
updates aliases which default to /etc/postfix/aliases unless
overridden by a config file edit. I want to make sure this doesn't
break. By any chance is /etc/postfix/aliases sym linked to
/etc/aliaes? Does /etc/postfix/aliases continue to exist, or has it
been completely removed?
Comment 38 Thomas Woerner 2004-10-15 11:20:35 EDT
Yes, there is 'alias_database = hash:/etc/aliases' in main.cf which is
config noreplace in the spec file.

No, /etc/postfix/aliases is not sym linked to /etc/aliases. I have
removed it completely. If there is really a need for a symlink for
aliases (and aliases.db ?), then I can put it in.
Comment 39 Matthew Miller 2004-10-15 11:42:26 EDT
I think Mailman should be fixed to not make that incorrect assumption.
Comment 40 John Dennis 2004-10-15 12:35:01 EDT
O.K. great, as long as its config noreplace nothing should break. I
don't think there is a need for a symlink, that only prolongs the
transition period, better if there is no file there which will force
folks to notice the change.

I will alter the default postfix alias file in the mailman config to
reflect this new Red Hat standard.
Comment 41 Thomas Woerner 2004-10-15 13:09:45 EDT
But there is a change in the init script in the postalias call. It is
using /etc/aliases, now. 

I think alias_database could be used for this:

	echo -n "Starting postfix: "
	alias_database=$(postconf -h alias_database 2>/dev/null)
	alias_database=${alias_database##hash:}
	[ -z "$alias_database" -o ! -f "$alias_database" ] && {
	    failure
	    echo
	    return 0
	}
	/usr/sbin/postalias $alias_database
	...

Is this ok for you?
Comment 42 Petri T. Koistinen 2004-10-15 13:30:47 EDT
It's good idea, but where can you see error message, as there is
nothing in /var/log/maillog and you see just mysterious start up
failure. Printing error message on screen would be good idea.

At start of script #!/bin/sh could be changed to #!/bin/bash to be
more explicit.
Comment 43 John Dennis 2004-10-15 15:52:01 EDT
FYI: I spoke in error in comment #37, the postfix alias file DOES NOT
appear in the mailman config. Rather it is the /usr/sbin/postalias and
/usr/sbin/postmap commands that appear in the mailman configuration
file and these have not changed. The mailman admin must edit
/etc/postfix/main.cf and add the mailman alias file to the postfix
alias_map variable. It just so happens this is the same postfix
variable that sets the postfix alias file path and although this
changed the change does not effect the mailman part of that variable
setting. Therefore there is nothing in mailman that needs fixing to
accomodate the change in the postfix alias file. I was wrong, sorry
for the red herring.
Comment 44 Petri T. Koistinen 2004-10-17 06:47:03 EDT
Created attachment 105348 [details]
patch for postfix-2.1.5-2.1, move alias_database in main.cf to correct place.
Comment 45 Thomas Woerner 2004-10-18 08:36:57 EDT
Fixed in rawhide in rpm postfix-2.1.5-2.2 or newer.
Comment 46 Nicolas Mailhot 2004-10-18 17:31:24 EDT
However the fix silently kills postfix on updates, since the old alias
file is removed *but* is still configured in main.cf since main.cf is
config(rpmsave)

Postfix will say it's running but won't deliver any mail
Comment 47 Thomas Woerner 2004-10-19 04:18:54 EDT
No, main.cf is config(noreplace):

%attr(0644, root, root) %config(noreplace) %{postfix_config_dir}/main.cf
Comment 48 Nicolas Mailhot 2004-10-19 07:18:21 EDT
Sory, that what I intended to write;)

Anyway the end result on a postfix upgrade is
- old main.cf is preserved (as it should be since it is often heavily
customized), pointing /etc/postfix/aliases*
- rpm removes the referenced alias file
- any mail delivery will now fail since postfix will consider it has
been asked to resolved addresses using /etc/postfix/aliases*, and this
is not available
Comment 49 Thomas Woerner 2004-10-19 09:11:50 EDT
There is a check in the newest version of postfix (postfix-2.1.5-2.2)
not to start if postalias is failing.
Comment 50 Nicolas Mailhot 2004-10-19 10:19:21 EDT
Ok, didn't test this one;), thanks
Comment 51 John Thacker 2007-01-12 10:21:38 EST
*** Bug 90653 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.