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
