RFC: Install script/DNAT

[Baylink]

The install script, as I've been discussing here, isn't all that well behaved in situations where the mail server lives behind a NAT box.

I'd like to propose how it ought to work, for comment, and if everyone agrees, then someone can patch the script.

Currently, the script appears to assume that the FQDN that the machine knows itself by is the domain name for which it will process mail, and that's almost never correct.

It's *often* correct to lop off the first element, and assume that.

That adjustment made, the install script should probably ask if it's assumption about the domain is correct (it might not be: franklink.corp.example.com might be the mail server for example.com), and once it's got the right idea, *then* is should check to see that a) it can find an MX record for that domain and b) that MX record points back to it's local interface IP.

In the long run, it would be nice to figure out why the mail server *needs* an MX record for the domain... but I suspect that's postfix-expert territory.

Anybody know any reasons why this would not be a suitable modification to the installer?

[brian]

The default behavior is to use FQDN for the mail domain. It attempts to verify an MX record pointing at the IP for which that FQDN resolves, if it doesn't find an MX it prompts to change the domain name. Even if it finds an MX record you can change the default domain name that gets provisioned under

Option 2) zimbra-ldap

Ldap configuration

1) Status: Enabled
2) Create Domain: yes
3) Domain to create: kaos.corp.yahoo.com


You could debate the merits of FQDN vs domain.tld forever, we chose to use FQDN, verify the MX and let you change it to fit your needs. I believe this also addresses your needs so no need for modifications.

[Baylink]

The default behavior is to use FQDN for the mail domain.

You could debate the merits of FQDN vs domain.tld forever, we chose to use FQDN, verify the MX and let you change it to fit your needs. I believe this also addresses your needs so no need for modifications.

Well, no it doesn't.

And I've been *administering* mail forever (since at least 1987, and perhaps back as far 1983), and I can tell you that if the FQDN of the mail machine is the proper answer for the domain name, someone has screwed up very badly, at least 98% of the time.

Hosts should almost never be named to match a basename of a domain. These days, it's almost unavoidable, because users are too stupid to type "www.", but it still causes problems. Any other machine should have a valid name subordinate to the 2LD or 3LD in question.

Hence, using the FQDN of the mail server is almost always the wrong decision.

If you'd like, I'll go ask Cricket Liu and Paul Vixie (among others) for better reasons why... :-)

[dijichi2]

Well, no it doesn't.

yes it does, just not in the particular way you want it to. I personally agree with you, it seems silly and confusing to the less experienced to take the fqdn as the mail domain and do dns verification against that, in 99% of cases it will be fqdn minus the hostname that should be used. this has nothing to do with being behind NAT, btw, it's just as valid on a public address.

however, all you have to do is ignore the installers DNS questions and install anyway, then add a proper domain in afterwards, or else change the domain at install time. either works well, if left as the default FQDN you also end up with an administrator account in a seperated domain that is unlikely to be used for other purposes - which is probably a good thing.

And I've been *administering* mail forever (since at least 1987, and perhaps back as far 1983), and I can tell you that if the FQDN of the mail machine is the proper answer for the domain name, someone has screwed up very badly, at least 98% of the time.

Hosts should almost never be named to match a basename of a domain. These days, it's almost unavoidable, because users are too stupid to type "www.", but it still causes problems. Any other machine should have a valid name subordinate to the 2LD or 3LD in question.

hosts should never be named to a 'base' domain, they should always have a proper fqdn or subdomain record of the authoritative domain they are a part of. an origin A record should always be set in DNS for lazy/stupid(/normal) users who type domain.com in a web browser instead of Register a Domain, Find Hosting and Create a Website at Domain.com. this is standard good webmaster practice, but nothing to do with naming a host or the point at hand here.

there's no point puffing your chest out and wading in here trying to teach zimbra to suck eggs when you don't have a good understanding of how the product works. zimbra has extremely experienced development team who I wager understand dns better than you.

however, i agree with the main point you're trying to make.

If you'd like, I'll go ask Cricket Liu and Paul Vixie (among others) for better reasons why... :-)

i expect they've got better things to do.

As always with opensource, if you don't like something, don't bitch, FIX IT. Submit a patch with better behaviour. It's been on my todo list for about a year to do this particular patch, just never got round to it cos it's not really that important.

[Baylink]

yes it does, just not in the particular way you want it to.

OP: I believe this also addresses your needs so no need for modifications.

Me: Well, no it doesn't.

IE: huh?

I personally agree with you, it seems silly and confusing to the less experienced to take the fqdn as the mail domain and do dns verification against that, in 99% of cases it will be fqdn minus the hostname that should be used. this has nothing to do with being behind NAT, btw, it's just as valid on a public address.

True. We just happened to be in that context when it came up

however, all you have to do is ignore the installers DNS questions and install anyway, then add a proper domain in afterwards, or else change the domain at install time.

Well, that's all *you* have to do, because you know about the problem and how to fix it.

I, on the other hand, wasted almost 2 hours on it, *precisely because I know how it's supposed to work*.

Nothing annoys me more than penalizing the smart people *because* they're smart.

either works well, if left as the default FQDN you also end up with an administrator account in a seperated domain that is unlikely to be used for other purposes - which is probably a good thing.

That's probably the only *good* reason I have heard to leave it that way, honestly.

Ok, no; I misread that. Yeah, that's not bad, but what I *thought* you meant was "if the user just takes the default, the installed server will fail to work without breaking other stuff", which would be good if it were true, but I don't think it is.

hosts should never be named to a 'base' domain, they should always have a proper fqdn or subdomain record of the authoritative domain they are a part of. an origin A record should always be set in DNS for lazy/stupid(/normal) users who type domain.com in a web browser instead of Register a Domain, Find Hosting and Create a Website at Domain.com. this is standard good webmaster practice, but nothing to do with naming a host or the point at hand here.

Sure it does. You just said that the unadorned domain node in DNS both should *and* should not have an A record. :-)

there's no point puffing your chest out and wading in here trying to teach zimbra to suck eggs when you don't have a good understanding of how the product works. zimbra has extremely experienced development team who I wager understand dns better than you.

Then why isn't the person who writes the installer talking to them? ;-)

however, i agree with the main point you're trying to make.

Didn't mean to get puffy. Sounded like Brian was trying to teach *me* how to suck eggs, and I like mine scrambled.

i expect [cricket and paul have] got better things to do.

My experience of Hats is that if you're asking a *good* question, The Smart Way, and it's 'their' question, they'll typically give you one, sometimes two go'rounds on the email wheel for free, actually. This is *actually* an Eric Allman question, I suspect, but...

As always with opensource, if you don't like something, don't bitch, FIX IT. Submit a patch with better behaviour. It's been on my todo list for about a year to do this particular patch, just never got round to it cos it's not really that important.

It's an installer. I'm happy to write the patch, but *I* dont' need it anymore. If it's not going to be accepted (and don't get me started on the "we want you to assign your copyright, but we don't want to admit (much) that it's so we don't screw up our commmercial licenses" thing), then why should I write it?

And, if you look at the original posting, that *was* the context in which I asked it.