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.
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 have. 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 configuration.
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.