Bug in 2.7.0 pre 14 and hostname
quanah at zimbra.com
Mon Mar 28 18:45:14 CEST 2011
--On Monday, March 28, 2011 6:04 PM +0200 Mark Martinec
<Mark.Martinec+amavis at ijs.si> wrote:
>> 2.7.0 pre 14 expects "hostname" to return a fully qualified hostname
>> value, but that is not correct. That is what "hostname -f" does. This
>> causes amavis to fail to start on correctly configured systems.
> It is no different than 2.6.4 and earlier, no changes in this area.
> I'm reluctant to change what used to work for most users for so long.
> If the default is not appropriate, one should set the $myhostname
> in a config file. It is probably sensible to do that explicitly even if
> a default is fine.
>> I see specifically it is using POSIX::uname, even though the
>> documentation says it is very unreliable. I would advise not using it.
>> Get name of current operating system.
>> ($sysname, $nodename, $release, $version, $machine) =
>> Note that the actual meanings of the various fields are not that well
>> standardized, do not expect any great portability. The $sysname might be
>> the name of the operating system, the $nodename might be the name of the
>> host, the $release might be the (major) release number of the operating
>> system, the $version might be the (minor) release number of the operating
>> system, and the $machine might be a hardware identifier. Maybe.
> Only the second field ($nodename) is used. It may or may not be a FQDN -
> if it isn't, a warning with an advice is produced on startup.
> If hostname(1) produces a more sensible result, one can place a:
> $myhostname=qx(hostname -f); chomp $myhostname;
> into amavisd.conf.
That's what I've ended up doing. The default behavior will fail on any
Debian/Ubuntu type of system, since they set it to the shortname.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
More information about the amavis-users