Bug in 2.7.0 pre 14 and hostname

Mark Martinec Mark.Martinec+amavis at ijs.si
Mon Mar 28 18:04:49 CEST 2011


> 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.
> uname
>     Get name of current operating system.
>     ($sysname, $nodename, $release, $version, $machine) =
>       POSIX::uname();
> 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.


More information about the amavis-users mailing list