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.
Le jeudi, 12 octobre 2017, 16.34:48 h CEST Dominik George a écrit :
> 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
On Thu 12 Oct 2017 at 16:34:48 +0200, Dominik George wrote:
> >CUPS' behaviour is intentional. It rejects requests addressed to the
> >system's FQDN host which are received over the local loopback
> >interface.
> >127.0.1.1 uses the loopback interface.
>
> Good thing I do not route 127.0.0.0/8
>CUPS' behaviour is intentional. It rejects requests addressed to the
>system's FQDN host which are received over the local loopback
>interface.
>127.0.1.1 uses the loopback interface.
Good thing I do not route 127.0.0.0/8 in my network - that wouldn't work anyway.
I said that I cannot access
On Thu 12 Oct 2017 at 14:50:20 +0200, Dominik George wrote:
> > Does either 127.0.0.1 or 127.0.1.1 in /etc/hosts map to your FQDN?
>
> The base host name of the system is resolvable to its FQDN and
> `hostname -f` returns the correct FQDN.
>
> Yet, as reported, CUPS only accepts the base name
> Does either 127.0.0.1 or 127.0.1.1 in /etc/hosts map to your FQDN?
The base host name of the system is resolvable to its FQDN and
`hostname -f` returns the correct FQDN.
Yet, as reported, CUPS only accepts the base name as reported by
`hostname`.
-nik
On Thu 12 Oct 2017 at 12:18:51 +0200, Dominik George wrote:
> Hi,
>
> >> What I report - and what is a fact - is that CUPS as installed from
> >> the Debian package does NOT WORK under normal network conditions,
> >> because it REFUSES to accept requests under its own FQDN.
> >>
> >> That the
Hi,
>> What I report - and what is a fact - is that CUPS as installed from
>> the Debian package does NOT WORK under normal network conditions,
>> because it REFUSES to accept requests under its own FQDN.
>>
>> That the docs tell it should accept those requests is another part of
>> the bug.
>
On Wed 11 Oct 2017 at 23:25:48 +0200, Dominik George wrote:
> >If you feel there is an upstream issue in the documentation there is
> >
> > https://github.com/apple/cups/issues/new
>
> Have you read devref? It's your responsibility as package maintainer
> to forward bugs upstream.
I am not a
Hi,
>If you feel there is an upstream issue in the documentation there is
>
> https://github.com/apple/cups/issues/new
Have you read devref? It's your responsibility as package maintainer to forward
bugs upstream.
On Wed 11 Oct 2017 at 20:59:24 +0200, Dominik George wrote:
> Control: reopen -1
>
> On Wed, Oct 11, 2017 at 07:35:25PM +0100, Brian Potkin wrote:
> > It is common to use manualpage(x) as a shorthand to instruct a user to
> > run the command 'man x manualpage'. Following the advice in
Control: reopen -1
On Wed, Oct 11, 2017 at 07:35:25PM +0100, Brian Potkin wrote:
> It is common to use manualpage(x) as a shorthand to instruct a user to
> run the command 'man x manualpage'. Following the advice in hostname(1)
> does result in the fully-qualified hostname being displayed when
Package: cups
Version: 2.2.4-7
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- From cups.d(5):
ServerName hostname
Specifies the fully-qualified hostname of the server. The default
is the value reported by the hostname(1) command.
This is plain wrong in
13 matches
Mail list logo
