Diary of a Newbie 1: The domain name

[Baylink]

I'm doing a PE install on RHEL5 (well, really CentOS 5.2, but I won't tell if you won't).

I'm going to document the problems I run into as I go -- take note that I've been running Linux since .99pl12f in 1993 (SLS, for those who really wanted to know), and administering Unix and Linux systems (and email) for even longer than that, back to Tandy Xenix 1.3 or so. So I'm not an idiot... I think. :-)

DNS ERROR resolving MX for benjamin.vicimarketing.com
It is suggested that the domain name have an MX record configured in DNS
Change domain name? [Yes] n


Look! An error message written by someone intimately familiar with teh code!! :-)

How did you try to resolve it? What were you resolving? What, precisely, does that second sentence *mean*? And change which domain name to what?

This all plays to "Zimbra doesn't really expect to be behind a DNAT box", and personally, I don't put anything anywhere else these days, except at gunpoint.

As you can see, I answered "no", which left me with this:

+Admin user to create: admin@benjamin.vicimarketing.com
******* +Admin Password UNSET
+Enable automated spam training: yes
+Spam training user: spam.rkxpgnkac5@benjamin.vicimarketing.com
+Non-spam(Ham) training user: ham.sbmwmtf2l@benjamin.vicimarketing.com
+Global Documents Account: wiki@benjamin.vicimarketing.com
+SMTP host: benjamin.vicimarketing.com


Clearly, only the last of those is correct. The name of the machine != the name of the domain, which != the MX target for the domain.

It would be nice if I didn't have to explain that, but I'll settle for expanding the documentation (and install scripting) so that it's possible to understand what's being asked, and what it's results will be.

Here, let me go restart my install under screen(1), so I can reconnect to it later.... :-}

(The forum timed out, so this might or might not be a duplicate post...)

Oh, and since I interrupted the install, it now thinks the packages are installed... even though I've removed the unpack directory *and* the target directory, and won't run without a key.

Um, where is it looking?

[dwmtractor]

Hey Baylink,

Sorry you didn't get any love earlier. . .been a long week for me. Just wiped out your dupe thread. . .

As to your domain issues, first of all, nobody with any sense is going to try to dissuade you from hiding behind a DNAT/SNAT box. . .I share your opinion that anything else, if not suicide, is at least very poor practice. This is where the split-DNS stuff you will find all over the forum comes into play. Basically, you load bind or bind9 on your Zimbra box, or else you have an internal DNS on another box in your DMZ subnet, and that provides your Zimbra box with (dare I call it) "self-resolution" INCLUDING MX RECORD to the internal (real) IP of your box on the DMZ. Of course, the rest of the world resolves your mailserver to the public IP via DNS that is "out there;" only your DMZ shows the internal DNS.

Second, there is an irritating little element in the install script where it implies to any normal reader (we've probably all been thru this) that it wants your FQDN, when what you should really put in is just your hostname (benjamin in your case?), and in other places just the domain (vicimarketing.com) and never both together. This wiki, while written for a Ubuntu installation, goes over some of these concepts in greater detail and may be helpful to you since you already understand basic Linux concepts.

If further questions come out as you play with this, just post back; despite how quiet it looks this forum really is the place to come for answers.

[Baylink]

Originally Posted by dwmtractor

Sorry you didn't get any love earlier. . .been a long week for me. Just wiped out your dupe thread. . .

Thanks. And I'm in a slow rollout; no hurry this time... thank ghod.

As to your domain issues, first of all, nobody with any sense is going to try to dissuade you from hiding behind a DNAT/SNAT box. . .I share your opinion that anything else, if not suicide, is at least very poor practice.

Good to hear.

This is where the split-DNS stuff you will find all over the forum comes into play. Basically, you load bind or bind9 on your Zimbra box, or else you have an internal DNS on another box in your DMZ subnet, and that provides your Zimbra box with (dare I call it) "self-resolution" INCLUDING MX RECORD to the internal (real) IP of your box on the DMZ.

So, if I'm reading you correctly, what you're saying is:

Public MX: A record of DNAT box public IP. (67.97.mumble)
Private MX: A record of the private internal IP of the actual Zimbra (what, MTA?) server -- the address to which the DNAT box tunnels. (10.55.mumble)

The only rollout problem I see for that is that if I have any internal machines that need to deliver mail inside the domain, and they are currently falling back to a hardcoded default because they can't see our public MX record -- I've just checked this, they can't -- they might pick up that MX and things will then break.

I don't see any other way to do it, though, so it's a risk I'll have to take.

Of course, the rest of the world resolves your mailserver to the public IP via DNS that is "out there;" only your DMZ shows the internal DNS.

Second, there is an irritating little element in the install script where it implies to any normal reader (we've probably all been thru this) that it wants your FQDN, when what you should really put in is just your hostname (benjamin in your case?), and in other places just the domain (vicimarketing.com) and never both together.

I'm not sure if you're talking about that prompt I've already gotten, or something later...

Since I just figured out that the reason it thinks everything is installed is that most of it is RPMs, and I just rpm -e'd everything, I'm about to start over.

To give you an idea of the sort of detail I think is reasonable in an installation walkthrough, take a look at this wiki writeup that I expanded and fleshed out (after about 8 reinstalls in a New Jersey motel room last October :-) for the WebGUI CMS Runtime Environment package.

It doesn't assume you know *anything*, and it explains most of the possible screwups you might encounter at each step, and how you can fix or avoid them.

Yes, I'm doing this because I intend to do a similar writeup here.

If I survive. :-)

This wiki, while written for a Ubuntu installation, goes over some of these concepts in greater detail and may be helpful to you since you already understand basic Linux concepts.

Thanks for the pointer; yes, I think I can generalize.

If further questions come out as you play with this, just post back; despite how quiet it looks this forum really is the place to come for answers.

Oh, they will. :-)

I'll also be FEECHing away over on the developer forum, as you no doubt already noticed.

[dwmtractor]

Originally Posted by Baylink

So, if I'm reading you correctly, what you're saying is:

Public MX: A record of DNAT box public IP. (67.97.mumble)
Private MX: A record of the private internal IP of the actual Zimbra (what, MTA?) server -- the address to which the DNAT box tunnels. (10.55.mumble)

Yes, exactly. And yeah, it's actually the address of the MTA but for most of us that is all that the Zimbra server is. Although it's quite possible to have multiple services on the box (and some of our people do it) Z plays nicest if it's in its own little sandbox.

Originally Posted by Baylink

The only rollout problem I see for that is that if I have any internal machines that need to deliver mail inside the domain, and they are currently falling back to a hardcoded default because they can't see our public MX record -- I've just checked this, they can't -- they might pick up that MX and things will then break.

Not if you load bind9 on your Zimbra box and keep it in a DMZ, and have your internal machines on the LAN subnet have their own DNS which is neither. Nothing else in the world has to point to your Zimbra bind; but Zimbra needs to see that one first and only forwarders for anything else.

Originally Posted by Baylink

'm not sure if you're talking about that prompt I've already gotten, or something later...

Yeah, that one you referenced in your OP is what I'm talking about

Originally Posted by Baylink

To give you an idea of the sort of detail I think is reasonable in an installation walkthrough, take a look at this wiki writeup that I expanded and fleshed out (after about 8 reinstalls in a New Jersey motel room last October :-) for the WebGUI CMS Runtime Environment package.

It doesn't assume you know *anything*, and it explains most of the possible screwups you might encounter at each step, and how you can fix or avoid them.

Hey, someone who believes what I believe about write-ups! Good to know there's more of us out there! That's why I wrote the "Beginners' guide" I pointed you to yesterday.

Best of luck!

[Baylink]

Originally Posted by dwmtractor

Yes, exactly. And yeah, it's actually the address of the MTA but for most of us that is all that the Zimbra server is. Although it's quite possible to have multiple services on the box (and some of our people do it) Z plays nicest if it's in its own little sandbox.

More my point was if your Z install is a separated cluster, it's the *MTA* machine that both DNAT and the internal MX record need to point to... right?

Not if you load bind9 on your Zimbra box and keep it in a DMZ, and have your internal machines on the LAN subnet have their own DNS which is neither. Nothing else in the world has to point to your Zimbra bind; but Zimbra needs to see that one first and only forwarders for anything else.

Bit lost now; this forum does not quote multiple levels deep -- which is a bug, BTW.

Ok; I see what you were replying to.

Hmm. I'm already running "real" split horizon DNS on my two firewalls; I'm not sure I want to run another one on the Z machine itself... unless I have to.

Yeah, that one you referenced in your OP is what I'm talking about

Hey, someone who believes what I believe about write-ups! Good to know there's more of us out there! That's why I wrote the "Beginners' guide" I pointed you to yesterday.

Best of luck!

I still may need it....

Because "@" already has a DNS record on my internal DNS: an A record for the public address of my firewall, necessary to keep my current mailscanner install from puking its guts up.

Hmm... can I have an A and an MX on the same domain "@"?

If not, I may *have* to run an extra server onboard the MTA.

[Baylink]

According to this article, yes, you *can* have an A and an MX for the same node. I probably should have known that...

[dwmtractor]

Originally Posted by Baylink

More my point was if your Z install is a separated cluster, it's the *MTA* machine that both DNAT and the internal MX record need to point to... right?

In my case my Zimbra server IS my MTA (Zimbra installs postfix for MTA with amavisd, clamav, and spamassassin) so it is a distinction without a difference. If you are intending to use a separate MTA I'll have to defer to others who have done this as I truly don't know.

Originally Posted by Baylink

Bit lost now; this forum does not quote multiple levels deep -- which is a bug, BTW.

It used to; they must've changed something recently. I don't like it either

Originally Posted by Baylink

Hmm. I'm already running "real" split horizon DNS on my two firewalls; I'm not sure I want to run another one on the Z machine itself... unless I have to.

Well, bottom line is that your Zimbra machine needs to resolve itself to its own true address--that is, the actual address on the NIC through which it communicates. . .and nothing else (or at the very least nothing outside) can use that address. Running bind9 on the Zimbra box is, IMHO, the simplest, cleanest way to do this, but it's not the only way.

Originally Posted by Baylink

Because "@" already has a DNS record on my internal DNS: an A record for the public address of my firewall, necessary to keep my current mailscanner install from puking its guts up.

Hmm... can I have an A and an MX on the same domain "@"?

If not, I may *have* to run an extra server onboard the MTA.

This is not my area of expertise, but there's documentation here in the wiki of running a split domain for those settings where you're trying to set up Zimbra without torpedoing an existing mailserver on the domain. I think this may provide you with the necessary info. . .???

[Baylink]

Originally Posted by dwmtractor

In my case my Zimbra server IS my MTA (Zimbra installs postfix for MTA with amavisd, clamav, and spamassassin) so it is a distinction without a difference. If you are intending to use a separate MTA I'll have to defer to others who have done this as I truly don't know.

Sorry; my point was that if you have a split/clustered Z install, it's the zimbra-mta machine to which all these (heh) machinations apply.

Well, bottom line is that your Zimbra machine needs to resolve itself to its own true address--that is, the actual address on the NIC through which it communicates. . .and nothing else (or at the very least nothing outside) can use that address. Running bind9 on the Zimbra box is, IMHO, the simplest, cleanest way to do this, but it's not the only way.

That phrasing clouds things up a bit for me again, I'm afraid. Are you talking about what the Z-mta needs to get back when it looks up the MX for the domain? Or just when it looks up an A record for what it thinks it's own FQDN is?

Or will I figure that out when I go read *your* writeup? ;-)

This is not my area of expertise, but there's documentation here in the wiki of running a split domain for those settings where you're trying to set up Zimbra without torpedoing an existing mailserver on the domain. I think this may provide you with the necessary info. . .???

I had actually skimmed that, but didn't have (and it didn't provide) quite enough background...

[Baylink]

Would you go poke the wikimaster? *Logging in* to the wiki causes all pages to be returned as blank; something appears borken.

[dwmtractor]

Originally Posted by Baylink

That phrasing clouds things up a bit for me again, I'm afraid. Are you talking about what the Z-mta needs to get back when it looks up the MX for the domain? Or just when it looks up an A record for what it thinks it's own FQDN is?

Both. The installation script will attempt to validate both a domain and an MX lookup and whine pitiably (or more accurately, turn passive-aggressive and sulk) if it doesn't find them.