Re: Idea: making it easier to change DEBCONF_PRIORITY
[To all recipients: Please, if you're still interested in the topic,
subscribe to pkg-exim4-devel, and continue reading there. Reply-To:
is appropriately set.]
On Sun, May 28, 2006 at 04:55:42PM +0200, Wouter Verhelst wrote:
> On Sun, May 28, 2006 at 11:18:32AM +0200, Wouter Verhelst wrote:
> > On Sun, May 28, 2006 at 08:59:31AM +0200, Marc Haber wrote:
> > > I am open to suggestions. Back when the exim4 packages were developed,
> > > we mainly copied what exim 3 did and debconfed the questions.
> >
> > I'll try to come up with something.
>
> Okay, so I've been thinking about this for most of the day now. What
> I've come up with is the following. It would need to be implemented
> still, but I want to discuss the general idea before I come up with a
> proof-of-concept implementation (or even a proposed final
> implemenation).
>
> The current approach centers around `how is your system connected to
> other hosts on the Internet?'
>
> While this was highly relevant in the day the original exim v3 config
> script was written, I would submit that this is no longer the case --
> or, at least, that it is no longer as important as it used to be. The
> central question in these days of desktop users versus administrators of
> large domains is "do you have your own mail domain". Though it is
> possible to configure your system in case you do not have your own mail
> domain currently, it feels a bit as if it was added as an afterthought,
> and is making the system needlessly confusing IMO.
Agreed.
> I would therefore suggest that the first question asked is about whether
> or not the user has his own mail domain. Maybe not as a boolean; perhaps
> as a select question with "no", "yes (handled locally)", and "yes
> (handled remotely)" or so, where the option to handle mail locally
> should also be used to handle the case of no network connection.
Maybe it is a good idea to have a flow-chart of the new debconf
structure somewhere?
> It should also include an option "stay away from my mail
> configuration!", which should then exit the config script immediately,
> _without_ asking any further questions. One of the most serious gripes I
> have with the current configuration system is that if you say "do not
> configure anything about my mail system; I know it'll be broken, I'll
> fix it", it will _still_ ask you exim4/dc_postmaster and a few other
> questions.
Agreed, that's an unnicety.
> Something like the following template would work:
>
> Template: exim4/domain-type
> Type: select
> _Choices: no, yes (handled locally), yes (handled remotely), no configuration
> Default: no
> _Description: Do you have your own mail domain?
> An email address consists of two parts: the part before the `@' sign,
> known as the `local part' which has to be unique for every mail domain;
> and the part after the `@' sign, known as the `mail domain', which is
> to be globally unique.
> .
> The most common setup is for people to have an email address with their
> ISP or with a web-based mail provider. If this is the case for you,
> then you do not have your own mail domain; in that case, choose `no'.
> If you are not certain what to do, this is probably the right choice.
> .
> If you do have your own mail domain, and you want this system to handle
> it as its primary mailserver, then you should choose `yes (handled
> locally)' here. Every account on the system will then be an email
> address, for which mail will be stored on the local hard disk; it will
> be possible to create more email addresses through /etc/aliases.
> .
> This is also the option which you should choose if your computer is not
> connected to the Internet in any way; as for the mail domain for which
> you will be asked later on, you can make something up, so long as you
> make sure it ends in '.local'.
.local has no RFC backing :-(
> .
> If you have your own mail domain, but you want mail to be taken care of
> on another system, then you should choose `yes (handled remotely)'
> here. Choosing that option will result in all mail being sent off to
> another system. You must manually ensure that there is a valid email
> address configured on the remote system for all local accounts that may
> send mail, or that may (appear to) receive mail locally.
> .
> If you prefer to manually configure your mail system, then choose `no
> configuration'. Use of this option is not recommended except for
> experienced system administrators; it will render your mail system
> completely broken until you manually configure it.
Do we still have that 24-line limit for debconf questions asked during
installation?
This does not take care too well for the classic case of a host with a
fixed IP and its own FQDN, handling local mail for the FQDN. This is
probably a not too special case of "own mail domain".
> So, if the user then told you that they do not have their own domain,
> you'll need a way for local user names to be mapped to globally valid
> email addresses. This could perhaps be done through a dotfile in the
> user's home directory, where they can enter their globally valid email
> address; when the system then mails something to a remote system, it
> should rewrite headers such that mail sent through /usr/bin/sendmail has
> their return path set up properly so that recipients can just hit
> 'reply' and have it end up where expected. I'm suggesting a dotfile
> since that will allow every user to manage it for themselves; however,
> it might just as well be a system-wide file which then the sysadmin has
> to manage. It doesn't really matter all that much.
Maybe we can have both, with the global file overriding the local one.
> Still in the case of no local domain, the user might also have the
> choice of having all mail sent off to the 'net (in case they use webmail
> or prefer to use POP3 or IMAP4 to read their mail) or to have their mail
> stored locally (so that they can read it out of /var/mail; they will
> need to set up fetchmail to get it there, though). Perhaps give this
> question a lower priority and set the default to send it remotely; I
> expect that people doing mail through webmail and/or POP3-capable
> clients is far more common than people willing to set up fetchmail etc.
Probably, es.
> I think it's fair to say that systems with no mail domain will need a
> smarthost to handle remote mail.
Yes, and since SMTP AUTH has become commonplace, we'd probably need to
ask for authentication credentials.
> I propose to completely drop the "hiding the local mailname"; I suspect
> the above setup will handle most cases where hiding the local mailname
> is interesting, while it will also not make things needlessly
> complicated.
Sounds kind of sexy, but I don't know about its possible implications.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
Reply to: