Printing in KDE4 (Was: Fwd: Re: Requesting feature freeze exemption for Gwenview)

[Kurt Pfeifle]

Aaron J. Seigo wrote:
> On Sunday 02 September 2007, Thomas Zander wrote:
>> If someone that is knowledgeable about kdeprints internals can stand up
>> and give a detailed way forward, that would be a great start.
>
> indeed. for all the "it's broken, oh no!" messages i really don't know what is 
> broken and what isn't, 

I'll dig into Bugzilla a little bit for you (that I can do even while on
Windows), and summarize a few bits...

( ... *digging* ... )

> partly because i'm not sure what every feature is 
> supposed to do in the first place ;)

/stupid_me though that the many "WhatsThis" in kprinter did somehow explain
at least 50% of them....


Anyway, for a start, have a look here:

   # unsupported CUPS 1.1.x features:
   http://bugs.kde.org/show_bug.cgi?id=130423

   # unsupported CUPS 1.2.x features:
   http://bugs.kde.org/show_bug.cgi?id=130425

   # unsupported CUPS 1.2.x features:
   (I'll try to add a bug report for that in the next couple of days)
  
=======================================================================

The most important one however (IMHO), which seems to break printing
for quite a lot of KDEPrint users, is the "unix domain socket" support
in CUPS 1.2.x

Let me explain:


  * In CUPS 1.1.x you could only have cupsd.conf (one or more) state-
    ments like (for TCP/IP + UDP socket connections):

      Listen localhost:631
      Listen 10.162.7.8:21631
      Listen [::1]:631
      Listen *:631         # This one only, while no other is present


  * In CUPS 1.2.x support for unix domain socket connections was added
    (these ones work for local printing only of course, and do speed it
    up, make it more comfortable, and more secure), where you can add
    (or exclusively use) one statement like this:

      Listen /var/run/cups/cups.sock
      Listen /var/run/cups/whatevername.cupssock

    The socket device file will be automatically created by cupsd upon
    starting up, with the correct permissions. Local authentication can
    then also be handled by automatically generated certificates (some-
    thing kprinter also doesn't seem to understand).

Unix domain socket will be used by any local printsystem client (these
are, in the first place, the CUPS commanline utilities like lp, lpr,
lpstat, lpoptions, lpadmin...) to connect to the local CUPS server if
the env var CUPS_SERVER does not contain "localhost" or "10.162.7.8",
but "/var/run/cups/cups.sock".

Now, users can of course configure their cupsd to *exclusively* use
a unix socket (and hence, disallow any remote connection from *any*
possible remote client, effectivly blocking any possible DoS attack
or worse. That may also disable the CUPS web interface, of course).

I dunno how current 3.5.7 kprinter and kjobviewer are behaving. Last
I could look, it was completely non-functional for printing or job
management if cupsd was set up like this.

At the very least, the KDEPrint UI should support the setting of the
connection to a local cupsd via a domain socket. Look at the interface
of

       kaddprinterwizard --kdeconfig
   --> go to "CUPS Server"

(I hope I quote this correctly from my memory), and notice how you can
only set "host" and "port". This should have *both*, a "host:port" part
and a "/path/to/whatever/sockfile" part to use (mutually exclusive, of
course). When I tried to put the socket file path into the host field
and keep the "port" field empty in the past (different consecutive re-
leases of KDE 3.5.x), kprinter crashed...., or it interpreted the path
as a hostname...., or it auto_added a port "0" or "631" to the env var
(it tried to use CUPS_SERVER=/path/to/whatever/sockfile:631")...  In
any case, it didn't print  :-(

I don't know if any of the more "security conscious" distros do use
this setting as their installation defaults yet... but it would break
KDE Printing completely.
 

=======================================================================

Or pick one or more of the easier ones here:

http://bugs.kde.org/buglist.cgi?product=kdeprint&component=general&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
http://bugs.kde.org/buglist.cgi?product=kcontrol&component=kcmprintmgr&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany 
---
Infotec Deutschland GmbH
Hedelfingerstrasse 58
D-70327 Stuttgart
Telefon +49 711 4017-0, Fax +49 711 4017-5752
www.infotec.com
Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen
Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398

Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen.
Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung.
This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of this communication, in whole or in part, is not permitted. Any views or opinions presented are those of the author and (unless otherwise specifically stated) do not represent those of Infotec Deutschland GmbH or their directors or officers; none of whom are responsible for any reliance placed on the information contained herein. Although reasonable precautions have been taken to ensure that no viruses are present, all liability is excluded for any loss or damage arising from the use of this email or attachments.
For further information please see our website at www.infotec.com or refer to any Infotec office.