Bug#878148: cups: Default ServerName wrong/not in sync with manual

[Dominik George <nik@naturalnet.de>]

Hi,

> > I said that I cannot access CUPS from the local network, not from loopback.
> 
> The title of this bug is "Default ServerName wrong/not in sync with manual". 
> I'm not sure I understand whether you think the documentation should be 
> changed, or whether the _code_ should be changed. Could you please clarify?
> 
> From the documentation, you need to have both a network-accessible IP in a 
> `Listen` stanza, as well as the hostnames you want the scheduler to be 
> accesssible to be listed in either `ServerName` and/or `ServerAlias`.
> 
> What I can say is that from the source (scheduler/conf.c, around lines 956 in 
> stable) https://sources.debian.net/src/cups/2.2.1-8/scheduler/conf.c/#L956
> 
> >   else
> >   {
> >     if (gethostname(temp, sizeof(temp)))
> >     {  
> >       cupsdLogMessage(CUPSD_LOG_ERROR, "Unable to get hostname: %s",    
> >                       strerror(errno));
> >       strlcpy(temp, "localhost", sizeof(temp));
> >     }
> >     cupsdSetString(&ServerName, temp);
> … ServerName is set from gethostname(2), which, by their manpages, return the 
> same value as hostname(1), aka uname(2)'s nodename, which you can retrieve 
> from $ uname -n.

Right. Now read the man page:

      ServerName hostname
            Specifies the fully-qualified hostname of the server.  The default is the value reported by the hostname(1) command.

Neither gethopstname(2) nor hostname(1) nor uname(2) return the
*fully-qualified hostname of the server*.

So the default used is NOT the FQDN, while ServerName shall be set to the FQDN.

So: The code should be changed…

> 
> ServerName is set around these lines and there are various heuristics which 
> add ServerAliases to that configuration. All these are logged at the 'debug' 
> level. I've added a patch to log the ServerName cups takes:
> 
> --- a/scheduler/conf.c
> +++ b/scheduler/conf.c
> @@ -891,6 +891,7 @@ cupsdReadConfiguration(void)
>      }
>  
>      cupsdSetString(&ServerName, temp);
> +    cupsdLogMessage(CUPSD_LOG_DEBUG, "Set ServerName %s", temp);

…especially as these heuristics try to generate the base host name by
stripping the domain part from the ServerName, expecting it to be the
FQDN.

> With this in place, and debugging enabled via `cupsctl --debug-logging` (see 
> [0] for a very good documentation), a restart of the server gives me:
> 
> D [12/Oct/2017:17:21:25 +0200] Set ServerName gyllingar
> D [12/Oct/2017:17:21:25 +0200] Added auto ServerAlias gyllingar
> 
> And:
> $ hostname -f
> gyllingar
> 
> What is it that you get?

$ hostname
foo
$ hostname -f
foo.example.com

Still, CUPS only responds to foo, not foo.ezample.com.

(Please mind that your system seems to be misconfigured and does not
return the FQDN with hostname -f!)

> And do you still think there's discrepancy between 
> code and documentation? If so, which one do you think is wrong?

The code is wrong. It should use the FQDN, like reported by hostname -f,
as default for ServerName, probably by resolving the name it got from
gethostbyname() twice (like hostname -f does).

-nik