Your message dated Wed, 8 Mar 2017 19:45:16 +0000
with message-id <08032017194347.847f35b18...@desktop.copernicus.org.uk>
and subject line Re: Bug#612419: cups: manpage about ipv6 support and other
asspects need to be improved
has caused the Debian Bug report #612419,
regarding cups: manpage about ipv6 support and other asspects need to be
improved
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
612419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612419
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: cups
Version: 1.4.5-2
Severity: normal
Tags: ipv6
Hi,
as in subject.
Most problematic is Listen and Allow directivies, which according to manpage
cupsd.conf(5),
have very simple syntax. But there is nothing which actually tells that IPv6
addresses,
or prefixes need to be in squere brackets.
I understand the needed, but it needs to be documented.
Actually in Allow squere brackets de facto would be needed,
as normally squere brackets are added around ipv6 to separate
it from mandatory or optional port, but in case of Allow,
there is no port, so it would on the first try appear
that one do not need to add squere brackets. But actually
they are needed.
Also error message isn't very helpfull.
E [08/Feb/2011:13:31:10 +0100] Bad netmask value 2001:470:111b:625::0/80 on
line 40.
E [08/Feb/2011:13:31:10 +0100] Unknown Location directive Allow on line 40.
wrong netmask?
manpage for cupsd.conf would be MUCH more usefull if each directive there will
be
provided with example, or more precise syntax. Not just "Allow ip-address",
what ip address?, or "Allow ip-address/mm", what is mm?. And actually
it is untrue, as Allow also allows an 'incomplete' ip-address, to describe
easly
subnets (i guess borowed from Apache), like "Allow 149.5.6." being
equicalent to "Allow 149.5.6.0/255.255.255.0".
This is main problem I see with documentation, lack of explicit examples
It would be better as:
Allow ip-address
Allow ip-address/netmask
Allow ip-address/prefix-length
Allow A.B.C.
Allow A.B.
Allow A.
Allow [ipv6-address]
Allow [ipv6-address]/prefix-length
And information that ipv6-address can be written in standard short notation.
Apperantly also things like 10.0.50.50/16 will also be accepted,
without concerns that actuall .50.50 part is completly non needed.
This can be an indicator that administrator specified too wide netmask
(to small prefix-length), thus will for example allow for
more traffic than admin really wanted. I suggest writing warning
to the log, but still supporting this notation, as it is usefull.
Similary for IPv6 addresses, like "Allow [2001:470:111b:625:1::154:2]/64",
have non-zero network part, and should produce warning (in this case
user probably wanted /128 netmask (equivalent also
to not providing "/128" at all).
Also lack of highlights (bold font) in manpage, makes it harder to
distinguish beetwen literals and "user variables".
Examples:
Allow @IF(name)
name? IF?
BrowseProtocols [All] [CUPS] [DNSSD] [LDAP] [SLP]
SystemGroup group-name [group-name ...]
PassEnv variable [... variable]
FontPath directory[:directory:...]
FatalErrors kind [... kind]
FatalErrors all -kind [... -kind]
I guess i do not need to write squere brackets in my cupsd.conf...
and this means each element is optional. I know people
are not stupid, and will know what this means most of the times
(becuase this is the way most manuals are written), but lack of
visual difference beetwen them, make it slightly harder to tell,
what is going on.
This would be especially problematic if syntax for ipv6 addresses,
will be given as they use squere brackets literally. This will make
hard to tell what will this mean:
Allow [ipv6-address]/prefix-length
(it can be interpreted that something like "Allow /64", will be correct,
whetever this is).
I see cupsd.conf tries to be make literals begin from upper letter,
but it is not always true: "Satisfy any", "AccessLogLevel config",
"Allow none".
Also reneming domain.com into example.com would be nice change. :)
Actually it should be changed from
Alllow domain.com
Alllow *.domain.com
into
Alllow domain-name
Alllow *.domain-name
and "Allow *.lan.example.com" given as an example in separate section.
Thanks.
-- System Information:
Debian Release: 6.0
APT prefers stable
APT policy: (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cups depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii bc 1.06.95-2 The GNU bc arbitrary precision cal
ii cups-client 1.4.5-2 Common UNIX Printing System(tm) -
ii cups-common 1.4.5-2 Common UNIX Printing System(tm) -
ii cups-ppdc 1.4.5-2 Common UNIX Printing System(tm) -
ii debconf [debconf-2.0] 1.5.38 Debian configuration management sy
ii ghostscript 8.71~dfsg2-10 The GPL Ghostscript PostScript/PDF
ii libavahi-client3 0.6.27-3 Avahi client library
ii libavahi-common3 0.6.27-3 Avahi common library
ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib
ii libcups2 1.4.5-2 Common UNIX Printing System(tm) -
ii libcupscgi1 1.4.5-2 Common UNIX Printing System(tm) -
ii libcupsdriver1 1.4.5-2 Common UNIX Printing System(tm) -
ii libcupsimage2 1.4.5-2 Common UNIX Printing System(tm) -
ii libcupsmime1 1.4.5-2 Common UNIX Printing System(tm) -
ii libcupsppdc1 1.4.5-2 Common UNIX Printing System(tm) -
ii libdbus-1-3 1.2.24-4 simple interprocess messaging syst
ii libgcc1 1:4.5.1-5 GCC support library
ii libgnutls26 2.8.6-1 the GNU TLS library - runtime libr
ii libgssapi-krb5-2 1.8.3+dfsg-4 MIT Kerberos runtime libraries - k
ii libijs-0.35 0.35-7 IJS raster image transport protoco
ii libkrb5-3 1.8.3+dfsg-4 MIT Kerberos runtime libraries
ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries
ii libpam0g 1.1.1-6.1 Pluggable Authentication Modules l
ii libpaper1 1.1.24 library for handling paper charact
ii libpoppler5 0.12.4-1.2 PDF rendering library
ii libslp1 1.2.1-7.8 OpenSLP libraries
ii libstdc++6 4.5.1-5 The GNU Standard C++ Library v3
ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
ii poppler-utils 0.12.4-1.2 PDF utilitites (based on libpopple
ii procps 1:3.2.8-10 /proc file system utilities
ii ssl-cert 1.0.28 simple debconf wrapper for OpenSSL
ii ttf-freefont 20090104-7 Freefont Serif, Sans and Mono True
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages cups recommends:
ii avahi-daemon 0.6.27-3 Avahi mDNS/DNS-SD daemon
ii cups-driver-gutenprint 5.2.6-1 printer drivers for CUPS
ii foomatic-filters 4.0.5-6 OpenPrinting printer support - fil
ii ghostscript-cups 8.71~dfsg2-10 The GPL Ghostscript PostScript/PDF
Versions of packages cups suggests:
ii cups-bsd 1.4.5-2 Common UNIX Printing System(tm) -
pn cups-pdf <none> (no description available)
ii foomatic-db 20100804-1 OpenPrinting printer support - dat
ii hplip 3.10.6-2 HP Linux Printing and Imaging Syst
pn smbclient <none> (no description available)
ii udev 164-4 /dev/ and hotplug management daemo
-- debconf information:
* cupsys/raw-print: true
* cupsys/backend: ipp, dnssd
--- End Message ---
--- Begin Message ---
On Tue 08 Feb 2011 at 14:05:58 +0100, Witold Baryluk wrote:
> as in subject.
>
> Most problematic is Listen and Allow directivies, which according to manpage
> cupsd.conf(5),
> have very simple syntax. But there is nothing which actually tells that IPv6
> addresses,
> or prefixes need to be in squere brackets.
>
> I understand the needed, but it needs to be documented.
> Actually in Allow squere brackets de facto would be needed,
> as normally squere brackets are added around ipv6 to separate
> it from mandatory or optional port, but in case of Allow,
> there is no port, so it would on the first try appear
> that one do not need to add squere brackets. But actually
> they are needed.
>
> Also error message isn't very helpfull.
>
> E [08/Feb/2011:13:31:10 +0100] Bad netmask value 2001:470:111b:625::0/80 on
> line 40.
> E [08/Feb/2011:13:31:10 +0100] Unknown Location directive Allow on line 40.
>
> wrong netmask?
>
> manpage for cupsd.conf would be MUCH more usefull if each directive there will
> be
> provided with example, or more precise syntax. Not just "Allow ip-address",
> what ip address?, or "Allow ip-address/mm", what is mm?. And actually
> it is untrue, as Allow also allows an 'incomplete' ip-address, to describe
> easly
> subnets (i guess borowed from Apache), like "Allow 149.5.6." being
> equicalent to "Allow 149.5.6.0/255.255.255.0".
>
>
> This is main problem I see with documentation, lack of explicit examples
>
> It would be better as:
> Allow ip-address
> Allow ip-address/netmask
> Allow ip-address/prefix-length
> Allow A.B.C.
> Allow A.B.
> Allow A.
> Allow [ipv6-address]
> Allow [ipv6-address]/prefix-length
>
> And information that ipv6-address can be written in standard short notation.
> Apperantly also things like 10.0.50.50/16 will also be accepted,
> without concerns that actuall .50.50 part is completly non needed.
> This can be an indicator that administrator specified too wide netmask
> (to small prefix-length), thus will for example allow for
> more traffic than admin really wanted. I suggest writing warning
> to the log, but still supporting this notation, as it is usefull.
> Similary for IPv6 addresses, like "Allow [2001:470:111b:625:1::154:2]/64",
> have non-zero network part, and should produce warning (in this case
> user probably wanted /128 netmask (equivalent also
> to not providing "/128" at all).
>
> Also lack of highlights (bold font) in manpage, makes it harder to
> distinguish beetwen literals and "user variables".
>
> Examples:
> Allow @IF(name)
>
> name? IF?
>
>
> BrowseProtocols [All] [CUPS] [DNSSD] [LDAP] [SLP]
> SystemGroup group-name [group-name ...]
> PassEnv variable [... variable]
> FontPath directory[:directory:...]
> FatalErrors kind [... kind]
> FatalErrors all -kind [... -kind]
>
> I guess i do not need to write squere brackets in my cupsd.conf...
> and this means each element is optional. I know people
> are not stupid, and will know what this means most of the times
> (becuase this is the way most manuals are written), but lack of
> visual difference beetwen them, make it slightly harder to tell,
> what is going on.
>
> This would be especially problematic if syntax for ipv6 addresses,
> will be given as they use squere brackets literally. This will make
> hard to tell what will this mean:
>
> Allow [ipv6-address]/prefix-length
>
> (it can be interpreted that something like "Allow /64", will be correct,
> whetever this is).
>
>
>
> I see cupsd.conf tries to be make literals begin from upper letter,
> but it is not always true: "Satisfy any", "AccessLogLevel config",
> "Allow none".
>
>
> Also reneming domain.com into example.com would be nice change. :)
>
> Actually it should be changed from
> Alllow domain.com
> Alllow *.domain.com
> into
> Alllow domain-name
> Alllow *.domain-name
>
>
> and "Allow *.lan.example.com" given as an example in separate section.
Enhancement requests are always welcome in the BTS. However, after six
years and no response it is probably unrealistic to expect the request
to be fulfilled any time soon. The question becomes - should we carry
this bug in the BTS indefinitely? I think not; hence closing. Sorry.
Regards,
--
--- End Message ---
