[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "hostname" question during Debian installation

>> I'm going to try it too.
> Ha! Beat you to it! :-)


I'd forgotten about this hostname and postfix business until your
email arrived last Monday but I haven't had the time to do my (far
less thorough) test.

On Sun, Feb 19, 2012 at 4:46 PM, Bob Proulx <bob@proulx.com> wrote:
> Tom H wrote:
>> >> Bob Proulx wrote:

>> AFAIR, "myhostname" is "/etc/hostname"
> Not quite. For Debian's Postfix configuration the postfix myhostname
> variable is set to the fqdn in /etc/postfix/main.cf. Postfix requires
> myhostname to be the fqdn. The default value for Postfix is to use
> the value of `hostname`. However in Debian the default hostname is
> the short hostname without the domain name. Therefore Postfix's
> default of `hostname` isn't suitable and must be supplemented by
> setting the FQDN explicitly.
> Well... What I said wasn't quite true. It is the summary of the
> overall result. What Postfix actually does is somewhat circular.
> Here are the official docs and a somewhat longer explanation.
> mydomain (default: see "postconf -d" output)
>   The internet domain name of this mail system. The default is to
>   use $myhostname minus the first component, or "localdomain"
>   (Postfix 2.3 and later). $mydomain is used as a default value for
>   many other configuration parameters.
> myhostname (default: see "postconf -d" output)
>   The internet hostname of this mail system. The default is to use
>   the fully-qualified domain name (FQDN) from gethostname(), or to
>   use the non-FQDN result from gethostname() and append
>   ".$mydomain". $myhostname is used as a default value for many
>   other configuration parameters.
> If not set then it sets mydomain from the fqdn obtained from hostname
> or to localdomain if that isn't a fqdn.  On Debian with a short
> hostname set that means mydomain always defaults to localdomain.
> If not set then it sets myhostname from the non-fqdn obtained from
> hostname and appends mydomain. On Debian with a short hostname that
> means myhostname always defaults to somename.localdomain. And if the
> hostname was chosen to be localhost then it would default to
> localhost.localdomain which is one consistent and desirable strategy
> for thin client systems without a network and without a network domain
> name.
> [Postfix was born on systems where the hostname was normally set to
> the fqdn. In that environment the above makes a lot of sense. On
> Debian with the short hostname it means that myhostname should always
> be set to provide that supplemental domain name information.]

I set "/etc/hostname" to the fqdn so my memory was correct but my
setup non-standard. Apologies for the misinformation!

>> and "myorigin" is "/etc/mailname".
> Yes. If an MTA has been installed. That file does not exist if no
> MTA has been installed.
>> What I find somewhat weird is that when you install Debian,
>> "/etc/hostname" and "/etc/mailname" are the same.
> They are only the same if you choose a fqdn for the hostname. By your
> comment I read that it implies that you do choose a fqdn for your
> hostnames? (And that you always choose either "Standard system" or
> otherwise install an MTA?) That is why they would be the same for
> you. If you choose a short name for the hostname, which is the worded
> with recommendation from the debian-installer and so most people
> probably choose it, then they are different. /etc/hostname will be
> the short name and /etc/mailname will be the fqdn.

I usually use preseed with
d-i netcfg/get_hostname string box
d-i netcfg/get_domain string company.internal
but then overwrite "/etc/hostname" with the fqdn in "late_command" and
install various packages starting with
tasksel tasksel/first multiselect standard
I'll have to try
d-i netcfg/get_hostname string box.company.internal

>> What I find somewhat weird is that when you install Debian,
>> "/etc/hostname" and "/etc/mailname" are the same.
>> So if it's "box.company.internal" and bob runs "mail tom", bob's
>> address'll be "bob@box.company.internal".
> Yes. Seems reasonable to me. That is exactly what I want. It is
> traditional BSD/Unix behavior.

But the address should be "bob@company.internal"!

>> There was a debian-devel thread where there was an argument about
>> whether "/etc/mailname" should be "box.company.internal" or
>> "company.internal".
> Oh! Well... If you want address masquarading then I think that
> should be an explicit choice. I wouldn't default to address
> masquarading by default. That would be wrong for many environments.
> It assumes that an environment has a central mail relay to handle mail
> for the entire domain and it routes all mail through that central mail
> relay. But in a simple environment with a few machines (or several
> thousand) that wants email to route directly from machine to machine
> then that is the wrong configuration. I have environments both ways.
> It is easy enough to set up address masquarading if desired.
> Either set the local domain in /etc/mailname for an MTA agnositc
> solution OR for postfix explicitly set:
> masquerade_domains = example.com
> masquerade_exceptions = root
> It would be perfectly nice if the package installation dialog were to
> ask the user if they want to set up address masquerading and to do it
> automatically. But for anyone who wants it the configuration is very
> easily accomplished with one of the above. I prefer to leave
> /etc/mailname along and to configure postfix explicitly. Then I can
> control over masquerade_classes and local_header_rewrite_clients too.

IIUC, what you mean by masquerading is that if you send an email from
"box.company.internal", the email address is "bob@company.internal"
rather than "bob@box.company.internal". I've never worked in or set up
an environment where the sender's address is
"bob@box.company.internal". But this explains why you didn't think
"bob@box.company.internal" above was wrong.

Anyway, I don't think that their argument was about masquerading; it
was about what the canonical form of "/etc/mailname" should be.

>> If you you do a regular install or don't use a preseed that installs
>> postfix, you'll have exim4 by default.
> Yes.
>> You can then change "/etc/hostname"
> No. Changing /etc/hostname has no effect for postfix. That is only
> used by the /etc/init.d/hostname.sh script. The postfix postinst
> script does:
>      mailname=$(hostname --fqdn 2>/dev/null || echo localdomain)
> And that uses the hostname command coupled with DNS to do a lookup of
> the hostname to get an IP address and then a reverse lookup of that to
> get a name associated with it. I disapprove of that process because
> it doesn't work in non-typical configurations such as machines with
> multiple network cards and with multiple IP addresses bridging
> different domains. But that is what it does.

I hadn't thought of looking at the postinst script. I wish that I
hadn't run "hostname $(cat /etc/hostname)" after changing
"/etc/hostname" because I'd have noticed that the hostname hadn't been
taken into account by the postfix install...

"dpkg-reconfigure postfix" doesn't change "myhostname" either with a
prompt for a hostname or through a "hostname" call so if you change
the box's hostname, you have to edit "/etc/postfix.main.cf" by hand.

>> and "/etc/mailname", install postfix, and see what gets pulled in as
>> "myhostname" into "/etc/postfix/main.cf".
> Changing mailname doesn't really have an effect on the
> /etc/postfix/main.cf configuration. Because there is a Debian
> specific patch to in enable reading myorigin from a file. So it has
> an effect only through the patched code that pulls in the value
> dynamically when postfix starts from /etc/mailname instead of needing
> to specify myorigin in the main.cf file explicitly.

I don't follow. Changing "/etc/mailname" changes "myorigin" because of
that patch. (I usually change "myorigin = /etc/mailname" to its actual
value on my boxes...)

Anyway, I was only suggesting the "mailname" change because on my
boxes "hostname" and "mailname" are the same and I just wanted to
ensure that they were different to trace what info the installer is
picked up from where by the installer.

Reply to: