Red Hat Bugzilla – Bug 143437
configure root mail alias to source /etc/rootalias (or /etc/mail/rootalias)
Last modified: 2010-08-24 15:52:14 EDT
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.
And if that file isn't there....? (considering all possible MTAs)
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.
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....
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
/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....
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
Read ya, Phil
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
Reopening -- there's relevant discussion on fedora-devel list this week.
does comment 6 still apply?
Should this be marked as a duplicate of Bug 135592 ?
> 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.)
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.
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...
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.
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.