Bug 143437 - configure root mail alias to source /etc/rootalias (or /etc/mail/rootalias)
configure root mail alias to source /etc/rootalias (or /etc/mail/rootalias)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
David Lawrence
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-20 15:10 EST by Matthew Miller
Modified: 2010-08-24 15:52 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-23 11:02:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2004-12-20 15:10:09 EST
The problem:

Root's mail needs to somehow get to an actual user account so it can be read by
a human being instead of just collecting in a mail spool. Having anaconda,
firstboot, or some other tool configure an alias for root is an eventual goal.

However, having a program which attempts to edit /etc/aliases is a bit scary.
It'd be handy if, instead, there were a small simple file containing the root
alias. Therefore, I suggest putting this in /etc/aliases:

  root:           :include: /etc/rootalias

and then programs like firstboot could drop the proper information into that file.

Configuring the aliases file this way should be a non-intrusive change, and will
make more advanced functionality easier later.
Comment 1 Bill Nottingham 2004-12-22 18:11:48 EST
And if that file isn't there....? (considering all possible MTAs)
Comment 2 Matthew Miller 2004-12-22 18:25:59 EST
A default file should be provided by 'setup'. (Since setup owns /etc/aliases.)

We've been doing this at BU for a while now and it works pretty well.

Comment 3 Matthew Miller 2004-12-22 18:27:46 EST
As for what MTAs do if someone would actually for some reason delete the file: I
obviously can't check _all_ possibilities, but sendmail and postfix both bounce
mail back to sender with a pretty clear error explaining that the included file
can't be found, and both write this to the maillog as well.

But I'm not sure why we'd be any more worried about this than we would be about
someone deleting /etc/aliases itself....
Comment 4 Phil Knirsch 2006-01-25 10:21:37 EST
Well, /etc/aliases in contrast to /etc/rootalias or /etc/mail/rootalias is very
common and every UNIX sysadmin knows about it. An overeager sysadmin would
rather delete /etc/rootalias than /etc/aliases.

So i'm not conviced this is a real good idea tbh as i don't really see the big
advantage of doing that.

The more proper way would be to have a directory /etc/aliases.d and put the
various aliases files in that dir. Afaik no MTA can handle that though, so all
MTSs would need to be patched and thats very undesirable if it's not done
upstream as well.

Maybe if the MTAs can handle it in the future we can make this change, but right
now i just don't see it as the right way.

Read ya, Phil
Comment 5 Matthew Miller 2006-01-25 10:33:52 EST
/etc/aliases.d *would* be nice. 

But as far as I know, the MTAs *do* all include the ability to include other
files, and it's pretty standard to do so. As I mention in comment #3, if the
file isn't there, the MTAs we ship do a good job of telling you what's wrong.
And really, overeager or not, pretty much all sysadmins are going to expect
something to break if they delete arbitrary files from /etc.

This is a configuration change, not a code patch, and it's a configuration
supported by all our MTAs without doing anything weird. The big advantage is
that the included file becomes a simple one that can be managed easily by a
program. (With just a list of addresses rather than the full /etc/aliases syntax.)

Do you have another suggestion for dealing with making sure root's mail is
aliased to somewhere useful? I really don't like some config program mucking
with the main /etc/aliases file....
Comment 6 Phil Knirsch 2006-01-25 11:09:46 EST
Yeah, i understand what you want to achive, Matthew. And belive me, i've seen
more than 1 sysadmin eagerly deleting files he didn't know from /etc (to "clean
up the system"...).

Anyway, the problem i see is that the imho right solution would be
/etc/aliases.d, but according to our sendmail guy our sendmail most likely can't
do it by default currently. Also take into account that a lot of tools might not
understand the /etc/aliases.d syntax, so this would probably require quite a bit
of work and again, without upstream buyin this is just not going to happen.

And the solution with the include is tricky because postfix seems to behave
rather strangely sometimes when it comes to those includes, so this isn't a real
working solution either and doesn't really solve the problem because the config
tool then might munge the include directive and you'd be out of a valid root
alias again, so nothing won there.

And doing a halfhearted solution isn't the way i want to do it, so until there
is a clean way to do it for all MTAs and tools i'll stick with what we currently
have.

Read ya, Phil
Comment 7 Matthew Miller 2006-01-25 11:22:00 EST
We've been using the includes with postfix for a couple of years now, without
any problem -- what's the "rather strangely" you see?

The config tool wouldn't touch the include directive -- it's just there in the
file, with a comment that if you remove it, the rootalias management tools won't
work. (Those tools should check for the include, but not try to do anything with
it.) The config tool then only needs to write the included file, which has a
very simple syntax. This seems like a huge win to me.

But okay, enough discussion; we'll have to keep maintaining this as our local
configuration.
Comment 8 Matthew Miller 2008-09-25 15:29:01 EDT
Reopening -- there's relevant discussion on fedora-devel list this week.
Comment 9 R P Herrold 2008-09-25 17:18:43 EDT
does comment 6 still apply?
Comment 10 Arthur Pemberton 2008-10-01 14:00:53 EDT
Should this be marked as a duplicate of Bug 135592 ?
Comment 11 Matthew Miller 2008-10-01 14:08:32 EDT
> Should this be marked as a duplicate of Bug 135592 ?

No. This step can be done before that one and is largely separate. It could be marked as a blocker, though. (The patch in that bug would then need to be correspondingly updated.)
Comment 12 Ondrej Vasik 2008-12-09 10:07:26 EST
Just to clarify reopenning by comment #8 - could you please add link to thread with that discussion? Got setup maintainance ~1 month ago and I failed to find the thread by just quick look to September 2008 fedora-devel-list archives. TIA.
Comment 13 Ondrej Vasik 2009-06-23 11:02:33 EDT
Discussed with current sendmail maintainer a bit. I guess the best way would be to close that bugzilla - you could always add that include to /etc/aliases yourself. I don't see anything wrong on editing /etc/aliases by anaconda - as anaconda already edits some critical files... Closing WONTFIX as there is no activity for quite a long time...
Comment 14 Matthew Miller 2009-06-23 11:09:11 EDT
I'll leave closed for now, but this may still need to become part of a future feature, and still seems a) much easier than implementing /etc/aliases.d in all the MTAs, b) much cleaner than not doing anything, and c) very easy.
Comment 15 Ondrej Vasik 2009-06-24 03:28:05 EDT
Yep, I see your point, generally I'm ok with it, but first it would be good to have /etc/rootalias or /etc/mail/rootalias generally accepted by at least some of major Linux distros (Gentoo,Debian,SuSe) - to not create another RedHat-specific behaviour/file.

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