CUPS 1.2rc2, troubles during test

[Kurt Pfeifle]

On Sunday 23 April 2006 16:59, Alexander Kern wrote:
> Hello,
> 
> I have various troubles with 1.2rc2.

I'd suggest to checkout current SVN of CUPS; otherwise wait for RC3 --
it should be out soon (non-authoritative personal guessing).

> First of all here are my configurations:
> 
> In office DELL Laptop and network HP LaserJet Series 8000. I can print pretty 
> well. Printer management was not tested, i can complete it only at thuesday.
> 
> At home desktop Athlon 64(native x86-64). 

Did you build the packages yourself? If not, which ones did you use?

See also 

   http://www.cups.org/newsgroups.php?gcups.commit+T 

for all the 70 commits and assigned commit messages that happened since
RC2.

> I cannot print at all. It stops me  
> and I trying from scrath, move old CUPS configuration from SuSE 10.0, 
> reinstall rpm and copy cupsd.conf from default sample.
> 
> My old PIII laptop has rc2 CUPS too. It has not any problems.
> 
> Web interfaces on x86-64 cancels alls actions with exception of 
> "http://localhost:631/printers/" with "413 Request Entity Too Large". I have 
> tryed add printer, delete and modify printer on old CUPS configuration and on  
> remote CUPS server.
> 
> One more interesting question, trying to add new printer testwise with 
> kaddprinterwizard communicating over socket brings another error.
> kdeprint: ==========
> kdeprint: Request to /var/run/cups/cups.sock:631

Well, it looks certainly wrong to use ":631" for a domain socket
connection. Whoever "fixed" that code did not completely fix it :-)

According to Mike, if we use only the public CUPS API, there should
not be any problem.

Are you aware that CUPS-1.2 has added "Unix Domain Socket" support
for localhost printing? (You know that domain sockets are different
from the "AppSocket" connections that use TCP/IP port 9100 of a
*network* socket?)

I wasn't myself fully sure about how it is supposed to work exactly,
from a user/configuration point of view. I asked Mike, and now I
know :-)

In cupsd.conf:

  "Listen /path/to/socket"

In client.conf (if client.conf is in use at all!):

  "ServerName /path/to/socket"

The client code, as before (in CUPS-1.1.x) checks for a default server
first. It uses this order:

 first,  it looks in /etc/cups/client.conf;
 second, it looks in ~/.cups/client.conf (or ~/.cupsrc, which is now
         deprecated);
 third,  it checks the CUPS_SERVER environment variable.

If it finds no default "server" (which can now even be represented by 
a unix domain socket in case of local printing), it lastly checks for
the compiled-in default domain socket path; if it exists, it uses it
-- if not, it uses localhost:631.

Note again, that unix domain socket support is *only*, *only*, *only* 
for local clients printing to local queues via the local cupsd. It
*never* can be used to print to a remote cupsd. (Samba printing also
may be *local* printing from the point of view of CUPS, if smbd and 
cupsd are running on the same host -- even if the Windows clients 
access the smbd server process over the network).

Last note: you do not need to manually create unix domain socket 
paths yourself; they are auto-created by the cupsd you run (it reads
its config file :-); however, cupsd of course needs write permissions 
to the directory they are supposed to live in. 

> kdeprint: ==========
> kdeprint: State = 0x0
> kdeprint: ID = 0x1
> kdeprint: Operation = 0x4003
> kdeprint: Version = 1.1
> kdeprint:
> kdeprint: attributes-charset (0x47) = utf-8
> kdeprint: attributes-natural-language (0x48) = de
> kdeprint: printer-uri (0x45) = 
> ipp:///var/run/cups/cups.sock/printers/tmpprinter_Qg1kpThh

the "ipp://" prefix also looks wrong in case of a unix domain socket
connection.

> kdeprint: device-uri (0x45) = parallel:/dev/lp0
> kdeprint: requesting-user-name-allowed (0x42) = all
> kdeprint: printer-info (0x41) =
> kdeprint: printer-location (0x41) =
> kdeprint: ==========
> kdeprint: Answer
> kdeprint: ==========
> kdeprint: State = 0x3
> kdeprint: ID = 0x1
> kdeprint: Status = 0x400
> kdeprint: Status message = client-error-bad-request
> kdeprint: Version = 1.1
> kdeprint:
> kdeprint: attributes-charset (0x47) = utf-8
> kdeprint: attributes-natural-language (0x48) = de
> kdeprint: status-message (0x41) = The printer-uri must be of the form 
> "ipp://HOSTNAME/printers/PRINTERNAME".

Of course, this kdeprint error message was designed at a time when
we had no idea that CUPS-1.2 would start supporting printing over
local domain sockets.

> Is socket connection not capable of it.

It's kdeprint that does not know about domain sockets.

> read httpSeparateURI() and trying
> "file:/var/run/cups/cups.sock/printers/tmpprinter_Qg1kpThh"
> "file:/printers/tmpprinter_Qg1kpThh"
> "/printers/tmpprinter_Qg1kpThh" do not work.

Sorry, I can't help on the C++ code basis -- only from this higher,
abstraction level.

Cheers,
Kurt