Debian argument.. postfix hostname
in [Postfix]
|
From: Wietse Venema on 3 Jun 2010 14:26 Moe: > The right way, as explained by Mike Paul in that ticket, would be to > call gethostbyname() on the return value of gethostname() and then split > the result of *that* into hostname and domainname. That would be AN INCREDIBLY STUPID IDEA, causing all mail processes to hang when the network is down and the hostname is not in /etc/hosts. Wietse
From: Moe on 3 Jun 2010 14:26 Wietse Venema wrote: > Moe: > [ Charset ISO-8859-1 unsupported, converting... ] >> Wietse Venema wrote: >>> Matt Hayes: >>>> Yes.. I know this has come up quite a bit, but on freenode in #postfix >>>> this discussion once again erupted when someone mentioned a bug in >>>> postfix and referencing this: >>>> >>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741 >>> They are talking about an eight-year old version of Postfix. >> I was the guy complaining on IRC, so I'd like to jump in and clarify: >> >> * The bug is still present in 2.7.0, which is not 8 years old >> >> * I think Mike Paul explains the problem pretty well on that ticket. >> >> * The bug is not debian specific and not triggered by doing anything >> "special" other than leaving myhostname and mydomainname out of >> main.cf. >> >> The problem boils down to postfix expecting 'gethostname()' to return >> a FQDN. This not the case on a properly configured linux host, >> regardless of the distribution (this is not debian specific). >> >> I apologize if it's actually a debian patch that introduced this >> behaviour, but from what I gather this is also how mainline postfix does it. >> >> If postfix goes to guess the FQDN when it isn't hardcoded in >> main.cf then it could just as well do it right, no? >> >> The right way, as explained by Mike Paul in that ticket, would be to >> call gethostbyname() on the return value of gethostname() and then split >> the result of *that* into hostname and domainname. > > If this is a non-debian bug then I would like to see a bug report > that can be reproduced on a non-Debian host. > > This is what happens on my non-Debian box when the kernel hostname > is not FQDN: > > # The kernel hostname, as returned by gethostname(2) > tail% uname -n > tail > > # The default mydomain "localdomain" when the kernel hostname is not FQDN. > tail% postconf -d mydomain > mydomain = localdomain > > # The default myhostname, created from gethostname(2) and $mydomain. > tail% postconf -d myhostname > myhostname = tail.localdomain > > As you see there is no guessing at all involved here. Try to extend your procedure like so: * Make sure /etc/hosts has something like: 127.0.0.1 tail.call tail * 'hostname' should return: tail * 'hostname -f' should now return: tail.call * 'postconf -d mydomain' will still return: localdomain Cheers, Moe
From: Moe on 3 Jun 2010 14:32 Wietse Venema wrote: > Moe: >> The right way, as explained by Mike Paul in that ticket, would be to >> call gethostbyname() on the return value of gethostname() and then split >> the result of *that* into hostname and domainname. > > That would be AN INCREDIBLY STUPID IDEA, causing all mail processes > to hang when the network is down and the hostname is not in /etc/hosts. Well, that's what 'hostname -f' does and, by my understanding, the only proper way to figure out the FQDN. Remember we're talking about the case of auto-detection here - if someone is not willing to take that risk then they should hardcode 'myhostname' and 'mydomainname' in main.cf, no? Moreover I'd suggest that postfix may very well accept a FQDN from gethostname() if that returns a value that contains dots. That way people who prefer it that way can have theirs, and people who take 'gethostname()' literally get theirs, too. Cheers, Moe
From: Victor Duchovni on 3 Jun 2010 14:33 On Thu, Jun 03, 2010 at 08:26:16PM +0200, Moe wrote: > * Make sure /etc/hosts has something like: > 127.0.0.1 tail.call tail > > * 'hostname' should return: tail > * 'hostname -f' should now return: tail.call > * 'postconf -d mydomain' will still return: localdomain Which is correct behaviour. Here is the Postfix get_hostname() function, read it carefully: char namebuf[MAXHOSTNAMELEN + 1]; /* * The gethostname() call is not (or not yet) in ANSI or POSIX, but it is * part of the socket interface library. We avoid the more politically- * correct uname() routine because that has no portable way of dealing * with long (FQDN) hostnames. * * DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION. IT BREAKS MAILDIR DELIVERY * AND OTHER THINGS WHEN THE MACHINE NAME IS NOT FOUND IN /ETC/HOSTS OR * CAUSES PROCESSES TO HANG WHEN THE NETWORK IS DISCONNECTED. * * POSTFIX NO LONGER NEEDS A FULLY QUALIFIED HOSTNAME. INSTEAD POSTFIX WILL * USE A DEFAULT DOMAIN NAME "LOCALDOMAIN". */ if (my_host_name == 0) { /* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */ if (gethostname(namebuf, sizeof(namebuf)) < 0) msg_fatal("gethostname: %m"); namebuf[MAXHOSTNAMELEN] = 0; /* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */ if (valid_hostname(namebuf, DO_GRIPE) == 0) msg_fatal("unable to use my own hostname"); /* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */ my_host_name = mystrdup(namebuf); } return (my_host_name); -- Viktor.
From: Moe on 3 Jun 2010 14:36
Victor Duchovni wrote: > On Wed, Jun 02, 2010 at 10:46:47PM -0400, Matt Hayes wrote: > >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741 >> >> Now, I'm not all that bright on how postfix sorts out the hostname, and >> frankly, I don't care, but I don't like people saying its a 'bug' when I >> have no problems following configuration directives. >> >> Can someone PLEASE explain this in clear terms as to what they are >> complaining about? > > An MTA needs a stable set of names for the domains listed in mydestination, > so that locally originated mail delivered locally is repliable. A laptop > with a DHCP-based FQDN is not a good candidate for defaulting the local > domain to the (volatile) FQDN of the host. > > Setting myhostname to "shortname.localdomain" is FAR preferable to picking > up some random DHCP (or reverse DNS lookup) supplied domain and becoming > an open relay for sub-domains of your ISP's domain or being unable to > reply to previously delivered local email. Said laptop should probably hardcode 'myhostname' and 'mydomainname' in main.cf. > In addition, Postfix operates correctly on stand-alone hosts, that > are not networked delivering local email between local users. There > must not be network dependencies in local mail delivery. > > Operating Postfix on a laptop typically requires some of the configuration > options listed in SOHO_README.html. > > The authors of the bug report have not thought this through. The bug > report is spurious. > > If they want the O/S distribution to fully configure a SOHO Postfix during > system installation, the Debian laptop profile would have to ask the user > for a list of user accounts and their mappings to external ISP mailboxes, > as well as submission server settings and passwords, ... This is a lot > of complexity to deal with at install-time. > > Far simpler to just deliver all local (cron, ...) mail locally, and > to expect the laptop user to use Thunderbird, Evolution, ... rather > than mutt or Pine via a local Postfix. To clarify again: I'm not coming from the laptop angle, I just happen to have been bitten by the same problem. My point is: When 'myhostname' and 'mydomainname' are left out of main.cf then postfix makes an attempt to auto-detect them. This auto-detection does not currently follow what other tools like 'hostname' do, and not what the man-pages of gethostname()/uname(), getdomainname() suggest. You suggest this auto-detection is deliberately done wrong to protect users on misconfigured hosts from themselves. I'd argue this is a bad trade-off, as it forces people that *have* properly configured hosts to duplicate their FQDN in main.cf - which would not be required if the auto-detection worked as expected. Anyways, in order not to break backwards compatibility, how about leaving the default behaviour as is, but introducing something like 'myhostname = $auto', 'mydomainname = $auto' (or whatever magic value that can not be a real hostname) which then does the "full" hostname detection the same way that 'hostname -f' does? Cheers, Moe |